Яндекс | Охота за ошибками

Привет, охотники! Нам нужно серьёзно поговорить.

ИИ радикально меняет правила игры как в разработке, так и в безопасности. LLM могут отлично ревёрсить, анализировать исходники и проверять сервисы блэкбоксом. За последние полгода мы получили много крутых и критичных уязвимостей, найденных с помощью агентов.

Однако бездумное использование ИИ может привести к большим проблемам, причём для всех сторон.

В первую очередь — это огромное количество шума, мешающее поймать полезный сигнал.А ведь эта метрика неразрывно связана с «качеством жизни» самих багхантеров: из-за резко возросшей нагрузки на команды безопасности время разбора отчётов тоже значимо увеличивается. Некоторые вендоры уже пересматривают свои программы и снижают награды, а кто-то целиком закрывает багбаунти.

Во-вторых — буквально потеря человечности. Когда нам пишут апелляции, созданные с помощью ИИ, либо когда в отчёте не всё однозначно и мы просим уточнений, а в ответ получаем ИИ-слоп, это напрямую сказывается на отношении в спорных ситуациях. А значит, отчёт просто улетит в N/A.

Означает ли это, что использовать ИИ запрещено ? Нет, но исследователь обязан придерживаться правил применения ИИ при написании отчётов.

Какие типичные проблемы мы замечаем?

1. Искусственно увеличенный объём отчёта.
Там, где достаточно 3-4 шагов для воспроизведения, LLM может сгенерировать 20 этапов, которые багхантер копипастит как есть. В результате анализ такого отчёта занимает в 10 раз больше времени.

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

2. Несуществующие термины, выдуманные формулировки и галлюцинации.
Продираться сквозь такой текст в попытках понять, что имел в виду исследователь (точнее, применяемая ИИ-модель), очень сложно.

Поэтому: самостоятельно воспроизводите описанное моделью поведение и убедитесь в достоверности.

3. Потеря контекста и теоретические проблемы.
LLM может подсвечивать «лабораторные» неэксплуатируемые уязвимости либо ошибки, которые вообще не влияют на безопасность или вовсе не учитывать контекст анализируемого сервиса. Мы считаем, что определение импакта — это часть работы исследователя, ведь за это он получает заслуженное вознаграждение.

Поэтому: определите и опишите реальное влияние на сервис. Приложите PoC и обязательно запишите видео-демонстрацию.

За все 10+ лет мы не прибегали к блокировкам исследователей, но сейчас вынуждены рассмотреть этот шаг. Пожалуйста, старайтесь не злоупотреблять программой и не создавать искусственную нагрузку. Систематическая отправка непроверенных ИИ-отчётов приведёт к ограничению участия в Охоте.

Подробно правила для ИИ-инструментов мы описали на отдельной странице. Познакомьте ваши LLM со ссылкой: https://yandex.ru/bugbounty/llms.txt

Призываем к этичному использованию LLM и верим, что это войдёт в негласный «кодекс» профессиональных багхантеров.

Свежие криты за август? Вот они:

😀Хардварные отчеты все чаще появляются в нашем дайджесте. Новый способ обхода Secure Boot для кое-какого умного устройства с большим экраном – 750К

😀Еще не встречали YQLi? Это как SQL инъекция, только YQL инъекция – 600К

😀Хороший IDOR, да еще и если идентификаторы легко брутить – всегда в цене, 550К

😀Необычная ошибка в бизнес-логике legacy API, основной побочный эффект которой – у пользователя полностью ломается почтовый ящик, 550К

Псс...у нас новый сервис:
sim.yandex.ru 📞

Делимся свежими результатами «Охоты» за июль 🏃‍♀️

😀[contest] XXE в SVG обработчике – 1.2М ₽
Наверное, все ведь знают, что XXE включает в себя импакт и от SSRF, и от чтения локальных файлов впридачу?
Так и вышло в рамках приватного конкурса в сервисах 360.

😀[contest] Повышение привилегий в рамках организации – 666К ₽
Собрать запросы с вызовами API от привилегированной учетной записи, а затем повторить их от самой слабой роли – простой и эффективный способ проверить баги в ролевой модели.
Один из последних отчетов из июньской приватки.

