Информационная безопасности для android

Безопасность в мобильных приложениях

Информационная безопасность это всегда гонка вооружений. Из чего следует одна простая мысль, что полная безопасность невозможна, особенно в случае с клиентскими приложениями, когда у злоумышленника есть физический доступ к устройству. Но тут как при убегании от медведя: необязательно бежать быстрее медведя, достаточно бежать быстрее соседа.

Главная идея заключается в том, чтобы сломать вас было дороже получения возможной выгоды. Нужно донести до потенциального хакера одну простую мысль, «ломать нас невыгодно, иди поищи счастья в другом месте». Поэтому одной из основных критических ошибок являются крики о том что ваша защита совершенна. На подобные заявления сразу сбегается куча высоко профессиональных хакеров, которые будут ломать вашу защиту просто для доказательства своей крутизны невзирая на любую возможную выгоду.

Одним из основных столпов хорошей защиты, является журналирование действий и мониторинг всех нестандартных событий. Тяжело выстраивать защиту, если вы даже не знаете что вас ломают и каков вектор угрозы. Тут многое специфично для ваших процессов, но в качестве примеров могу привести использование большого количества разных аккаунтов с одного устройства; попытки обратиться к API к которому у аккаунта не должно быть доступа; многочасовые сессии в случаях, когда среднее время измеряется в минутах; нестандартные сбои и так далее.

Базовые методики защиты

Они не защитят от продвинутых ребят, но прикручиваются быстро и выбрасывают всех script-kiddie которые просто скачали утилиты из интернета и не особо понимают что делают.

В природе есть много разных методик обнаружения рута. Одним из самых простых является проверка подписи прошивки или попытка достучаться до суперпользователя:

Также очень популярным методом получения рута является Magisk. Обнаружение само по себе является той еще игрой в кошки мышки: находят один способ, потом разработчики его патчат, находят другой, его патчат и так далее. Самой свежей методикой обнаружения является использование изолированного процесса.

Emulator

Для обнаружения запуска на эмуляторе можно проверять разные поля из класса Build. Большинство возвращаемых данных постоянны и одинаковы для подавляющего большинства эмуляторов:

Также практически не меняется эмулируемая среда: сеть, данные с датчиков и так далее.

Xposed

Один из самых популярных инструментов для изучения приложений. Принцип работы достаточно простой: хукается основной процесс Zygote, что позволяет перехватить вызов любой функции и прочитать/подменить ответ. Есть много методик обнаружения такой атаки, например проверка stackTrace:

Проверка имени установщика приложения

Имя можно получить через

Если вернуло null, то в 99% случаев это означает что приложение установлено вручную и скорее всего взломано. Имена основных сторов:

Продвинутые методики защиты

Эти методики не спасут от профессионального специалиста по реверс-инжинирингу. От такого вообще ничего не защитит, поэтому лучше не держать на клиентских приложениях ничего сверх того что необходимо для работоспособности этого приложения. Зато они доставят достаточно много проблем, чтобы злоумышленники еще раз задумались, а надо ли это им.

Проверки на клонирование/пересборку приложения:

Можно проверить путь установки приложения, в большинстве случаев при клонировании приложение устанавливается по нестандартному пути:

и/или проверить подпись

Safety net

basicIntegrity — базовые проверки надежности устройства;

ctsProfileMatch — Более строгая проверка, прохождение которой означает что профиль устройства соответствует сертифицированному Google

SSL pinning

Эта проверка означает что мы не доверяем базовым сертификатам устройства, а доверяем только тому сертификату который нам известен. В случае okHttp3(стандарт сетевой библиотеки в большинстве приложений) проверка включается так:

Обфускация

Стандартным подходом в индустрии является Proguard. Для дополнительной защиты можно использовать собственный словарь с символами иностранного языка(китайский и арабский особенно хороши). Также существует проблема, при которой строковые литералы не обфусцируются. Решается платным обфускатором DexGuard, также на GitHub есть библиотеки не настолько качественные, зато бесплатные, например paranoid.

Шифрование

