Методология баг-баунти: гайд для охотников за багами

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

Обо мне: я Киаран (или Monke). Я ирландец, но живу в Эдинбурге. Занимаюсь баг-баунти уже примерно четыре года, участвовал в четырех мероприятиях Live Hacking Event на разных платформах, скоро будет пятое. Я довольно типичный веб-хакер, сейчас мне больше всего нравится заниматься хакингом на стороне клиента. В этом году я наконец полностью перешел на зарабатывание денег при помощи баг-баунти и основал компанию Simian Security. Возможно, я единственный ирландец, для которого баг-баунти является полноценной работой.

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

• Инструменты: чем пользуется хакер, чтобы атаковать цель?

• Образ мышления: насколько настойчив хакер? Как хакер преодолевает ментальные барьеры?

• Подход к работе: некоторые хакеры используют чек-листы. Другие руководствуются собственной интуицией. Как хакеры применяют свои знания на практике?

• Опыт: конкретный порядок реализации методологии зависит от предыдущего опыта хакера. Опытные хакеры обычно очень в этом эффективны. Эффективность — это результат накопленного опыта.

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

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

Инструменты

Процесс

Проксирование

В зависимости от цели я выбираю или Burpsuite, или Caido. В последнее время я чаще всего пользуюсь Caido и применяю Burpsuite только в очень специфических ситуациях, например, при атаках одним пакетом. В Caido преимущественно есть все, что мне нужно, и для него проще писать расширения, потому что для интерфейсов пользователя в нем используются Javascript+CSS, а не Java Swing. Если вы начинающий, то рекомендую Caido, потому что им проще пользоваться.

Стоит ли покупать Burpsuite Professional Edition или Caido Pro? Мне кажется, что да. Необязательно платить за прокси, чтобы найти свой первый баг. Но вы точно сможете найти больше багов, если у вас будет возможность сохранять проекты. Burpsuite Community Edition вообще не позволяет сохранять проекты, а бесплатная версия Caido ограничена двумя проектами. Существуют и другие прокси, но сегодня большинство хакеров пользуется либо Burp, либо Caido.

Составление списка поддоменов

Я использую Subfinder. Обычный инструмент, ничего выдающегося. Если мне нужен датасет побольше, я обращаюсь к моим друзьям, занимающимся автоматизацией. Для первоначальной разведки я в основном пользуюсь пакетом инструментария ProjectDiscovery. Для проверки активных хостов я использую httpx и время от времени выполняю сканирование портов. Для парсинга списка активных поддоменов и упорядочивания их по домену я написал собственный инструмент. Он преобразует данные в диаграмму связей в Obsidian, которую можно использовать для ведения заметок. Ниже я подробнее расскажу о заметках.

При работе над крупными проектами я следую Recon Methodology Джейсона Хаддикса, крайне ее рекомендую. Если у вас есть лишние деньги на обучение, стоит подумать над покупкой The Bug Hunter’s Methodology Live.

URL

Я пользуюсь Waymore, написанным XNL-H4ck3r, и Gau Корбена Лео. Это тоже вполне обычные инструменты. На этом этапе я отфильтровываю имеющие параметры результаты, как самые интересные для меня. Еще я изучаю любые серверы IIS, которые можно проверить Shortscan, на какие-нибудь дополнительные данные.

Nuclei

Стандартные шаблоны Nuclei достаточно хороши, но будем реалистами — вы будете гораздо эффективнее, если освоите автоматизацию самостоятельно. Наибольшего успеха можно добиться при помощи собственных шаблонов. Тут есть одна тонкость: иногда уязвимости могут находиться на нестандартных путях (например, одной-двумя папками выше или ниже), и их Nuclei пропустит, ведь он проверяет только пути, прописанные в шаблоне. Я нашел много багов благодаря этому способу.

На стороне клиента

