Вознаграждаем за уязвимости четвёртый год подряд

Специалисты в IT-безопасности, которые умеют находить уязвимости и эксплуатировать их, всегда стоят перед выбором — что, в итоге, с этими знаниями и умениями делать? И надо признать, что довольно большое количество таких специалистов выбирает путь ответственного раскрытия информации о найденных проблемах и уязвимостях. Именно с такими людьми компании должны уметь и хотеть взаимодействовать. Речь идет о Bug Bounty — объявляемых компаниями программах поиска уязвимостей в их продуктах и сервисах за денежное вознаграждение.

Bug Bounty

Мы только и слышим в новостях, что снова нашли <название уязвимости> в <название продукта> и всё очень, очень плохо. Компании пытаются сами находить проблемы в безопасности своих продуктов до того, как их найдут другие, и для этого создают внутренние команды безопасности, нанимают внешних аудиторов, а также запускают программы поощрения за обнаружение уязвимостей (т.н. Bug Bounty). Последнему аспекту и посвящена эта статья: как организован поиск уязвимостей за вознаграждение в нашем бизнес-подразделении «Почта и Портал», сколько мы уже заплатили денег, и какие в этой сфере мировые тренды и практики.

Подобные программы обычно проходят так:

• Компания объявляет, что теперь готова благодарить исследователей за найденные уязвимости в её продуктах и сервисах.
• Исследователь сообщает об уязвимости.
• Компания проверяет её, если есть — исправляет.
• Компания вносит исследователя в свой «зал славы» и выплачивает денежное вознаграждение (или дарит подарки в виде толстовок, футболок и т.п.)

Часто для проведения Bug Bounty компании используют почту или свою тикет-систему, но есть две очень популярные площадки, которые автоматизируют вышеописанный процесс: hackerone.com и bugcrowd.com. Эти сайты представляют собой каталог компаний, у которых можно поискать уязвимости и сообщить о них через этот же сайт. Одно из главных свойств, за которое ценят эти площадки и компании, и исследователи безопасности, это удобная система вознаграждений. Компании могут пополнять свой счет банковским переводом (бухгалтерии сильно проще), а исследователи могут беспроблемно выводить деньги на свои счета (Paypal, Coinbase, банковский перевод) без лишних задержек (1-2 дня).

Bug bounty в Mail.Ru Group

В Mail.Ru Group сейчас идут четыре Bug Bounty-программы:

• hackerone.com/mailru
• hackerone.com/icq
• hackerone.com/vkcom
• hackerone.com/ok

Наша команда продуктовой безопасности Почты (в Mail.Ru Group несколько команд безопасности) занимается программами /mailru и /icq (также недавно запустили для delivery-club.ru и lootdog.io — входят в /mailru). К нам «прилетают» уязвимости со всех поддоменов: *.mail.ru, *.my.com, *.icq.com и некоторых других. Кстати, у нас 5 человек в команде + 1 человек в команде тестирования, и все имеют тот или иной опыт поиска уязвимостей в Bug Bounty-программах других компаний (например).

В качестве примера рассмотрим программу hackerone.com/mailru. Немного статистики за всё время её работы (запущена 21 апреля 2014 года):

• ~700 уязвимостей с денежным вознаграждением.
• 446 исследователей, которые прислали подтвержденные уязвимости.
• Всего выплатили ~ $250 000.
• Средняя выплата — $345.
• Среднее время ответа — 13 часов.