Шифрование всех важных данных — очень хорошее препятствие для обратного инжиниринга. Отличным вариантом алгоритма шифрации будет AES-256

Единственное, что нужно продумать, это ротацию ключей. В идеале это будет отдельный ключ на каждую сессию, но это очень сложно и дорого поддерживать, поэтому подбирайте баланс в зависимости от доступных ресурсов и требуемого уровня безопасности.

Также очень интересным вариантом является перенос критической логики в нативный код. Отреверсить код на C намного тяжелее, чем это сделать с APK. Но так же как и с шифрованием это довольно дорого поддерживать, поэтому стоит продумать баланс в зависимости от доступных ресурсов и требуемого уровня безопасности.

Если вас заинтересовала тема безопасности в мобильных приложениях, то есть прекрасное руководство от OWASP с которого можно начать своё путешествие в кроличью нору.

Источник

10 приложений для защиты устройств на Android

Недавние исследования показали, что почти 87% устройств на Android уязвимы к атакам.

Это связано с тем, что не проводятся обновления системы безопасности. От интернета не защититься, пока устройство подключено к сети. Обеспечение безопасности в наше время является одной из основных задач, поэтому появилось много сторонних приложений для ее повышения.

Следующие приложения помогут защитить ваши устройства Android от угрозы безопасности и личным данным.

Список приложений для защиты устройств Android

1. Avast Mobile Security

Avast – это прекрасное приложение для защиты телефона на базе Android от вирусов и других угроз.

Avast – это один из наиболее популярных бесплатных антивирусов для Android. Он уведомляет об установке шпионских и рекламных программ, которые угрожают защищенности ваших личных данных.

Вероятность обнаружения новейших вредоносных программ примерно 99,9%, а в случае вредоносных программ, появившихся в течение месяца, вероятность практичеки 100%.

Вывод: Если вам необходима защита от вредоносных программ и для безопасного просмотра сайтов, то вам это приложение подойдет.

2. Sophos Antivirus and security

Sophos – один из лучших бесплатных антивирусов для Android.

Пользовательский интерфейс может не вызвать восхищения. Однако, функционал позволит вам перестать беспокоиться о безопасности.

• сканирование на наличие вирусов установленных и существующих приложений, а также хранилищ данных;
• защита от потери и воровства с поддержкой удаленного доступа, позволяющего форматировать, заблокировать, включить звуковой сигнал на вашем устройстве или установить его местоположение;
• фильтрация веб-контента;
• блокировка спама.

У Sophos самая высокая вероятность выявления новейших вредоносных программ – 100%. Этим она разительно отличается от других.

Вывод: Если полезные функции для вас важнее симпатичного дизайна, то лучше Sophos вы мало что найдете.

3. AppLock

Этим приложением довольно просто пользоваться. AppLock защищает отдельные приложения от взломщиков, запрашивая ПИН-код или графический ключ. Таким способом можно защитить SMS, контакты, Gmail, да и вообще любое приложение.

Не перепутайте такую блокировку приложений и встроенную в телефон блокировку устройства. Встроенная блокировка блокирует весь телефон. Нет доступа ни в какие приложения. В свою очередь AppLock позволяет заблокировать избранные приложения.

Вывод: Если вам требуется предотвратить доступ злоумышленников к отдельным приложениям, но вы не хотите защищать паролем устройство в целом, то для этого подойдет Applock.

4. Signal Private Messenger

Существует множество приложений для безопасного обмена сообщениями. Большинство из них работают только, если оба пользователя используют одно и то же приложение.

Однако, Signal Private Messenger позволяет добавить дополнительный уровень защиты к обыкновенным SMS, даже если один из пользователей не пользуется Signal Private Messenger. Приложение разработано Open Whisper System.

Приложение имеет следующие особенности:

• открытый исходный код;
• сквозное шифрование. На сервере приложения не хранится ничего;
• шифрование возможно даже если у одного из пользователей нет Signal Private Messenger.

Вывод: Для сквозного шифрования обычных SMS лучше Signal Private Messenger ничего нет.

5. Secure Call

