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

В нативных библиотеках можно найти много интересного. Но что если в приложении их штук 50, и не очень понятно с какими из них приложение работает напрямую, а какие являются зависимостями для других библиотек. Можно поискать по коду ключевое слово native, которое используется для обозначения методов вызываемых из библиотек, а можно поступить чуть-чуть проще и сразу увидеть всю возможную поверхность атаки c помощью утилиты nm. Для этого нужно распаковать приложение и выполнить следующую команду в директории с библиотеками:

$ nm -A -D *.so | grep -E "(Java_|JNI_OnLoad)" 2>/dev/null

В ответ получаем примерно следующее:

libTransform.so: 00000b8c T Java_com_huawei_location_lite_common_util_coordinateconverter_Transform_gcj02to84Native
libTransform.so: 000008ec T Java_com_huawei_location_lite_common_util_coordinateconverter_Transform_wgs84to02Native
libcrashlytics-handler.so: 00006968 T JNI_OnLoad
libcrashlytics.so: 00006f58 T JNI_OnLoad

Что помогает быстро понять какие библиотечные функции доступны в JVM мире.
#aht

Если приложение пытается бороться с фридой и не дает себя хукать, то можно попробовать поставить альтернативную сборку этого фреймворка, которая содержит полезные патчи, способные отстрелить базовые методы детекта. Патчи построены в основном на рандомизации и кодировании имен различных компонентов, чтобы понизить узнаваемость фриды для систем безопасности. Код патчей однозначно стоит изучить, потому что это хорошая отправная точка для создания собственной сборки со своим уникальным набором патчей, что позволит избегать обнаружения более успешно. Для любителей ставить фриду из модуля MagiskFrida, я сделал форк, который вместо оригинального репозитория, подтягивает уже запатченную фриду и собирает ее в модуль для Magisk. Сам форк не очень красивый, и PR-ы для улучшения приветствуются.
#aht

Классный доклад с удачным примером бинарной эксплуатации небезопасной десериализации в приложении AliExpress. Всем кто не стесняется заглядывать на уровень ниже виртуальной машины - однозначно рекомендую посмотреть.

Финальный эксплойт забирайте здесь. Пароль на архив: cc79dc9a77483e3de7c75c39bd13b41b

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

<intent-filter android:label="Перейти в приложение">  
    <action android:name="android.intent.action.VIEW" />  
  
    <category android:name="android.intent.category.DEFAULT" />  
    <category android:name="android.intent.category.BROWSABLE" />  
  
    <data  
        android:host="victim.com"  
        android:pathPrefix="/pages/sensitive/data"  
        android:scheme="https" />  
</intent-filter>

После редиректа в уязвимом приложении, появится стандартный диалог, где будет браузер и приложение хакера. Нужно пошаманить с иконкой, чтобы юзер захотел кликнуть 😋 И после клика, данные улетят в приложение злоумышленника.
#aht

Рубрика #aht прощается с вами.

Это был очередной эксперимент с контентом канала, который я считаю в общем-то удачным. Но, как и всякий эксперимент, этот тоже должен быть завершен. Я поддерживал эту рубрику практически год, и в ней вышло 49 постов, которые, судя по реакциям, были кому-то полезны. У меня есть еще идеи для контента, часть из которых я планирую начать реализовывать с начала следующего года. Как всегда — без спойлеров. Чтобы оставить себе пространство для маневра 🙃Всех с наступающим!

Короч я устал отдыхать, и решил начать год с публикации материала для новичков. Надеюсь, что он будет полезен всем кто только пришел в мобильный инфобез или собирается прийти. Возможно я буду дополнять и актуализировать этот материал, если пойму, что упустил какие-то важные детали или что-то эволюционировало слишком сильно. Всем продуктивного года! 👨‍🔬

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

Тут уже пара авторитетных изданий написали про очередную "новую", атаку на Android которая конечно же всех погубит:
- Introducing MavenGate: a supply chain attack method for Java and Android applications (Oversecured)
- Разбираемся с MavenGate, новой атакой на цепочку поставок для Java и Android-приложений (Stingray)

Если коротко: при определенных условиях (коих масса и шанс их наступления это большой вопрос) можно залить вредоносную библиотеку под видом легитимной и тем самым осуществить атаку на цепочку поставок.

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

В общем у кого есть желание, давайте обсудим это в комментариях. Может быть проблема действительно серьезная и всем разработчикам нужно начать боятся внимательнее следить за зависимостями, которые они затягивают в свои приложения (какой сюрприз 🫢)

