Ситуация: приложение хранит в 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.

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

Какое время, такие и конкурсы 🤕 Разработчики не пожелали получить, проходку, поэтому обе две уходят хакерам. В результате напряженных обсуждений всем составом жюри в моей голове, из двух участников было выбрано два победителя: @qasimis и @iamwii2. С чем вас и поздравляю 🫡 Чуть позже приду в личку за информацией для оформления проходок. На PHD у нас будет мобильный стенд, так что приходите развиртуализироваться и потрындеть за уязвимости.

Команда анализа мобильных приложений компании Positive Technologies подготовила пару активностей на предстоящем Positive Hack Days.

1. Уже ставший традиционным конкурс Snatch, который в прошлом году обзавелся мобильным приложением. В мобильной части этого конкурса вы получаете приложение с уязвимостями, которые мы в том или ином виде встречали в дикой природе сами. Вам нужно будет эти уязвимости найти, отправить по ним отчеты и получить внутреннюю валюту и мерч. Задача предельно простая 😎
2. Для тех, кто еще не чувствует в себе достаточное количество мидихлорианов чтобы грузить приложение в jadx и разматывать уязвимости - смогут принять участие в викторине. Там нужно будет ответить на несколько несложных вопросов и получить охапку внутренней валюты, которую можно будет обменять на мерч (а может быть что-то еще).

Вся дополнительная информация по конкурсам и ссылки появятся сразу после старта. Следите за анонсами здесь или в любых других чатах/каналах где будут рассказывать про активности на PHD.

Ну а если вам все это тяжело или скучно и хочется прийти пообщаться про безопасность мобилок, то всех рады будем видеть. Я буду эпизодически появляться на этом стенде, так что все желающие развиртуализироваться ловите меня там. До встречи!

Немного юмора 🙃 Пока разработчики будут читать такие книги, у android хакеров всегда будет работа 😎

В свежем бюллетене безопасности Android есть неприметная CVE-шка c традиционно мутным описанием и не менее мутным патчем. Зачем гугл так делает - загадка. Но хорошо, что есть не только "не прекрасный" гугл, но еще и нормальные исследователи которые это нашли, зарепортили и сделали очень подробный разбор.

Суть проблемы: имея разрешение WRITE_SECURE_SETTINGS можно выполнять код от имени любого приложения в системе.

Да, разрешение не самое простое, но во-первых его имеет adb, а во-вторых устройства и сценарии бывают разные. Поэтому однозначно рекомендую ознакомиться с разбором.
#cve