🕷 BugBountyRu

💡 Один принцип, который помогает находить больше багов Огромное семейство багов сводится к одной идее: два компонента получают один и тот же ввод, но понимают его по-разному. Когда это начинаешь видеть, многие баги складываются в одну картину. ➡️ Инъекции: XSS, SQLi, code injection — приложение думает, что это обычные данные, а другой парсер видит там код: браузер, база данных, шаблонизатор или интерпретатор. ➡️ Request smuggling: фронт и бэк по-разному определяют, где заканчивается HTTP-запрос. ➡️ Байпас фильтров SSRF: валидатор URL видит один адрес, а HTTP-клиент после нормализации идёт уже в другое место. Это называют parser differentials — расхождения между парсерами. Идея простая: не искать только классические баги, а искать место, где есть эти самые расхождения. Не все классы багов так работают. Например, broken access control живёт по другим правилам. Но для многих технических уязвимостей это сильная модель мышления. Ищешь не тип бага. Ищешь расхождение, а REcollapse тебе в помощь 🥷 @BugBountyRu 🕷 Буст каналу

Как эффективно отслеживать, перехватывать и отлаживать JavaScript sinks в режиме реального времени 🤔 Прокси хорошо показывает HTTP-запросы и ответы, но часть клиентских багов живёт уже внутри браузера: данные попали в JS, прошли через роутер, пару обработчиков, санитайзер — и оказались в innerHTML, eval, document.write, postMessage или другом sink. Для таких кейсов есть Caido DOMLogger++ (похожий функционал имеет DOM Invader в Burp). Он хукает опасные JavaScript sinks прямо в браузере и отправляет события в Caido. В итоге видно, что реально произошло в DOM и JS-контексте. Ключевые фичи: 🔸 Мониторинг sink’ов в реальном времени — фиксирует вызовы JavaScript sink’ов (innerHTML, eval, fetch, postMessage и др.) во время обхода приложения. 🔸 Расширенный поиск и автодополнение — язык запросов с операторами вроде sink.tag.eq:"XSS" AND sink.data.cont:"<script>". По любому полю можно кликнуть, чтобы сразу отфильтровать находки. 🔸 Улучшенные stack traces — обогащение в один клик подтягивает релевантный исходный код из HTTP-кэша Caido и заменяет минифицированные stack frames на читаемый контекст. 🔸 Debug canary — клик по URL находки генерирует ссылку с ?domloggerpp-canary=, которая вызывает breakpoint в точном месте вызова sink’а. 🔸 Управление проектами и сессиями — изолированные базы данных для разных целей, запись сессий для ограничения области находок, массовые операции: экспорт, удаление, AI-оценка. 🔸 AI-оценка эксплуатируемости — интеграция с OpenRouter с поддержкой 100+ моделей. Каждая находка получает оценку от 1 до 5 с помощью настраиваемых условных промптов под разные классы багов. 🔗 Читай подробнее @BugBountyRu 🕷 Буст каналу

⌛️ SSRF через асинхронные задачи и фоновые воркеры Одна из самых недооценённых поверхностей атак для SSRF — асинхронная обработка. Иногда приложение не отправляет запрос сразу, а ставит задачу в очередь. Через несколько минут или часов её забирает фоновый воркер. Из-за этого уязвимость сложнее обнаружить: в ответе приложения ничего нет, а OOB-колбэк приходит позже и с другого IP-адреса. Такие механизмы стоит проверять отдельно. Пользовательский эндпоинт может только принять URL, а загрузкой ресурса занимается другой внутренний сервис со своим окружением. Обращай внимание на следующие кейсы ⬇️ ✅ Генерация отчётов. Экспорт по расписанию, аналитические панели и email-дайджесты могут загружать встроенные ресурсы на стороне сервера. ✅ Рендеринг писем. Платформа может скачивать изображения, чтобы встроить их в HTML-письмо как вложения или CID-ресурсы. ✅ Модерация и сканирование. Антивирусные, антифишинговые и другие системы проверки могут обращаться к URL, который передал пользователь. ✅ Индексация и создание превью. Поисковые индексаторы, краулеры и генераторы превью часто запускаются уже после загрузки контента. И не забудь использовать долгоживущий OOB-листенер — Burp Collaborator/interactsh/self hosted 👀 @BugBountyRu 🕷 Буст каналу

