По данным IBM Security, средняя стоимость утечки данных превысила $4,8 млн. Но мобильные приложения - особый случай: атакующий владеет клиентом. Скачал APK из магазина, разобрал за пять минут через jadx, нашёл захардкоженный API-ключ в
strings.xml, подключил Frida к процессу - и серверная логика, какой бы идеальной она ни была, стала прозрачной. Серверы под контролем компании. Устройство пользователя - нет. Это и есть фундаментальное отличие мобильного пентеста от всего остального.Карта темы: от методологии до конкретных техник
Почему пентест мобильных приложений - не «веб-тест на маленьком экране»
Веб-приложение живёт на серверах компании. Мобильное - файл, который пользователь скачал на устройство, к которому у компании нет доступа. Всё, что на клиенте, по определению скомпрометировано.В классическом веб-пентесте работаешь с HTTP-запросами через браузер. Поверхность атаки ограничена: API, формы ввода, cookies. В мобильном пентесте поверхность расширяется кратно:
- Клиентское хранилище - SharedPreferences, SQLite, Keychain/KeyStore, файлы в песочнице. По MASVS-STORAGE, любые данные вне защищённого хранилища - потенциальная утечка (техника T1552.001 - Credentials In Files).
- Межпроцессное взаимодействие - Android Intents, Content Providers, iOS URL Schemes, Universal Links. Каждый экспортированный компонент - точка входа.
- Бинарный код на устройстве - DEX-файлы в Android легко декомпилируются через jadx, iOS-бинарники анализируются через class-dump и Hopper. Обфускация замедляет, но не останавливает (техника T1027 - Obfuscated Files or Information).
- Сетевой трафик - перехват через прокси после установки корневого сертификата (T1553.004 - Install Root Certificate) и отключения SSL Pinning.
- Рантайм-модификация - Frida позволяет хукать любой метод прямо во время работы приложения, подменяя логику аутентификации, проверки лицензии или root-detection.
Место в цепочке атаки
Тестирование безопасности мобильных приложений охватывает несколько этапов kill chain: от разведки (сбор APK/IPA, анализ permissions, определение серверных endpoints) через начальный доступ (эксплуатация deeplink, обход аутентификации) до пост-эксплуатации (извлечение токенов, эскалация привилегий через серверное API). Клиентская часть здесь - полноценный вектор, а не просто интерфейс к серверу.Когда мобильный пентест не нужен
Если приложение - обёртка над WebView без локального хранения данных и нативной логики, пентест мобильной части даст мало. Эффективнее сосредоточиться на API и веб-компоненте. Не надо тестировать ради галочки.OWASP Mobile Top 10 и MASVS: каркас методологии мобильного аудита
Любой структурированный пентест мобильных приложений начинается с выбора методологии. Два документа формируют каркас: OWASP Mobile Top 10 (каталог рисков) и OWASP MASVS/MASTG (стандарт верификации и руководство по тестированию).
OWASP Mobile Top 10
Десятка критичных рисков мобильных приложений обновляется по мере изменения угроз. Категории, которые находим практически в каждом аудите:- Insecure Data Storage - токены в открытом виде, незашифрованные базы, секреты в
plist-файлах. Самая частая находка в реальных проектах - и самая обидная для разработчиков. - Insecure Communication - отсутствие TLS, слабая реализация certificate pinning, утечка данных через HTTP.
- Insecure Authentication / Authorization - клиентская валидация ролей, предсказуемые сессионные токены, отсутствие проверки на серверной стороне.
- Insufficient Cryptography - использование устаревших алгоритмов, хранение ключей рядом с зашифрованными данными. Ключ и замок в одном ящике - классика.
OWASP MASVS и MASTG
MASVS определяет, что проверять. MASTG - как. Три домена непосредственно связаны с мобильной спецификой:- MASVS-STORAGE - безопасное хранение: KeyStore/Keychain, шифрованные базы, отсутствие чувствительных данных в песочнице в открытом виде.
- MASVS-NETWORK - TLS, certificate pinning, отсутствие clear-text HTTP, безопасная сетевая конфигурация.
- MASVS-PLATFORM - WebView, IPC, deep links. Здесь концентрируются платформенно-специфичные риски: Android Intents, iOS URL Schemes.
Практический takeaway
При начале аудита открывайте MASTG-чеклист по целевой платформе и идите по каждому контролю. Это гарантирует полноту покрытия и структурированность отчёта. Без чеклиста неизбежно что-нибудь пропустите - проверено на собственных шишках.Статический анализ APK и IPA: 5 находок, которые видны до запуска приложения
Статический анализ - первый этап после получения пакета. APK распаковывается черезapktool d target.apk, DEX-код декомпилируется через jadx в читаемую Java. IPA-файл - zip-архив с бинарником Mach-O, который анализируется через class-dump и дизассемблеры.Что ищем в первую очередь
- Захардкоженные секреты - API-ключи, токены Firebase, credentials от staging-серверов. Grep по паттернам
api_key,secret,password,AWS,firebaseнаходит их в строковых ресурсах,BuildConfig.java,Info.plist. Удивительно, как часто это срабатывает. - Серверные endpoints - полный список URL-адресов бэкенда, включая staging- и dev-серверы, которые разработчики забыли удалить. Часто dev-эндпоинты не требуют аутентификации вообще.
- Компоненты без защиты - экспортированные Activity, Content Providers и Broadcast Receivers в Android (анализ
AndroidManifest.xml). На iOS - зарегистрированные URL Schemes. - Криптографические ошибки -
ECB-режим,MD5/SHA1для хеширования паролей, ключи шифрования в коде рядом с данными. По OWASP A02:2021 (Cryptographic Failures) это одна из критичных категорий. - Небезопасные сетевые конфигурации -
android:usesCleartextTraffic="true"в манифесте, отсутствие или неполная конфигурация Network Security Config, разрешение clear-text на произвольные домены.
Автоматизация
MobSF (Mobile Security Framework) выполняет статический анализ APK и IPA автоматически: сканирует манифест, проверяет permissions, ищет hardcoded secrets, анализирует криптографические вызовы. Результат - HTML-отчёт с severity-рейтингом. Но MobSF выдаёт массу false positives, особенно на обфусцированных приложениях - каждую находку нужно верифицировать руками. Отчёт MobSF без ручной верификации - это не результат пентеста, а черновик.Подробный разбор процесса декомпиляции и восстановления исходного кода: Реверс-инжиниринг APK: от распаковки до восстановления исходного кода.
Динамический анализ мобильных приложений: перехват трафика и обход SSL Pinning
Статический анализ показывает потенциальные проблемы. Динамический - подтверждает их в рантайме: приложение работает, трафик перехватывается, поведение модифицируется на лету.
Цепочка: прокси - сертификат - SSL Pinning bypass
Стандартная последовательность для перехвата трафика мобильного приложения:- Настроить Burp Suite или mitmproxy на прослушивание всех интерфейсов (порт 8080).
- Установить CA-сертификат прокси на устройство. На Android 7+ пользовательские сертификаты не доверяются по умолчанию - нужен root-доступ или патчинг Network Security Config.
- Обойти SSL Pinning. Приложение проверяет сертификат сервера против вшитого пина - стандартный прокси-сертификат отклоняется.
Обход SSL Pinning через Frida
SSL Pinning bypass - первый барьер в динамическом анализе мобильных приложений. Frida хукает функции проверки сертификата в рантайме. Черезobjection (обёртка над Frida) обход делается одной командой:
Код:
objection -g com.target.app explore
# внутри objection:
android sslpinning disableios sslpinning disable. Objection перехватывает вызовы TrustManager (Android) и SecTrustEvaluate (iOS), подменяя результат проверки на «доверен».Ограничения: кастомные реализации pinning, которые не используют стандартные системные API, требуют написания собственных Frida-скриптов. Приложения на Flutter или с нестандартными TLS-библиотеками (BoringSSL напрямую) стандартными скриптами не обходятся - придётся копать глубже.
Runtime-модификация
После обхода pinning открывается полный трафик между приложением и бэкендом. Дальше:- Подмена параметров запросов (IDOR, повышение привилегий).
- Повторная отправка запросов с изменёнными токенами.
- Анализ ответов сервера на наличие избыточных данных.
- Тестирование бизнес-логики: обход лимитов, фарм бонусов, манипуляции с геолокацией.
Пентест Android приложений: 4 вектора, которые ломают защиту
Android - открытая платформа с тысячами прошивок, модификаций ядра и уровней API. Это одновременно упрощает пентест (root получить проще) и усложняет его (фрагментация создаёт непредсказуемое поведение). Зоопарк, одним словом.
Вектор 1: Insecure Data Storage
SharedPreferences, SQLite-базы, файлы в/data/data/com.app.name/. На рутованном устройстве всё это доступно напрямую. Типичные находки: OAuth-токены в plain text, PIN-коды в shared_prefs, полная история транзакций в незашифрованном SQLite. Проверка по MASVS-STORAGE занимает 15 минут и почти всегда даёт результат. На одном проекте так нашли полный набор credentials от админки - прямо в shared_prefs.Вектор 2: Экспортированные компоненты и deeplink
Каждый<activity> с android:exported="true" и <intent-filter> - потенциальная точка входа. Через adb shell am start можно вызвать Activity напрямую, минуя аутентификацию. Deep links (app://action?param=value) при отсутствии валидации позволяют инжектить произвольные параметры - вплоть до XSS в WebView.Подробный разбор: Пентест Android приложений: от декомпиляции APK до эксплуатации deeplink и WebView.
Вектор 3: Обход root-detection
Приложения с чувствительными данными (банкинг, MDM) проверяют наличие root. Проверки обычно сводятся к поиску файлов (/su, /system/app/Superuser.apk), проверке системных свойств или вызову Runtime.exec("which su"). Frida хукает эти проверки и возвращает «чисто». Magisk Hide/Zygisk маскирует root от приложений на уровне системы.[Применимо: white box / grey box, реальное устройство с root]
Пошаговая инструкция: Пентест Android-приложений: от настройки окружения до обхода root-detection и SSL pinning.
Вектор 4: Inter-Process Communication через Binder
Android Binder - основной механизм IPC между процессами. Некорректная реализация Content Providers, незащищённые bound Services и широковещательные Intents позволяют сторонним приложениям получать данные или вызывать привилегированные функции. Drozer автоматизирует перечисление атакуемых IPC-компонентов (проект поддерживается WithSecure, обновления нерегулярны - последний релиз стоит проверить перед использованием).Глубокий разбор механизма: WOOTdroid: аудит Android Binder IPC без семантического разрыва.
Пентест iOS приложений: от jailbreak до эксплуатации runtime
iOS - закрытая среда с code signing, sandbox и аппаратным Secure Enclave. Без jailbreak динамический анализ сильно ограничен, а Apple активно борется с инструментами модификации.
Jailbreak как предусловие
Полноценный пентест iOS приложений требует jailbreak. Для iOS 15-16 используется palera1n (полупривязанный), для более ранних версий - checkra1n или unc0ver. После jailbreak ставится менеджер пакетов (Sileo/Cydia), через который устанавливается frida-server.[Применимо: white box / grey box, реальное устройство с поддерживаемой версией iOS]
Критический момент, на который наступают все: версия frida-server на устройстве должна совпадать с версией frida-tools на рабочей станции. Несовпадение версий - причина 80% ошибок подключения на начальном этапе. Запомните это и сэкономите себе часы.
Три гайда покрывают разные аспекты iOS-пентеста:
- Пентест iOS приложений: от jailbreak до обхода SSL Pinning - базовая настройка и сертификаты
- Пентест iOS приложений: от установки Frida до обхода jailbreak detection - борьба с защитами приложения
- Пентест iOS приложений: от jailbreak до анализа бинарников и обхода биометрии - продвинутый анализ
Специфика iOS-хранилища
iOS Keychain - защищённое хранилище, но при jailbreak его содержимое дампится черезkeychain-dumper или Frida-скрипты. Plist-файлы в песочнице приложения часто содержат токены и конфигурации в открытом виде. NSUserDefaults - аналог SharedPreferences на Android - типичное место утечки чувствительных данных. Разработчики почему-то считают, что «на iOS и так всё защищено» - и кладут секреты в NSUserDefaults.Реверс-инжиниринг iOS-бинарников
Бинарники iOS-приложений зашифрованы при загрузке из App Store. Для анализа их нужно расшифровать (через Clutch илиfrida-ios-dump), после чего Mach-O файл анализируется через class-dump (выгрузка Objective-C классов и методов) и дизассемблеры. Class-dump не работает со Swift-only приложениями - тут придётся лезть в Hopper или Ghidra.Подробный разбор: Реверс-инжиниринг iOS приложений: IPA-анализ, class-dump и Frida глазами защитника.
Атаки на уровне платформы
iOS не ограничивается уязвимостями внутри приложения. Механизмы push-уведомлений, iCloud-бэкапы, Handoff между устройствами - всё это расширяет поверхность атаки за пределы самого приложения. Показательный пример: как через push-инфраструктуру Apple можно было получить доступ к метаданным сообщений Signal.8 инструментов для пентеста мобильных приложений: trade-off таблица
Выбор инструментов определяет эффективность аудита. Ниже - не проплаченый обзор, а реальная картина с ограничениями каждого инструмента.| Инструмент | Назначение | Платформа | Ограничения | Когда использовать |
|---|---|---|---|---|
| Frida | Динамическая инструментация, хукинг | Android, iOS | Требует root/jailbreak; на iOS без jailbreak - только gadget-режим с пересборкой IPA; детектируется продвинутыми anti-tampering решениями | Обход pinning, root/jailbreak detection, runtime-анализ |
| objection | CLI-обёртка над Frida | Android, iOS | Стандартные скрипты не обходят кастомные pinning-реализации; нет поддержки Flutter из коробки | Быстрый pinning bypass, дамп keychain, перебор файловой системы |
| Burp Suite | Перехват HTTP/S-трафика | Любая | Не видит не-HTTP трафик (gRPC без HTTP/2, binary протоколы); требует ручной настройки прокси на устройстве | Анализ API, подмена параметров, тестирование авторизации |
| MobSF | Автоматический статический и динамический анализ | Android, iOS | Много false positives; динамический анализ iOS ограничен; не работает с обфусцированным нативным кодом | Первичный скан, быстрый черновик отчёта |
| jadx | Декомпиляция DEX в Java | Android | Обфусцированный код читается плохо; некоторые конструкции Kotlin некорректно декомпилируются | Анализ логики, поиск hardcoded secrets |
| apktool | Распаковка/пересборка APK | Android | Пересобранные APK могут не запускаться из-за проверки целостности; не декомпилирует в Java (только smali) | Патчинг smali-кода, анализ ресурсов и манифеста |
| Drozer | Аудит IPC-компонентов Android | Android | Проект WithSecure, обновления нерегулярны; требует agent на устройстве | Перечисление экспортированных компонентов, атаки на Content Providers |
| class-dump | Выгрузка ObjC-классов из Mach-O | iOS | Не работает со Swift-only приложениями; требует расшифрованный бинарник | Быстрый обзор API iOS-приложения |
Критерии выбора
Этот набор покрывает полный цикл аудита: статический анализ (jadx, apktool, class-dump, MobSF) -> динамический анализ (Frida, objection, Burp Suite) -> аудит IPC (Drozer). В конкретном проекте набор определяется платформой (Android/iOS/обе), типом приложения (нативное/гибридное/Flutter) и уровнем защит. Для Flutter-приложений, например, стандартный стек не подходит - нужны специализированные Frida-скрипты для BoringSSL, и об этом лучше знать до начала работы, а не после трёх часов безуспешных попыток обойти pinning.Лаборатория для мобильного пентеста: минимальный стек за один вечер
Требования к окружению
| Параметр | Android-стенд | iOS-стенд |
|---|---|---|
| Рабочая станция | (GNU/Linux)/macOS/Windows, 16 ГБ RAM (8 ГБ минимум для эмулятора) | macOS (обязательно для Xcode), 16 ГБ RAM |
| Эмулятор/устройство | Android Studio AVD или Genymotion; физическое устройство с root | Физический iPhone/iPad с поддерживаемой для jailbreak версией iOS |
| Прокси | Burp Suite Community/Pro или mitmproxy | Burp Suite Community/Pro |
| Инструментация | Frida + frida-tools, objection (pip install frida-tools objection) | Frida + frida-server (через Sileo/Cydia, версия = frida-tools на рабочей станции) |
| Статический анализ | jadx, apktool, MobSF (Docker) | class-dump, MobSF, Hopper/Ghidra |
Android: эмулятор или реальное устройство
Для базового анализа достаточно Android Studio AVD с образом без Google Play (он позволяет получить root черезadb root). Genymotion удобнее для длительных проектов - быстрее рендерит, хорошо интегрируется с adb. Физическое устройство с Magisk предпочтительнее для приложений с проверками эмулятора - а таких всё больше.iOS: без устройства - почти никак
Полноценный iOS-эмулятор для пентеста не существует. Xcode Simulator не запускает ARM-бинарники из App Store. Для полного динамического анализа нужен физический iPhone с jailbreak. Альтернатива для ограниченного анализа - Corellium (облачный, платный, от $99/мес за один инстанс).Пошаговую инструкцию по сборке лаборатории мы описали в отдельном гайде: Лаборатория для мобильного пентеста: от эмулятора до перехвата трафика за один вечер.
Реверс-инжиниринг мобильных SDK и supply chain атаки
Приложение - не монолит. Современное мобильное приложение включает десятки сторонних SDK: аналитика, рекламные сети, платёжные шлюзы, push-сервисы. Каждый SDK - потенциальный вектор supply chain атаки. И проверяют их значительно реже, чем собственный код.
SDK poisoning: реальная угроза
Инцидент с уязвимостью CocoaPods (менеджер зависимостей iOS) показал, что скомпрометированный пакет может попасть в тысячи приложений одновременно. Атакующий модифицирует SDK так, чтобы он выполнял легитимные функции, параллельно собирая данные или предоставляя удалённый доступ. Матрёшка: внутри нормальной библиотеки - RAT.Конкретный разбор такого сценария: Reverse engineering мобильного SDK: разбор SilentSDK - RAT внутри легитимной библиотеки.
Что проверять при аудите зависимостей
- Список permissions, которые запрашивает SDK (не приложение, а конкретная библиотека) - зачем SDK для аналитики просит доступ к камере?
- Сетевые вызовы из кода SDK - домены, к которым обращается библиотека.
- Наличие обфускации в SDK при отсутствии обфускации в основном приложении - это может указывать на скрытую функциональность.
- Версия SDK и её соответствие текущей стабильной - устаревшие версии часто содержат известные уязвимости (OWASP A06:2021 - Vulnerable and Outdated Components).
Место в kill chain
Supply chain атака через SDK - initial access. Скомпрометированная библиотека уже работает внутри периметра приложения, имеет доступ к песочнице, сетевым запросам и данным пользователя. Обнаружение требует глубокого реверса и сравнения поведения SDK с его документированным API. Автоматика тут бессильна.Как выбрать вектор атаки: decision tree мобильного пентестера
При начале аудита мобильного приложения количество возможных проверок превышает сотню. Структурированный подход к выбору вектора экономит время и позволяет сфокусироваться на наиболее вероятных уязвимостях.Алгоритм выбора
- Определить тип приложения: нативное (Java/Kotlin, Swift/ObjC), гибридное (React Native, Cordova), Flutter.
- Нативное -> полный цикл: статический + динамический анализ + IPC.
- Flutter -> стандартные Frida-скрипты для pinning bypass не работают; нужны специализированные скрипты для BoringSSL. Это сразу добавляет полдня к таймлайну.
- Гибридное -> фокус на WebView-уязвимости (JavaScript injection, XSS) и bridge-интерфейсы.
- Оценить уровень защит: есть ли root/jailbreak detection, SSL pinning, обфускация, anti-tampering.
- Нет защит -> начать с перехвата трафика и анализа хранилища (быстрые результаты за первый час).
- Базовые защиты -> обход через objection/Frida стандартными скриптами.
- Продвинутые защиты (integrity checks, native anti-tampering) -> потребуется реверс нативных библиотек.
- Определить модель угроз заказчика: что критичнее - утечка данных, обход бизнес-логики или компрометация серверной части через мобильный клиент.
- Утечка данных -> MASVS-STORAGE, анализ хранилища, трафика.
- Бизнес-логика -> фрод-сценарии: фарм бонусов, обход лимитов, манипуляции с геолокацией.
- Серверная часть -> API-тестирование через перехваченные запросы, IDOR, broken access control.
- Выбрать контекст: black box (только APK/IPA из магазина) vs grey box (доступ к исходному коду, тестовые учётные записи) vs white box (полный доступ).
- Black box -> начать со статического анализа APK/IPA, затем динамический.
- Grey box -> параллельный code review и динамическое тестирование. В реальных проектах это самый частый сценарий.
- White box -> полный code review с фокусом на криптографию и авторизацию.
Куда движется мобильный пентест
Ежегодные аудиты перестают быть достаточными. PCI DSS v4.0 ужесточает требования к регулярности тестирования, а атакующие переключаются на API и supply chain. SDK poisoning, fake-app campaigns в сторах, ИИ-генерированный вредоносный код - угрозы мобильных приложений смещаются от классических уязвимостей клиента к цепочкам поставок и серверным API.Практический вывод: пентест мобильных приложений встраивается в CI/CD. Статический анализ через MobSF интегрируется в pipeline, Frida-скрипты для regression-тестов запускаются автоматически при каждом релизе, а ручной аудит фокусируется на бизнес-логике и нетривиальных сценариях, которые автоматика не покрывает.
Для начинающих пентестеров путь один: собрать лабораторию, взять DIVA (Damn Insecure and Vulnerable App) или InsecureBankv2, пройти по MASTG-чеклисту руками. Теория без практики в мобильном пентесте бесполезна - каждое устройство ведёт себя по-своему, каждая прошивка вносит нюансы.
Большинство команд, которые проводят анализ защищённости мобильных приложений, работают по одному шаблону: запустили MobSF, получили отчёт, добавили скриншоты трафика из Burp, оформили PDF. Формально аудит проведён. По факту - проверены те же пять пунктов, которые и так очевидны: «нашли токен в SharedPreferences, рекомендуем использовать Keystore». Это не пентест. Это checkbox compliance.
Реальные уязвимости мобильных приложений всё чаще прячутся не в хранилище и не в сетевом трафике, а в бизнес-логике: гонка состояний при проведении платежей, обход серверной валидации через подмену параметров в нестандартном порядке, эскалация привилегий через цепочку из трёх безобидных API-вызовов. Автоматика этого не видит. А ручной анализ требует понимания предметной области заказчика: как работает скоринг, какова логика начисления бонусов, где проходит граница между ролями пользователей.
В ближайшие пару лет разрыв между автоматическим сканированием и экспертным пентестом будет только расти. Flutter, Kotlin Multiplatform, серверный рендеринг в мобильных приложениях, gRPC вместо REST - каждое технологическое решение создаёт новые слепые зоны для стандартных инструментов. Команды, которые не вкладываются в глубокое понимание платформенных механизмов (Binder IPC, XPC, runtime hooking), будут выдавать отчёты всё менее релевантные реальным угрозам. Мобильному пентесту нужны не новые сканеры, а люди, которые умеют думать как разработчик мобильного приложения - и одновременно как тот, кто его ломает.
Последнее редактирование модератором:
