Аудит безопасности мобильных приложений: особенности, инструменты и лучшие практики

Цель аудита безопасности мобильных приложений

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

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

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

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

Более подробно об OWASP ASVS можно прочитать тут.

Соответствие тому или иному уровню гарантирует правильную реализацию ИБ-практик для защиты обрабатываемых данных. При проверке или запросе аудитора BSIMM, можно предъявлять пройденный L2 комплаенс ASVS, в котором есть перечень пунктов соответствия.

Особенности проведения аудита

Специфика первичного анализа приложения

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

1. Код.

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

1. Взаимодействия приложения и ОС.

Чаще всего под этим понимается обмен данными на уровне IPC и файловой системы, регулируемой механизмами ОС (например, Android Permissions). Поскольку ОС определяет то, как будет реализован механизм работы с ней, этот этап может быть качественно оптимизирован через использование автоматических средств анализа приложения, а также taint-анализ.

1. «Клиент-сервер».

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

Зависимость от физического оборудования

Современные приложения имеют достаточно жесткую привязку к физическому оборудованию: часто встречаются приложения, где функционал вынесен в нативные библиотеки, собранные под ARM, в то время как большинство эмуляторов — x86_64 или x64.

Мы часто используем эмуляторы для проведения анализа защищенности мобильных приложений, так как это позволяет обеспечить доступность одного стенда большому числу исследователей. Но современные приложения не всегда совместимы с такими условиями работы. Зачастую, приложения запрещают работу на эмуляторах, причем, сами разработчики такой механизм не внедряли, за них это мог сделать фреймворк. Также, очень популярным является решение удалять все ABI, кроме ARM, из конечной сборки, что приводит к невозможности запуска приложения на не-ARM эмуляторах.

Инструменты для анализа защищенности на ОС Android

Эмуляция: Android Studio Emulator, WSA, Nox

Android Studio Emulator — это типовой эмулятор, представляемый Android Studio AVD. Легок и удобен в настройке и управлении:

Windows Subsystem for Android — это механизм, предоставляемый Microsoft для Windows 11, позволяющий запускать приложения для Android. Существенный плюс — наличие сборки WSA, содержащей предустановленные Magisk и GApps. Способ установки WSA описан тут .

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

Работа с сетевым трафиком: BurpSuite, MitmProxy, ZAP, Charles Proxy.

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

Распаковка/Запаковка приложений: Apktool / Split APKs Packer (SAP)

Apktool используется для распаковки приложения в случае, если другие инструменты не смогли этого сделать, либо если нужно быстро запатчить smali-код приложения.

SAP зарекомендовал себя как стабильный инструмент для запаковки Android App Bundles в единый apk-файл.

Декомпилляция: JADX / GDAE / ByteCode Viewer

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

JADX — это декомпилятор Dex в Java. Это развиваемый открытый декомпилятор, который выдает достаточно неплохой код Java на выходе. Помимо этого, он позволяет:

• декомпилировать байт-код Dalvik в классы Java из файлов APK, dex, aar, aab и zip;
• декодировать AndroidManifest.xml и другие ресурсы из resources.arsc;
• использовать встроенный деобфускатор.

С помощью jadx-gui вы можете:

• просмотреть декомпилированный код с выделенным синтаксисом;
• быстро переходить в требуемую часть кода;
• использовать полнотекстовый поиск по коду;
• использовать встроенный отладчик smali.

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

• он написан на С++, поэтому работает чрезвычайно быстро, особенно по сравнению с аналогами;
• в нём присутствует возможность быстро вызывать механизмы шифрования и расшифрования данных:

• в нем есть модуль taint-анализа:

• он очень хорошо совместим с frida и позволяет ставить хуки на функции автоматически из отладчика:

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

• Вспомогательные фреймворки: lamda, Inspeckage (magisk-модуль)

LAMDA — это вспомогательный фреймворк для решения задач автоматизации реверс-инжиниринга и динамического анализа приложения.

Inspeckage — это Magisk-модуль, позволяющий собрать базовую информацию о приложении, а также отследить типовые вызовы функций в режиме реального времени. Можно добавлять собственные хуки, что тоже упрощает анализ приложения. Очень полезен при первом запуске приложения.

Инструменты статического анализа кода приложения: Androguard, Mariana Trench, APKHunt, QARK, Soot/SootUp

Androguard перестал поддерживаться в 2018 году, впрочем, всё равно является довольно удобным инструментом для taint-анализа приложений. Помимо большого количества внутренних модулей, также умеет строить визуальные графы исполнения приложения.

Mariana Trench проводит taint-анализ по байткоду Dalvik. Есть большой набор баз для первичного анализа приложений. В результате работы создаёт базу данных для приложения SAPP. Стоит отметить два важных момента:

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

QARK – это еще один taint-анализатор, но уже от Linkedin. Мы используем его в паре с Mariana, так как, по опыту, срабатывания не пересекаются.

APKHunt — это быстрая по времени работы утилита, которая, фактически, ищет в исходном коде приложения типовые функции, использование которых может быть небезопасным. Результат работы предоставляется в виде текстового файла с классификацией находок согласно MASVS.

