Mobile Security с нуля

Безопасность мобильных приложений: почему клиентские баги опаснее, чем кажется

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

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

Компания может потерять репутацию ещё до всяких проверок регулятора: хватит одной громкой статьи о том, что через такую дыру у пользователей можно украсть данные.

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

Мобильный пентест: чем он отличается от веба

На пентесте мобильного приложения типичный безопасник подходит к нему как к вебу: снимает SSL pinning, смотрит трафик и начинает перебирать запросы к API. Это полезно, в мобильном API тоже находятся IDOR, обход аутентификации и мисконфиги. Но клиентские уязвимости мобильных приложений остаются за кадром: обход PIN-кода, кража токена через соседнее приложение, неудачная настройка, которая через мобильный клиент сильно бьёт по бизнесу.

Специалистов, которые хорошо знают именно клиентскую часть, мало. Готовых инструментов автоматизации под мобилки намного меньше, и чаще всего они умеют смотреть только Android. А находку сканера или багхантера нужно ещё правильно интерпретировать: это критичная уязвимость или так и задумано. Android и iOS заметно различаются, и в каждую платформу можно погрузиться с головой.

Профессия мобильного безопасника: вакансии и вход с нуля

Вакансию с названием «мобильный безопасник» встретишь редко. Такую роль обычно называют Application Security Engineer или пентестер, а то, что нужен именно мобильщик, выдают инструменты в требованиях, например Frida. Найти сильного кандидата сложно: даже начинающего специалиста с пониманием Android одна компания искала полгода, и на собеседованиях люди не отвечали на простейшие вопросы. Дальше на очереди HarmonyOS от Huawei, отдельная от Android платформа, которая уже активно захватывает рынок в Китае.

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

Уязвимость Deep Link: угон аккаунта через одну ссылку

Самый простой и при этом частый сценарий это угон аккаунта через Deep Link. Deep Link это ссылка, по которой вместо браузера открывается нужное приложение. Если приложение не проверяет параметры такой ссылки, в неё можно подставить произвольный хост. Пользователь нажимает на ссылку, которая выглядит валидно, а приложение идёт на сервер атакующего и само кладёт в запрос токен аутентификации.

Нажатие даже не обязательно. В Android Deep Link можно доставить через intent: обычное приложение без особых прав отправляет сформированное сообщение, и угон происходит так же. На iOS разработчику ошибиться сложнее, но бывает и там: приложение по Deep Link открывало во внутреннем WebView сервер атакующего и отправляло туда токен.

Причина одна: нет валидации параметров и белого списка хостов для HTTP-клиента или WebView.

Как такую уязвимость находят:

1. 1

   В манифесте смотрят схему и хост ссылки.

2. 2

   Реверсят код и ищут обработчик, где разбирается параметр Deep Link.

3. 3

   Прослеживают, как параметр обрабатывается дальше и можно ли подставить свой хост.

4. 4

   Подтверждают гипотезу динамическими хуками.

Уязвимости Android-приложений: IPC, песочница и обход PIN-кода

Приложения на смартфоне общаются между собой через IPC (межпроцессное взаимодействие). Если разработчик не продумал защиту компонента, стороннее приложение без дополнительных прав подключается к нему и получает данные. Классический пример в Android это content provider, который отдаёт чувствительные данные кому угодно. Встречался даже content provider с записью в базу данных, причём в библиотеке безопасности для мобильных приложений.

Отдельная история это песочница. Без root в приватную директорию приложения не попасть, но ошибки разработчика открывают к ней доступ через ту же ссылку, intent или даже текстовое поле. Дальше всё решает шифрование. Токен лежит в открытом виде: это полная эксплуатация с критичным уровнем. Данные зашифрованы: ситуация всё равно плохая, но до критичной не дотягивает.

Отсюда правило: шифровать файлы даже в приватной директории.

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

WebView и path traversal: как утекают приватные файлы

WebView это встроенный в приложение браузер и очень опасный компонент. Он исполняет JavaScript, умеет открывать файлы и ходить на произвольные сайты, если нет белого списка. Если удаётся прокинуть в WebView ссылку со схемой file://, он открывает приватный файл приложения. В Android примерно до API 29 доступ к файлам в WebView был включён по умолчанию. Современные приложения часто держат minSdk на уровне 24 или 26 ради старых устройств, поэтому вектор до сих пор живой.