Гарантирует, что никто не сможет прослушивать звонки. Secure Call обеспечивает сквозное шифрование звонков, предотвращающее прослушивание посторонними лицами.

Приложение используется по умолчанию для входящих и исходящих звонков. Благодаря децентрализованной архитектуре (peer-to-peer) с надежным сквозным шифрованием никакие посторонние лица не смогут прослушать ваши звонки, в том числе сами разработчики приложения.

Вывод: если вам требуется сквозное шифрование звонков, пользуйтесь Secure Call.

6. App Ops

Основная функция App Ops – аннулировать определенный набор разрешений у выбранных приложений. Многие приложения запрашивают дополнительные разрешения, которые ни в какой мере не связаны с их функциями.

App Ops позволяет блокировать излишние полномочия. При установке приложения требуется разрешить доступ ко всему, что потребует приложение.

Если вы отклоните какое-либо разрешение, приложение установлено не будет. App Ops вас выручит, если понадобится устновить приложения, при этом не давая определенных разрешений.

Вывод: App Ops решит вопрос отзыва конкретных ненужных разрешений.

7. Lastpass

У всех сегодня по несколько учетных записей и паролей. Помнить их все не легко.

LastPass – один из лучших доступных на рынке менеджеров паролей. При хранении паролей применяются дополнительные уровни защиты.

Все ваши конфиденциальные данные доступны для вас с любого комьютера или мобильного устройства. Пароли зашифрованы одним мастер-паролем. Чтобы получить доступ ко всем паролям, нужно помнить лишь пароль LastPass.

Вывод: Простое решение для хранения всех паролей.

8. Android Device Manager

Android Device Manager позволяет включить звуковой сигнал, определить местоположение, заблокировать ваше Android-устройство. Приложение также позволяет удалить все данные с устройства на случай, если телефон уже окончательно не под вашим контролем.

Во многих приложениях это реализовано в качестве дополнительной функции. Тем не менее, приложение Google установить легче. Также, оно позволяет зайти в вашу учетную запись через чужое устройство и удалить все данные на ходу.

Вывод: Для удаленного доступа Andriod Device Manager идеальный вариант.

9. NoRoot Firewall

Многие приложения для Android впустую потребляют мобильный трафик.

С помощью NoRoot Firewall вы сможете контролировать доступ приложений без рутинга устройства. Вы сможете разрешить выбранным приложениям доступ в сеть только через wifi, только через мобильный интернет или же полностью запретить/разрешить.

Вывод: Для тех кому не подходит рутинг, но нужен файервол, подойдет NoRoot Firewall.

10. Orbot

Orbot – это приложение для Android в рамках проекта Tor. Оно позволяет перенаправлять весь трафик через сеть Tor.

VPN использует один сервер, а Tor перенаправляет трафик через несколько IP-туннелей, чтобы не оставлять следов. Orbot устанавливает поистине защищенное мобильное соединение. Данные шифруются повторно.

Шифрование данных проходит многократно, до тех пор, пока они не дойдут до пункта назначения, где они дешифруются. Таким образом, отправителя не отследить.

Вывод: Orbot позволяет вам без труда зашифровать интернет-трафик.

Надеюсь, эти приложения помогут сохранить ваш мобильный телефон или устройство на базе Andriod в целости и безопасности. Также попробуйте воспользоваться VPN от SurfEasy для защиты своей анонимности в сети.

Источник

Безопасность Android-приложений. Лекция в Яндексе

Разработчик Дмитрий Лукьяненко, чью лекцию мы публикуем сегодня, не только является специалистом Яндекса, но и умеет проверять на прочность решения разработчиков других компаний. Это позволяет учиться на чужих ошибках — не исключая порой своих, конечно. В докладе Дмитрий поделится примерами Android-уязвимостей, в том числе найденных им собственноручно. Каждый пример сопровождается рекомендациями — как нужно и как не нужно писать приложения под Android.

Меня зовут Дмитрий, я работаю в компании Яндекс в минском офисе, занимаюсь разработкой аккаунт-менеджера. Это библиотека, которая отвечает за авторизацию пользователей. Поэтому мы поговорим о безопасности Android-приложений.

Я бы выделил следующие источники проблем. Первые — сетевые, связанные с коммуникацией с сервером. Это когда ваши данные передаются не совсем защищенным способом. Вторые связаны с проблемой хранения данных: это когда ваши данные хранятся где-то в открытом виде, могут даже где-то на SD-карте храниться, либо они не зашифровываются, в общем, когда к ним есть доступ извне.

Третий вид проблем — воздействие сторонних приложений на ваше. Это когда стороннее приложение может получить несанкционированный доступ к вашему, выполнить какие-то действия от имени пользователя, либо даже украсть что-то и т. п.

В этом докладе мы остановимся именно на третьем виде проблем, связанном с воздействием сторонних приложений. Мы рассмотрим не только теорию, но ещё и конкретные примеры из реально существующих приложений. Причем некоторые эти примеры до сих пор актуальны, видимо, на них просто забили, но мне они кажутся достаточно интересными.

Этот доклад будет полезен тем, кто занимается Android-разработкой. Я бы советовал уделить внимание этим аспектам всем, кто делает приложения. Например, тестировщикам. Тестировщики, мне кажется, если посмотрят эти нюансы, смогут какие-то премии выбивать, они начнут более глубоко вникать в разработку, даже программировать можно особо не учиться. Manifest-файл просто смогут анализировать и выявлять потенциально опасные места. И всем остальным, кто интересуется такими вопросами безопасности.

Прежде чем начнем, стоит упомянуть софт, который может пригодиться. В первую очередь BytecodeViewer, очень полезная программка, позволяет одним кликом получить из apk-файла все исходники, все ресурсы, в том числе manifest-файл.

Стоит отметить удобную утилиту для Android — ManifestViewer. Она позоляет очень быстро просматривать manifest-файлы всех установленных приложений. Я её использую по работе, например, когда ко мне приходят и говорят: аккаунт-менеджер не работает, что такое? В первую очередь всегда смотрю manifest-файл, чтобы убедиться, что аккаунт-менеджер был правильно интегрирован, то есть что все его компоненты объявлены как надо.
Эта программка полезна, чтобы вы на скорую руку открыли и посмотрели точки входа, вектор атак из manifest-файла.

Если вы любите всё делать из консоли, вот вам все эти программы отдельно. apktool позволяет выдернуть все ресурсы и manifest-файл. Dex2jar и enjarify позволяют конвертировать apk-файл в jar. Dex2jar может какие-то apk не конвертнуть, выдать с каким-то исключением. Не отчаивайтесь: часто такие файлы скушает enjarify, и вы получите jar. Это две хороших утилиты.

После того, как у вас есть jar-файлы, вы можете взять Java Decompiler и сконвертировать их в более удобный вид — в вид классов. Понятно, что их нельзя будет запустить, но анализировать их гораздо проще, чем код, который там получается, и т. п.

Давайте рассмотрим самые базовые проблемы. Во-первых, сначала нам нужно проанализировать manifest-файл, потому что в нем обязательно должны быть описаны все компоненты Android-приложения. Это Activity, Service, Broadcast Receiver, ContentProvider. Все они, за исключением Broadcast Reciever, обязательно должны там находиться.

Поэтому когда мы начинаем поиск каких-то проблем, мы смотрим эти компоненты. Вот конкретный пример. Это сервис, который был объявлен в manifest-файле одного приложения, он явно экспортируется. В нем даже явно указано, что он экспортирован. Это означает, что он доступен любому другому стороннему приложению. Любое другое приложение, в свою очередь, может послать в этот сервис интент, и сервис может выполнить какие-то действия, если они там предусмотрены.

В данном случае мы видим потенциальный вектор для атаки. Если копнем глубже и посмотрим исходники, по ним станут понятно, что этот сервис позволяет, допустим, удалить авторизованного пользователя в этой программе. Я сомневаюсь, что разработчики предусматривали такую фичу для каких-то сторонних приложений. Это конкретный пример, которому следует уделить внимание.