🧰 Арсенал скиллов для автоматизации разведки и поиска уязвимостей Recon-skills — проверенный на практике набор готовых инструкций для AI-агентов, которые прокачают разведку и помогут проверять цели по единой методике. Внутри тебя ждут кейсы для ⬇️ ▪️Поиска поддоменов, виртуальных хостов и реальных IP ▪️Анализа JavaScript-бандлов и утекших ключей ▪️Поиска секретов в GitHub ▪️Проверки CORS, XSS, SQLi, SSRF, IDOR и RCE; ▪️Разведки WordPress, облачной инфраструктуры, API, MCP и LLM-приложений ▪️Построения цепочек атак из нескольких находок Каждый навык содержит условия запуска, команды с ограничением скорости, способы подтвердить результат и типичные ошибки. Репозиторий можно подключить к агенту как библиотеку Markdown-инструкций или использовать отдельные сценарии вручную. @BugBountyRu 🕷 Буст каналу

🔍 Black-box фингерпринт reverse proxy Прежде чем искать байпасы средств защиты, полезно понять, какой reverse proxy стоит перед приложением 🤔 Это помогает выбрать подходящие техники тестирования, понять особенности маршрутизации и быстрее найти потенциальные векторы атак. Небольшой чек-лист для быстрого фингерпринта ⬇️ 1️⃣ Заголовки ответов на успешные запросы curl -sk -D- https://target/ -o /dev/null HAProxy и Traefik не добавляют собственных заголовков, а обычно просто проксируют заголовок Server, который возвращает бэкенд. 2️⃣ Сигнатуры страниц с ошибками curl -sk https://target:443/nonexistent-path-xyz Страницы ошибок часто позволяют определить используемый reverse proxy. Например, встроенная страница 403 Forbidden у HAProxy содержит строку "Request forbidden by administrative rules", характерную именно для него. 3️⃣ Subject в TLS-сертификате curl -skv https://target:443/ 2>&1 | grep "subject:" Traefik с дефолтной конфигурацией использует автоматически сгенерированный сертификат с CN=TRAEFIK DEFAULT CERT. Это хороший индикатор dev-окружений, хотя в проде обычно используются кастомные сертификаты. 4️⃣ Согласование протокола через Application-Layer Protocol Negotiation (ALPN) Проверь, какие протоколы сервер объявляет через ALPN и какие фактически обрабатывает: curl -skv --http2 https://target:443/ 2>&1 | grep "ALPN" Один из самых характерных признаков HAProxy: во время согласования ALPN сервер объявляет только поддержку HTTP/1.1, но всё равно обрабатывает HTTP/2, если клиент проигнорирует результат ALPN и сразу отправит HTTP/2 connection preface. 5️⃣ Метод исключения Если сигнатур Envoy, Caddy, Nginx, Apache и HAProxy нет, вероятно, используется Traefik с кастомным сертификатом. @BugBountyRu 🕷 Буст каналу

Вайб-пентестер сдает проект заказчику

https://dzen.ru/a/aketeeKJCirWZmmv

🤩 Максимальные выплаты — за реальную защищенность пользователей Фокусируемся на том, что действительно важно — на приватности и безопасности пользовательских данных. 🔹С 1 июля мы меняем правила программы багбаунти: теперь не важно, какая именно бага найдена, важно — какой импакт она несет. Любые узявимости, которые позволяют получить доступ к данным пользователей будут оцениваться по новой шкале. 🔹 Например, в наших социальных сетях Account Takeover теперь будет оцениваться наравне с RCE. Также оцениваться будут репорты не только в наших социальных сервисах, но и в VK Cloud, VK Workspace и VK HR Tek. 🔹 За нарушение изоляции между проектами пользователей в VK Cloud можно получить до 1 000 000 ₽. В каких программах изменения? 🔹ВКонтакте 🔹Одноклассники 🔹VK Видео 🔹VK Workspace 🔹VK Cloud 🔹VK HR Tek Все существующие категории остаются в силе — мы дополняем программы новыми сценариями, чтобы сделать акцент на защите пользовательских данных. Спасибо каждому, кто помогает делать наши продукты безопаснее 💙 ⭐ Не забывайте и про Bounty Pass: с каждым новым оплачиваемым отчетом можно получить до +5% к каждому следующему вознаграждению. VK Security | Буст этому каналу! #bugbounty #bountypass

