Группа исследователей из Мичиганского университета опубликовала (http://web.eecs.umich.edu/~jackjia/material/open_euro17.pdf) доклад о безопасности мобильных приложений для платформы Android, которые открывают сетевые порты в слушающем режиме и принимают на них соединения. Отмечается, что обработка внешних сетевых запросов создаёт угрозу для безопасности мобильных устройств, которая обычно упускается из виду из-за не серверной специфики мобильных приложений. Исследователи разработали специализированную утилиту OPAnalyzer для статического анализа кода, которая выявляет открытие сетевых портов и оценивает наличие типовых уязвимостей в реализации.
Проверив более 100 тысяч приложений из каталога Google Play были выявлены 1632 программы, принимающие сетевые соединения, половина из которых насчитывает более 500 тысяч загрузок. Исследователи пришли к выводу, что почти половина всех обработчиков сетевых соединений незащищена и может быть использована для организации удалённых атак. Всего при автоматизированной проверке было выявлено 410 уязвимых приложений и 956 потенциальных методов эксплуатации уязвимостей. Вручную было подтверждено наличие уязвимостей в 57 приложениях, в том числе очень популярных, насчитывающих от 10 до 50 млн загрузок, и предустанавливаемых на смартфоны некоторых производителей.
Выявленные уязвимости, через отправку запросов на открытый приложением сетевой порт, позволяют получить доступ к контактам и фотографиям, перехватить параметры аутентификации, установить вредоносное ПО, выполнить свой код на устройстве или отправить SMS на платный сервис. Уязвимости разделены на две категории - ошибки реализаций (например, отсутствие экранирования спецсимволов и ".." в путях) и вредоносные закладки (например, вшитый в приложения инженерный пароль для удалённого доступа).
По решаемым задачам обработчики внешних соединений в мобильных приложениях разделены на пять категорий: организация совместного доступа к данным (69.3%), прокси-сервисы (6.3%), удалённое выполнение операций (6.5%), приём VoIP-вызовов (2.3%) и приложения на базе платформы PhoneGap (14.6%). 60% уязвимостей при организации совместного доступа к данным связаны с ненадлежащим механизмом аутентификации клиента или её отсутствием. Основная проблема с прокси, которые обычно применяются в таких приложениях как фильтры содержимого и блокировщики рекламы, связана с ненадлежащим контролем доступа, что может использоваться как усилитель для DDoD-атак, заметания следов или выделения прокэшированного контента.
Удалённое выполнение операций связано с предоставлением интерфейсов для выполнения определённых действий на телефоне, например, отправки SMS с ПК или обращения к хранилищу. Гибридные приложения на базе фреймворка PhoneGap (Apache Cordova) разделены на бэкенд и фронтэнд, который оформляется на JavaScript/HTML5. Обработчик PhoneGap должен привязываться к внутреннему сетевому интерфейсу, но по ошибке часто прикрепляется и к внешнему интерфейсу, при этом запросы аутентифицируются по UUID и вероятность атаки через PhoneGap оценивается как маловероятная.Для демонстрации возможных методов эксплуатации исследователи подготовили (https://sites.google.com/site/openportsec/) несколько сценариев атак:
- Доступ (https://sites.google.com/site/openportsec/home/threat-model/...) к фотографиям атакующим в локальной сети, выполнившим сканирование доступных в сети устройств:
- Доступ (https://sites.google.com/site/openportsec/home/threat-model/...) к фотографиям из вредоносного приложения, имеющего только право установки сетевых соединений:- Инициирование (https://sites.google.com/site/openportsec/home/threat-model/...) отправки платных SMS при клике на ссылку в браузере:
- Перехват (https://sites.google.com/site/openportsec/home/attack-airdroid) параметров аутентификации при работе пользователя с внешним сервисом:
URL: https://www.wired.com/2017/04/obscure-app-flaw-creates-backd.../
Новость: http://www.opennet.dev/opennews/art.shtml?num=46472
Я правильно понимаю, что для создания слушающего сокета в Android достаточно обычных полномочий на создание сетевых соединений, без разделения для listen и connect?
> Я правильно понимаю, что для создания слушающего сокета в Android достаточно обычных
> полномочий на создание сетевых соединений, без разделения для listen и connect?а какая разница? Идиотская схема "безопасности" андроида все равно не позволяет пользователю решать, какие на самом деле приложению можно дать права, а без каких оно на его устройстве вполне может и обойтись.
Проблема-то не в слушающем сокете, а в том что уродцу, который его создает, вообще нехрен рыться в фотках и тем более отправлять sms, количество программ, которым дан доступ к телефонному модулю, я бы урезал ровно до двух, запретив их прямой вызов из любых других - если бы имел такую возможность.
А что к нему приходит вдруг кто-то не тот - так я и "того", в общем-то, видеть не особенно рад.Эту -то "проблему" легко и просто решает ручная настройка iptables. Проблему идиoтов-гуглоидов, написавших изначально бессмысленную систему разграничения прав (потому что "модель угроз - не, не слышали") решить невозможно (всякие exPosed - а вы их верифицировали, да? Или "вот патчик хз какого анона с 4pda, с ним встает, давай-давай, скорее"? Разграничить доступ к fs, даром что это ext4 с атрибутами-шматрибутами - вообще никак и ничем)
Ставьте винду. Корпорация зла, почему-то, решила что именно тyпoй пользователь, а не гени[т]альный автор софта, имеет право решать, каких доступов какой апликухе выдать.
Но вы ведь вместо этого купите новый самсунг, да?
>Эту -то "проблему" легко и просто решает ручная настройка iptables.Ключевое слово "ручная", а не "легко". Вообще, даже специалисту в этом вопросе, чтобы правильно настроить файрволл для приложения потребуется приличное кол-во времени, особенно, если приложение работает на мульти-протоколах (например, SIP).
Чтобы это дело автоматизировать приложение нужно запихивать в инкубатор, снимать логи всех возможных соединений и после этого выдавать выхлоп специалисту. Потому, что в наш век уже редко встретишь сервисы с 1 айпи, и вопрос о том какое правило вкатывать может решить только человек: один айпи, сеть (скажем /23) или вообще весь интернет (0.0.0.0). Одна ошибка в выборе (злоумышленник может быть даже в злощастной сети /30) и все пойдет по колее.
Походу вы настраивали файрвол для демонов, а не для клиентских программ и уж тем более не для сложных клиентских программ, которые еще общаются на 127.0.0.1 с собой (а могут общаться и не с собой). Поэтому для вас все "легко и просто".
>>Эту -то "проблему" легко и просто решает ручная настройка iptables.
> Походу вы настраивали файрвол для демонов, а не для клиентских программ и
> уж тем более не для сложных клиентских программ, которые еще общаются
> на 127.0.0.1 с собой (а могут общаться и не с собой).
> Поэтому для вас все "легко и просто".А нафига специально настраивать на каждой,
для начала запретить установку соединений по TCP/IP извне,это отсеет 99% программ написанных людьми которым пофиг на безопасность,
UDP ИМХО используют люди которые хоть как-то разбираются в вопросе.
>для начала запретить установку соединений по TCP/IP извнеЭто уже имеется, называется запрет всех соединений для фоновых приложений. Работает. Удобно? Нет. Потому что ломает работу любого чата, любого почтовика и т.д.
Вы плохо понимаете суть проблемы, раз предлагаете такие радикальные решения. Они не будут приемлимы для 99% людей.
>UDP ИМХО используют люди которые хоть как-то разбираются в вопросе
А злоумышленники значит все поголовно идиоты и про UDP не слышали. Поразительная логика. Про STUN не слышали? А он сейчас почти везде, где не лень его прикручивать. Как вы проблему с доверием к STUN-серверам будете решать? Не говорите, я знаю ответ: ЗАПРЕТИТЬ!
> Потому что ломает работу любого чата, любого почтовика и т.д.Чаты и почтовики, ломающиеся от запрета входящих соединений на *клиентских* устройствах??!
>Чаты и почтовики, ломающиеся от запрета входящих соединений на *клиентских* устройствах??!Чаты и почтовики ломаются потому что запрещаются исходящие соединения. Я немного опередил ход мыслей опонента, поэтому некоторые не понимают всю сложность вопроса.
Допустим будет запрет на входящие соединения. Однако это не остановит злоумышленников. Что видно по взломам серверов, рабочих станций под любыми ОС. Т.е. плохие парни перейдут к тому, что разрешено, а именно построение ботнетов, сливы инфы через соединения с _рандомными_ серверами, скажем слив на тот же pastebin.
Как вы этот вопрос будете решать? Тоже через блокирование всего? Так это уже есть (см. выше).
Такое ощущение, что некоторые "умники" считают, что в гугле и AOSP работают полные идиоты. Это не так и потому как проблема не решена до сих пор (актуальной она стала еще 5+ лет назад), говорит о том, что нужно решить ряд других вопросов, в частности запретить выкладывание приложений, которые не могут вообще работать без доступа ко всему (как сказали ниже про систему в винде).
Оболочку над файрволлом можно стырить из любого спец. дистрибутива, того же m0n0wall и его клонов. Или даже написать свою на коленке за неделю, это не проблема. Только помимо файрволла надо еще фигачить разграничение прав доступа к сервисам на двух уровнях (простой, для 95% людей и полноценный вплоть до указания к какому файлу разрешить доступ и сколько байт в нем можно читать).
Так вот, ни файрволла для 95% людей так и не написали. А если напишут по функционалу такой же как сейчас имеется с двумя кнопками "да"/"нет", то прока от него не будет никакого.
> Такое ощущение, что некоторые "умники" считают, что в гугле и AOSP работают полные
> идиоты.не полные, но мягко говоря, альтернативно одаренные. Банальная индусятина. Умные там были, но сейчас уже все поразбежались или загнаны в мертвые проекты, занимающиеся непойми чем.
> Это не так и потому как проблема не решена до сих пор
проблема не решена потому, что ее никто не дал команду решать (а некому, в менеджменте вменяемых не осталось) - тогда могли и специалиста нанять или сманить из соседнего отдела. Работнички гугля занимаются исключительно затыканием дыр по мере утыкания в них носом.
И решить ее можно только глобально, на уровне архитектуры. То, что она изначально была полным дерьмом вообще без управления пользователем - как раз и говорит об уровне тех, кто этот жабский шлак спроектировал.
Похоже, они действительно думали только об одном - как бы поганый юзверь не заблокировал отправку своих личных данных и показ себе ненужно-баннеров, и не понаставил себе чего-нибудь в обход гуглестора, не заплатив (гуглю, плевать на авторов). И вот в эту сторону и направили все усилия.
Мысль что данные может тырить не только гугль - в индусские головы просто не пришла.
Мысль о том что безопасность нужно начинать строить с модели угроз - тоже.Получите тот хлам, который мы и имеем сейчас.
> Оболочку над файрволлом можно стырить из любого спец. дистрибутива
мне не нужна "оболочка из любого дистрибутива", я умею пользоваться шеллом. Мне нужен нормальный дальвик-апи. Не требующий рутования устройства, даже временного. Умеющий спросить разрешения в момент попытки открытия сокета (винда умеет, двенадцать лет как, так что не рассказывайте мне сказки что никак невозможно) или превентивно (опять таки через апи - программа вполне может попросить файрвол заранее спросить у пользователя разрешения - заметьте, спрашивать должен именно файрвол, иначе кто-то начнет это делать без спросу)
Дождемся мы чего-нибудь подобного в ближайшие пару лет? Полагаю, нет. Вместо этого будет стройная система костылей и подпорок- вот типа предлагаемого разбиения права создавать сокеты на два - отдельно для listen, отдельно для connect. Добавляющая только видимость безопасности и видимость контроля пользователю.
>мне не нужна "оболочка из любого дистрибутива", я умею пользоваться шеллом. Мне нужен нормальный дальвик-апи. Не требующий рутования устройства, даже временного. Умеющий спросить разрешения в момент попытки открытия сокета (винда умеет, двенадцать лет как, так что не рассказывайте мне сказки что никак невозможно) или превентивно (опять таки через апи - программа вполне может попросить файрвол заранее спросить у пользователя разрешения - заметьте, спрашивать должен именно файрвол, иначе кто-то начнет это делать без спросу)Я не знаю, какой идиот тебя минисует, но, чувак, ты безумно прав. Хочу добавить, что рутовый доступ ставит жирный крест на всей безопасности в принципе. Вообще, я недавно начал пользоваться андроидом и первые пару месяцев был в шоке от обилия костылей. Даже шрифты в интерфейсе (я про стандартный aosp, если что) без рута или пересборки прошивки сменить нельзя. И это самый последний Android 7. Омерзительно, в общем.
Чуваки из Copperhead, кстати, сами правила iptables для сабжевой фигни пишут, но там и половина ведроедового софта работает так себе.
> Ключевое слово "ручная", а не "легко". Вообще, даже специалисту в этом вопросе,неспециалиста все равно поимеют. Тут беда в том,что и специалиста тоже. Ну и отдельная, конечно, да, что штатного управления ядерным файрволлом не предусмотрено.
> чтобы правильно настроить файрволл для приложения потребуется приличное кол-во времени,
> особенно, если приложение работает на мульти-протоколах (например, SIP).э... nf_conntrack_sip пятнадцать лет. Еще с ipchains спортирован.
Там есть свои ньюансы (вокруг reinvite) но хорошие программы об этом сами должны догадываться, а плохие и запускать не стоит.> уж тем более не для сложных клиентских программ, которые еще общаются
> на 127.0.0.1 с собой (а могут общаться и не с собой).это как раз самое простое. Кстати, не надо путать 127.0.0.1 и lo.
(ну мы же предполагаем, что внутри нашего телефона нет намеренных троянцев,да?)
> не надо путать 127.0.0.1 и loЭмм, а?
>> не надо путать 127.0.0.1 и lo
> Эмм, а?$ ping 127.255.255.128
С моделью угроз у них всё в порядкеЗадача Гугла — чтобы функционал по сбору и отправке данных о пользователе работал. И они с этой задачей справляются. Единственный потенциальный противник согласно данной модели (пользователь) успешно нейтрализован путём пропихивания своих сервисов в большую часть приложений в маркете (фонарики, требующие разрешений на GPS и чтение контактов, ага).
> С моделью угроз у них всё в порядкевы код-то видели? Там все не в порядке, гугл уже давно 100% индусская контора, мозгов там иметь и некому, и не положено.
(то что там где-то по углам еще прячутся нормальные люди, это со временем проходит, к тому же они уже лишены и ресурсов, и права влиять на происходящие процессы - я немножко знаю, как это изнутри устроено)> Задача Гугла — чтобы функционал по сбору и отправке данных о пользователе
> работал.ненене. Задача гугля - чтобы работал функционал по сбору и отправке данных о пользователе - гуглю. А не в пятьдесят стремных бангалорских помоек, и еще сотню тех кто просто поимел систему с соседнего столика в кафешке.
Это, к сожалению, именно фатальная, непробиваемая тупость копченых обезьян, а не злонамеренные козни. Но вот накрутить им хвосты уже совершенно некому (да и вся гугловая пирамида построена без механизмов такого воздействия).
> в большую часть приложений в маркете (фонарики, требующие разрешений на GPS
> и чтение контактов, ага).вдруг ты хочешь подсказать друзьям, что тут темно?
Про отзыв полномочий не слышал?
Xposed с XPrivacy решают эту проблему. Не доверяете разработчикам - исходники открыты.
> Xposed с XPrivacy решают эту проблему. Не доверяете разработчикам - исходники открыты.эту - решают (поделки вида install.apk - не решают, разьве что в совсем тривиальных случаях - потому что приложение не проверяет кодов возврата или проверяет и тут же завершается аварийно - разработчики-то тоже привыкли что можно все, что перечислили в манифесте)
Но создают новую, поскольку первый внедряется в такие кишки системы, где уже вообще может делать что угодно.Нет, не доверяю. Это хакеры, они совершенно не обязаны быть белыми и пушистыми, к тому же и очень белого и пушистого можно нагнуть. И я спрашивал не про открытость исходников, а _вы_ - верфицировали? (раз вы слышали про xposed, значит, проблема privacy и кражи данных вас как-то занимала) Полагаю, нет.
>Идиотская схема "безопасности" андроида все равно не позволяет пользователю решать,
>какие на самом деле приложению можно дать права, а без каких оно на его устройстве
>вполне может и обойтись.ломающие новости: андроид 4.3 и 6+ позволяют не давать разрешения приложениям через гуй.
а через adb можно было и до этого
Так уже давно (начинаяс 6.0) можно выбирать каким приложениям какие полномочия будут доступны. Во всех новых приложениях будет запрос при первой попытке получить доступ к какойто возможности. Во всех старых можно в настройках отключить разрешения. Если приложение без каких-то разрешений работаь не может то при отключении из настроек разрешений будут возвращены пустые данные (например пустой список контактов или нулевые координаты).
> Так уже давно (начинаяс 6.0)не работает нихрена - у меня есть шестой (если бы это работало - пользовался бы, а так в столе лежит).
Тут только xposed поможет - там не нуль надо возвращать, а какой-нибудь фейк, чтобы уродский код радостно в него вцепилсо. (от описанной проблемы, заметим, не поможет вовсе - тут только файрволлом)
> доступны. Во всех новых приложениях будет запрос при первой попытке получить
> доступ к какойто возможности.нажмешь "нет" - оно плавненько завершится.
> Во всех старых можно в настройках отключить
а старое упадет, ага.
нет,если ему на самом деле было низачем не нужно - то работает, но таким и install помогал. У меня их целых одно.
Ну и еще не забываем, что там есть свой целый ipc, для которого никаких особых разрешений не нужно. (да и непонятно, как его гранулировать, кроме предложенного мной способа, который в гуглоконцепцию совсем никак) То есть платную sms отправит встроенная sms'илка, а не сама кривая программа, и с твоего же разрешения.> при отключении из настроек разрешений будут возвращены пустые данные
тоже не всем помогает. вернешь нулевой дескриптор - оно его радостно пытается использовать. Вернешь нулевые координаты - оно на этот ноль поделит и очень удивится.
Виндовая система, где любое приложение должно работать при любых настройках privacy, и это заставляют, кстати, проверять - гораздо жизнеспособнее. Но, увы, microsoft. Специалисты просохатить все, что только оказывается в их руках.
А толку? Вот ставлю Сбербанк Бизнес Онлайн (для юриков). Он говорит: хочу (не жить не быть) управлять твоими звонками, иметь доступ к твоим фоточкам, знать где ты находишься, отправлять и читать твои СМС. На каждый такой запрос отвечаю: хер тебе. А дальше он выводит msgbox, где говорит: раз так, тогда я не буду работать, и выходит. И толку от такого контроля прав?
Начиная с 6-й версии Андроида, можно вручную отключать ненужные разрешения для каждого приложения.
> Проблему идиoтов-гуглоидов, написавших изначально бессмысленную систему разграничения прав (потому что "модель угроз - не, не слышали") решить невозможноSELinux на что?
Там вроде нужны особые права на создание сокетов, потом с ними можно делать всё. По крайней мере раньше так было, может в новых версиях что-то изменилось
Когда раньше? Под Android 4 написал скрипт и запустил с баша который создал сокет и сконнектился. Не под рутом.
Разрешения наследуются от эмулятора терминала вместе с UID
Какая вообще разница, когда блин, вайфай дырявый, и вообще, когда есть недоброкодеры, знающие ассемблер...
> Для демонстрации возможных методов эксплуатации исследователи подготовили несколько сценариев атак:А для исправления и предотвращения что делать? На мобилке - Android 6.0
> А для исправления и предотвращения что делать? На мобилке - Android 6.0переписывать больное приложение. (файрволлом не поможешь, работать не будет)
Не, не ваше?Значит, windows mobile - ваш выбор. (был бы, если бы не корпорация зла)
Windows mobile не выбор, ибо сдохла.https://www.neowin.net/news/yep-it039s-dead-microsoft-phone-...
ну так я о том же - нынешняя ms,к сожалению, очаровательно умеет испортить все, чего касается.
> ну так я о том же - нынешняя ms,к сожалению, очаровательно умеет
> испортить все, чего касается.Да они все нынешние ничем другим не занимаются, только портят. Достаточно почитать комменты на опеннете и это становится очевидным.
Приложения только с открытыми исходниками, F-Droid наше всё. 100% защиты не даст, но повысит безопасность.
Фаервол без рут поставте и контролируйте кому давать доступ и через какой порт