Некоторое время назад разобрался и воспроизвел интересную уязвимость (CVE-2023-40121) в коде android фреймворка работающем с SQLite. Это тот редкий случай, когда в бюллетенях безопасности Android попадается действительно что-то интересное, а не всякие странные уязвимости позволяющие узнать существует какая-то иконка другого приложения или нет. Приятного чтения.

P.S. А вообще, если вам нравится все это творчество, то покидайте бустов на канал: https://news.1rj.ru/str/boost/android_guards_today 🌚
#cve

Продолжаем разбирать прикольные уязвимости. На этот раз у нас уязвимость в библиотеке Jetpack Navigation. Суть ее в том, что она позволяет стороннему приложению открыть любой экран атакуемого приложения и передать туда параметры. Круто звучит? Вот и я так думаю. А Google не считает это уязвимостью и после получения репорта нам ответили, что "поправят документацию". Не будь как Google, исправляй ошибки в своих приложениях! И знай чем грозит использование библиотеки Navigation.

У разработчиков и исследователей безопасности часто бывает проблема с мапингом тех или иных уязвимостей на OWASP Mobile Top 10. Оказалось, что в Google тоже подумали про эту проблему и сделали такой мапинг. Помимо довольно неплохих описаний рисков и рекомендаций по фиксам, есть ссылки на отчеты на платформе hackerone и всякая дополнительная инфа по уязвимостям. Теперь можно ссылаться прямо на официальную документацию по Android когда репортите очередной android:allowBackup=true на багбаунти 🌚

Результаты голосования за конкурс вышли весьма забавными. Но большинство из проголосовавших решило, что розыгрыш проходок им нужен. Так тому и быть. Будет два задания, по одному на каждый билет. Выбирать победителя буду лично я. Никакого рандома. Первое задание будет для хакеров, второе для разработчиков. Поехали!

Задание на первую проходку: В комментариях под этим постом напишите с комфортным вам уровнем подробностей, какую самую серьезную уязвимость в android приложениях, системе или библиотеках от Google вы нашли в этом году.

UPD: приложения любые, а не только от Google. На всякий случай уточнил 😉

Хочу вам рассказать про прикольную фишку студии, которая чрезвычайно полезна для реверса. Декомпиляторы (привет HexRays), страдают такой болезнью как "распад переменных". В "нашем мире" это может выглядеть вот так:

String str = this.url;
if (str != null) {
    String str2 = str;
    doCoolThings(str2);
}

Из кода видно, что str2 здесь явно лишняя, и декомпилятор просто не смог ее заинлайнить. Решить эту проблему очень просто: ПКМ на str2, далее Refactor->Inline variable. Также доступно по хоткею: ⌥⌘N (macOS)/Ctrl+Alt+N (Windows/Linux). Ну и студия также показывает подсказку прямо на месте. Если никогда не пользовались, то рекомендую.

btw, в HexRays так тоже можно 🌚

Меня часто спрашивают (да успокойся ты уже, никто тебя об этом не спрашивает...) как качать скилл анализа мобильных приложений если InsecureBank надоел? Мне всегда нравились настоящие, а не выдуманные задачи, поэтому я в основном прохладно отношусь к разного рода CTF. Чтобы развивать навыки на невыдуманных задачах их (задачи) нужно откуда-то брать. И по моему скромному мнению имеет смысл начать с анализа open source приложений, которые можно добыть из магазина F-Droid например. Чем менее уверенно вы себя чувствуете, тем менее популярное и большое вам нужно там выбрать. А все найденные уязвимости сдаете разработчику приложения. И это будет отличным продолжением для погружающихся в анализ защищенности мобилок. Дальше уже есть смысл учавствовать в bug bounty программах. Но сразу туда лезть не рекомендую. Без устойчивых навыков получите только дизмораль и никакого профита. Что касается самих программ, то их можно найти как на площадках вроде Standoff365 и BI.ZONE, так и в виде self-hosted программ у конкретных вендоров. Вендоров, которые включают мобильные приложения в скоуп BB не так много, но они есть, и вот буквально недавно ребята из Яндекса обновили описания уязвимостей и правила для участия в их программе. Легкой прогулкой это не будет, но если чувствуете, что поиск багов в open source апах вам наскучил, то заскакивайте в мобильный челлендж от Яндекса. Удачного похека!

Конкурс на вторую проходку на PHD. На этот раз для разработчиков. Опишите самую сложную уязвимость которую вам когда-либо приносили (QA, апсеки, внешний аудит, кто угодно). Вот прямо такую, что вы сначала ничего не поняли, а потом как поняли. А потом опять не поняли как фиксить, а потом поняли и пофиксили плохо и вам принесли байпас... Ну вот это вот все 😅 Самый топовый расказчик получит бесплатную проходку на PHD.

Итоги этого и прошлого этапа подведем в середине недели.