🕷Универсальный стартовый набор для багхантера Команда Intigriti подготовила гайд со всем необходимым для начинающего багхантера: от разведки и выбора цели до эксплуатации уязвимостей ⬇️ 1️⃣Как составить полную карту приложения 2️⃣Основной тулинг, который упрощает работу 3️⃣Поиск и эксплуатация SQLi, XSS, IDOR 🔗 Канал в МАХ

🕷 Получаем исходники через открытую директорию .git Ситуация: на таргете доступны служебные файлы Git ⬇️ https://sub.target.com/app/.git/index https://sub.target.com/app/.git/HEAD https://sub.target.com/app/.git/config На первый взгляд — просто несколько файлов. На практике этого может хватить, чтобы восстановить исходники приложения. Самый простой путь — использовать GitTools: bash gitdumper.sh https://sub.target.com/app/.git/ dest-dir bash extractor.sh dest-dir dest-dir-dump gitdumper скачает содержимое .git, а extractor попробует восстановить рабочее дерево проекта. После восстановления проверь: ▪️ конфиги и .env, ▪️ API эндпоинты, ▪️ внутренние домены, ▪️ ключи, токены и пароли, ▪️ старые коммиты, ▪️ dev/staging-настройки, ▪️ закомментированный код и debug-ручки. 🔥 Канал в МАХ

🕷 Как быстро добавить скрытые JS chunks в Burp Sitemap Иногда при тестировании таргета в одном JSON-файле можно найти ссылки на сотни .js chunk-файлов, которые ещё не подгружались в браузере. Например: приложение лениво загружает модули, а в манифесте уже лежат ссылки на 300+ JS-файлов. Что можно сделать: 1️⃣ Вытащить ссылки на эти .js chunks → отправить их через Intruder 2️⃣ В таблице результатов Intruder выделить все ответы 3️⃣ Нажать правой кнопкой мыши → Add to Sitemap После этого Burp добавит найденные ресурсы в Site map, и с ними можно будет работать как с обычными файлами, которые ты нашел при ручном обходе приложения. Зачем это нужно: ⚫️ Быстрее собрать скрытые роуты приложения ⚫️ Найти API эндпоинты внутри JS ⚫️ Вытащить фича-флаги и dev-настройки ⚫️ Собрать старые ручки, staging-домены и sourcemaps 🔥 Канал в МАХ

🕷 Шпаргалки по SQLi и XSS для багхантера Когда находишь потенциально уязвимый параметр, важнее быстро перейти к проверке, чем заново вспоминать синтаксис для PostgreSQL, контексты XSS или способы обхода фильтров. Собрали шпаргалки, которые удобно держать под рукой во время ручного тестирования 🔥 SQL Injection / SQLMap ➖ PortSwigger SQLi Cheat Sheet: синтаксис для Oracle, MySQL, PostgreSQL и MSSQL: UNION, задержки, извлечение данных и OAST ➖ Tib3rius SQLi Cheat Sheet: короткая памятка по пяти популярным СУБД: удобно открыть рядом с Burp ➖ NetSPI SQL Injection Wiki: большая база по определению СУБД, эксплуатации и эскалации SQLi ➖ Advanced SQL Injection Cheatsheet: подборка техник и пэйлоадов для более глубокого тестирования ➖ SQLMap Cheat Sheet от HighOn.Coffee: команды для автоматизации проверки и эксплуатации SQLi через sqlmap Cross-Site Scripting (XSS) ➖ PortSwigger XSS Cheat Sheet: интерактивная база векторов: можно фильтровать пэйлоады по тегам, событиям и браузерам ➖ OWASP XSS Filter Evasion Cheat Sheet: векторы для проверки фильтров и понимания, почему одного blacklist недостаточно ➖ PayloadsAllTheThings — XSS Injection: reflected, stored, DOM XSS, polyglot-пэйлоады, обходы CSP и фильтрации ➖ HackTricks — XSS: методика поиска, контексты инъекции и нестандартные кейсы эксплуатации ➖ HowToHunt — XSS: практические подходы к поиску reflected XSS и разбору точек отражения Общие базы для веба ➖ PayloadsAllTheThings — пэйлоады и обходы по основным веб-уязвимостям ➖ HackTricks — методики и техники для веб-пентеста ➖ HowToHunt — практические чек-листы для багхантера ➖ OWASP Cheat Sheet Series — как устроена защита и какие механизмы стоит проверять ➖ PortSwigger-Academy-CheatSheets — база знаний из лабораторий PortSwigger Academy ➖ URL validation bypass cheat sheet — полезно для эксплуатации SSRF, мисконфигов CORS и open redirect ➡️ Канал в МАХ