Soot — это универсальный инструмент анализа скомпилированных файлов путём трансформации в виде Jimple-объектов, которые затем могут быть преобразованы в другие форматы, такие как байт-код или Dalvik-байт-код (в случае анализа Android приложений). Мы используем Soot для поиска уязвимостей с учетом особенностей конкретного приложения. Soot — это достаточно сложный инструмент, требующий хорошую инженерную подготовку, но базовые алгоритмы работы с Soot можно изучить здесь.

Инструменты динамического анализа кода приложения: Frida, Objection, Medusa

Dynamic Instrumentation Toolkit — набор инструментов, позволяющих на лету внедрять собственный код в другие приложения. Удобство утилиты перед аналогами в том, что она позволяет внедрять код быстро, в режиме реального времени, не требует компиляции и перезапуска программы. Frida — свободное программное обеспечение. Трассировка программ поддерживается на платформах Linux, Windows, macOS, Android и iOS.

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

Также, хорошей коллекцией сниппетов для Frida являются инструменты Objection и Medusa. Причем, в отличие от Objection, где сниппеты выбраны по принципу базовых проверок из MASVS/MSTG, Medusa — это набор сниппетов, которые направлены на анализ приложения, а не на анализ соответствия уровню защищенности.

Вспомогательные модули анализа Magisk

Наиболее полно об этом уже написано в статье коллег из DSec. К их списку я бы добавил только Inspeckage, о котором уже написано выше.

Инструменты для анализа защищенности приложений на ОС iOS

Работа с сетевым трафиком: BurpSuite, MitmProxy, ZAP, Charles Proxy.

Аналогична инструментам для Android.

Вспомогательные модули анализа Cydia:

Если добавить URI: https://build.frida.re, https://apt.saurik.com/cydia, https://ryleyangus.com/repo/. Станут доступны следующие инструменты: frida, cycript, wget, Apps Manager, Liberty Lite, Filza. Через wget скачать следующие инструменты:(SSLKillSwitch); (CrackerXI+).

CrackerXI+ — это утилита для работы с приложениями, установленными из AppStore, в том числе предоставляющая возможность генерации *.ipa-файла. Механизм работы улилиты схож с механизмом работы bfdecrypt. SSLKillSwitch — это один из универсальных инструментов для SSL Unpinning, хорошо зарекомендовал себя для сбора трафика большинства приложений:

Инструмент предварительного анализа: FLEX, xpcspy.

FLEX позволяет выполнить предварительный анализ приложения, включая SSL Pinning, Keychain, Heap. Требует наличие: otool, dsdump, optool. XPCSpy позволяет более глубоко изучить XPC.

Вспомогательные фреймворки: Grapefruit

Grapefruit – это фреймворк для создания динамических макетов пользовательского интерфейса на iOS. Он позволяет создавать и отображать пользовательские элементы интерфейса в реальном времени, используя текстовое описание интерфейса на языке разметки. Grapefruit также предоставляет набор инструментов для работы с этими элементами интерфейса, таких как обработка пользовательского ввода и управление анимацией.

Реверс и отладка: Hopper

Hopper Disassembler – это инструмент для обратной разработки приложений, который позволяет дизассемблировать, декомпилировать и отлаживать бинарные файлы приложений на различных платформах, таких как macOS, iOS, Windows и Linux. Одной из особенностей Hopper Disassembler является возможность написания скриптов на языке Python и использование Hopper SDK для автоматизации рутинных задач и расширения функциональности инструмента.

Инструменты динамического анализа кода приложения: Frida, Objection

Аналогично инструментам для Android.

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

1. Следовать MASVS и MSTG, которые ссылаются друг на друга. Порядок глав важен, потому что так проще отследить и оценить риски.
2. Читать hackerone и описания всяких багов, чтобы пытаться воспроизводить это у себя на стенде и стендовых приложениях или добавлять это себе в наборы правил для автоматического обнаружения в будущем;
3. Накапливать опыт разработки, часто инструменты с github будут отказываться работать, либо не решать поставленную задачу полностью. Лучше всего — использовать актуальный опыт коллег и работать со стороны ОС, встраивая свои анализаторы или маячки, чтобы у приложения было меньше триггеров для выставления флага isRooted/isJailbroken. Также, подход, использованный известным исследователем @bagipro и описанный в его статье Discovering vendor specific vulnerabilities in Android достаточно чётко указывает на необходимость такой работы. Компания Quarkslab разработала фреймворк QBDI, который решает существенную часть проблем, связанных с анализом поведения приложения. Однако в этой статье он не указан как используемый в силу того, что его, за всю практику, приходилось применять только в ряде некоторых частных случаев.
4. Заказывать аудиты безопасности мобильных приложений у компании Awillix.

Актуальные вакансии по ИБ: https://cisoclub.ru/vacancy/. Отправить резюме во все популярные IT-компании: https://cisoclub.ru/jobmail/

Больше интересного материала на cisoclub.ru. Подписывайтесь на нас: VK | Twitter | Rutube | Telegram | Дзен | YouTube.