Ещё один момент: когда у нас какая-то компонента использует интент-фильтры, то по умолчанию она тоже становится экспортируемой. Тут, возможно, начинающие разработчики могут споткнуться. Если интент-фильтр есть, то всё, эта компонента уже публичная. Тут стоит быть внимательным.

Я сталкивался с такими видами проблем, когда над уведомлением, которое показывается в соответствующей панели, можно произвести ряд действий. Например, такое бывало в Яндекс.Почте и других приложениях.

Что делало это событие? Оно обрабатывалось при помощи публичного BroadcastReciever. То есть злоумышленник тоже мог послать любой бродкаст — подобрать ID письма и, допустим, удалить его. Причем необязательно, чтобы это было сообщение в панели.

Когда-то давно в Яндекс.Почте была такая уязвимость. Уже всё поправили, так что можно пользоваться, всё отлично. Спасибо Ильдару, они оперативно всё это делают.

Как это решилось? Компоненту просто сделали недоступной извне, поставили ещё permission дополнительно. Его можно было и не ставить, главное — если она не экспортируется, значит, уже никто не сможет к ней подключиться и что-то выполнить.

Следующий вид проблем — использование неявных интентов, когда в интенте не задается конкретное место, в которое он должен прийти. Это означает, что у вас нет гарантии, что этот интент придет туда, куда вы хотите. Он может прийти куда-то ещё. Поэтому тут надо быть внимательным.

Ещё нюанс, который я отнес бы к неявным интентам, — это Browsable Activity, когда у нас из браузера можно открыть Activity стороннего приложения. Это происходит, когда задана какая-то схема, хост, там кликают и у вас открывается окно. Хорошо, когда просто открылось окно и например, передалась позиция на карте. Это не страшно. А страшно — следующее. Допустим, у нас некоторые ребята предлагают использовать Slack в компании. В Slack очень интересная авторизация. Если вы авторизовались в браузере на Android, то вы можете авторизоваться и в установленном приложении Slack. Это работает по такой схеме, когда в браузере есть URL, вы по нему кликаете и его перехватывает приложение Slack.

Но здесь нет гарантии, что URL не перехватит кто-то другой, причем по нему передается токен. Схема достаточно простая: когда вы кликаете в браузере, вас сразу авторизовывают в приложении Slack. Значит, этого URL достаточно для авторизации.

Здесь отмечены кнопки, которые можно кликать в браузере и которые инициируют это открытие. Это не только «Открыть Slack», но и логотип — он всегда находится сверху, на любом экране.

Давайте посмотрим видео, которое демонстрирует использование этой проблемы. Мы авторизовались, зашли в свою директорию, нажали на логотип Slack — но приложения Slack у нас нет, у нас злоумышленник подставил интент-фильтр. Вернулись, нажали… Можно фишинг сделать — точно такой же по внешнему виду, как Slack. Написать, что авторизация не сработала и всё такое. Пользователь ничего не поймет, а токен окажется у вас. Поэтому если пользуйтесь Slack, то будьте внимательны с этой браузерной авторизацией.

Решение очень простое. Как говорил мой коллега, можно использовать явные интенты, которые открываются из браузера. Но когда я в Slack зарепортил и мой тикет получил номер 80000 с чем-то, они сказали, что это дубликат и что уже есть тикет 50000-какой-то. Если прикинуть, получится, что им это больше чем полгода назад сообщили. Исправляется вроде достаточно просто, но — не исправили. Значит, это не критичная проблема и можно тогда о ней рассказать.

Здесь есть рекомендация, что лучше всегда использовать явный интент. Если вы почитаете и вникнете более глубоко, то узнаете, что у Android была прикольная опечатка. Они в одном месте использовали неявный pending intent. Из-за этого можно было получить доступ к пользователю с правами system. Они эти ошибки исправили в Android 5. Такие ошибки у всех бывают, даже у Google.

Всегда лучше использовать явный интент или, если это невозможно, всегда задавать какой-то permission. Он позволяет ограничить доступ.

Рассмотрим другой вид уязвимостей — основанный на пользовательских данных.

У нас есть приложения, которые могут получить какие-то данные от пользователей, например отправить какой-то файл, открыть его, просмотреть. Это обычно осуществляется при помощи интентов типа view и send.

