Иногда можно столкнуться с такой неприятной вещь как TLS Fingerprint, но еще более неприятно, когда провал проверки сопровождается многочасовым баном. Бороться с этим можно несколькими способами.

1. Использовать расширение Awesome TLS для Burp Suite. Там можно даже выставить кастомный fingerprint чтобы все было совсем хорошо. Но расширение работает весьма неторопливо и не всегда стабильно
2. Перехватывать трафик прямо на устройстве через PCAPDroid и перенаправлять его куда-то еще. Пример для Wireshark: curl -NLs http://192.168.1.12:8080 | Wireshark -k -i -
3. Также иногда с этим справляется Charles, но это не точно.

А если вам просто нужно отправить какой-то запрос на хост и не спалиться по фингерпринту, то можно попробовать использовать curl прямо в консоли девайса.
#aht

Если попалось приложение с библиотекой Navigation от Google, то можно очень быстро найти все диплинки, которые обрабатывает приложение. Для этого ищем по ключевому слову <deepLink и получаем красивый список со всеми параметрами и типами данных. Но этот фокус работает только если навигация реализована в XML файлах. А так бывает не всегда, и некоторые особо увлеченные разработчики делают все в коде.
#aht

В экосистемах приложений часто встречается такая практика как кастомные разрешения. Некое "главное" приложение объявляет разрешение вроде my.cool.app.READ_STORAGE. чтобы другие приложения из той же экосистемы могли его использовать. Если protectionLevel такого разрешения пустой или выставлен в normal, то все круто - берем и пользуемся. Но чаще всего там стоит signature, что уже является некоторой проблемой. Но signature - не приговор! У нас же экосистема! А значит довольно большая поверхность атаки. Первое, что надо сделать - найти все приложения, которые запрашивают это разрешение. Самый простой и незамысловатый способ получить эту информацию - drozer. Ставим все приложения вендора на девайс, подключаемся и выполняем команду run app.package.list -p my.cool.app.READ_STORAGE. В ответ получаем список приложений которые нужно взломать чтобы получить заветные права.
#aht

Часто ли разработчики полностью переходят в информационную безопасность? Случается 😉 Набросал немного своих мыслей на этот счет и попытался показать альтернативный путь развития для уже состоявшихся разработчиков. Приятного чтения!

В приложениях часто можно найти dev/stage сервера, которые используются на этапе разработки. Если повезло, то в приложении также есть дебаг-панель позволяющая удобно переключаться между этими серверами, что неплохо расширяет поверхность атаки. Но если дебаг-панели нет или она по каким-то причинам недоступна, то переключить приложение на такой сервер можно прямо в BurpSuite. Идем в настройки proxy, выбираем вкладку Request handling и в поле Redirect to host указываем адрес нужного сервера. Все. Ничего не надо пересобирать и заниматься прочей ерундой. Способ не идеален, т.к. приложение может ходить на несколько серверов сразу, но в большинстве случаев этот подход здорово экономит время.
#aht

Начиная с Java 9 стал доступен инструмент JShell. Фактически это такой же REPL как в python или других языках, но только для Java. И это весьма удобная штука. Особенно когда в приложениях попадаются конструкции вида Class a = Class.forName(new String(new byte[]{106,97,118,97,46,108,97,110,103,46,83,116,114,105,110,103})); и нужно быстро понять что это за класс вообще. Да, эти байтики можно разобрать чем угодно. А если там используется какая-то специфика Java, которую не всегда просто переложить на другие языки? Подобные механизмы защиты также могут включать в себя отдельные библиотеки в виде jar-файлов и все это сильно усложнит вам жизнь при попытке разобрать это в каком-нибудь питоне. А в jshell можно просто закидывать java-код и играть с ним как душе угодно. Сторонние jar-ники также можно подкидывать через параметры команды, и вообще посмотрите на выдачу jshell -h, там есть интересные опции.
#aht

Современные приложения на Xamarin хранят dll-ки в XABA архиве, который лежит в ресурсах приложения по пути assemblies/assemblies.blob (могут быть также разделены по архитектурам). Там же рядом лежит assemblies.manifest с списком всех сборок. Для того чтобы извлечь все сборки в виде dll-файлов и спокойно реверсить, можно воспользоваться утилитой pyxamstore. Она также умеет собирать все обратно.
#aht

Там ребята опять собираются делать Standoff Hacks в ноябре, и, по уже сложившейся традиции объявили конкурс чтобы на мероприятие попали не только известные (и всем надоевшие!) личности, но и свежая кровь. Всего есть 6 инвайтов и 1 бонусный. Все условия читайте здесь, повторяться не хочу. От себя добавлю, что мероприятие действительно крутое. Позволяет очень сильно подумать мозгами и посоревноваться с очень толковыми людьми. Я был на двух прошлых, и впечатления исключительно положительные. Вопрос: какого Фрейда ты пишешь это в канале про мобилки? Ответ: что на первом, что на втором хаксе в скоупе были мобилки. Очень много мобилок. Не за все из них платили хорошо и местами мне приходилось сильно бодаться с триажерами, но все равно это очень полезный и интересный опыт. Давайте уже развивать мобильное багбаунти, а то все веб да веб...

