Как работает bug bounty
Такой вид заработка, как поиск уязвимостей за вознаграждение, приобрел немалую популярность в последние годы и уже выделился в отдельную область занятости для специалистов информационной безопасности. Все больше компаний присоединяются к таким программам, получившим название bug bounty. О том, как развивалась эта индустрия и как она функционирует сейчас, рассказывает аналитический центр Falcongaze.
Чем же так привлекательны программы bug bounty для компаний? Большую роль здесь играет экономический фактор. Совокупная стоимость bug bounty для организации окажется значительно дешевле, чем найм отдельных специалистов для проведения аудита информационной безопасности и тестов на проникновение. Кроме того, такая кампания чаще всего окажется более эффективной. Многочисленные багхантеры (так называют людей, занимающихся поиском уязвимостей) за короткий срок проверят сервис на практически все возможные уязвимости.
Но вместе с пользой такие программы несут и сложности — появляющиеся от багхантеров отчеты требуется оперативно рассматривать и исправлять, а в случае более-менее популярного ресурса количество предполагаемых уязвимостей может достигать сотен в день, среди которых еще нужно найти те, которые описывают реально существующую проблему. Кроме того, багхантеры редко находят действительно сложные ошибки в работе продукта. Зачастую большая часть исследователей быстро просматривает сервис на простые и широко распространенные ошибки, в надежде малой кровью заработать вознаграждение, а потом переходят к следующей компании. Не дождавшись реакции компании, исследователь также может выложить уязвимость в открытый доступ. Такое случилось, например, с социальной сетью «ВКонтакте». Исследователь обнаружил логическую ошибку в принципе работы рекламного кабинета соцсети. Несмотря на то, что он оставил подробный отчет по ошибке, — компания более полугода не реагировала на его сообщения. В результате уязвимость, вследствие которой можно было практически бесплатно проводить дорогостоящие рекламные кампании на сайте, стала известная широкой общественности.
Такое поведение не слишком характерно для сообщества багхантеров, однако оперативное реагирование все-таки является важным фактором для программ вознаграждения за найденные уязвимости. Задолго до широкого распространения программ bug bounty, внутри сообщества whitehat-хакеров (занимающихся исследованиями без противозаконных целей) сформировался даже своеобразный кодекс чести, согласно которому после нахождения уязвимости информация о ней в первую очередь предоставляется компании, в сервисе которой эта уязвимость была найдена, а в общий доступ попадает уже по прошествии достаточного для устранения этой уязвимости времени. По таким же принципам работает и система bug bounty — репорты отправляются непосредственно компаниям, а после закрытия уязвимости исследователь может рассказать миру о своих достижениях.
Публичный поиск уязвимостей приносит финансовую выгоду не только компаниям, но и исследователям. Для опытных профессионалов программы bug bounty являются неплохим средством заработка. Известный российский багхантер Иван Григоров в своем интервью порталу «Хабрахабр» рассказывал, что специалисты, занимающиеся поиском уязвимостей на постоянной основе, способны зарабатывать своим ремеслом до 25 тысяч долларов в месяц, и это далеко не предел.
Один из самых популярных ресурсов, с помощью которого большинство компаний и внедряют систему bug bounty, — платформа HackerOne. На данный момент платформа объединяет более 3000 специалистов по безопасности в 150 странах. Вообще, история масштабного багхантинга, в том виде, в котором мы знаем его сейчас, с whitehat-хакерами и программой вознаграждения, берет свое начало со спонсирования компаниями Facebook и Microsoft инициативы Internet Bug Bounty. Но если углубиться в историю, то вознаграждение за найденные ошибки практиковалось и до этого, просто не в таком конвейерном масштабе. Один из первых браузеров — Netscape Navigator — собственно и подарил подобным инициативам их имя. Сотрудник Netscape в начале 1996 года заметил, что многие из преданных фанатов продуктов компании являются при этом специалистами в различных технологичных сферах и предложил платить им за участие в разработке проекта, а также впервые использовал для описания этого процесса словосочетание «bug bounty». Первым же подобием программы по поиску уязвимости можно назвать инициативу одного из самых известных математиков и компьютерных специалистов прошлого века Дональда Кнута. За каждую найденную в своей самой известной книге «Искусство программирования» ошибку он высылал внимательным читателям по почте чек на один шестнадцатеричный доллар ($2.56).
Bug bounty может принести пользу не только отдельным компаниям. Совсем недавно стало известно о том, что Министерство обороны США с помощью программы поиска уязвимостей выявило более ста потенциальных брешей в своих электронных ресурсах. Это первая подобная инициатива, проведенная на уровне федеральных властей. В проекте Пентагона приняло участие свыше 1400 специалистов, а представители ведомства, в том числе министр обороны США Эштон Картер, назвал программу отличным способом повысить уровень безопасности систем ведомства при невысоких расходах.
Подобной инициативой заинтересовались даже российские государственные ведомства — об этом газете «Известия» рассказал в майском интервью замминистра связи Алексей Соколов. Представители Минкомсвязи думают о запуске bug bounty для программ из реестра отечественного ПО и сейчас находятся в процессе обсуждения этой возможности с представителями отрасли.
Легкий способ заработать на Bug Bounty
Наверняка вы уже не раз слышали выражение «багхантинг», и я уверен, что вы бы не отказались заработать пару-тройку сотен (а то и тысяч) долларов, найдя в чужой программе потенциальную уязвимость. В этой статье я расскажу о трюке, который поможет исследовать проекты с открытым исходным кодом на наличие таких уязвимостей.
Bug Bounties on Free and Open Source Software — что это такое?
Bug Bounty — это общее название для различных программ, в которых разработчики сайтов и программного обеспечения предлагают денежные вознаграждения за нахождение багов и уязвимостей. Помимо весьма известных Bug Bounty программ от крупных корпораций типа Apple или Microsoft, существуют также программы по поиску уязвимостей в проектах с открытым исходным кодом.
Многие из них можно найти на HackerOne, но, пожалуй, самым крупным является FOSSA — Free and Open Source Software Audit. Это программа по поиску уязвимостей в различных открытых проектах, спонсируемая Европейским Союзом. Суммарный призовой фонд представляет собой внушительную сумму — аж 850 000 евро!
Как принять участие?
Для начала нужно зарегистрироваться на HackerOne. Нам будут нужны именно те проекты, которые имеют открытый исходный код. На HackerOne есть целый список.
Если же есть желание поучаствовать в Bug Bounty от Европейского союза — список проектов, участвующих в этой программе, можно найти вот здесь. Для большинства проектов будет достаточно быть зарегистрированным на HackerOne, но многие их приведенных в том списке программ находятся на сайте intigriti.com.
Чтобы принять участие, необходимо выбрать подходящий для себя проект, а затем внимательно прочитать условия участия. Если они вас удовлетворяют — значит, настала пора практики.
Чтобы найти уязвимость и получить свои деньги, нужно будет всего лишь скачать проект (или клонировать его с GitHub) и тщательно проанализировать каждую строчку кода, исследуя каждое выражение на предмет потенциальных ошибок. Если найдёте что-нибудь, что может повлиять на безопасность программы — оформляйте это в отчет и присылайте разработчикам. Если они оценят вашу находку как стоящую поощрения — ваши денежки у вас в кармане :).
Подождите, а где легкость?
А легкость заключается в том, что анализировать код исключительно вручную вовсе не обязательно. Существуют инструменты, позволяющие искать ошибки в коде в автоматическом режиме. Например — статические анализаторы кода. Я предпочитаю использовать нашу разработку – PVS-Studio. Анализатор PVS-Studio способен находить ошибки в коде, написанном на C++, C# и Java, а также имеет удобный интерфейс. Помимо этого, есть несколько вариантов его бесплатного использования. Также существует и множество других анализаторов кода.
Конечно, статические анализаторы могут выявить далеко не все ошибки. Да и бог с ними! Ведь перед нами стоит цель найти ошибки быстро и просто, а не найти их все.
После того, как проект скачан и собран, будет достаточно сделать лишь пару кликов, чтобы запустить анализ. Результатом его будет отчет с некоторым (как правило, немалым) количеством сгенерированных анализатором предупреждений. В PVS-Studio они классифицируются на три уровня достоверности. Начинать стоит с предупреждений первого уровня, поэтому оранжевый и желтый уровни можно отфильтровать из результата анализа.
Пример фильтрации результатов анализа.
Таким образом, останется лишь просмотреть оставшиеся предупреждения и выбрать из них те места, которые могут представлять собой наибольшую опасность. Стоит обязательно проверить, можно ли воспроизвести какую-либо из них непосредственно во время работы программы. Если у вас получится это сделать — это не только увеличит шансы на то, что разработчики примут отчет, но и наверняка увеличит сумму выплаты. В этом деле наглядность — ваш лучший друг.
Также стоит подумать, не влияет ли найденная ошибка на безопасность программы. Ведь в этом случае выплаченная вам сумма будет в несколько раз больше 
На скриншоте показан интерфейс Visual Studio. Однако, пусть это не вводит вас в заблуждение. Анализатор можно использовать не только как плагин для Visual Studio, но и самостоятельно, в том числе в среде Linux и macOS.
Плюсы данного подхода
Во-первых, использование статического анализатора — это один из самых простых способов поиска ошибок. Чтобы использовать анализаторы кода, вовсе не обязательно обладать какими-то специальными знаниями: достаточно лишь разбираться в языке, на котором написан проверяемый код.
Во-вторых, анализаторы внимательны. Они не устают и не теряют бдительности, в отличие от человека. Поэтому с помощью них можно анализировать сколь угодно большие базы кода с практически минимальными затратами.
В-третьих, анализаторы зачастую обладают большим знанием, чем человек. Что это значит? Давайте я поясню свою мысль на примере кода из ядра Android:
Казалось бы, где здесь может быть ошибка?
Оказывается, компилятор, видя, что массив keyEncryptionKey больше нигде не используется, может оптимизировать код и удалить из него вызов функции memset. Причем делать это он будет только при сборке в конфигурации release. Всё бы ничего, да только ключ шифрования на какое-то время останется в оперативной памяти незатёртым, благодаря чему он может быть получен злоумышленником. Настоящая брешь в безопасности!
И ведь найти эту ошибку самому практически невозможно: в режиме отладки вызов memset работает нормально. Да и тесты для этого особо и не напишешь… Остается об этой фиче только знать и помнить самому.
А что, если об этой фиче не знают разработчики проекта? Что, если при поиске багов об этой фиче не будете знать и вы? Анализатору это не важно, потому что у него есть диагностика V597, поэтому во время просмотра отчета вы обязательно о ней узнаете.
Наконец, в-четвертых. Один из самых полезных плюсов применения статического анализа при участии в погоне за Bug Bounty — это скорость. Да, с помощью него можно проверить два, три, четыре проекта за вечер — но это еще не всё.
Самое главное, что вы можете быть первым. Пока за нахождение багов в каком-либо проекте предлагается награда, проект продолжает дорабатываться и развиваться. Разработчики выкатывают новые релизы и новые фичи, а вместе с ними приходят новый код и новые просторы для ошибок. При использовании описанного мной подхода можно будет прицельно рассматривать новые ошибки и потенциальные уязвимости в первый же день их выхода в свет.
Потенциальные уязвимости
Внимательный читатель может озадачиться:
Стоп, стоп! С одной стороны, говорится об поиске в коде ошибок в программах, с другой стороны упоминаются потенциальные уязвимости. Более того, уязвимости более интересны с точки Bug Bounty. Прошу пояснить!
Дело в том, что ошибки и потенциальные уязвимости – это, по сути, одно и тоже. Конечно, только немногие ошибки/потенциальные уязвимости при дальнейшем исследовании могут оказываются настоящими уязвимостями. Однако, безобидный ляп и серьезная уязвимость может выглядеть в коде совершенно одинаково. В статье «Как PVS-Studio может помочь в поиске уязвимостей?» приводится несколько таких (на первый взгляд обыкновенных) ошибок, которые, как теперь известно, являются уязвимостями.
Кстати, согласно докладу National Institute of Standards and Technology (NIST), около 64% уязвимостей в приложениях, связаны именно с программными ошибками, а не с недостатками системы безопасности (not a lack of security features).
Так что уверенно берите в руки PVS-Studio и приступайте к поиску ошибок и дефектов безопасности! В этом, кстати, вам поможет классификация предупреждений согласно CWE.
Заключение
Надеюсь, я помог читателю в поисках того самого бага, который принесет ему немного признания и денежного вознаграждения. Уверен, что статический анализ им в этом поможет! Помните, что у разработчиков, как правило, нет времени на детальный анализ найденных ошибок, поэтому вам еще предстоит доказать, что ваша находка действительно может повлиять на работу программы. Лучшим способом будет наглядно её воспроизвести. И помните: чем сильнее баг в коде может нарушить безопасность, тем больше за неё заплатят.
На этом, пожалуй, всё. Желаю удачи в поисках награды!
Если хотите поделиться этой статьей с англоязычной аудиторией, то прошу использовать ссылку на перевод: George Gribkov. An Easy Way to Make Money on Bug Bounty.
Как зарабатывать на чужих ошибках: История Bug Bounty
Создатель Ruby on Rails Давид Хейнемейер Ханссон (David Heinemeier Hansson) однажды написал статью под заголовком «В программах встречаются баги. Это нормально». За всю историю работы человека с ПО (и не только с ним) баги были неизбежным и порой дорогостоящим спутником новых и интересных решений.
Есть и еще одно направление, на которое компании также не жалеют денег, — программы Bug Bounty. Крупные технологические корпорации — Apple, Facebook, Google — и даже правительственные организации выплачивают вознаграждения «белым хакерам» за поиск уязвимостей в ПО. Разберемся в истории этого явления.
Краткая история Bug Bounty
Прошло более 100 лет, и вопросы безопасности, которые решают компании, переместились в цифровое пространство. Программные уязвимости, которыми могут воспользоваться недоброжелатели, стали для бизнеса не меньшей проблемой, чем ненадежные дверные замки.
Предположительно, первой программой поощрения за поиск уязвимостей в ИТ стало объявление от Hunter & Ready, датируемое 1983 годом. Компания разрабатывала операционную систему реального времени VRTX и предлагала в качестве награды за найденный в ней баг Volkswagen Beetle («Жук»). Однако победитель мог забрать свой приз и деньгами — давали тысячу долларов.
/ Flickr / Greg Gjerdingen / CC
К середине 90-х в мире уже произошло несколько крупных хакерских атак и начала формироваться современная индустрия ИТ-безопасности. Тогда же набирали популярность первые веб-браузеры — в этой нише шло противостояние между продуктами Netscape и Microsoft. 1995-й был особенно успешным для первой — компания, пользуясь своим лидирующим положением на рынке, удачно провела IPO. В том же году инженер технической поддержки Netscape Джарретт Ридлинхафер (Jarrett Ridlinghafer), обнаружил, что многие пользователи-энтузиасты самостоятельно искали баги в браузере и выкладывали для них фиксы в сеть. Поэтому Джарретт предложил руководству поощрить подобную деятельность и начать выплачивать денежные вознаграждения.
Bug Bounty сегодня
Проблемы и победы Bug Bounty
Однако на сегодняшний день обстановка с программами Bug Bounty не такая радужная, как может показаться на первый взгляд. В индустрии случаются конфликты, связанные с правовыми вопросами «белого хакинга». В 2015 году эксперт по безопасности компании Synack Уэсли Вайнберг (Wesley Weinberg) обнаружил уязвимость, с помощью которой он получил доступ к огромному количеству данных Instagram: исходным кодам, SSL-сертификатам и приватным ключам, изображениям, загруженным пользователями, и др. Пользуясь этой уязвимостью, можно было выдавать себя за любого пользователя или сотрудника сервиса.
Уэсли сообщил о своей находке в Facebook, владеющей Instagram, рассчитывая на вознаграждение. Но представители компании сказали, что Вайнберг вышел за рамки, то есть получил доступ к личным данным сотрудников компании и пользователей сервиса. А это нарушает правила Bug Bounty компании.
За свою находку Вайнберг был исключен из программы, а его босс — Джей Каплан (Jay Kaplan), CEO Synack, — получил звонок от Алекса Стэймоса (Alex Stamos), сотрудника по вопросам информационной безопасности FB, который пригрозил обращением в полицию, если сведения об уязвимости будут опубликованы.
Этот инцидент поднимает вопросы баланса, этичности и контроля за работой «белых хакеров». С одной стороны компании хотят решить свои проблемы с безопасностью, но с другой им важно уберечь конфиденциальные сведения пользователей и сотрудников, не давая ИТ-исследователям «заходить слишком далеко». Сейчас в США утверждают законопроект, который позволяет Министерству национальной безопасности США запустить свою программу Bug Bounty. Возможно, он установит общие юридические рамки для всего рынка.
Будущее Bug Bounty
В 2017 году у 94% крупнейших публичных компаний из Forbes 2000 не было каналов для получения отчетов об уязвимостях. Однако те компании, которые все же имеют программы Bug Bounty, регулярно увеличивают выплаты участникам. При этом отдельные платформы привлекают средства от инвесторов. Это может говорить о том, что рынок расширяется, и у него есть потенциал для роста.
/ Flickr / Gordon / CC
Есть предпосылки и к автоматизации работы исследователей. Gartner прогнозирует, что к 2020 году 10% тестов на проникновение будут проводиться с помощью алгоритмов машинного обучения (по сравнению с 0% в 2016). Эту тенденцию подтверждают инвестиции в сферу автоматизированных bug hunting-систем. В прошлом году в Microsoft представили платформу, которая с помощью искусственного интеллекта выявляет уязвимости и сообщает о них разработчикам. У Ubisoft есть похожее решение для поиска багов в играх.
Это согласуется с тем, что все больше компаний внедряют решения на основе ИИ в корпоративные системы безопасности. Такой подход позволяет сочетать преимущества программ Bug Bounty с конфиденциальностью — чем меньше на процесс влияет человеческий фактор, тем ниже вероятность утечки информации. Поэтому в будущем, возможно, произойдет перераспределение финансирования между живыми и виртуальными «охотниками за багами».
Every bug matters: Как запустить программу Bug Bounty в компании. Опыт Timeweb
Рассказываем об опыте Timeweb
Любой компании необходим взгляд со стороны на состояние информационной безопасности сервисов и продуктов. Эту задачу можно решить разными способами, один из которых — участие в Bug Bounty программах.
Bug Bounty программа как свежая сила в деле багхантинга
Bug Bounty («вознаграждение за ошибку») — это программа, которая предусматривает денежное вознаграждение или другие бенефиты за нахождение багов, эксплойтов и уязвимостей в работе ПО. Программы Bug Bounty реализованы многими компаниями, в том числе Facebook, Google, Reddit, Apple, Microsoft и др.
Компания может запустить подобную программу самостоятельно, своими силами организовав все процессы и взаимодействия. Второй вариант — обратиться к специальным Bug Bounty платформам: заключаем соглашение, и армия багхантеров приступает к работе.
Timeweb запустила Bug Bounty программу около года назад. На тот момент в компании не было специалистов с опытом в этой области, всё приходилось делать методом проб и ошибок. В сети почти никто не делится рекомендациями по построению данного процесса, поэтому часто изобретаются велосипеды, а знания обычно передаются в разговорах с коллегами у кофе-машины.
В этой статье мы расскажем, как организовать запуск Bug Bounty программы, если вы ни разу этим не занимались, на что стоит обратить внимание и как еще можно проверить состояние системы информационной безопасности.
Check it out!
Почему мы запустили Bug Bounty программу?
Перед нами стояла задача: поднять систему информационной безопасности на новый, более качественный уровень и не потратить при этом слишком много денег. Важно отметить, что Timeweb — зрелая компания со сложной инфраструктурой и большим набором критически важных сервисов, поэтому для нас тогда было совсем неочевидным, в какой очередности нужно тестировать сервисы и закрывать уязвимости, к чему вообще приступать первым делом.
Можно выделить несколько способов, как проверить систему информационной безопасности. Перед запуском Bug Bounty программы мы постарались рассмотреть и проанализировать различные варианты. Среди них, наверное, внешний аудит является наиболее распространенным решением задачи. Благодаря аудиту можно найти сложные, нестандартные проблемы, но, даже заплатив большую сумму, ты не можешь быть уверен, что получишь то, что тебе действительно нужно.
Еще один способ — обучить команду и развить компетенции сотрудников. Здесь необходимо понимать, что ресурсы команды все-таки ограничены, и найти все возможные баги своими силами, конечно, невозможно.
В деле проверки системы ИБ помогают также тикеты и обращения клиентов в техподдержку, если получается эффективно обрабатывать замечения и сообщения пользователей.
Параллельно мы общались с коллегами и собирали экспертные мнения, как выстроен процесс поиска багов в других компаниях. Как раз благодаря рекомендациям мы решили обратить внимание на Bug Bounty программы.
Запуск Bug Bounty программы
Что важно учесть на старте?
Существует огромное количество различных типов Bug Bounty программ и платформ.
На первом этапе мы выбирали между публичной и приватной программами, решив остановиться на последней. В публичной программе доступ не ограничен: все желающие могут искать баги. В приватной программе — по приглашению. В обоих случаях баги раскрываются только по соглашению сторон. Мы посчитали, что публичную программу нам открывать пока рано: прежде всего, мы должны быть уверены, что наши сервисы и продукты не содержат критических уязвимостей.
Что касается самой Bug Bounty платформы, мы проанализировали существующие варианты и выбрали наиболее подходящий для нас, оптимальный по количеству багхантеров и стоимости услуг.
Приводим список наиболее известных Bug Bounty платформ на рынке:
В первую очередь, мы выстроили работу внутри компании: определили, как должны взаимодействовать между собой отделы, кто ответственен за исправление багов, кто следит за обновлением скоупа и ответов на репорты.
Перед запуском программы мы бы посоветовали убедиться, что вы сделали все, что смогли, нашли все возможные баги своими силами. Также важно вдоль и поперек знать продукт, который вы планируете отдать в работу багхантерам: какие проблемы есть сейчас, какие были; появляются ли систематические ошибки. Эта информация позволит вам сформировать корректный скоуп (scope) — емко, но исчерпывающе дать вводные данные и описать запрос для багхантеров.
Платформа выбрана, подготовку провели — начинаем набивать шишки работать!
Формируем скоуп
Рассказываем, что мы поняли за год существования программы
Скоуп, заполняемый на Bug Bounty платформе, своего рода оферта — договор между компанией и сообществом багхантеров. В скоуп необходимо включить следующую информацию:
Пример секций скоупа с содержанием пунктов на примере нашей действующей программы:
Как выбрать, что именно проверять в первую очередь? Мы бы посоветовали включить в программу такой сервис или аспект, который, скорее всего, больше всех остальных нуждается в проверке. Невозможно сразу понять, что именно нужно искать, можно только выбрать направление, важно нащупать самые проблемные точки. С каждым новым репортом и каждой новой программой мы наращивали опыт и более отчетливо понимали, куда стоит идти дальше.
До сих пор не все наши сервисы и продукты выставлены на Bug Bounty платформу. Это сделано сознательно, так как часть сервисов, например, создана на основе opеn source решений: их развитием и поддержкой занимаются сторонние команды, поэтому мы считаем, что нет смысла их выставлять в рамках нашей Bug Bounty платформы, так как наша команда следит только за актуальностью данных сервисов.
Стоит учесть, сможете ли вы изменить продукт, включенный в Bug Bounty программу: есть ли команда, которая может заняться его развитием; позволяют ли нюансы архитектуры.
Со своей стороны, во время проведения Bug Bounty программ мы постоянно исследовали все сервисы и сеть своими силами. Это позволило нам сэкономить средства: мы исправляли найденные баги и актуализировали скоуп.
Важной составляющей программы является определение уровня критичности найденной уязвимости и установление размера вознаграждения. Постарайтесь зафиксировать прозрачную зависимость между критичностью ошибки и размером награды. Чем прозрачнее, тем меньше вопросов к вам! Хорошая практика — привязать размер награды к шкале CVSS (открытый стандарт для оценки критичности уязвимости). Кроме того, на Вug Bounty платформах обычно выставлены методички и инструкции, как определять размер вознаграждения. Менеджеры площадок смогут вам с этим помочь. Чтобы ориентироваться в уровне оплаты работы багхантеров, можно зайти на портал HeadHunter и проанализировать указанные зарплаты. Если хакеры перестали проявлять активность, возможно, стоит поднять размер вознаграждения.
В Timeweb мы самостоятельно оцениваем критичность ситуации в зависимости от влияния на бизнес. Наша градация критичности багов по влиянию на бизнес включает 4 уровня:
Таким образом, для установления уровня критичности найденного бага мы анализируем тип уязвимости, важность сервера и степень влияния на компанию. На основании этих критериев мы определяем уровень для каждой найденной уязвимости, от этого и зависит размер вознаграждения багхантеру. Однако добавим, что всё учесть невозможно и часто при определении уровня критичности найденного бага не обойтись без субъективности.
Более детальное описание процесса оценки критичности уязвимости приведено в таблицах:
Таблица оценки сервера/сервиса
Bug Bounty Timeline: Как это было?
Скоуп: Скоуп был составлен на основе примеров других компаний. Spoiler: так делать не стоит! Но нам нужно было с чего-то начинать.
Результаты: В течение недели мы получили 20 репортов, в основном с указанием критичных уязвимостей, и… потратили все деньги, которые положили на счет (несколько тысяч долларов). За эти 7 дней мы увидели повторяющиеся паттерны проблем: множественные проблемы с фильтрацией ввода и отображения данных, различные нарушения бизнес-логики приложения, а также некоторые другие риски по OWASP Top Ten. Мы решили приостановить программу, и следующий месяц занимались только исправлением найденных багов и их анализом.
Как только мы разобрали эти 20 репортов, пришло понимание, что делать дальше: куда копать при разработке, как правильно работать с безопасностью.
Скоуп: Скоуп мы исправили на основе полученных ранее репортов: убрали исправленные уязвимости и акцентировали внимание на то, что интересно нам.
Результаты: В этот раз мы получили достаточно много критичных репортов, однако более точечных и конкретных. Все таски по Bug Bounty были определены как срочные. Благодаря второй программе мы подкорректировали процессы разработки и исправления багов.
Результаты: Получили около 40 репортов с багами разной степени критичности.
Поскольку наши продукты схожи по функционалу, иногда они наследуют не только функции, но и баги друг друга. Оказалось, что новая панель содержала баги, которые уже были найдены в предыдущих программах Bug Bounty. Такие баги были прописаны в скоупе как дубликат, поэтому нам не пришлось за них повторно платить.
В работе сайта было обнаружено много проблем с формами и XSS-уязвимостями.
Скоуп: Главной целью четвертой по счету программы стал поиск SQL-инъекций.
Результаты: Перед запуском программы мы самостоятельно изучали, как это работает, и выполнили исследования своего продукта самостоятельно: нашли только 1-2 некритичные уязвимости. Через 2 недели после запуска этой программы ночью нам прислали долгожданный репорт: багхантер продемонстрировал вектор атаки с деструктивным воздействием на базу данных с данными биллинга посредством blind-SQLi. Оперативно в течение 5 минут мы смогли закрыть эту уязвимость: она была в предыдущей глобальной версии ядра, которая до сих пор используется в виде подключаемых модулей для нескольких action в актуальных последних глобальных версиях панелей управления (виртуальный хостинг, VDS, веб-мастера). Мы были в восторге, что смогли обнаружить такую серьезную проблему и вовремя исправить ее. Помимо прочего мы тщательно проверили по аналогии все остальные аналогичные участки кода.
Отдаем на растерзание: Виртуальный хостинг Timeweb
Виртуальных хостинг — это, грубо говоря, физический сервер, поделенный между сотнями клиентов. Клиенты размещают свои веб-приложения и рабочие каталоги на этом сервере, имеют доступ по SSH и FTP к серверу. У каждого из наших клиентов есть собственные клиенты. На таком сервере крутятся наши обслуживающие сервисные скрипты, сервисы и иные кастомизации, которые взаимодействуют с другими обслуживающими сервисами и базами данных.
Скоуп: Основная цель для багхантеров тут была проста: поиск векторов повышения привилегий до root. Также мы ожидали поиск векторов воздействия на других пользователей и их ресурсы, поиск векторов воздействия на наши обслуживающие скрипты и поиск векторов атаки на другие сервера как виртуального хостинга, так и на сервисные сервера, к которым была бы гипотетическая возможность доступа.
Результаты: Мы выделили багхантерам специальный сервер без клиентов, аналогичный по функционалу production серверам. На данный момент багхантеры нашли всего 10 багов. В 2 репортах были продемонстрированы векторы атаки с повышением привилегий до root, но на другие сервера попасть не удавалось. Эти проблемы были моментально исправлены.
Перед запуском пятой программы мы погрузились в обновление серверов и ПО, разбирались со слабыми местами, разворачивали служебные сервисы в локальную сеть, недоступную для внешней сети. Благодаря этой программе мы провели рефакторинг внутренних систем на сервере. Это позволило нам замечать ошибки даже раньше, чем нам о них напишут.
И куда вас это привело?
О результатах Bug Bounty программы
За почти год работы Bug Bounty программы мы получили 72 репорта. Из них 36 отчетов не удовлетворяют правилам нашего скоупа. Однако багхантеры нашли 7 опасных уязвимостей критического уровня, 9 — высокого и по 10 багов среднего и низкого уровня критичности.
Чтобы получить такой результат, мы потратили более 15 000$ на вознаграждение багхантерам (без учета комиссии за услуги платформы). Наименьшая награда составила 50$ (за уязвимость, позволяющую получать информацию о способе оплаты любого счета посредством IDOR). Наивысшая выплаченная награда на данный момент — 1 500$. Средний размер вознаграждения: примерно 423$.
Что касается качественных результатов:
сохраняем тонус ИБ-мышц
Можно сказать, что багхантеры симулируют действия хакеров. Они каждый день создают санкционированную “вредоносную” активность, заставляя нас смотреть в оба и не терять бдительность.
Багхантеры используют новые сервисы, незнакомые утилиты и современные техники взломов. Благодаря этому наши специалисты могут актуализировать компетенции и знания.
совершенствуем сервис и продукты
Информационная безопасность в целом и Bug Bounty процессы в частности всегда направлены на улучшение и развитие сервиса и продуктов для клиента.
привлекаем сообщество экспертов
В осуществлении информационной безопасности участвуют не только наши внутренние админы, но и полноценное сообщество экспертов с различным опытом и знаниями.
Часто мы спрашивали у багхантеров, как вопроизвести найденный баг и даже как его закрыть. Специалисты были готовы общаться напрямую в Telegram, записывать видео, за что мы им очень благодарны.
Работая с Bug Bounty платформами, мы ответственны за закрытие багов не только перед собой и клиентами, но и перед багхантерами, они ждут обратную связь. Взаимодействие проходит согласно установленному регламенту, мы должны регулярно актуализировать информацию по текущим репортам.
В течение 3 дней мы должны были ответить багхантеру на его репорт: является ли найденная ошибка багом, каков ее уровень критичности. Конечно, мы могли давать ответ и в течение недели, но такое поведение не будет хакер-френдли и может оттолкнуть багхантеров.
лучше понимаем пользователей
Багхантеры — это те же самые пользователи и клиенты, которые передают нам определенный пользовательский опыт в аспектах информационной безопасности.
Есть ли жизнь после Bug Bounty?
Мы продолжаем работать в рамках приватной Bug Bounty программы с проверенной платформой. Мы бы хотели эффективно выстроить все внутренние процессы по закрытию и исправлению багов. Как только мы поймем, что багхантеры, с которыми мы сейчас взаимодействуем, стали менее активными, мы попробуем перейти на другие, в том числе более крупные, Bug Bounty площадки, чтобы получать еще больше репортов и найти все возможные проблемы.
Другим направлением развития для нас стало внедрение принципов безопасной разработки. Обычно разработчики занимаются функциональным программированием, а безопасность уходит на второй план. Важно сделать проверку кода на безопасность ключевым моментом любого код-ревью.
Команда Timeweb старается внедрять новые, современные инструменты для аудита информационной безопасности сервисов. О некоторых из ресурсов мы узнали благодаря сотрудничеству с багхантерами.
Постепенно мы подключаем к решению задач информационной безопасности сотрудников технической поддержки: обучаем коллег и усиливаем команду.
Мы готовы разговаривать о Bug Bounty программе бесконечно долго. Возможно, у вас остались вопросы к нашим экспертам, — пишите в комментариях, о чем еще интересно и полезно почитать. Постараемся ответить на все вопросы ниже или расскажем более подробно в следующих статьях.