Простой способ заработать на Bug Bounty

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

Bug Bounty в бесплатном программном обеспечении с открытым исходным кодом — что это такое?

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

Многие из них можно найти на HackerOne, но, пожалуй, самая крупная — это FOSSA — Аудит бесплатного программного обеспечения с открытым исходным кодом. Это программа по поиску уязвимостей в различных проектах с открытым исходным кодом, спонсируемая Европейским Союзом. Общий призовой фонд составляет внушительную сумму — целых 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:

static void FwdLockGlue_InitializeRoundKeys() {
  unsigned char keyEncryptionKey[KEY_SIZE];
  ....
  memset(keyEncryptionKey, 0, KEY_SIZE); // Zero out key data.
}

Казалось бы, где тут ошибка?

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

Кроме того, его вряд ли можно найти самостоятельно: в режиме отладки вызов memset работает нормально. Тесты тоже не помогут… Остается только самому знать и помнить об этой особенности.

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

Наконец, четвертый пункт. Одним из наиболее полезных преимуществ использования статического анализа при погоне за Bug Bounty является скорость. Да, за один вечер можно проверить два, три, четыре проекта — но это еще не все.

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

Потенциальные уязвимости

Внимательный читатель может удивиться:

Подождите, подождите! С одной стороны, вы говорите о поиске ошибок в коде в программах, с другой — упоминаете о потенциальных уязвимостях. Уязвимости более интересны с точки зрения Bug Bounty. Пожалуйста, поясните, что вы имеете в виду!

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

Кстати, согласно отчету Национального института стандартов и технологий (NIST), около 64% ​​уязвимостей в приложениях связаны с программными ошибками, а не проблемами, непосредственно связанными с безопасностью.

Так что хватайтесь за крапиву, берите PVS-Studio и приступайте к поиску ошибок и брешей в безопасности! Здесь здорово поможет классификация по CWE.

Вывод

Надеюсь, я помог читателю в его поисках тех самых жуков, которые принесут ему почет и денежное вознаграждение. Уверен, статический анализ поможет в этом! Помните, что у разработчиков обычно нет времени на подробный анализ ошибок, поэтому вам придется доказать, что ваша находка действительно может повлиять на программу. Лучший способ — визуально воспроизвести его. И помните: чем больше ошибка нарушает безопасность, тем больше вам за это заплатят.

Вот и все. Удачи в поисках награды!