Ого, что?! Вышел первый выпуск нашего подкаста «Спасибо за репорт» 🎧 Это проект VK Bug Bounty для багхантеров, а также для всех, кто формирует индустрию. Поговорим с топ-хантерами, командами bug bounty-платформ, вендорами и теми, кому не всё равно, как развивается поиск уязвимостей. Гость первого выпуска — Всеволод Кокорин aka Slonser. Разбираемся с ИИ-агентами в багхантинге без восторженных «они всё заменят» и без паники. Что уже работает, что лучше перепроверять три раза и почему хороший результат не получить без реальных знаний. Всеволод как раз из тех, кто разбирается в этом по-настоящему. Он эффективно применяет ИИ-агентов в реальных задачах и точно знает, где они ускоряют работу, а где им не стоит доверять. В выпуске: – как ИИ-агенты меняют поиск уязвимостей? – какие задачи можно отдавать агентам, а какие лучше оставить себе? – где агенты начинают галлюцинировать вместо того, чтобы искать баги? – от чего зависят аватарки Slonser'а? 🍿 Первый выпуск Ставьте лайк, шерьте друзьям, репостите в чатики — будет полезно всем, кто хочет использовать агентов точнее и получать на выходе качественные репорты. Пишите в комментариях: как вам запуск, кого позвать дальше и какие темы разобрать👇👇👇 VK Security | Буст этому каналу! #bugbounty #подкаст

Google Cloud RCE: $148 000 за одну уязвимость (CVE-2026-2031) Исследователь из BruteCat обнаружил критическую цепочку уязвимостей в Google Cloud Application Integration, которая позволила выполнить произвольный код в продакшен-среде Google. Всё началось с безобидного на первый взгляд эндпоинта отладки: GET /v1/integrationPlatform:getProtoDefinition Он возвращал protobuf-схемы любых сервисов в монолите google3 — от YouTube до внутренних систем. Это дало возможность «видеть» структуру запросов/ответов любых внутренних API. Дальше — интереснее: • Утечка очереди задач: через параметр ?alt=proto + X-Goog-Encode-Response-If-Executable: base64 удалось получить доступ к внутренней очереди рабочих процессов, включая данные из Spanner → Salesforce. • GenericStubbyTypedTaskV2: в конфигурации воркфлоу нашлась задача, позволяющая выполнять произвольные Stubby-вызовы (внутренний RPC-фреймворк Google) от имени продакшен-сервиса. • Обход проверок: с помощью двух аккаунтов и манипуляций с ACL удалось опубликовать и запустить вредоносный воркфлоу. Результат: выполнение /ServerStatus.GetServices на gslb:alkali-base вернуло список внутренних сервисов с полными proto-дескрипторами. Раунд 2: через 3 месяца После фикса первой уязвимости исследователь обнаружил IDOR в публичном API Application Integration - можно было читать чужие интеграции, подставляя чужой UUID в свой project ID. Через endpoint ListTestCases без фильтра утекали тест-кейсы всех проектов в регионе. С помощью бинарного поиска по фильтру удалось восстановить 128-битный UUID жертвы за ~128 запросов. Цепочка привела к полному доступу к чужим интеграциям и потенциально — к повторному RCE через внутренние задачи (PythonTask, GenericStubbyTypedTaskV2). Первая цепочка (RCE) P0/S0 $60 000; вторая цепочка (IDOR + RCE) P0/S0 $75 000; доп. находка (остаточный IDOR) P1/S1 $13 337 - итого ~$148 000.

