CTF учит находить уязвимости в специально подготовленной среде. В багбаунти среда живая, правила жёстче, а найденная проблема должна иметь понятный риск для бизнеса. Но фундамент навыков часто один и тот же.
Мы поговорили с Михаилом Ильиным и Андреем Шпаком, — багбаунтерами и активными CTF-игроками.
Как вы пришли из CTF в багбаунти? Был ли конкретный момент, когда захотелось искать баги в реальных продуктах, а не флаги в задачах?
Михаил Ильин: Два года назад, узнал что есть багбаунти и сколько там платят, первую багу нашёл через неделю на вышедшей госке, баги ищу и в настоящий момент, но от CTF не отхожу.
Какая CTF-специализация помогла больше всего: web, pwn, reverse, crypto, mobile, forensics? А какая почти не перенеслась?
Михаил Ильин: Веб, пентест очень помогали на протяжении этих двух лет, т.к. бинарщину не оч люблю, но сейчас стал осваивать kernel pwn и использовать это в багбаунти.
Какой навык из CTF дал первый воспроизводимый результат в багбаунти?
Михаил Ильин: Уметь раскручивать самую незначительную ерунду до сильного импакта.
Какие три навыка вы бы посоветовали развивать CTF-игроку, который хочет перейти в багбаунти?
Андрей Шпак: На данный момент, будто потерянные из-за ИИ навыки, но: чтение оригинальных статей (когда ты их сам читаешь, больше фиксируешь), больше самому погружаться в код и логику приложения/сайта, научиться выжимать все соки из софта, с которым работаешь (т.е. научится нормально использовать Burp, IDA, gdb, терминал Линукса и т.д.)
Что в багбаунти оказалось самым непривычным после CTF?
Андрей Шпак: Сайты большие, приложения большие и не понятно что с ними делать и куда копать, т.к. на CTF есть конечная точка маршрута — флаг, и ты до него по чуть-чуть идешь, а на бб такого нет.
Михаил Ильин: Что не каждая находка, которая может привести к флагу в CTF будет считаться багом и оплачиваться, а также, что уже это кто-то мог найти, и просто вендор решил не фиксить баг полгода.
В CTF задача гарантированно имеет решение. В багбаунти у цели может не быть уязвимости в вашем направлении. Как вы понимаете, когда продолжать копать, а когда остановиться?
Михаил Ильин: Если вектор перспективный, можно в нём закопаться подольше, это интересно, и ты размениваешь время на опыт, который тебе пригодится, а в конце может быть ещё и вкусный баг.
Андрей Шпак: После нахождения какого-то функционала, которым ты можешь управлять, стоит задуматься, что я с ним могу сделать? Поискать ручки или поэкспериментировать с запросами, и по сути случайно возможно получить что-то большее, чем какое-то прикольное состояние, полноценный баг уже с повышенной критичностью.
Расскажите о первой отклонённой находке. Почему её не приняли и что вы изменили после этого?
Андрей Шпак: Моя первая и единственная именно отклоненная находка была, когда я экспериментировал с Codex: было интересно посмотреть, на что он способен без человека. Я попросил его найти вулну в одном фреймворке, и просто втупую сдать это без проверки. И конечно же, он нашел какую-то ерунду, которая была даже не багом, и мне отчет отклонили.
После этого я перестал верить gpt’шкам, и стараюсь до сих пор большую часть работы стараюсь делать руками.
Как вы выбираете программу и скоуп? Есть ли признаки, что в цель не стоит вкладывать вечер или неделю?
Михаил Ильин: Есть уже зарекомендовавшие себя вендоры, есть не очень хорошие по слухам. Если инфраструктура большая и есть продукты, у которых сразу возникают разные идеи, буду брать его.
Что в отчёте отличает «интересное наблюдение» от бага, за который готовы платить?
Андрей Шпак: «Ннтересное наблюдение» — это что-то прикольное, но без реального риска для компании.
Баг — все же что-то, что имеет риск для компании, так как даже самые незначительные ошибки, при их большом количестве, могут складываться в полноценные цепочки уязвимостей, и принести компании достаточно много неприятных последствий.
Как изменился ваш подход к автоматизации? Какие скрипты и тулзы из CTF остались, а что пришлось написать заново?
Михаил Ильин: Стадия осинта полностью проходит тулзами, которые принёс из CTF, кроме стандартных nmap, sqlmap, Burp, дописанные плагины на скульмап, сстимап, написанные расширения для бурпа, фаззеры.
Насколько важны коммуникация с триажем, аккуратный PoC и понимание продукта? Этому можно научиться в CTF?
Андрей Шпак: Все это важно, особенно последние два пункта, так как нормально написанный PoC поможет триажеру быстрей отсмотреть баг, а понимание продукта поможет найти багу, под которую ты напишешь PoC.
На CTF возможно научится пониманию продукта (та же категория реверс — как раз на понимание программы: если ты понял, что происходит, то сможешь и найти флаг) и написанию PoC (скрипты на веб и pwn, если пишете ручками, то разовьете навык написания скриптов).
Но коммуникацией с триажем ты не научишься, как по мне, все же есть различие между написанием создателю таска по какому-то вопросу, и общению с человеком которому ты сдаешь багу.
Есть ли у вас пример, когда CTF-мышление помешало: вы искали красивую эксплуатацию, а реальный баг был в бизнес-логике или конфигурации?
Андрей Шпак: У меня такое было как раз с багбаунти в бинарке. Я привык, что в тасках на pwn обычно тебе надо либо получить rce либо прочитать как-то флаг через oob-примитивы или aw/ar. Оказалось, что в реальных продуктах таких уязвимостей либо нет, либо в большинстве случаев они без импакта, и это очень замыливало глаза. По итогу для сдачи бага достаточно просто пофаззить или точечно поискать какие-то баги в обработчиках, так как во многом, как показал опыт, ты вряд ли что-то кроме DOS-a получишь в большинстве случаев.
Что бы вы сделали иначе, если бы начинали переход в багбаунти сегодня?
Андрей Шпак: Я бы определенно сразу не брался за вебки (с ними почему-то не везёт), поизучал бы отчеты других, чтоб понять, что и как вообще делать; изучил бы как работает фаззинг и как писать фаззеры под программы, выбрал какой-то ± легкий скоуп, и по чуть-чуть старался бы вливаться в бинарочку на багбаунти, так как это и достаточно дорого, и как по мне, более реализуемо, чем баг в вебе.
Назовите один навык из CTF, который стоит перенести в багбаунти без изменений, и один — который придётся переучивать
Михаил Ильин: Переучивать возможно надо лёгкую победу до маленького импакта, которую можно докрутить до хорошего чейна, не переучивать терпение в одном векторе при решении.
Андрей Шпак: Навык поиска какой-то нужной информации 100% надо переносить без изменений, так как он помогает достаточно сильно. Навык слопить точно надо переучивать, ИИ не очень хороши в поиске импактых баг, особенно в плохих руках. Так что придется менять подход к использованию нейронок.