P.S. А на этот хакс меня пока не позвали... Видимо придется в конкурсе участвовать 🌚

Перехват трафика приложений на Xamarin выглядит довольно изученной темой. Но так выглядит ровно до тех пор пока не сталкиваешься со странностями из-за которых почему-то ничего не работает как нужно. Про перехват трафика я уже писал большую статью, и если у вас что-то не получается с перехватом, то лучше обратиться к ней. Но базовый алгоритм для Xamarin я все же напишу здесь:
1. Сбросить все настройки прокси, которые были сделаны до этого (wifi или глобальный). Смартфон должен иметь чистый доступ к интернету.
2. Убедиться, что все MITM-сертификаты установлены корректно как в пользовательское, так и в системное хранилище. А лучше накатить их заново выгрузив из текущей версии burp.
3. В настройках прокси, в burp, выставить галочку Support invisible proxy (во вкладке Request handling)
4. Закинуть на смартфон этот скрипт, зайти в adb под root-ом и выполнить его.

Если ничего не заработало, то путь самурая начинается здесь...
#aht

Порой очень хочется поработать с т.н. "скрытым" API в Android. Есть несколько способов дотянуться до этой возможности. Самый простой - включить эту настройку через adb с помощью команды: adb shell settings put global hidden_api_policy 1. Но это может не сработать, и getDeclaredMethod будет падать с ошибкой. Тогда на помощь приходит вот такой трюк:

val parcel = Parcel.obtain()  
val writeString8 = parcel::class.java.declaredMethods.filter { it.name == "writeString8" }[0]
writeString8.invoke(parcel,scheme)

Здесь метод writeString8 получается не напрямую, а через поиск по коллекции методов. Кому интересно почему это работает - смотрите исходники.
#aht

Умение обходить фильтры - очень важный навык. Обычно он складывается из двух компонентов: развитого аналитического мышления и знания трюков. Сегодня будут трюки. Представим себе такой синтетический фильтр:

val input = "http://evil.com"

val filter = """^(https?)://.*@?evil\..+""".toRegex()

if (filter.matches(input)) {
  throw MalformedURLException("Banned URL!")
}

val okhttp = OkHttpClient()
val req = Request.Builder().url(URL(input)).build()

Есть мысли как его обойти? Подумайте 30 секунд.

Один из способов - модифицировать input любым из этих способов:
- url:http://evil.com
- http://evil.com (первый символ - пробел)

Но проверка по черному списку встречается все реже. Кажется, что разработчики начинают что-то подозревать 😰
#aht

Продолжая тему фильтров стоит сказать про более сложный в эксплуатации вариант - фильтрация по белому списку. Приложение может принимать только заданный список доменов и отклонять все остальные. Но варианты эксплуатации есть и в этом случае. Нужно сместить фокус внимания на список разрешенных доменов и искать проблемы уже в них. Допустим мы хотим грузить произвольный контент в WebView. В этом случае может помочь найденная на одном из доменов белого списка уязвимость CRLF. Чаще всего ее можно трансформировать в возможность внедрения произвольного HTML, а там уже и XSS и все остальные приятные штуки с этим связанные. Сам эксплойт может выглядеть как-то так:

val payload = "%0d%0aContent-Length:35%0d%0aX-XSS-Protection:0%0d%0a%0d%0a23%0d%0a<noscript%20onload=alert(document.domain)>%0d%0a0%0d%0a/%2f%2e%2e"  
  
val i = Intent().apply {  
    setClassName("com.app.victim", "com.app.victim.WebViewActivity")  
    putExtra("url", "https://whitelisted.victim.com/$payload")  
} 
  
startActivity(i)

Подробнее: раз, два.
#aht

Android предоставляет весьма широкие возможности по логированию различных событий. Одним из наиболее полезных, на мой взгляд, является логирование SQL запросов, которые делают приложения. Не важно, напрямую или через ORM. В логах будут те запросы, которые непосредственно выполняет БД. Включить эту возможность можно командой: adb shell setprop log.tag.SQLiteStatements VERBOSE. После чего в logcat должны появиться логи запросов. А если поискать в исходниках Android ссылки на метод isLoggable, то можно найти другие подобные теги и включить логирование для них аналогичным способом.
#aht

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

'use strict';

var argv = {};

rpc.exports = {
    init: function (stage, parameters) {
      argv = parameters;
    },
};

Java.perform(function() {
  if (argv.debug) {
    console.log('Debug message');
  }
  console.log('Main flow');
});

Теперь, если запустить фриду вот так:
frida -U -f com.myapp -l hook.js -P '{"debug":true}', то сработает ветка условия с отладочным сообщением.
#aht

