Хабрахабр

Легкий способ заработать на Bug Bounty

Рисунок 2

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

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 есть целый список.

Для большинства проектов будет достаточно быть зарегистрированным на HackerOne, но многие их приведенных в том списке программ находятся на сайте intigriti.com. Если же есть желание поучаствовать в Bug Bounty от Европейского союза — список проектов, участвующих в этой программе, можно найти вот здесь.

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

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

Подождите, а где легкость?

А легкость заключается в том, что анализировать код исключительно вручную вовсе не обязательно. Существуют инструменты, позволяющие искать ошибки в коде в автоматическом режиме. Например — статические анализаторы кода. Я предпочитаю использовать нашу разработку – PVS-Studio. Анализатор PVS-Studio способен находить ошибки в коде, написанном на C++, C# и Java, а также имеет удобный интерфейс. Помимо этого, есть несколько вариантов его бесплатного использования. Также существует и множество других анализаторов кода.

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

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

Рисунок 1

Пример фильтрации результатов анализа.

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

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

Однако, пусть это не вводит вас в заблуждение. На скриншоте показан интерфейс 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.
}

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

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

Да и тесты для этого особо и не напишешь… Остается об этой фиче только знать и помнить самому. И ведь найти эту ошибку самому практически невозможно: в режиме отладки вызов memset работает нормально.

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

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

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

Рисунок 4

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

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

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

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

Кстати, согласно докладу National Institute of Standards and Technology (NIST), около 64% уязвимостей в приложениях, связаны именно с программными ошибками, а не с недостатками системы безопасности (not a lack of security features).

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

Заключение

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

Желаю удачи в поисках награды! На этом, пожалуй, всё.

An Easy Way to Make Money on Bug Bounty. Если хотите поделиться этой статьей с англоязычной аудиторией, то прошу использовать ссылку на перевод: George Gribkov.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть