Темная комната: багбаунти в России

Что нужно уметь, чтобы стать багхантером? 

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

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

Отмечу, что для багхантера будет полезен любой навык — от анализа кода до знания особенностей конфигурации разных сервисов и их настроек по умолчанию. Например, в ходе исследования вы можете раскрыть код, в котором используется парсер XML с включенной обработкой внешних сущностей (небезопасные настройки по умолчанию). Зная эти факты, можно без проблем протестировать возможности и ограничения XXE-атаки. Проще говоря, любой полученный навык и знания в области ИТ рано или поздно пригодятся. 

Существует ли в России полноценное комьюнити багхантеров? 

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

На твой взгляд, багхантеры скорее топят за безопасность или просто любят всех ломать?

Все зависит от конкретного исследователя. Лично я могу взяться за небольшую программу, связанную с государственными сайтами, просто потому что хочу сделать наш «государственный ИТ-сектор» немного более безопасным. В этом случае я скорее топлю за безопасность. Каждый найденный Broken Access Control или простой IDOR — это сохраненные в тайне персональные данные граждан и предотвращенные риски дискредитации. Приятно осознавать, что мой труд помогает обществу. 

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

Спокойствие vs деньги

Сколько багов в среднем ты находишь за месяц и сколько денег на этом зарабатываешь? Это твоя основная работа?

За 17 месяцев в багбаунти я сдал около 200 валидных и оплачиваемых багов — примерно 10–12 в месяц, что на самом деле немало. Но для меня это исключительно хобби и способ получить дополнительный доход. Моя основная деятельность — проведение пентестов.

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

Может ли поиск багов заменить работу в офисе? Сколько времени придется тратить, чтобы получать деньги, сопоставимые с заработком в крупной ИТ- или ИБ-компании? 

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

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

Расскажи о баге, за который ты получил самую большую награду.

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

Во время очередного созвона мне стало скучно, и я решил зайти в программу, которую ранее не просматривал. Сразу же нашел там простейший IDOR, который позволял выкачивать множество данных о клиентах. При этом баг не был дубликатом, хотя программу уже просматривали опытные исследователи (это к вопросу о том, что «все уже нашли»). Я сдал отчет и заработал свыше 700 тыс. руб. всего за пару минут. 

Команда вендора устранила недостаток и попросила провести ретест — проверить корректность исправления уязвимости. Во время повторного тестирования я заметил интересное поле ответа. Установил его в запросе, увидел, что сервер сохранил переданную мной XSS-инъекцию, и тем самым нашел еще одну уязвимость — слепую XSS, которая позволяла захватывать аккаунты администраторов системы. Более того, это оказалась 0-day! В итоге, потратив суммарно около 10 минут, я заработал свыше 1,4 млн руб. и получил идентификатор БДУ.

За какую сумму ты бы продал найденный баг на черном рынке? Есть ли такие запросы в даркнете и случаются ли подобные кейсы в комьюнити?

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

Бывает ли, что заказчики просят тебя найти что-то, что выходит за рамки легальной работы? Как бы ты отреагировал на такой запрос?

К счастью, в моей практике таких моментов не было, но на любые намеки заказчик получил бы отказ. 

Насколько справедливо оценивается критичность багов на популярных платформах? Часто ли случаются конфликты? 

Все зависит от вендора. У одних оценка уязвимостей четко привязана к метрикам CVSS, а другие действуют по принципу «нормальный отчет, дадим 10 тысяч». Размеры выплат тоже сильно разнятся: иногда крупная компания платит столько же, сколько небольшая организация с сайтом государственного назначения (например, региональные власти). 

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

Как много багов несправедливо закрывают как «дубли» или «неважные»? 

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

В целом я хоть и редко, но сталкиваюсь с некорректной обработкой отчетов. В большинстве случаев достаточно написать комментарий и запросить дополнительную информацию — команда вендора либо даст исчерпывающие объяснения, либо пересмотрит оценку. Хотя я прямо сейчас решаю спорный кейс со специфичным вендором, который не идет на контакт и попросту игнорирует любые сообщения и вопросы :) Причем подобная ситуация с ним возникает не первый раз...

Приведи пример спорного случая из своей практики.

Был интересный кейс, где диалог с вендором продолжался несколько дней и растянулся аж на 24 сообщения. Разрешения на дисклоуз у меня нет, но скажу так: я нашел в определенном функционале уязвимость, позволявшую обходить СЗИ и осуществлять атаки (PoC в отчете был). Мой отчет получил статус «дубликат», и первым делом я решил запросить оригинал: ошибка была не совсем стандартная, и я имел все основания полагать, что что-то пошло не так. И действительно — что-то пошло не так… 

Сначала мне скинули ссылку из URL, по которой я не мог просмотреть отчет (на платформе нет IDOR-уязвимости, пришлось еще раз в этом убедиться). При этом вендор утверждал, что все работает, и «мы сами по этой ссылке все смотрим». 

Потом было так:

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

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

Какую часть найденных тобой уязвимостей компании реально исправляют, а не просто закрывают отчет?

Я не слежу, но думаю, что доля таких багов достаточно мала — около 1/4. К тому же многие отчеты могут висеть в статусе «принят», даже если проблема давно исправлена. Здесь нужно учитывать, что задача бизнеса — держать баланс между безопасностью и доходом. Если баг не критичный, на его исправление могут немного забить, принимая риски. 

Можно лучше?

Каких механизмов и процессов пока не хватает на багбаунти-платформах? 

На момент проведения интервью активно появляются программы по недопустимым событиям (НС), и их явно нужно исправлять, поскольку: 

1. Они не учитывают все возможности реализации НС. Иногда, чтобы выкачать персональные данные из базы, достаточно просто найти бэкап, а не пробиваться в закрытый порт. 
2. Условия не всегда прописаны четко. Например, в одной из программ стоит цель «Получить доступ к базе Elasticsearch с ПДн», при этом не указано, к какой именно (а их несколько). В этом случае тяжело понять, выполнил ли ты условия реализации НС. Например, ты можешь получить к базе с ПДн, но не той, или предоставить не совсем те данные, которые ожидает увидеть вендор. 

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

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

Какие меры стоит принять платформам для защиты интересов багхантеров и компаний-заказчиков?

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

• скорость ответа;
• удовлетворенность исследователей; 
• время выплат;
• качество триажа. 

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

Ранжируй российские багбаунти-платформы от худшей к лучшей.

В России есть две основные площадки — Standoff Bug Bounty и BI.ZONE Bug Bounty. На них комфортно работать и мне хватает скоупов, поэтому на остальных я не сижу. У каждой из них есть свои плюсы и минусы, но для меня главный критерий — хорошие приватные программы, которые интересно смотреть. Они есть на обеих площадках, поэтому в моем рейтинге они равны, хотя и конкурируют друг с другом. 

Какое будущее ждет российский рынок багбаунти? 

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

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