Составив список интересных хостов, я начинаю заходить на каждую страницу. У меня в профиле Chrome установлен DomLogger++, а также postMessage-tracker Франса Розена. Затем я начинаю исследовать поток данных через веб-приложение, а если страница кажется особенно интересной, я пропускаю ее через Param Miner из пакета Burpsuite, чтобы обнаружить новые параметры. Я просматриваю активность postMessage и внимательно изучаю любые интересные рефлексии в DOM. Все это ситуативно и сильно зависит от цели исследования. Для изучения ограничений и поведения браузеров, которые вам необходимо знать, стоит воспользоваться великолепным ресурсом Beyond XSS.

На стороне сервера

Выполняемый мной список тестов на стороне сервера сильно зависит от приложения.

• API — отличный выбор для тестирования. Я довольно часто выполняю тестирование на контроль доступа и IDOR, но их очень легко устранить, поэтому и вероятность найти что-нибудь мала. Порывшись в файлах JS, часто можно найти скрытые конечные точки, которые стоит протестировать. Кто-то автоматизирует и эту задачу, выявляя изменения в файлах JS, но я до этого пока не дошел.

• Я выполняю тестирование на обход каталогов вторичного контекста (secondary context path traversal) в параметрах и значениях JSON.

• SQL-инъекции, NoSQL-инъекции, инъекции шаблонов на стороне сервера и так далее. Принцип понятен — список был бы слишком длинным для перечисления, но я тестирую их все в зависимости от контекста. Единственный мой совет — не тестируйте вслепую: не проверяйте наличие NoSQL-инъекции, если знаете, что в бэкенде используется база данных SQL.

Разное

• Если на сайте есть Salesforce, то я тестирую его на наличие ошибочных конфигураций Salesforce.

• Как говорилось выше, я выполняю Shortscan для всего, где есть IIS.

• Я тестирую классический обход каталога ..; в приложениях на Java.

• В крупных проектах я выполняю брутфорс виртуальных хостов и немного фаззинга.

• Я достаточно хорошо знаю поток OAuth, это бесценное знание для поиска возможностей захвата аккаунта (account takeover, ATO). SAML — это тоже важнейшая поверхность атаки для поиска ATO, но я меньше с ним знаком.

Автоматизация

Я написал большой объем автоматизации, но пользуюсь ей не так уж и часто — просто потому, что она нужна мне только для самых основ. Для полноты статьи я опишу, что создал.

Практически для всех своих VPS я использую DigitalOcean. Он не особо дорог и имеет простой UI. Я уже выполнил десятки итераций со своим кодом, поэтому моя кодовая база достаточно совершенна.

Hakluke написал отличную статью об эволюции автоматизации баг-баунти. Его пост во многом справедлив.

Как это работает

Я не находил толковых объяснений того, как работает автоматизация, так что попробую рассказать об этом здесь. Для начала разобьем задачи на два типа: длительные и единовременные. Длительные задачи — это, например, операции сканирования наподобие составления списка поддоменов. Единовременные задачи — это более нагруженные операции, например, фаззинг. В больших системах автоматизации нам требуется возможность масштабирования этих операций сканирования (больше длительных задач = больше скорость обработки данных, больше единовременных задач = более интенсивные сканирования, выполняемые параллельно). Чтобы реализовать это, специалисты по автоматизации используют очереди сообщений. Очереди сообщений позволяют создавать бэклог задач, из которого эти задачи можно брать. Если мы увеличим количество контейнеров, выполняющих определенные задачи, то сможем забирать больше задач из очереди. В Kubernetes для этого достаточно изменить одно число в спецификациях YAML. Чем же пользуюсь я?

• Очереди сообщений: у меня есть сервер RabbitMQ — он хорошо справляется со своей задачей и для него легко писать код, интегрируемый с Python или Go.

• База данных: я предпочитаю пользоваться MongoDB, потому что мне кажется, что формат документов BSON лучше подходит для баг-баунти.

Очень важен и выбор языка программирования. Python замечательно справляется с обработкой данных, но Go лучше подходит для сканирующих программ, потому что благодаря горутинам имеет встроенную в язык конкурентность. У каждого языка есть свое место в экосистеме. Свой собственный код я в основном писал на Go, но некоторые задачи ради гибкости написаны на Python.

После завершения выполнения задач результаты куда-то передаются, чтобы вы могли их просмотреть. Большинство людей использует веб-хуки Slack или Discord. Раньше я экспериментировал и с Grafana.

Крайне рекомендую попробовать самостоятельно собрать собственную автоматизацию с использованием минимального количества ресурсов. Попробовав это сделать, вы научитесь очень многому.

Что ищут при помощи сканирования

В настоящее время по-прежнему есть множество возможностей для захвата поддоменов. Этот класс багов постепенно вымирает, но его все еще вполне можно эксплойтить. Если взглянуть на картину в целом, мне кажется, автоматизация эволюционирует, и люди теперь выполняют сканирование на XSS, баги кэша и, разумеется, уязвимости нулевого дня. Кроме того, исследователи выполняют реверс-инжиниринг патчей и сканируют их наличие до выпуска публичных PoC, или находят уязвимости плагинов WordPress и выполняют крупномасштабное сканирование в их поисках.

Ведение заметок

Ведение заметок — важнейшая часть процесса. Качественно ведя заметки, гораздо проще возвращаться к тому, над чем работал в прошлом. В этой сфере все большую мощь набирают LLM; ниже поделюсь парой мыслей о них. Организованный подход к делу окупает себя десятикратно.

ПО для ведения заметок

На самом деле, подойдет что угодно, даже файлы TXT. Я рекомендую Obsidian или Notion. Для написания отчетов баг-баунти советую использовать Obsidian. Notion хорош тем, что он работает в облаке, так что вам не придется беспокоиться об утере своих заметок и вы достаточно легко сможете делиться ими с другими. У каждого из этих инструментов есть свои преимущества. Диаграммы связей (ментальные карты, mindmap) — отличный способ упорядочивания заметок по баг-баунти, потому что их можно сортировать по домену, затем поддомену и даже по пути.

LLM

Крайне рекомендую использовать ChatGPT или любую другую LLM, позволяющую загружать данные, чтобы выполнять запросы к своим заметкам. В частности, если вы сможете экспортировать свои заметки как файл PDF, это позволит использовать функциональность ChatGPT «custom GPT» для создания личного чат-бота, источником знаний для которого станут ваши заметки. Это отличный способ генерации идей на основе уже проведенных исследований, когда вы работаете над взломом целевой системы. Кроме того, если отправить ссылку для доступа к этому GPT друзьям, то они тоже легко смогут выполнять запросы к вашим заметкам.

Образ мышления

Хакинг по плану

Хакинг без цели — распространенная ошибка. У вас могут быть инструменты для взлома, но ни бессмысленны, если у вас нет плана. Без плана или направления вы впустую тратите время. Даже «потыкать палочкой, чтобы увидеть, что произойдет» — тоже план, если вы понимаете, зачем это делаете.

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

• «Я хочу идентифицировать параметры, рефлексируемые в DOM».

• «Я хочу вызывать ошибки, чтобы определить технологический стек бэкенда».

• «Я хочу найти файлы во внутренней файловой системе, чтобы провести эскалацию этой SSRF».

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

Синдром самозванца

Он может возникнуть у человека с любым уровнем опыта в этой сфере. Однажды вы просыпаетесь и чувствуете, что хуже всех остальных. Например, причиной могло стать то, что Orange Tsai опубликовал RCE веб-сервера Apache (это сделал кто-то другой, а не вы). Каким бы ни был триггер, такое случается, и с этим ничего не поделаешь. В подобных ситуациях хорошо пообщаться с кем-то, предпочтительно с другом-хакером, которому вы доверяете, или с кем-то на хакерском сервере Discord. Сообщество исследователей баг-баунти — это потрясающая сеть поддержки.

Справиться с синдромом самозванца помогает и объективный взгляд. Подумайте о том, что вы делаете. В мире примерно тысяча хакеров, регулярно зарабатывающих хорошие деньги на баг-баунти. И вы стремитесь стать одним из них? Задумайтесь о том, что же такое баг-баунти. Вы пытаетесь находить баги в системах, уже проверенных опытными пентестерами и красными командами, и конкурируете при этом с десятками других хакеров. Что бы кто вам ни говорил, это непростая задача! Так что не корите себя! Баг-баунти — это как волны, иногда вы на вершине, а иногда падаете вниз. Просто помните: хотя многое зависит от удачи, для наступления удачного исхода нужен шанс, а шансы возникают, только если вы усердно трудитесь.

Мотивация

С этим пунктом все сложно. Мотивация появляется и исчезает, и в конечном итоге нельзя полагаться на нее, если вы хотите добиться мастерства в своем деле. Придумайте себе привычку («я буду заниматься хакингом по два часа каждый день по утрам») или поработайте над чем-то другим, если чувствуете усталость. Часто мне надоедает ручное тестирование, и я переключаюсь на написание кода для нового инструмента или на что-то подобное, просто чтобы сменить темп работы. Многие хакеры страдают от СДВГ, и им может быть сложно сосредоточиться на одной конкретной вещи; я считаю, что если вы делаете хоть что-то, даже слушаете хакерский подкаст, то вы уже молодец. Шаг за шагом, метр за метром. Правильно управляйте своей энергией, и вы увидите, что достичь прогресса станет проще.

Разумеется, бывает и так, что вы упорно трудитесь, но не находите никаких багов. Такое случается. Это часть процесса. Верьте в себя и знайте, что если продолжите работать, то следующий баг неизбежен. Он должен рано или поздно найтись. Продолжайте двигаться в нужном направлении!

С чего начинать

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

Гибкость мышления

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

Например, если вы ищете только IDOR и контроль доступа, то можете упустить абсолютно очевидные баги систем, потому что никогда не задумывались над тем, что делаете. Вот пример:

Я тестировал программу со стандартной моделью SaaS. У нее были администраторы, пользователи с пониженными привилегиями и куча функциональности с системой разрешений на основе ролей. Приложение было маленьким, а программа написана примерно два года назад — по идее, систему разрешений должны были тщательно протестировать. Однако на деле все упустили, что в случае приглашения нового пользователя ему присваивалось по умолчанию разрешение «Administrator», и это разрешение можно было изменить только после того, как новый пользователь принимал приглашение. Образовалось окно эскалации привилегий для нового пользователя, которое злоумышленники могли эксплуатировать. Я написал об этом отчет, и мне оплатили его как проблему уровня High. Если бы я, как и все остальные, сосредоточился на IDOR и контроле доступа, то полностью упустил бы это.

Допущения

Еще одна распространенная ошибка — допущение о том, что какая-то система или ее часть безопасна. Это порочный подход, а мозг человека склонен к множеству логических ошибок, склоняющих его к неверному пути. Тестируйте то, что, по вашему мнению, не может быть уязвимым, потому что часто оно оказывается таковым. За свою карьеру я видел баги, которые, как я считал, были просто невозможны. Но они обнаруживались.

Подход к работе

Выбор программ

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

На самом деле, мне особо не важна область тестирования (scope) — если она слишком узкая, я копаю глубже, а если слишком широкая, то я применяю методологию разведки. Если вы организуете программы баг-баунти, то не обманывайте хакеров! Серьезно, информация о таких кейсах мгновенно разлетается.

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

Интуиция

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

Генерация идей

Уверен, что это явление вам знакомо: как часто вы застревали на одном и том же, а потом возвращались на следующий день и решали проблему за несколько минут? Иногда все, что нужно — это свежий взгляд. Если вы где-то зашли в тупик, рекомендую сделать перерыв и прогуляться. Не надевайте наушники, просто останьтесь наедине со своими мыслями, и ваш мозг естественным образом начнет блуждать и придумывать идеи. Такая «скука» — неотъемлемая часть творчества. Если вы зашли в тупик и вас это раздражает, то остановитесь, примите душ, перекусите, а потом возвращайтесь со свежим взглядом.

Перерывы

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

Для разделения дня на части также помогает техника Pomodoro. Я понимаю, что природа хакерства не всегда позволяет ее использовать, но если вы собираетесь проводить интенсивные исследования, то это чуть ли не необходимость.