Вот это зловредное приложение может вам сказать: отправь мне файл, который лежит у тебя же в приватной директории, в твоей же песочнице. Допустим, этот файл может быть вашей базой данных, содержащей всю переписку, или преференсы, если хранятся какие-то токены. Некоторые приложения могут выполнять с этими файлами какие-то действия. Они могут, например, файл закешировать на SD-карте или отправить куда-то. В том числе можно выполнить такое действие, что этот файл станет доступен злоумышленнику, хотя изначально они предполагали, что это будет их внутренний файл.

Можно взять getAbsolutePath() и проверить, совпадает ли директория с вашей приватной. Но это неправильно.

Вам злоумышленник может прислать не сам файл, а ссылку на него.

Как может создаваться эта ссылка? У злоумышленника создается readme.txt — он сделал ссылку на приватный файл вашего приложения. Затем он запихнул эту ссылку вам, и если вы будете использовать getAbsolutePath(), то вам вернётся путь ссылки — путь к файлу readme.txt. А вы подумаете, что всё нормально.

Чтобы это исправить, лучше использовать метод getCanonicalPath(). Он возвращает полный путь, самый настоящий. В данном случае система вернет не readme.txt, а какой-нибудь mailbox. Учитывайте эти проблемы.

Я сталкивался с ситуацией, когда подобная проблема была у одного приложения более чем с 50 млн пользователей. Говоришь: покажите мне этот файл. Они его кешируют на SD-карту и потом пытаются открыть. Так можно было все токены украсть. Они уже всё исправили, но попросили пока не разглашать. Тем не менее, такое встречается.

Следующий интересный момент: вам могут прислать ссылку на content provider, и он тоже может быть передан. Даже если он защищен через permission, даже если он не экспортируемый, то всё равно — когда ваше приложение попытается его открыть, выполнится метод query, который есть в content provider.

Тут надо быть осторожным. Вот ещё один реальный пример, уже из другого приложения. Они делали бэкап БД из метода query. Туда можно было передать action типа backup и программа сразу дублировала всю БД на SD-карту. Получается, вроде провайдер защищен, но его можно так подсунуть, чтобы получить в итоге всю БД.


Я больше нигде не встречал, чтобы кто-то делал запись в методе query, но там всегда лучше открывать что-то для чтения. А ещё — учитывать, что там может быть SQL-инъекция. Сейчас есть ряд приложений, в которых я обнаружил возможность SQL-инъекции. Однако доступы у них только для чтения, и я пока не понял, можно ли там дальше что-то сделать. Но вдруг найдется уязвимость в самой БД SQLite, которая позволит выполнить уже не настолько безобидную инъекцию? Всё-таки лучше их не допускать, даже если если при открытии есть доступ только для чтения.

Теперь давайте рассмотрим одну проблему с WebView, причем срабатывает она во всех Android до версии 5.0 и позволяет обойти SOP. Из этого мы сделаем вывод, что в WebView лучше никому не давать открывать свои файлы.

Рассмотрим этот вид атаки. Зловредное приложение может попросить ваше приложение, если оно имеет доступы к WebView: покажи мне файлик index.html. Предположим, ваше приложение открыло index.html. Содержимое файлика очень простое — JavaScript, который через 5 секунд сам файлик, самого себя, загружает в iframe, перезагружает как бы.

В этот период времени зловредное приложение указанный файлик удаляет и заменяет на символическую ссылку на приватный файл из вашего приложения. Проходит 5 секунд, оно перезагружается, но контент в нём уже становится контентом того самого приватного файла. На Android до 5.0 ещё до WebView, видимо, стоит неправильная проверка на то, что это символическая ссылка. Таким образом можно прочитать контент. Оно смотрит — имена файлов совпадают, значит SOP не нарушена, контент можно отдать и значит, JavaScript может взять контент и отправить его на сервер.

Такой вид атаки встречается не только в WebView. Он до сих пор работает в UCBrowser, у которого больше 100 млн установок. Я встречал такое и на некоторых версиях Android-браузера, до Android 5.0. Наверное, он тоже на WebView построен. Например, на телефонах Samsung у меня такое не получилось воспроизвести, а на моем телефоне Acer срабатывает.