😀Возможность получить root-привилегии на актуальных устройствах – довольно ценный сценарий в рамках «Охоты». Исследователь смог успешно адаптировать эксплойт к CVE в драйверах ядра, за что получил заслуженные 500К ₽

🚧 На этой неделе наблюдались технические неполадки с присвоением идентификатора для новых отчётов. Уже всё починили.

Если вы не получили письмо с ID вашего отчёта на почту, пожалуйста, отправьте отчёт повторно 🚧

Yet Another BugBounty Meetup 2026: done! 😎

Были рады увидеть как старых друзей, так и познакомиться с новичками!

Спасибо за вопросы, обсуждения, доклады и атмосферу. Уже ждём следующей встречи 😀

😀Ловите фотографии с митапа

Если вы всё ещё размышляете участвовать ли в багхантерской премии Pentest Award от Awillix — возможно, это знак!

Ребята продлили приём заявок до 19 июля ⌨️

Тот самый Yet Another BugBounty meetup снова в деле!

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

Продолжаем традицию: забронировали несколько мест на митапе для участников канала 🎉

Что в программе:
• Поделимся традиционными итогами Охоты за год
• Обсудим, как найти XSS в фиче, которую все уже сотню раз смотрели
• Расскажем, как раскрутить RCE в одном из крупнейших сервисов
• и ещё кое-что секретное 😎

🕒 17 июля, 19:00
⭐️ Москва, офис Яндекса

➡️ Регистрация открыта

Количество мест на площадке ограничено, поэтому все заявки проходят модерацию.

Ждём встречи!

Июнь был особенно жаркий, потому что у нас проходил закрытый конкурс  с повышенными выплатами в отдельном скоупе 😎

Поэтому сводку мы хотим разделить на 2 части

Топ-3 за июнь:
😀Исследуя старое, но еще доступное API, исследователь наисследовал критичный IDOR с возможностью перезаписи данных, за что получил 450 000 ₽

😀225 000 ₽: Возможность раскрыть умеренно чувствительные данные о произвольной учетной записи через “абуз” инвайтов в кампании

😀И еще одна награда в 225К ₽, но уже за Blind-SSRF. Кстати, вы же знаете, что SSRF очень удобно самостоятельно валидировать через ssrf-sherif? 

😀😀😀

Топ 3 в рамках конкурсного скоупа:
😀2 400 000₽ Serverside Prototype Pollution  ==> RCE 

😀2 400 000₽ path_traversal при распаковке файла приводил к перезаписи файлов ==> RCE

😀1 200 000₽ SSTI. Да-да, они бывают не только в CTF 😳

😀 P.S. поступают вопросы как попадать в приватные конкурсы - тут всё просто, рассказываем:
• по умолчанию приглашаем топ нашего Зала славы
• и тех охотников, кто мог ещё не попасть в топ, но был эффективен в последнее время

В мае топ награды получили 2 отчета с необычными дисклозами и RCE за счет необычной эксплуатации CVE.

😀[RCE] Охотник смог успешно реализовать эксплуатацию CVE в обработчике изображений (уже догадались, что за библиотека?)

Стандартные, всем известные PoC тут не подходили, но охотник доработал кастомный эксплойт и забрал заслуженные 1,2 млн ₽.

😀[Information Disclosure] Исследователь продемонстрировал возможность получения доступа к стороннему 3rd-party-сервису, в котором обрабатывались наши данные. Хоть сервис и «чужой», но данные наши... Поэтому решили награждать!

😀[Information Disclosure] Внимательный охотник обратил внимание на избыточное логирование и забрал приз в 500К ₽

💰Хотим разобрать популярный вопрос про сроки выплат

"- НУ ЧТО ТАМ С ДЕНЬГАМИ?"

Раз в месяц мы складываем все награды, которые накопил каждый исследователь за прошлые 30 дней, и отправляем в банки.

Это означает, если у вас было 3 обработанных отчета с назначенными наградами в прошлом месяце, то вы получите одну суммарную выплату сразу за 3 отчета, если только 1 отчет — значит, придет за 1.

Обычно, с учетом работы банков, награды приходят 13-15 числа каждого месяца.
Изредка выплата может перенестись на следующий месяц. Если вы не получили награду за отчет, где письмо о награде было больше 2 месяцев назад, — напишите нам в саппорт.

😀Несколько дополнений про налоги:

