Разведка Android-приложений: Drozer и анализ версий 📱

Статический анализ — только половина работы. Многие баги проявляются только во время выполнения приложения или появляются между версиями.

Лови несколько кейсов, которые часто находят то, что пропускают стандартные тулзы 🔽

1️⃣ Runtime-тестирование IPC через Drozer

Drozer позволяет напрямую взаимодействовать с компонентами Android-приложения: activities, services, broadcast, receivers, content providers.

После установки можно быстро проверить реальную поверхность атаки:

run app.package.attacksurface com.target.app

Дальше — интереснее. Например, можно попробовать запустить экспортированную дебаг activity:

run app.activity.start --component com.target.app com.target.app.DebugActivity

Такие activity иногда обходят авторизацию, раскрывают внутренние данные, дают доступ к скрытым фичам приложения.

2️⃣ Content provider → SQL-инъекция

Content providers часто работают как база данных между приложениями. Если provider экспортирован, можно потестить пэйлоад для SQLi:

run app.provider.query content://com.target.app.provider/users --projection "* FROM users; --"

3️⃣ Broadcast injection

Некоторые приложения слушают системные broadcast-события. Если действие не защищено, его может вызвать любое приложение:

run app.broadcast.send --action com.target.app.PRIVILEGED_ACTION --extra string key value

Так иногда удаётся триггерить фичи, которые разработчики считали внутренними.

4️⃣ Сравнение версий для анализа регрессий безопасности

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

Поэтому сравнение версий может показать:
✅ какие проверки добавили,
✅ какие дебаг фичи удалили,
✅ какие API появились.

Быстрый способ посмотреть изменения:

apktool d target_v1.0.apk -o v1
apktool d target_v1.1.apk -o v2
diff -r v1/ v2/

💡 Иногда разработчики случайно выкатывают дебаг фичи в прод, а в следующем релизе убирают их. Этот короткий промежуток между версиями — отличная возможность протестить функциональность, пока она существует.

Посты по теме:
🔗 Первичный анализ любого APK-файла: советы багхантеру
🔗 Упрощаем обработку приложений APK / XAPK / APKM / DEX / JAR / WAR с помощью BFScan
🔗 Реверс приложений на Flutter

Эксплуатация NoSQLi с помощью массивов параметров 💨

Если приложение не принимает JSON и работает только с application/x-www-form-urlencoded, это не защита от NoSQL-инъекций.

Многие серверные либы автоматически преобразуют параметры вида:

username[$ne]=1

в объект:

{ username: { $ne: 1 } }

Таким образом, можно передавать NoSQL-операторы через обычные параметры формы 🔥

Ключевое:
➡️ Парсер на сервере преобразует массивы в объекты
➡️ Ограничение по Content-Type не спасает от инъекции
➡️ NoSQL-операторы можно внедрять без JSON

Second-Order (Stored) IDOR: заметки для багхантера 💡

Обычный IDOR срабатывает сразу: ты меняешь условный user_id=1 на user_id=2 в запросе — и сервер мгновенно отдаёт данные второго юзера. Second-order IDOR работает иначе — с «задержкой».

Как это выглядит ⤵️

Ты подсовываешь тот же айдишник жертвы в одном месте,
а доступ к данным происходит позже — через другой эндпоинт или фоновую джобу.

➡️ В момент инъекции всё выглядит легитимно
➡️ Эксплуатация происходит совсем в другом контексте

Атака — это всегда два шага:

1⃣ Seed (сохранение): инжектишь ID жертвы в безобидное поле: профиль, настройки, связанный ресурс. Сервер проверяет сессию и спокойно сохраняет данные.

2⃣ Trigger (исполнение): позже происходит асинхронное действие. Система берёт сохранённый ID из базы, слепо ему доверяет и выполняет операцию.

Почему такие баги часто дают высокий импакт:

⚫️ Сканеры почти не находят такие баги — здесь нужно понимать состояние приложения, бизнес-логику и отложенное выполнение
⚫️ Разработчики часто защищают только публичные API
⚫️ Внутренние джобы (генерация PDF, отправка писем и т.д.) считаются «безопасными»
⚫️ Проверки прав доступа на втором этапе просто отсутствуют

Где искать ⏳

Ищи функционал приложения с асинхронной обработкой:

⚫️ Экспорты и отчёты: меняй ID аккаунта → запрашивай CSV/PDF → через время получай данные жертвы
⚫️ Webhooks и интеграции: подменяй ID workspace → при синхронизации (Slack, Jira) получай чужие данные
⚫️ Автоматические саппорт-боты: вставляй ID заказа жертвы → бот подтягивает детали из базы и показывает чужие данные

Что нужно ❓

1⃣ Две учетки: атакующий (User A) и жертва (User B)

2⃣ Терпение: ввел данные → подождал выполнение задачи → проверил результат (почта, webhook и т.д.) → повторил

В Chrome при нажатии на значок очистки (иконка ❌ для быстрой очистки поля) в <input type="search"> запускаются события onsearch и oninput 🔍

Если стилизовать элемент так, чтобы эта иконка покрывала нужную целевую область, на выходе получишь надёжный 1-click вектор эксплуатации XSS ⤵️

<h1>Click here</h1>

<input type=search value=x onsearch=alert('onsearch') oninput=alert('oninput') style=position:fixed;left:50%;top:50%;padding:0;width:10px;z-index:99;transform:scale(9999);opacity:0>

Broken Access Control: с чего начинать охоту 🔓

BAC — это зачастую не про сложные эксплойты. Это про логику и внимательность. Разберемся, с чего вообще начинать ⬇️

1️⃣ Разведка модели авторизации

Прежде чем кидаться менять ID в запросах — разберись, как работает авторизация на таргете. RBAC? Мультитенант? Обычная модель «юзер-админ»?

Это определяет стратегию тестирования.

2️⃣ Тестовые аккаунты

Минимум — два обычных аккаунта (User A и User B). Если RBAC — по аккаунту на каждую роль. Мультитенант? Регистрируй аккаунты в разных организациях/тенантах.

3️⃣ Маппинг

Прогоняй приложение через Burp/Caido под каждым аккаунтом. Лови каждый эндпоинт и роут. Выделяй контролируемые параметры: userId, orderId, accountId, UUID и т. д.

4️⃣ Атака

Берешь токен/куки User B и пробуешь дёрнуть ресурсы User A. Чекни админские эндпоинты из-под обычного юзера.

Не забывай про менее очевидные места — массовые операции, экспорт данных, вебхуки, GraphQL-запросы с вложенными объектами. Там часто забывают про проверки 🤔

P. S. Autorize — расширение для Burp, которое автоматизирует поиск BAC:

— перехватывает запросы привилегированного юзера,
— повторяет их с менее привилегированными аккаунтами,
— сравнивает ответы и находит байпасы.

Материалы и лабы по теме:
🧡 Access control vulnerabilities and privilege escalation
🧡 Testing access controls with Burp Suite
🧡 Начинаем в багбаунти: доступно об уязвимостях типа Broken Access Control