🕷 Разведка API: как понять, что под капотом С обычными веб-приложениями всё просто: открыл Wappalyzer или BuiltWith — и уже видишь фреймворки, CMS и часть стека. С API сложнее. Там нет привычного фронта, а реальные детали часто прячутся за gateway, WAF, CDN или reverse proxy. Но язык и фреймворк всё равно можно вычислить по косвенным признакам. И это полезно не из любопытства. От стека зависят потенциальные векторы атак: ▪️ Java / Spring → паттерны десериализации ▪️ PHP → небезопасная десериализация и магические методы ▪️ Node.js / Express → JSON-десериализация и особенности middleware ▪️ SOAP / XML → шанс на XXE ▪️ Шаблонизаторы → возможная SSTI Зачем определять стек API: ☑️ Точнее строить разведку директорий ☑️ Понимать, какие расширения и эндпоинты искать ☑️ Предполагать шаблонизатор ☑️ Подбирать пэйлоады под конкретный язык ☑️ Фокусироваться на типичных ошибках фреймворка Как это делать: 1️⃣ Смотреть ответы сервера Проверяй: ▪️ HTTP-заголовки: Server, X-Powered-By, Set-Cookie ▪️ robots.txt ▪️ API-документацию 2️⃣ Провоцировать ошибки Пустой JSON, неправильный тип поля или сломанный пэйлоад иногда раскрывают больше, чем баннер сервера. В ошибках могут всплыть: ▪️ Названия классов, stack trace ▪️ Spring / Django / Express-специфичные сообщения ▪️ Формат валидации 3️⃣ Смотреть, как API обрабатывает данные Полезно проверять: ▪️ Лимиты GET/POST ▪️ HTTP Parameter Pollution ▪️ Булевы значения: true, false, True, False, 1, 0 ▪️ Типы данных: строка vs число vs boolean Разные языки и фреймворки могут по-разному интерпретировать одни и те же входные данные. Это помогает уточнить стек и иногда приводит к более интересным багам. ➡️ Канал в МАХ

🕷 Правильный байпас ограничений 403/40X Ограничение доступа не всегда означает надёжную защиту. Иногда 401 или 403 появляются из-за ошибки в роутинге, прокси, middleware или правилах WAF. Достаточно изменить HTTP-метод, добавить заголовок или слегка поменять путь — и закрытый эндпоинт внезапно начинает отвечать. Nomore403 — тулза для автоматизации проверок обхода 403/40X. Она перебирает типовые техники: ▪️ Подстановку заголовков ▪️ Изменение HTTP-методов ▪️ Вариации путей ▪️ Кастомные пэйлоады Одна из ключевых фич — «автокалибровка», которая уменьшает количество фолсов ⬇️ Перед основным тестированием скрипт отправляет несколько запросов на заведомо несуществующие пути и запоминает статус-код, размер ответа, заголовки и другие признаки типичной ошибки. После этого каждый новый ответ сравнивается с базовыми показателями. Если он заметно отличается от обычной ошибки, такой кейс помечается как потенциальный байпас. ➡️ Канал в МАХ

🕷 Прежде чем отправлять репорт, попробуй показать максимальный импакт Распространенные способы получения удаленного исполнения кода (RCE): ➡️ Небезопасная загрузка файлов ➡️ SQL injection ➡️ Небезопасная десериализация ➡️ Server-side prototype pollution ➡️ XXE ➡️ Внедрение команд ➡️ Server-side template injections ➡️ Server-Side Request Forgery ➡️ LFI/RFI ➡️ Race Condition Иногда «слабая» находка становится критичной именно из-за комбинации нескольких проблем в цепочку атаки: SSRF → внутренняя админ панель → file upload → RCE IDOR → доступ к конфигу → креды → RCE SSTI → чтение файлов → секреты → RCE LFI → log poisoning → RCE File upload → LFI → выполнение загруженного файла Path traversal → чтение конфигов → креды → RCE ➡️ Канал в МАХ