• Прямо сейчас получать выплаты как ИП/самозанятым нельзя, но это возможность может появиться в будущем.

• Яндекс выступает налоговым агентом и самостоятельно удерживает и перечисляет налог в ФНС с наград Охоты. Именно поэтому мы просим указать СНИЛС, ИНН, ИФНС и прочие страшные аббревиатуры — это требование налоговой. Но это нужно сделать всего лишь один раз 🧡

➡️ Кстати, у нас появился раздел FAQ, где мы ответили и на другие вопросы, которые вы нам задавали, бежим читать!

Привет, охотники за hardware уязвимостями! 😎

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

Собираетесь вкатиться в hardware-security — велком читать целиком статью на Хабре! 😀

Делимся информацией о трех самых дорогих репортах апреля:

😀Один из охотников продемонстрировал успешное применение "состояния гонки" — вышел честный и довольно стабильный тейковер.

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

Кстати, советуем почитать наш пост — он как раз о таких сценариях.

😀Чтение локальных файлов с сервера.

Изучение исходных текстов может дать очень хороший результат!

Что происходит с отчётом после кнопки "Отправить" 🤔

Этап 1: Новый отчёт
Сразу после нажатия «Отправить» приходит автоматическое письмо с уникальным ID отчёта. По этому ID вся переписка по отчёту собирается в один тред на почте, а мы быстрее находим его, если вы к нам обращаетесь.

Этап 2: Статус «В работе»
Инженер начал работу с вашим отчётом. Вам на почту приходит автоматическое письмо.

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

Этап 3: Статус «Обработан»
Уязвимость воспроизведена, дубликата нет. Вы получаете письмо об изменении статуса.

😀Движение отчёта от статуса «В работе» до «Обработан» в среднем занимает 14 рабочих дней.

Этап 4: Оценка
Разбираем root-cause, иногда проводим внутреннее исследование, обсуждаем критичность и назначаем награду.

Этап 5: Финальная проверка и итоговое письмо
Второй инженер верифицирует назначенную сумму. Это нужно для согласованности и свежего взгляда на оценку со стороны. После проверки на почту приходит итоговое письмо: размер награды и идентификатор выплаты.

😀От статуса "Обработан" до письма с суммой вознаграждения проходит до 10 рабочих дней.

Весь путь – это несколько этапов, и каждый требует времени. Мы стремимся укладываться в 30 дней до финальной резолюции, но иногда сложные или спорные отчёты требуют большего внимания. Если прошёл месяц, а вестей нет, смело пишите в бота — мы дадим актуальный статус. Спасибо за терпение и крутые находки!

Есть что спросить? Велком в форму, ответим в следующих постах

Рубрика #охотникам_на_заметку

В нашей практике нередко бывают случаи, когда мы размечаем RCE как «не представляет опасности».
Про это и хотим рассказать — когда на первый взгляд опасный баг оказывается вовсе не опасным и как не потратить своё время зря.

Сценарии, где это актуально:

1. Режим «Исследовать» у Алисы
2. Виртуальные машины и платформы запуска скриптов в Практикуме / CodeRun / Contest
3. Виртуальные машины для игр

По умолчанию всё это отдельные изолированные окружения. Поэтому само по себе RCE там не несёт опасности без связки с другими мисконфигами.

😀На что стоит обратить внимание, если хочется поглубже копнуть и как доказать импакт?

1️⃣Агенты в режиме «Исследовать»
Запускаются в serverless-окружении, которое создаётся под одного пользователя и удаляется после формирования ответа. Попробуйте получить данные других пользователей — разумеется, своих тестовых аккаунтов.

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

2️⃣Обратиться к ресурсам из внутренней сети Яндекса (SSRF)
Контейнеры должны быть сетевым образом изолированы. Если вы считаете иначе — проверьте это через SSRF-Sherif.

3️⃣Выход за пределы контейнера (sandbox escape)
Если вы считаете, что можете влиять на контейнеры других пользователей или получить привилегии уровня гипервизора — расскажите нам об этом.

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

4️⃣Секреты и токены доступа
Предполагается, что в «одноразовом» контейнере не должно быть ценных технических секретов. Если вы их обнаружили — постарайтесь определить, к чему они относятся. Особенно интересуют credentials для внутренних и облачных сервисов.

Удачи!