Максимальная выплата (без бонусов и не в рамках какого-либо конкурса — $5000 (https://hackerone.com/reports/315837), минимальная — $100.

Как работает наша программа:

1. На HackerOne мы получаем сообщение о наличии какой-нибудь уязвимости.
2. Проверяем: находится ли она в скоупе? Хватает ли информации для воспроизведения уязвимости? Не является ли сообщение дубликатом? После всех проверок соответствующим образом помечаем отчёт.
3. Если всё в порядке, один из аналитиков команды безопасности проверяет уязвимость.
4. Если уязвимость подтверждается, информация о ней экспортируется «как есть» в нашу Jira (в ней заведён проект “HackerOne”).
5. Аналитик описывает уязвимость на русском языке, уточняет для программистов специфичные детали и создает тикет в проекте нужного продукта (связывая тикет с п.4). Тикет «падает» на руководителя разработки и включается в план. Задача по устранению уязвимости передаётся ответственным людям, которые разрабатывали эту функциональность или сейчас занимаются её сопровождением, и они начинают героически закрывать дыру.
6. В ближайшую среду (с момента принятия уязвимости) команда безопасности собирается и принимает решение по выплате. Чаще всего, если уязвимость подтверждена и подлежит оплате, исследователь получает деньги в течение недели после отправления уязвимости.
7. Как только уязвимость исправлена, закрываются два тикета в Jira (п.4 и п.5) и сообщение об уязвимости на HackerOne.
8. С точки зрения бизнеса, главная ценность Bug Bounty не в том, чтобы узнать об уязвимости раньше «тёмной стороны» и исправить (хотя это тоже важно), а в том, чтобы узнать, где у вас всё плохо и в какой команде нехватка квалификации или плохо выстроены процессы.

Мифы и факты Bug Bounty

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

• В 95 % случаев уязвимости относятся только к данному коду.
• В 5 % случаев исследователь сам пойдет и проверит эту уязвимость в других Bug Bounty-программах.

Вы можете отметить сообщение об уязвимости как уже известное и присланное другим исследователем, и не заплатите денег!

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

Ваша задача — заплатить меньше денег!

• Наша задача — заплатить достойную награду за достойный репорт.
• Размер наших выплат всегда зависит от максимально возможной угрозы, которую несёт найденная уязвимость. Даже если исследователю кажется, что уязвимость пустяковая, а на самом деле это не так, мы заплатим как за серьёзную уязвимость. Пример: исследователь нашел запрос, на который возвращается 500 ошибка. Выглядит как DoS или просто исключение, но под капотом командой безопасности вскрывается более серьезная проблема, за которую и будет выплачена награда.

На «черном рынке» уязвимости можно продать дороже!

• Далеко не всегда. Например, никто не покупает на «черном рынке» уязвимости вида «смена порядка сортировки писем после посещения сайта example.com» или Self Cross Site Scripting (т.е. внедрение JS только для своего аккаунта). А мы принимаем такие сообщения и, чаще всего, выплачиваем за них некоторую сумму, в зависимости от угрозы и сложности использования уязвимости.
• Как пример: мы готовы выплатить $15 000 за RCE на auth.mail.ru, а это ~935 тысяч рублей по текущему курсу, что является крупной суммой.

И ещё немного о Bug Bounty

Поскольку HackerOne международная площадка, мы получаем уязвимости от исследователей со всего мира, что позволяет делать некоторые выводы об общих тенденциях в Bug Bounty. Сейчас люди начали искать уязвимости не только в написанном компанией коде, но и в различных популярных решениях, которые используются сразу несколькими организациями. И стала реальной ситуация, когда присылают уязвимость нулевого дня в одном из продуктов, который писали не мы (т.е. уязвимость не имеет исправления от производителя — 0day). Что мы в этом случае делаем:

1. Временно отключаем уязвимый сервис или «виртуально» патчим. Например, пишем правило nginx. Если есть исходники сервиса (допустим, это уязвимость в самом nginx), то исправляем, пересобираем, раскатываем по всей компании.
2. Сообщаем вендору с указанием, что эту уязвимость нам прислал такой-то исследователь на HackerOne.
3. Выплачиваем исследователю вознаграждение. Да, мы платим за уязвимость в чужом коде, но проблему мы исправили, безопасность повысили, а еще поняли: если это не разовая проблема с конкретным софтом — возможно, его стоит изолировать (вынести в другую сеть, поместить в «песочницу») или отказаться от него вообще.

Бывает и обратная ситуация: исследователь искал уязвимость у нас, нашел её, но она оказалась не в нашем коде. Тогда мы тоже действуем по пунктам выше. Например, нам присылают уязвимость, найденную в ПО компании Х, тоже имеющей свою программу Bug Bounty. По идее, исследователь должен получить вознаграждение и от нас, и от компании Х. Но с точки зрения Х ситуация выглядит так, что исследователь непреднамеренно раскрыл уязвимость совместно с «третьей стороной» (“3rd party persons”), т.е. с нами. И в таких случаях Х может отказать в выплате, а мы всё же платим исследователю.

Развитие Bug Bounty

Если вы вдруг задумаетесь о своей Bug Bounty-программе (или уже запустили её), то важно не просто описать правила, выставить цены, принимать и исправлять уязвимости, выплачивать деньги, но и развивать программу. Мы делаем это следующим образом:

• Самое «простое» — повышение выплат. Например, буквально недавно мы подняли выплаты за все Server Side-уязвимости в среднем на 3-5 тысяч долларов (на постоянной основе), а до этого поднимали прошлым летом.
• Присоединились к программе Google Play Bug Bounty. Если ваше приложение есть в Google Play, у вас есть Bug Bounty-программа, и в приложении кто-то нашёл критическую уязвимость, то Google доплатит исследователю $1000. В нашем случае доплачивают за уязвимости в Android-приложениях Почты, Облака, Кода Доступа (ТОТР) и Календаря.
• Важно, чтобы о вашей программе писали сами исследователи. Поэтому не только не бойтесь раскрытия найденных уязвимостей, но и просите об этом исследователей (на HackerOne это можно делать ограниченно, например, если в обсуждении уязвимости есть конфиденциальная или иная информация, не подлежащая разглашению). Также все раскрытые сообщения об уязвимостях на HackerOne попадают в Твиттер и Телеграм-канал, на которые подписаны багхантеры со всего мира.
• Пробуем систему грантов. Выбираем самых «крутых» исследователей (оцениваем по общей сумме выплат за год и количеству валидных уязвимостей), пишем им, какой сейчас фронт работ (выбираем важные для себя продукты и фичи) и предлагаем их посмотреть, а по окончании — написать небольшое резюме, какие уязвимости искали и что смотрели. Вне зависимости от того, будут найдены уязвимости или нет, выплачиваем по $500. За каждую найденную уязвимость выплачиваем отдельно, в соответствии с действующими правилами. Стоит отметить, что это сработало очень эффективно.
• Также работает система проверки новых фич, которые еще не доступны всем пользователям.

Популяризация Bug Bounty

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

Мы уверены, что Bug Bounty нужно популяризировать, особенно в России. Например, на днях мы приняли участие в большой конференции по информационной безопасности Positive Hack Days 2018.

Секция по Bug Bounty



Во-первых, мы собрали секцию по Bug Bounty. Цель была простой — собраться багхантерами и поговорить «за жизнь». О чем беседовали:

• Как нам (hackerone.com/mailru) живется на принимающей стороне.
• О подходах при разведке и сборе доменов.
• Рассмотрели различные уязвимости, которые вообще находили багхантеры.
• Обсудили инструменты для Blind XSS, SSRF и многое другое.

Кстати, зал был чуть ли не переполнен, послушать доклады собралось около 150 человек. Также мы поучаствовали в паре круглых столов.

Промокоды на $50. Фраза «50 баксов — это 50 баксов» была произнесена Кириллом 'isox' Ермаковым из Qiwi на одном из митапов Mail.Ru Security, где он рассказывал, как заработать миллион на Bug Bounty



Эти $50 (по промокодам с розданных на конференции карточек) мы выплачиваем дополнительно к стандартным выплатам за баг (главное, успеть сдать, валидировать и представить к оплате до 31 августа).

Кстати, о выплатах: в честь конференции мы в течение недели платили за server side-уязвимости в скоупе по двойному тарифу! И, само собой, после конференции была очень душевная закрытая after party, где уже в более непринуждённой обстановке продолжились обсуждения новых уязвимостей и опыта участия в багбаунти-программах.

Наверное, можно еще многое рассказывать — про варианты управления Bug Bounty-программами (можно делать их силами сотрудников самой компании, а можно и аутсорсить, это становится всё более популярным); про то, почему важно исправлять уязвимости, которые даже не затрагивают сейчас других пользователей и могут быть использованы атакующим только против себя самих. Поэтому задавайте вопросы в комментариях, буду рад ответить.