Мы используем куки, чтобы пользоваться сайтом
было удобно.
Наверняка вы уже не раз слышали выражение "багхантинг", и я уверен, что вы бы не отказались заработать пару-тройку сотен (а то и тысяч) долларов, найдя в чужой программе потенциальную уязвимость. В этой статье я расскажу о трюке, который поможет исследовать проекты с открытым исходным кодом на наличие таких уязвимостей.
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:
static void FwdLockGlue_InitializeRoundKeys() {
unsigned char keyEncryptionKey[KEY_SIZE];
....
memset(keyEncryptionKey, 0, KEY_SIZE); // Zero out key data.
}Казалось бы, где здесь может быть ошибка?
Оказывается, компилятор, видя, что массив 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.
Надеюсь, я помог читателю в поисках того самого бага, который принесет ему немного признания и денежного вознаграждения. Уверен, что статический анализ им в этом поможет! Помните, что у разработчиков, как правило, нет времени на детальный анализ найденных ошибок, поэтому вам еще предстоит доказать, что ваша находка действительно может повлиять на работу программы. Лучшим способом будет наглядно её воспроизвести. И помните: чем сильнее баг в коде может нарушить безопасность, тем больше за неё заплатят.
На этом, пожалуй, всё. Желаю удачи в поисках награды!
0
0
0
Мы ответим вам на
Если вы так и не получили ответ, пожалуйста, проверьте, отфильтровано ли письмо в одну из следующих стандартных папок:
0