Анализ поверхности атаки

Практически самое важное в баг-баунти — это степень опасности выявленной уязвимости. Поэтому к выбору уязвимостей, которые вы хотите найти, стоит подходить с умом. В случае финансовых компаний это все, что затрагивает платежи или финансовые данные. Для чат-приложений это способность получать доступ к беседам других пользователей. И так далее.

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

Кроме того, если вам кажется, что вы достаточно изучили программу, но ничего не нашли, то не сдавайтесь. Продолжайте двигаться. Возможно, через 50-60 часов стоит перейти к чему-то другому, но потратьте хотя бы 30 часов на цель, а уже потом думайте о переходе. У каждой программы есть слой сложности, который вы не увидите, пока не потратите на нее 30 часов и более. У каждой программы. Я находил баги в проектах с невероятно узкой областью тестирования просто потому, что не сдавался и копал глубже.

Совместная работа

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

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

Совместная работа также помогает докрутить относительно безобидную уязвимость до чего-то более серьезного. Практически все хакеры высокого уровня знают, что к Алексу Чапмену следует обращаться, если нужно при помощи эксплойтов Chrome превратить SSRF «безголового» браузера в RCE. Общаясь с другими людьми, вы можете узнать, в чем их сильные стороны; они же узнают, в чем ваши, и вы сможете положиться друг на друга в поисках возможностей для эскалации уязвимости.

Если рядом с вами есть хакеры, то встречайтесь и работайте вместе! Обмен идеями может привести к великолепным находкам, а работа становится намного веселее.

Специализация

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

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

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

Опыт

Начиная с нуля

Люди часто спрашивают, с чего им начать и что изучать в первую очередь. Я постоянно повторяю: не стоит пренебрегать фундаментальными знаниями. Срезая углы, вы вредите будущему себе. Ниже в разделе «Самообучение» я поделюсь списком полезных ресурсов. 

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

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

Наконец, скажу пару слов на тему отправки отчетов о безвредных багах. Такие отчеты вряд ли помогут вам расти профессионально. Не сообщайте о багах, если не уверены в степени их влияния. Прежде чем писать отчет, остановитесь и задайтесь вопросом: на что влияет баг? Действительно ли он может причинить вред компании? Если вы затрудняетесь с ответом, то не отправляйте отчет. Имейте стандарты! Опытные хакеры обычно не сообщают о багах со статусом Low. Если хотите стать одним из них, придерживайтесь тех же стандартов.

Мероприятия Live Hacking Event

Поверьте мне, лучшие хакеры действительно пользуются теми же инструментами, что и вы. Если вы когда-нибудь попадете на Live Hacking Event, то увидите, что люди во многом копируют друг друга, даже при работе над сложными багами. Почему? Потому что все мы мыслим одинаково! Участники подобных мероприятий накопили достаточно опыта, чтобы их мыслительный процесс был приблизительно одним и тем же. Попросите опытных хакеров придумать пять идей по решению нишевой проблемы, и минимум трое совпадут во мнениях.

Каждый амбициозный охотник за багами должен стремиться попасть на Live Hacking Event. Лично я встретился с большим количеством людей, выступления которых стали крайне важной частью моего роста. Проще попасть на маленькие платформы наподобие Intigriti, но и это будет стоить огромных усилий.

Самообразование

Пожалуй, самая важная часть баг-баунти — это «научить себя учиться». Самое главное — вы должны получать удовольствие от процесса. Не заставляйте себя учиться. Если вы в принципе не способны получать удовольствие от процесса, скорее всего, баг-баунти — не для вас.

Ресурсы для тренировок

• Portswigger Labs: старый и надежный ресурс. Их лабораторные работы — самый лучший бесплатный ресурс для обучения хакингу.

• XSS Gym by BruteLogic: очень хорошая площадка для освоения XSS. Тоже бесплатная.

• PentesterLab: очень хорошая лабораторная среда. Платная. Особенно полезна для изучения ревью исходного кода.