Dirty Frag: Universal Linux LPE Появилась публичная информация о Dirty Frag — новом классе LPE-уязвимостей в Linux, позволяющем локальному непривилегированному пользователю получить root за счет записи в page cache через сетевые буферы ядра. Исследователь Hyunwoo Kim описывает цепочку из xfrm-ESP и RxRPC Page-Cache Write; заявлено, что эксплуатация не требует race condition и имеет высокую надежность. Наибольший риск — для серверов с контейнерами, Kubernetes, CI/CD runners, shared-хостинга и любых систем, где недоверенный код может запускаться локально. Dirty Pipe в 2022 показал возможность атаковать page cache через pipes. Copy Fail недавно продемонстрировал похожий класс проблемы через AF_ALG. DirtyFrag продолжает ту же линию — page cache write через ESP и RxRPC. Три разные подсистемы ядра, но один повторяющийся класс ошибок. До выхода backport-патчей рекомендуется оценить использование esp4/esp6/rxrpc, временно отключить соответствующие модули там, где это безопасно, и оперативно обновить ядро после публикации исправлений дистрибутивом.

OWASP RUSSIA MEETUP: AI в анализе кода, SSR-безопасность, атаки на CMS, Telegram-фишинг и ML в AppSec 14 мая состоится OWASP RUSSIA MEETUP — встреча для специалистов по информационной безопасности, разработчиков, AppSec/SRE/DevSecOps-инженеров, инфраструктурных команд и всех, кому интересны современные практики защиты приложений. В программе — доклады о графовых подходах в анализе кода, рисках SSR на примере React2Shell, атаках на установщики CMS, сценариях Telegram-фишинга через QR-коды и балансе между ML-подходами и классическими правилами в AppSec. Программа митапа 19:00 — Приветственное слово Лука Сафонов, OWASP Russia chapter leader Модератор: Павел Кузнецов, Инфосистемы Джет 19:10 — AI + анализ кода: графовые подходы и почему они снова актуальны Радда Юрьева, PT Доклад будет посвящён тому, как CPG/PDG-графы становятся основой для контекстного поиска уязвимостей в коде. Ключевые темы: CPG/PDG-графы в анализе кода; контекстный поиск уязвимостей; связка графовых подходов с LLM; применение графовых нейросетей в задачах AppSec. 19:55 — Риски безопасности SSR на примере React2Shell и их митигация Артем Чувикин, Ngenix Современные web-приложения всё чаще используют server-side rendering, что улучшает производительность, SEO и пользовательский опыт, но одновременно расширяет поверхность атаки. На примере React2Shell будут разобраны риски, возникающие в SSR-архитектуре, и способы их снижения. Ключевые темы: особенности безопасности SSR-приложений; attack surface server-side React; уязвимость React2Shell; практическая эксплуатация на демонстрационном приложении; virtual patching через WAF, CDN и reverse proxy. 20:35 — Перерыв 20:50 — Атаки на установщики CMS: как захватить контроль над ещё не установленной системой Александр Колчанов, независимый эксперт Доклад посвящён сценарию, при котором атакующий находит доступные установщики CMS и использует их для получения контроля над сервером ещё до полноценной установки системы. Ключевые темы: поиск открытых установщиков CMS; получение доступа к админке через процесс установки; загрузка shell; удаление установленной CMS и восстановление установщика; захват контроля без эксплуатации типовых CVE. 21:30 — Как я украду вашу телегу Михаил Жмайло, CICADA8 QR-код давно стал привычным способом аутентификации во многих приложениях. В докладе будут разобраны фишинговые атаки на QR-аутентификацию, сценарии QRLjacking и использование Telegram как платформы для атак социальной инженерии. Ключевые темы: QRLjacking; фишинговые атаки через Telegram; захват аккаунта через QR-код; вредоносный MiniApp; автоматизация сбора информации; persistence в Telegram-сценариях. 22:10 — Баланс точности и полноты: ML vs ifчики Павел Конан, Yandex Индустрия кибербезопасности активно продвигает AI-powered-решения, противопоставляя их классическим сигнатурам и правилам. Но на практике выбор между ML и rule-based-подходами почти всегда упирается в компромисс между Precision и Recall. Ключевые темы: ML против правил и эвристик в AppSec; компромисс между Precision и Recall; False Positive и False Negative в WAF и SAST; alert fatigue у разработчиков; архитектурные паттерны security-инструментов; чек-лист: когда нужен ML, а когда достаточно rule-based-подхода. 22:50 — Завершение Участие в митапе бесплатное и осуществляется по предварительной регистрации. Ссылка на место проведения (Москва) будет отправлена на email. До встречи 14 мая!