Всем привет!

Пока одни специалисты спорят в комментариях, способны ли нейросети эффективно искать уязвимости, я решил проверить это на практике. На связи Nuit, мне 18 лет, я учусь и в этом году сдаю ЕГЭ и планирую двигаться дальше в ИБ. Параллельно с этим увлекаюсь багбаунти. За последние полтора месяца мне удалось заработать более 7 миллионов рублей на поиске уязвимостей. Ниже я расскажу о своем пути: как я выгорел в CTF и начал багхантить, как использую нейросети для поиска уязвимостей – а еще разберу кейс, который принес мне полтора миллиона рублей.

Статья носит исключительно информационный и образовательный характер и не является инструкцией или призывом к совершению противоправных действий. Описанные материалы предназначены для повышения осведомленности о возможных уязвимостях и методах их предотвращения. Любое тестирование безопасности допускается только при наличии явного разрешения правообладателя соответствующих ресурсов или в рамках официальной программы багбаунти. Несанкционированные действия могут нарушать законодательство. Автор статьи не поощряет и не поддерживает неправомерное использование представленной информации и не несет ответственности за ее использование в противоправных целях. Помните, что нужно уделять внимание защите своих данных и использовать информацию из статьи исключительно в законных целях.

Почему пришлось уйти из CTF и как пришел в багбаунти

Все началось с классических CTF-соревнований. Долгое время играл и мне это нравилось, особенно категория web. Но со временем пришло выгорание: тяжело двое суток сидеть над сложными, специфическими задачами, когда твой потолок — получить за первое место очередную мерчевую футболку. Когда я совсем устал, знакомые подсказали, что можно делать практически то же самое, но получать за это приличные деньги, – так я пришел в багбаунти.

Первые результаты появились не сразу. Свой первый оплачиваемый баг я искал довольно долго. Это был обход лицензии в одной крупной компании, за который мне выплатили 6 000 рублей. Сумма небольшая, но сам факт того, что за найденную уязвимость можно получить реальные деньги, мотивировал.

Почти сразу после этого мне удалось найти две уязвимости с критическим уровнем опасности. Причем на поиск одной из них с нуля у меня ушло буквально десять минут. После этого процесс начал набирать обороты: за полтора месяца с момента первой выплаты суммарный заработок превысил 7 миллионов рублей.

Больше всего в багбаунти мне нравятся две вещи:

• Технический азарт. Дико нравится сама мысль, что я в свои годы нахожу опасные уязвимости в серьезных корпорациях.

• Вознаграждения. Конечно, радует финансовая сторона хантинга, на который я трачу не более 5 часов в день, а обычно гораздо меньше.

Как нейросети меняют правила игры в багхантинге

Скажу прямо, без ИИ я бы столько не заработал. Я взял свои наработки из CTF и адаптировал их под багбаунти. Ни для кого не секрет, что ИИ может искать уязвимости гораздо эффективнее исследователей. К тому же интереснее просто получать сводку по уязвимым векторам и докручивать их, минуя рекон.

Важный совет по работе с ИИ: нейросети хорошо находят такие типы уязвимости, как IDOR (неавторизованный доступ к объектам). При этом я не советую давать ИИ-агентам развлекаться с уязвимостями типа Docker Escape или Privilege Escalation – с большой вероятностью они что-нибудь сломают (у меня такое бывало не раз).

Чаще всего я использую последние модели OpenAI Codex и Claude для поиска уязвимостей. На практике это выглядит примерно так: вместо того чтобы часами разбирать огромный объем однотипных данных, ты получаешь предварительную сводку по подозрительным векторам и уже дальше вручную проверяешь наиболее интересные направления. При этом я бы не сказал, что ИИ заменяет исследователя. Скорее, он сильно ускоряет рутинную часть работы. Финальная валидация, понимание критичности уязвимости и демонстрация реализации атаки все равно остаются за человеком.

Ложные срабатывания и нейроотчеты

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

Как отличать ложное от настоящего? Только через практику: сдавать отчеты в программы и со временем понять, какие компании какие уязвимости принимают.

Многие жалуются, что из-за ИИ качество отчетов ухудшилось. Чтобы ваш отчет не потерялся и был валидным, важно максимально подробно показывать воспроизведение уязвимости. Во многих случаях для этого достаточно детальных скриншотов с пошаговой демонстрацией атаки и ее результата. Иногда владельцы багбаунти-программ дополнительно просят видеодемонстрацию эксплуатации найденной уязвимости. Такой подход также помогает компаниям убедиться, что это не результат работы нейросети, а валидный отчет от исследователя.

Разбор кейса на полтора миллиона рублей

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

История началась с обычного анализа APK мобильного приложения. В приложении был сервис для обработки изображений: клиент отправлял ссылку на картинку, сервер ее скачивал, обрабатывал и возвращал результат. Чтобы нельзя было подсунуть сервису произвольные ссылки, запросы подписывались через HMAC.

Проблема оказалась в том, что ключ для этой подписи лежал прямо в коде приложения. То есть схема защиты выглядела так: приложение само создает подпись → ключ хранится внутри приложения → сервер доверяет этой подписи. Значит, если декомпилировать APK, можно получить ключ и генерировать подписи самостоятельно для любых URL. Я быстро написал маленький скрипт, который подставлял любой адрес и генерировал для него валидную ссылку.

Дальше обнаружилась еще одна важная деталь. У сервиса был параметр raw. В обычном режиме сервер ожидал, что по ссылке размещено изображение. Но в raw-режиме он просто возвращал ответ как есть, без проверки типа контента. Через это конечное устройство можно было получать HTML-страницы, JSON-ответы, внутренние API и вообще любой контент, до которого сервер мог дотянуться. Фактически это была SSRF – уязвимость, при которой злоумышленник заставляет сервер уязвимого приложения отправлять произвольные HTTP-запросы от своего имени (писали про это здесь: Где и как искать этот ваш SSRF: первые шаги в багхантинге).

Следующий вопрос был самым важным: есть ли у этого сервиса доступ во внутреннюю сеть компании? Проверил я это довольно просто. Попробовал обратиться к внутреннему адресу панели администратора, который вообще не открывался из интернета. Напрямую к нему подключиться было невозможно, но через уязвимый сервис сервер спокойно вернул HTML внутренней страницы. Стало понятно, что обработчик изображений имеет доступ к внутренней инфраструктуре компании.

После этого цепочка начала раскручиваться дальше. Сначала удалось получить конфигурационные файлы. Потом source map фронтенда, из которых можно было восстановить структуру внутренних API. В итоге нашлось конечное устройство, через которое постранично выгружались данные пользователей: имена, телефоны, email-адреса. При этом на каждом этапе я отдельно проверял, что эти данные действительно недоступны извне и открываются только через внутреннюю сеть. Это было важно для подтверждения уязвимости. Итог – полностью подтвержденный опасный вектор и выплата в 1 500 000 рублей за один отчет.

Что дальше?

На данный момент я ищу уязвимости только на Standoff Bug Bounty. Мне в целом приятно работать с этой площадкой, где, к тому же, у меня открыто уже много приватных программ.

Из ближайших целей – добить недопустимое событие в рамках кибериспытаний у одной компании. Уже долгое время кручусь рядом с этим сценарием: периодически кажется, что до полноценной цепочки остается совсем немного, но пока чего-то не хватает.

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