Для удобной работы с Binder есть классная утилита с весьма экстравагантным названием: BDSM. Она сильно упрощает ковыряния в этой области системы, и позволяет например получить список всех системных сервисов и их методов (если AIDL загружен), а также узнать кто в системе использует этот сервис. Для демонстрации покажу как получить инфу по всем соединениям с БД и запросам: su -c bdsm dump dbinfo

Да, все эти возможности можно получить написав свое тестовое приложение и дергая в нем Context.getSystemService(..), но во-первых это требует гораздо больше телодвижений, а во-вторых названия сервисов еще нужно добыть из документации. А с помощью утилиты, просто вбиваем JCOLOR=1 su -c bdsm list и получаем все доступные сервисы. Ну и конечно ее можно использовать в сложных пайплайнах и скриптах.
Обязательно почитайте документацию!
#aht

Это должна была быть короткая заметка в Telegram, но потом что-то пошло не так... Делюсь своими мыслями по поводу новой редакции OWASP Mobile Top Ten 2023. Обсуждения приветствуются!

Чтобы не копировать каждый раз базу данных с устройства можно воспользоваться утилитой входящей в Android Studio: View -> Tool Windows -> App Inspection -> Database Inspector. Он покажет все базы данных с которыми работает приложение и даст возможность в них поковыряться. Единственный нюанс: приложение должно иметь флаг android:debuggable=true, иначе инспектор просто не увидит такое приложение. Установить этот флаг очень просто: разбираем приложение с помощью apktool, добавляем флаг в application и собираем заново.
#aht

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

В простом варианте эти логи можно получить если в звонилке набрать "секретный код" *#*#4636#*#*. Откроется UsageStatsActivity из приложения Settings, в которой нужно ткнуть Usage statistics (другие пункты тоже обязательно потыкайте, там тоже интересно).

Более расширенную версию этих логов можно получить с помощью команды adb shell dumpsys usagestats | less и позалипать на прекрасное.

Отдельно скажу про комбинации вида *#*#<код>#*#*: их довольно много в системных приложениях, а также подобные комбинации используют обычные клиентские приложения для доступа ко всяким отладочным интерфейсам и не только.
#aht

Продолжим тему секретных кодов. Я покажу один из возможных способов их извлечения через dumpsys. Тут придется немного погрепать или что-то заскриптовать чтобы выглядело красиво, но в базовом варианте команда будет выглядеть так: adb shell dumpsys package -f | grep -A 5 "android.provider.Telephony.SECRET_CODE". Далее можно или бездумно вводить каждый код, пытаясь понять почему же он не работает, или исследовать receiver который этот код слушает.

В самих же кодах нет никакой магии. Например код *#*#225#*#* отправленный из звонилки приведет к отправке intent-а с URI: android_secret_code://225, который и будет разбирать целевой receiver. А это значит, что можно отправить такой intent из своего приложения, и если в receiver-е нет проверки на action, то он будет обработан. Так можно проэксплуатировать какую-нибудь уязвимость в receiver-е.
#aht

У ребят из Стингрей вышла статья про то, как магазины приложений проверяют приложения на уязвимости. Спойлер: очень плохо проверяют.

В общем-то для меня это довольно очевидное положение дел. Почему? Да потому что статический анализ приложений это сложно. Вероятно, если отдавать магазинам *.map файлы для деобфускации, то дело пошло бы лучше, но в здравом уме так делать никто не будет. Поэтому анализаторы вынуждены пытаться наковырять что-то в обфусцированной каше, которая может быть изначально написана на любых пришедших в голову разработчика технологиях. Даже навигация в приложениях до сих пор не стандартизирована. И скорее всего не будет =)
Короче, результат немного предсказуем и показывает что даже у Google нет нормального taint анализа и хорошо работающих подходов к автоматизированному сканированию приложений. Возможно ситуация улучшится с изобретением AGI, но это не точно ;)

В общем, господа разработчики - безопасность это ваша ответственность и никто кроме вас ее в приложении не сделает.

Ситуация: приложение хранит в keystore ключи, которые использует для шифрования/расшифровки некоторых данных в запросах. Возможности поставить хуки — нет. Нужно извлечь ключи. Сделать это на устройстве не выйдет, там hardware-backed keystore. Поэтому ставим приложение на эмулятор, проходим сценарий во время которого создаются ключи и забираем с эмулятора файл /data/misc/keystore/persistent.sqlite
Далее, делаем к этой базе запрос:

SELECT KE.id, KE.alias, BE.blob
FROM keyentry as KE  
JOIN blobentry as BE  
ON BE.keyentryid = KE.id  
WHERE KE.alias = 'secret'

Должны вернуться две записи. Одна для приватного, вторая для публичного ключа. Выгружаем содержимое поля blob в файлы blob1 и blob2 и натравливаем binwalk чтобы понять где какой ключ. Теперь выполняем команды для извлечения и перекодирования ключей:

$ openssl x509 -in blob1 -pubkey -noout > pub.pem
$ binwalk -D "private key":.der blob2
$ openssl rsa -in extracted.der -text > priv.pem

Все, теперь у нас есть ключи, которые использует приложение 😎
#aht