Глянем небольшое видео о том, как это работает в UCBrowser. Речь о небольшом зловредном приложение, но оно может сработать. Вы легли спать, телефон тоже, внезапно запускается activity, страничка. Вы спите, а там запустилось — какой-то iframe, подтверждение, алерт. Если алерт прочитал контент, значит, мы точно так же могли отправить этот контент куда угодно. Это bookmark.db, тут хранятся закладки. Думаю, кому интересно — может поисследовать. Возможно, удастся найти там более приватные пользовательские данные. Можно и куки украсть. Но куки у них названы по имени сайта, поэтому надо перебирать. ВКонтакте можно взять. Уязвимость до сих пор есть, вроде пока ещё не исправили и не спешат исправлять.


Вывод: если у вас есть WebView, то не давайте никому открывать в нём свои ссылки. А если всё-таки даёте, то хотя бы запретите открытие локальных файлов. В этом плане большие молодцы компания Qiwi, я их приложение пробовал, обрадовался, что сейчас открою файлик — ан нет, они запретили открывать локальные файлы и ничего не сделаешь.

Рассмотрим следующий вид нетривиальной проблемы. Она основана на особенностях десериализации в Android. Возможно разработчикам самой Java может быть полезно.

Представим, что у нас есть интент, который содержит какие-то данные, которые передаются в наше приложение — оно берет одно поле и считывает его с интента. И если приложение считало хоть одно поле, то происходит автоматическая десериализация всех данных в интенте. Даже если они не будут использованы, они всё равно десериализуются. Сейчас поймете, что здесь опасного.

Есть в Android до 5.0 такой бонус: на некоторых версиях при десериализации не проверяется, что класс действительно имплементирует интерфейс сериализации.

Это означает, что все классы, которые есть в вашем приложении, могут быть уязвимы. Да, они могут быть не сериализуемы, но если они подойдут под критерий, который будет описан дальше…

Итак, что тут опасного? Если объект был создан, он когда-нибудь будет удален. Обычно в том, что метод finalize вызовется, нет ничего опасного, ничего не реализуется. Однако когда есть нативная разработка, то обычно в методе finalize вызывают деструктор из нативной области и передают туда указатель. Я нативной разработкой не занимался, но поизучал, как туда передаются указатели. Если данный указатель сериализуется, то злоумышленник может подставить свой, а он, в свою очередь, может как вызвать ошибку выхода за границы памяти, так и указать на другую память, которая потом возьмет и выполнит какой-то код.

Этим воспользовались ребята из компании IBM. Они проанализировали весь список классов на платформе Android — проверили больше тысячи или сколько их там. И нашли всего один, который удовлетворял критериям: он был сериализуемый, и он сериализовал native-указатель. Они взяли этот класс, подставили свой указатель, он сериализовался и десериализовался. Он был новым не каждый раз. Сделали proof of concept, демонстрацию, есть видео. Эта уязвимость позволила им при помощи этого класса заслать интент в системное приложение. Оно позволило им, допустим, удалить оригинальное приложение Facebook и заменить его на фейковое. Видео длится минут 7. Там приходится повертеть — пока finalize вызовется, пока очистится память. Но вывод — никогда не надо десериализовывать нативный указатель.

Подытожим. Лучше никогда не экспортировать компоненты, которые есть в вашем приложении. Либо — ограничивать доступ по permission. Интенты всегда лучше использовать явные, либо permission задать. Никогда не доверяйте тем данным, которые придут от пользователя — это могут данные на что угодно, даже на ваши приватные области. Вы их потом можете повредить. Внимательно отнеситесь к ContentProvider, в том числе к SQL-инъекции и т. п.

Такая штука, как WebView, — она вообще не для игрушек. Если она есть в вашем приложении, закройте её и никому не давайте с ней играться.

Сериализация, а точнее, нативная разработка — это тоже как спички, будьте с ней поосторожнее. Спасибо за внимание.

Источник