Похожим образом ломается разбор путей (path traversal). В корпоративном приложении известного вендора, которое считалось защищённым, сотрудники пересылали друг другу zip-архивы и смотрели их содержимое прямо в чате. Распаковку написали сами вместо готовой библиотеки. В архив положили файл с путём, где стоят две точки и слеш, и он распаковался не в кэш приложения, а куда нужно атакующему. Так можно переписать файлы приложения или вытащить данные наружу.

FileProvider при неправильной настройке отдаёт произвольные файлы, а не те, что задумал разработчик. А через шаринг вместо картинки приложение можно заставить отправить наружу незашифрованный файл с токеном из приватной директории.

Реверс Android-приложений: почему секреты в коде не спрятать

Android-приложение легко реверсится: DEX однозначно раскладывается в smali и восстанавливается до читаемой Java. Разработчики надеются на обфускатор R8, но он переименовывает классы, методы и переменные, а не прячет секрет. Если пароль захардкожен, в релизной сборке он остаётся на месте.

Можно разложить секрет по битам, прогнать через XOR и спрятать за сдвигами и ассемблерными трюками. Это не помогает. Секрет где-то используется, а значит, в этой точке он соберётся обратно и придёт, например, в класс Cipher уже в готовом виде. Искать по бинарнику, где его спрятали, не нужно: достаточно дождаться, пока ключ появится в памяти, и снять его хуком Frida.

Прятать в клиентском приложении что-либо вообще бессмысленно. Надо изначально делать архитектурно правильно.

Игорь Кривонос

Что находят в сборках:

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

Android или iOS: что безопаснее на самом деле

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

1. 1

   Подключи iPhone к Mac.

2. 2

   Сделай резервную копию без пароля.

3. 3

   Открой её инструментом для просмотра бэкапов. Там часто лежит много лишнего.

У Android богаче IPC и платформа открытее, поэтому способов ошибиться больше. У iOS многие клиентские векторы идут со словом «но»: нужен бэкап или приложение из App Store, ведь ставить программы из сторонних источников там без взлома почти нигде нельзя. На практике Android требуется чаще, но если у заказчика приложения под обе платформы, iOS тоже проверяют обязательно.

Зачастую Android-приложение защищено лучше, чем iOS: все слышали про дыры Android, и разработчики сами ищут, как защититься ещё больше. В iOS открываешь дверь ногой, а там всё лежит открыто.

Игорь Кривонос

Защита мобильного приложения в недоверенной среде

Безопасная разработка и поиск уязвимостей это одна задача. Вторая это защита мобильного приложения в недоверенной среде. Пользователь может не знать, что на его устройстве повышены привилегии через эксплойт под его модель или что в noname-устройстве стоит бэкдор. Но чаще он сам ставит вредонос: ломаную игру или apk «смотри твои фоточки», и выдаёт ему разрешения на SMS, звонки и установку приложений. Эксплойты дорогие и прицельные, массово ими не ломают.

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

• overlay перекрывает экран поддельными формами и заставляет нажать не туда;
• accessibility-сервис в Android сам нажимает кнопки, считывает весь интерфейс и может перебирать PIN-код;
• атака по времени отрисовки пикселей позволяет вычислить, что написано на экране. Защита тут только логическая: не показывать критичные данные дольше нескольких секунд или не показывать вовсе.

Разработчики смеются: пользователь сам виноват, что поставил себе малварь. Я говорю: да, мы тоже виноваты, потому что мы должны защищать нашего пользователя.

Игорь Кривонос

Настройка окружения: Frida, эмулятор Android и Mac для iOS

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

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

Что помогает:

• Linux или Mac вместо Windows: на Windows отдельно ставят Java и Python и постоянно упираются в мелочи;
• для iOS Mac с Xcode и старый iPhone под джейлбрейк, симулятор iOS устройство не заменяет;
• эмулятор Android на API 31 как средний вариант, а под старые векторы эмулятор постарше, например API 28 для доступа к файлам в WebView;
• Frida для хуков и инъекций на обеих платформах. Важнее понимать и запускать чужие скрипты, чем писать свои;
• автоматизация рутины на Python или Bash, чтобы информация о приложении собиралась за пару кликов.

Методология OWASP Mobile: статический и динамический анализ

Методология исследования мобильных приложений опирается на OWASP Mobile, открытый стандарт сообщества: статический анализ сборки и кода, динамический анализ в рантайме и проверка API.

Приватного API не существует: любой может поставить приложение и посмотреть его запросы и код.

Учитывай и антифрод: приложения собирают данные об устройстве и видят эмулятор. Около 95% приложений на это не реагируют, но строгие сервисы, например государственные, могут сразу заблокировать аккаунт.