• BugBountyHunter.com: реалистичная среда обучения баг-баунти, созданная Zseano. Сам я ее не пробовал, но Zseano — человек, которого очень уважают в нашей отрасли, так что я верю, что эта платформа научит вас хакингу.

• HexTree.io: платный. Новый игрок в сфере обучения безопасности, созданный усилиями ветеранов отрасли LiveOverflow и StackSmashing.

Подкасты

• Critical Thinking: обязательный подкаст для всех, кто интересуется баг-баунти. Я регулярно его слушаю и крайне рекомендую.

• Day[0]: потрясающий подкаст, в котором обсуждаются многие сложные темы. Один из ведущих — мой приятель Zi, за опыт которого я могу поручиться лично.

Рассылки

• Hive Five: наверно, лучшая рассылка. Я бы не добился всего того, что знаю, без этой рассылки Securibee.

• Bug Bounty Reports Explained: очень подробные разборы примеров различных типов багов от опытного хакера.

• MonkeHacks: моя рассылка. Если вам понравилась эта статья, прервитесь на секунду и подпишитесь на нее.

YouTube

• InsiderPHD: отличный канал для начинающих в сфере баг-баунти. Кэти — моя приятельница, очень приятная при личном общении.

• PwnFunction: хорошие видео по темам, которые могут отсутствовать на других каналах.

• Bug Bounty Reports Explained: потрясающий канал, простым языком объясняющий сложные уязвимости. Кажется, с него Гжегож начинал заниматься контентом по баг-баунти.

• Stök: Stök — один из лучших хакеров-инфлюенсеров. Его видео во многом повлияли на то, что я занялся хакерством, и в особенности ролики про мероприятия Live Hacking Event. Его видео про H1-4420 за 2019 год стало большим источником вдохновения для меня, а в прошлом году мне довелось соревноваться на H1-4420, так что, похоже, история совершила полный круг.

• NahamSec: Я почти не смотрел этот канал, но многие мои друзья попали в мир баг-баунти благодаря просмотру его видео про изучение систем в прямом эфире. Крайне рекомендую.

• Codingo: отличные технические видео. Автор уже давно успешен в этой области, и если вы посмотрите его контент, то поймете, почему.

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

Кодинг

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

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

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

Конференции и встречи

Общение с коллегами очень важно, как и в любой другой сфере безопасности. В целом сообщество хакеров очень отзывчивое и приветствует новичков; если вы будете относиться ко всем с уважением, вам будут открыты все дороги. Проверьте в HackerOne’s Brand Ambassador Program, есть ли в вашей стране клубы HackerOne, или просто присоединитесь к одному из основных серверов Discord на любой из крупных платформ, и вам подскажут верное направление.

Def Con — это крупное ежегодное мероприятие, и если у вас достаточно времени и средств, то рекомендую на него съездить. Я летал на него в 2022 году и видел многих знаменитостей, например, Джеймса Кеттла, который вживую рассказал о своих последних исследованиях. Это настоящий обряд посвящения для любого начинающего специалиста в сфере безопасности.

Сравнение баг-баунти с пентестингом

Между двумя этими понятиями существует большая разница: пентестинг — это единовременная активность, а баг-баунти — непрерывная. Компании постоянно выпускают новые фичи. Эти фичи редко тщательно тестируются перед релизом. Разумеется, навыки пентестинга полезны для хакинга, но пентестинг обычно проще, чем баг-баунти. Он не подстраивается под постепенные изменения в продуктах компании.

Заключение

Надеюсь, моя статья дала вам представление о том, что такое методология баг-баунти. Это не только инструменты для поиска багов, но и образ мышления, опыт и даже люди, с которыми вы работаете. Здесь нет коротких путей, а если вы нашли короткий путь, то поздравляю — вы отличный хакер! Поиск дыр в системах — это как раз то, чем мы занимаемся. Чтобы добиться успеха в мире баг-баунти, нужно еще много всего, но изложенное в статье поможет вам надолго определиться с маршрутом. Теперь, когда у вас есть все нужные знания, идите и сделайте что-нибудь крутое!