Bug bounty как заработать

История первая или как заработать свои первые 15000р обычным сканированием директорий и файлов.
Вот и первая запись, которая относится к теме поиска уязвимостей в программе bug bounty.

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

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

Баг Баунти для новичков или как начать в bug bounty? Техники и моя методика.

Обо всем этом я думал, ехав в душном автобусе «гармошке», который по всему своему виду должен был закончить свой путь еще лет десять назад.

Отстояв очередную пробку, которая была последней на моем пути, я вышел из автобуса на остановке. Мне предстояло идти еще где-то 10-15 минут.

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

Я почти дошел до моего места работы, как неожиданно вспомнил о том, что я еще вчера вечером после появления на hackerone новой компании, которая готова была отдать себя на растерзание толпам пентестеров и исследователям информационной безопасности, куда я причислял с недавнего времени и себя, запустил программу Aaquatone .Это одна из множества программ, которая помогает искать субдомены. Она была моим хорошим помощником, которая нашла мне по анналам интернета не одну сотню интересующих меня субдоменов, нашла бы еще больше, если бы я не поленился с самого начала засунуть в нее API ключи различных сервисов.

Об этом можно почитать тут. Ну а на саму программу можно найти кучу обзоров в нашем любимом google. Не поленитесь, она действительно клевая. После того, как Aquaton выдал мне большую кучу субдоменов, я, немного подумав, решил с помощью встроенного в Aquaton сканера проверить их на популярные для веб служб порты.

После того, как и это было сделано, я, не особо надеясь на удачу, наверно, в сотый раз запустил aquatone-takeover, который должен был проверить смогу ли я захватить какой-то субдомен этой замечательной компании. Но результат, как в предыдущих сотнях раз, был нулевой.

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

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

Поначалу все было стандартно: файлы robots.txt, страницы, где нужно было ввести логин и пароль иле же наоборот зарегистрироваться, я уже было хотел идти делать себе очередную утреннюю чашку кофе, как меня привлек один файл размером 500 мегабайт и названием nohup.out в dirsearch был 200 ответ и я решил перейти с помощью браузера и скачать его. Как ни странно, он начал, хоть и не хотя, перебираться с удаленного сервера ко мне на мой жесткий диск. А пока это происходило, я полез в google искать информацию, что же там могло храниться. При переходе по первой же ссылке я понял, что в этом файле будет лежать информация, которую не стоит размещать на веб сервере в открытом доступе. После того, как файл был успешно скачан, я открыл его и, немного пролистав вниз, увидел некоторую критическую информацию, которая явно не должна была попасть ко мне в руки.

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

Проснувшись утром, я чувстовал себя не важно. Хоть и был выходной и стоило бы радоваться предстоящим планам, но к сожалению видимо кто-то наверху решил, что я должен эти выходные провести лежа в кровати. Да я заболел. Целый день я провел как в тумане и все надеялся на письмо от hackerone, но оно сее не приходило.

Но вот, уже приготовившись ко сну, я в последний раз открыл свой почтовый ящик и увидел то, что так долго ждал: письмо о том, что мне не только добавят репутацию, но еще и присудили денежное вознаграждение в сумме, эквивалентной 15000р. Это было лучшее, что могло произойти в этот день, я наконец-то получил свою первую награду, потратив на это не мало времени и услилий, я все-таки смог. Это дало мне много мотивации чтобы дальше и дальше искать.

P.S
Иногда нужно просто делать то, что ты делаешь, и в итоге все получится. Выше я описал, как можно с помощью банального поиска субдоменов и дальнейшего сканирования их с помощью стандартного словаря Dirsearch, найти первым то, что не успели найти другие, и получить свой куш.

Последнее редактирование: 17.12.2018

robdollard

Well-known member
Green Team

The Codeby

ООО Кодебай

30.12.2015 4 627 6 665

robdollard

Green Team
02.05.2018 64 68

Сделал) спасибо) буду сначала здесь размещать а потом в личном блоге со ссылкой на вас, нормально?)
Еще одна уже готова, буду стараться раз в два дня писать)

The Codeby

ООО Кодебай

30.12.2015 4 627 6 665
Сделал) спасибо)
Заливать надо полную картинку. Я исправил как должно быть.
буду сначала здесь размещать а потом в личном блоге со ссылкой на вас, нормально?
Выдержите паузу час и более после публикации у нас и размещайте где пожелаете.
буду стараться раз в два дня писать

robdollard

Green Team
02.05.2018 64 68

Заливать надо полную картинку. Я исправил как должно быть.

Выдержите паузу час и более после публикации у нас и размещайте где пожелаете.

Хорошо без проблем, так и буду делать со всеми последующими статьями.

volodya_m

Green Team
15.12.2018 34 52
В статье идёт речь о программах из набора KaliLinux ?
maurosoria/dirsearch
michenriksen/aquatone

robdollard

Green Team
02.05.2018 64 68
В статье идёт речь о программах из набора KaliLinux ?
maurosoria/dirsearch
michenriksen/aquatone
Да все верно. Они самые.

explorer

Platinum
05.08.2018 1 088 2 482
Статья интересная Но ссылочку забыли поставить где почитать
API ключи различных сервисов. Об этом можно почитать тут

robdollard

Green Team
02.05.2018 64 68
Статья интересная Но ссылочку забыли поставить где почитать

Действительно забыл, вот она michenriksen/aquatone
Добавлять можно вот таким способом aquatone-discover —set-key %Название сервиса и дальше то что требуется email или api ключ
тут более подробно об этом Censys and PassiveTotal Key · Issue #32 · michenriksen/aquatone

Ну и так же Aquaton сейчас обновился, здесь же идет речь о версии 0.5.0 которую можно скачать здесь michenriksen/aquatone

SearcherSlava

Red Team
10.06.2017 935 1 254

История первая или как заработать свои первые 15000р обычным сканированием директорий и файлов.
Вот и первая запись, которая относится к теме поиска уязвимостей в программе bug bounty.

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

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

Обо всем этом я думал, ехав в душном автобусе «гармошке», который по всему своему виду должен был закончить свой путь еще лет десять назад.

Отстояв очередную пробку, которая была последней на моем пути, я вышел из автобуса на остановке. Мне предстояло идти еще где-то 10-15 минут.

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

Я почти дошел до моего места работы, как неожиданно вспомнил о том, что я еще вчера вечером после появления на hackerone новой компании, которая готова была отдать себя на растерзание толпам пентестеров и исследователям информационной безопасности, куда я причислял с недавнего времени и себя, запустил программу Aaquatone .Это одна из множества программ, которая помогает искать субдомены. Она была моим хорошим помощником, которая нашла мне по анналам интернета не одну сотню интересующих меня субдоменов, нашла бы еще больше, если бы я не поленился с самого начала засунуть в нее API ключи различных сервисов.

Об этом можно почитать тут. Ну а на саму программу можно найти кучу обзоров в нашем любимом google. Не поленитесь, она действительно клевая. После того, как Aquaton выдал мне большую кучу субдоменов, я, немного подумав, решил с помощью встроенного в Aquaton сканера проверить их на популярные для веб служб порты.

После того, как и это было сделано, я, не особо надеясь на удачу, наверно, в сотый раз запустил aquatone-takeover, который должен был проверить смогу ли я захватить какой-то субдомен этой замечательной компании. Но результат, как в предыдущих сотнях раз, был нулевой.

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

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

Поначалу все было стандартно: файлы robots.txt, страницы, где нужно было ввести логин и пароль иле же наоборот зарегистрироваться, я уже было хотел идти делать себе очередную утреннюю чашку кофе, как меня привлек один файл размером 500 мегабайт и названием nohup.out в dirsearch был 200 ответ и я решил перейти с помощью браузера и скачать его. Как ни странно, он начал, хоть и не хотя, перебираться с удаленного сервера ко мне на мой жесткий диск. А пока это происходило, я полез в google искать информацию, что же там могло храниться. При переходе по первой же ссылке я понял, что в этом файле будет лежать информация, которую не стоит размещать на веб сервере в открытом доступе. После того, как файл был успешно скачан, я открыл его и, немного пролистав вниз, увидел некоторую критическую информацию, которая явно не должна была попасть ко мне в руки.

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

Проснувшись утром, я чувстовал себя не важно. Хоть и был выходной и стоило бы радоваться предстоящим планам, но к сожалению видимо кто-то наверху решил, что я должен эти выходные провести лежа в кровати. Да я заболел. Целый день я провел как в тумане и все надеялся на письмо от hackerone, но оно сее не приходило.

Но вот, уже приготовившись ко сну, я в последний раз открыл свой почтовый ящик и увидел то, что так долго ждал: письмо о том, что мне не только добавят репутацию, но еще и присудили денежное вознаграждение в сумме, эквивалентной 15000р. Это было лучшее, что могло произойти в этот день, я наконец-то получил свою первую награду, потратив на это не мало времени и услилий, я все-таки смог. Это дало мне много мотивации чтобы дальше и дальше искать.

P.S
Иногда нужно просто делать то, что ты делаешь, и в итоге все получится. Выше я описал, как можно с помощью банального поиска субдоменов и дальнейшего сканирования их с помощью стандартного словаря Dirsearch, найти первым то, что не успели найти другие, и получить свой куш.

Здрав будь! Ты прав. Бороться и искать, найти и перепрятать! В некоторых случаях человек сначала работает за 100$ в месяц, затем за 100$ в день, затем его рабочий день начинается от 1000$, затем человек начинает заниматься ВЭД и т.д по нарастающей. Удачи во внеучетном доступе!

Источник: codeby.net

Bug Bounty: как белым хакерам заработать в России на поиске уязвимостей

В чём отличие программ по поиску уязвимостей (Bug Bounty) от пентестов и Red Teaming? Какие возможности предоставляют заказчикам российские платформы Bug Bounty в сравнении с ушедшей HackerOne? Как измерить эффективность от проведения Bug Bounty? Как правильно заложить бюджет и сколько реально могут заработать хакеры? Как добиться того, чтобы программа Bug Bounty принесла фактическую пользу компании, а не стала проявлением «бледного» пиара, который не принёс никаких плодов?

1. Введение
2. Что такое программа Bug Bounty?
3. Кто становится заказчиком программ Bug Bounty?
4. Почему нельзя просто привлечь экспертов по безопасности?
5. Публичные и непубличные (приватные) программы Bug Bounty
6. Оценка эффективности программ Bug Bounty
7. Сколько можно заработать на Bug Bounty?
8. Другие стимулы для исследователей
9. Исследователи в программах Bug Bounty: кто они?
10. Пентестеры и специалисты по поиску багов
11. Риски в программах Bug Bounty
12. Как сделать инициативу Bug Bounty привлекательной для компаний?
13. Как планировать бюджет инициативы Bug Bounty?
14. Выводы

Введение

12 мая прошёл очередной эфир AM Live. На этот раз он был посвящён обсуждению популярной опции при разработке крупных программ — запуска инициатив Bug Bounty. Их участники получают легальную возможность заработать немалые деньги (от 1 до 100 тыс. долларов США, а иногда и более), выполнив задание, связанное с поиском уязвимостей / багов в определённой программе или инфраструктуре. Обнаружив баг, достаточно описать его и предоставить отчёт, за который можно получить вознаграждение. Очень заманчиво и просто.

Приглашённые на эфир эксперты рассказали, как выстраивается процесс, насколько реально заработать немалые деньги, кто участвует в этих программах. Но главное — они объяснили, почему компаниям выгодно участWowать в подобных инициативах и почему они готовы платить такие огромные деньги.

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

В дискуссии приняли участие:

• Ярослав Бабин, руководитель продукта The Standoff, Positive Technologies.
• Лука Сафонов, технический директор компании «Синклит».
• Дмитрий Шмойлов, руководитель отдела безопасности программного обеспечения, «Лаборатория Касперского».
• Алексей Гришин, руководитель программы Bug Bounty, VK.
• Илья Сафронов, директор по информационной безопасности (CISO) Delivery Club.

Модератором дискуссии выступил Илья Шабанов, генеральный директор аналитического центра Anti-Malware.ru.

Что такое программа Bug Bounty?

Инициатива Bug Bounty предоставляет всем желающим возможность принять участие в поиске уязвимостей заданного типа. Поиск ведётся в продуктах или в инфраструктуре, выставленных заказчиком для теста. Объявления о таких программах обычно появляются на специальных площадках, которые становятся посредниками между хакерами / исследователями и заказчиком.

«Исследователь получает в своё распоряжение описание политик, список правил, описание того, что можно и что нельзя делать с инфраструктурой и набором приложений. В политиках описывается, как хакер может прийти на “объект” и что может делать / ломать» (Ярослав Бабин).

Соглашаясь с этими правилами, можно в удобное время выполнить задание. Обнаружив баг, следует отослать отчёт на площадку. Заказчик проводит анализ, оценивает уровень обнаруженной угрозы и выплачивает вознаграждение.

Расценки по багам известны заранее. Деньги получает только тот хакер, который первым сообщил об обнаруженной уязвимости.

Кто становится заказчиком программ Bug Bounty?

«Участие в программах Bug Bounty характерно только для крупных компаний со зрелыми процессами ИБ, выстроенными политиками и внутренними регламентами. У небольших компаний нет таких бюджетов, которые способны привлечь хакеров» (Лука Сафонов).

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

Участие даёт возможность реализовать «краудсорсинг в безопасности, когда продукт оценивается в условиях реальной практики. Это позволяет реально оценить продукт с точки зрения рынка, не ограничиваясь только мнением собственной группы разработчиков» (Дмитрий Шмойлов).

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

«Участие в таких программах положительно влияет на создание положительного имиджа. Он формируется в профессиональных кругах, на форумах. Это — своеобразный маркетинг в профессиональной среде» (Дмитрий Шмойлов).

Почему нельзя просто привлечь экспертов по безопасности?

Возникновение инициатив Bug Bounty объясняется вполне обыденными причинами. «Как показывает практика, привлечение к поиску багов индивидуальных хакеров часто приводит к вымогательству с их стороны. Кто-то нашёл что-то и начинает требовать немыслимых денег за информацию, раскрыть которую заранее он отказывается. Иначе он угрожает распространить сведения о баге по всем форумам и телеграм-каналам, переходя к угрозам и не предоставляя достоверных данных об обнаруженной уязвимости. В такой ситуации невозможно провести анализ, невозможно определить реальную цену» (Лука Сафонов).

Без программ Bug Bounty нельзя рассчитывать на высокую культуру хакеров. Её формируют именно эти инициативы. До них поведение хакера определяется тем, что даже имея на руках реальный баг, он лишён всяких гарантий получения платы за свой труд. Более того, любые попытки надавить на менеджмент, угрозы разглашения информации об уязвимости в случае отказа от обещанной платы порождают обвинения в вымогательстве. Это — уже статья УК.

«Появление Bug Bounty становится катализатором развития культуры на рынке. Эти площадки привлекают опытных специалистов в области безопасности, которые могут найти здесь интересную работу» (Ярослав Бабин).

Это имеет ценность и для компаний. Взамен получения сведений о случайных, единичных багах создаётся поток собираемой полезной информации. Он позволяет достичь уверенности в созданном продукте, подталкивает к выстраиванию процессов в компании, проведению широкого анализа. Это помогает своевременно выявить большинство недочётов и избавиться от системных ошибок.

Рисунок 1. Оценка уязвимости продуктов в рамках программы Bug Bounty

Публичные и непубличные (приватные) программы Bug Bounty

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

Публичные платформы формируют рынок поиска багов для ИБ. Они помогают новичкам быстро вырасти профессионально и набрать необходимый опыт. Привлекательным становится также объявление крупных сумм вознаграждений, хотя получить их непросто.

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

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

«Приватная программа Bug Bounty позволяет собрать максимальный “улов” доступных багов. Публичная программа помогает выявить эксклюзивные ошибки, которые не очевидны ни разработчикам программ, ни специалистам по ИБ» (Лука Сафонов).

Рисунок 2. Выбор платформы Bug Bounty

Оценка эффективности программ Bug Bounty

«Главное достоинство программ Bug Bounty состоит в следующем. Хотя обнаружить одну и ту же ошибку могут сразу десять исследователей, компания обязана заплатить только первому из них. Это позволяет избавиться от ошибок с максимальной эффективностью, потому что при любых других формах тестирования пришлось бы заплатить всем 10 участникам» (Лука Сафонов).

Но следует принять во внимание и обратный эффект. «Публичное участие в Bug Bounty, скорее всего, приведёт к тому, что количество выявленных багов возрастёт, а не сократится. Этого не стоит бояться: на компанию стали смотреть с разных углов зрения, которые раньше не принимались во внимание» (Алексей Гришин).

Встречаются инциденты разных типов. Простое выявление и устранение багов не означает повышения уровня защищённости. «Оценка безопасности по количеству обнаруженных уязвимостей не является корректной. Положительный эффект состоит в том, что разработчик внедряет правильный процесс контроля безопасности. Участие в Bug Bounty повышает уровень зрелости компании, её команды разработчиков, системы защиты. Вся компания выигрывает в целом, она становится более зрелой и безопасной» (Алексей Гришин).

Сколько можно заработать на Bug Bounty?

До сих пор самой известной площадкой для исследователей была HackerOne. Однако из-за сложностей в получении вознаграждений с калифорнийской площадки теперь внимание в России приковано к локальным ресурсам.

«Самые щедрые вознаграждения на российском рынке предлагала, если не ошибаюсь, VK. Они обещали выплату 70 000 долларов за обнаружение ошибки уровня RCE (Remote Code Execution), как на площадке HackerOne.

Telegram обещал выплачивать до 200 000 долларов за баг. Но реально я получил там 1 500 долларов. Больше в этой программе я не участWowал. Apple также обещала выплатить до 200 000 долларов, но хотя отправленный репорт разместили в общем списке, сделать выплату они отказались. Приличный заработок даёт в первую очередь участие в приватных программах Bug Bounty.

Например, в одной из них я получил 10 000 долларов. Кто платит, тот и получает приток багхантеров.

Был случай, когда я нашёл уязвимость в Mail.ru, которая требовала только специальной настройки. Она выполнялась в течение двух минут. В результате удалось заработать 800 долларов. С другой стороны, я сталкивался со случаем, когда отправил репорт, а в ответ получил уведомление, что ошибка стала частью более серьёзной уязвимости, которая уже обнаружена. Несколько тысяч долларов “ушли” к другому» (Лука Сафонов).

Рисунок 3. Целесообразность использования программ Bug Bounty

Другие стимулы для исследователей

Следует сразу отметить, что исследователей привлекают не только заработки. «Многие приходят за новыми навыками, на которых можно повысить репутацию, получить признание в профессиональном сообществе» (Ярослав Бабин).

«Репутация хакера — это его реальная валюта. Она позволяет получать новые заказы. Её можно заработать не только на суммах полученных вознаграждений, подходит также участие в социально значимых проектах» (Лука Сафонов).

«На своей площадке мы планируем привлекать хакеров также за счёт необычных предложений, которые позволяют получить более широкие навыки. Например, реализовать события, которые формально неприемлемы для оцениваемого продукта. Разработчики не исследуют подобные опции, опираясь на невозможность событий. Нахождение багов помогает серьёзно поднять уровень навыков» (Ярослав Бабин).

Исследователи в программах Bug Bounty: кто они?

Следует отметить, что несмотря на большое число участников публичных программ Bug Bounty, многие среди них не являются высококвалифицированными специалистами. «По большей части это — новички, которые научились запускать сканеры безопасности. Они создают отчёты диагностики, пользуясь автоматическими сканерами. Большинство выявляемых ими багов являются неопасными либо не входят в список уязвимостей, за которые компания готова платить деньги» (Ярослав Бабин).

Исследователями чаще всего становятся молодые специалисты в возрасте 20–25 лет. Официально многие из них уже работают в ИБ, а в свободное время они участвуют в программах Bug Bounty. Это позволяет им заработать дополнительные деньги.

Главный стимул — «на программе Bug Bounty можно очень хорошо прокачать свои навыки. Исследователь получает реальную задачу и возможность заработать вознаграждение. Такое участие позволяет серьёзно повысить свой уровень» (Ярослав Бабин).

«Существуют также те, для кого багхантинг — это основной вид заработка, причём вполне достойный. Хотя главная притягательная функция — это практическое изучение новых технологий. Там встречаются сисадмины, разработчики, настоящие технари — люди, которые хорошо понимают архитектуру» (Лука Сафонов).

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

«Большую пользу приносят реальные практики. У нас был случай, когда большинство репортов приносил специалист, который занимался установкой ПО в компаниях. Хорошо зная пользовательский рынок, как ведёт себя продукт на практике, он отыскивал ошибки там, где не додумались разработчики» (Илья Сафронов).

«Хорошие результаты показывают пентестеры. Имея опыт перебора различных опций, они приобретают хорошие навыки в поиске уязвимостей» (Алексей Гришин).

Пентестеры и специалисты по поиску багов

Во многих компаниях не рассматривают участие в инициативах Bug Bounty, ограничиваясь проведением пентестов. Но «пентесты проводятся в рамках отведённого времени. Это становится ограничением, которое мешает исследователям добиться полноценной оценки безопасности для своего продукта.

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

«Пентест может проходить с раскрытием внутренней архитектуры приложения, пентестерам могут быть доступны исходные коды. Это создаёт сильный крен в сторону поиска “заранее ожидаемых” багов. Bug Bounty работает иначе. Это всегда “чёрный ящик”, когда условия похожи на реальный взлом, тогда как в пентестах проверяются отчасти искусственные условия» (Дмитрий Шмойлов).

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

Риски в программах Bug Bounty

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

«Первый — после отправки репорта о баге становится известно, что это — дубликат: кто-то нашёл баг раньше. В качестве доказательства предоставляется репорт, признанный как победный.

Второй — компания уже обнаружила уязвимость, о которой сообщает исследователь. Это должно быть отражено в документах. Там указывается на раскрытую уязвимость, даже если она ещё не была исправлена.

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

Четвёртый — баг относится к типу, который не отвечает правилам программы Bug Bounty. Это — самый сложный случай. В случае разногласий проводится арбитраж на площадке» (Алексей Гришин).

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

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

Как сделать инициативу Bug Bounty привлекательной для компаний?

Сильным аргументом для руководства компаний является то, что в отличие от приватных программ и пентестов публичные программы Bug Bounty предусматривают оплату найденных багов по результату. «Это — максимально эффективно и максимально дёшево» (Илья Сафронов).

«Для компаний это — ещё и имиджевая история. Это порождает доверие к компании со стороны рынка» (Ярослав Бабин).

«Bug Bounty позволяет выстроить активную защиту с учётом особенностей мышления реальных людей. Эта программа позволяет оценить безопасность с точки зрения того, как работают живые люди, а не программы или роботы. Так удаётся выявить те места, через которые хакеры “ломают” программу.

Bug Bounty позволяет закрыть уязвимость не только там, где проводится тест. Появление репортов порождает процессы в системе безопасности, которые помогают закрыть аналогичные уязвимости в других проектах. Это влияет на рост уровня безопасности разработки» (Алексей Гришин).

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

Когда исследователи не имеют возможности для получения легального вознаграждения за обнаруженные баги, информация о них попадает на чёрный рынок. Там за них могут также предложить деньги. Bug Bounty — это канал, который удерживает хакеров от нелегального использования результатов проделанной ими работы» (Лука Сафонов).

«Руководство компаний должно прийти к пониманию, что проблема сущестWowания багов в якобы полностью готовых продуктах вполне реальна. Для получения ощущения высокой уверенности в своих продуктах, для выхода на мировой рынок требуется участие в таких программах» (Дмитрий Шмойлов).

Как планировать бюджет инициативы Bug Bounty?

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

Но возникает также задача не растратить выделенные средства понапрасну. «Для этого компания прописывает в своих правилах, что после достижения определённого размера выплат дальнейшее проведение программы Bug Bounty приостанавливается. Лучше заняться сначала устранением выявленных ошибок, чем продолжать участие без намерения выплачивать вознаграждение» (Лука Сафонов). Обман хакеров ведёт к потере репутации и в дальнейшем лишает поддержки со стороны хакерского сообщества.

«К выработке бюджета надо подходить с умом. Не надо выставлять для оценки сразу всю инфраструктуру. Достаточно выделить участки, в надёжности работы которых есть наибольшая уверенность. Например, по ним уже был проведён аудит. Можно также ограничить охват только информацией о самых критически значимых уязвимостях, например RCE и SQL-инъекциях.

Это позволит открыто взаимодейстWowать с хакерами и постепенно расширять охват, добавляя уязвимости среднего и низшего уровня» (Ярослав Бабин).

Выводы

В эфире AM Live от 12 мая приняли участие эксперты, которые представляют рынок Bug Bounty со всех сторон: заказчики инициатив, организаторы платформ для их проведения, хакеры. Они согласились, что программа Bug Bounty может принести большую пользу компаниям, позволив им рассматривать свой продукт как полностью готовый для работы на рынке. В то же время в планировании и проведении таких программ есть ряд важных особенностей, которые необходимо учитывать, чтобы добиться полезного эффекта.

Самые горячие для российского рынка информационной безопасности темы мы обсуждаем в прямом эфире онлайн-конференции AM Live. Чтобы не пропускать свежие выпуски и иметь возможность задать вопрос гостям студии, не забудьте подписаться на YouTube-канал Anti-Malware.ru. До встречи в эфире!

Источник: www.anti-malware.ru

Как заработать на Bug Bounty

Меня зовут Алексей Гришин, я руководитель направления Bug Bounty VK. За 9 лет участия в программе по поиску уязвимостей на различных платформах мы накопили огромный опыт получения, проверки и оплаты самых разношерстных отчётов, поэтому в этой статье я хочу поделиться советами о том, как правильно написать отчёт, чтобы его оплатили, и рассказать, что делать, если ваши ожидания по выплатам не совпали с реальностью. Добро пожаловать под кат.

Эволюция Bug Bounty в VK

Впервые программа Bug Bounty VK возникла 9 лет назад для почтового сервиса Mail.ru, и надо сказать, что в тот момент программы по поиску уязвимостей только начали набирать популярность и мы были среди первопроходцев по их организации и развитию.

В частности, у нас самих сперва не было четкого видения и требований к тому, как должен выглядеть хороший репорт. Поэтому спустя время мы выработали такую формулу — засчитывали и оплачивали только полезные отчёты, т.е. в которых были правильно и корректно описаны уязвимость и её влияние, а также приведен PoC (proof of concept).

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

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

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

Шпаргалка по проблемным зонам поиска багов

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

Область поиска уязвимостей можно разделить на 2 основные составляющие:

1. Названные домены. C такими доменами все просто, если в нем найти уязвимость, то за нее вознагражден будет в соответствии с правилами программы.
2. Wildcard домены (или те, что «под звездочкой»). В широких областях поиска иногда присутствуют домены, которые могут разочаровать исследователя отсутствием оплаты или тем фактом, что найденную в них уязвимость вообще не примут и не будут рассматривать. Давайте разберем их подробно.

Совет №2: В Wildcard попадают домены без оплаты не специально, они появляются там из—за постоянного развития и изменения программного продукта, в котором исследователь ищет уязвимость. Внимательно следите за новыми версиями ПО, изменения всегда несут в себе ошибки, а следовательно, и возможность заработать для исследователя.

Типы неприятных доменов в областях поиска «со звёздочкой»:

Тестовый домен. Может появиться в области поиска уязвимостей, если разработчикам нужно проверить технологию или решение. В таком WEB—сервисе нет важных данных (исключением может стать код, который потом будет использоваться в “боевом” продукте), а если нет данных, то и влияния от уязвимости нет. Соответственно, в таком случае, уязвимость будет исправлена, но не оплачена. Максимум, что можно заработать тут, — это опыт и очки рейтинга… но их на хлеб не намазать.

Учебный домен. Создан с целью научить студента, нового сотрудника, провести отбор кандидатов или организовать публичный конкурс; реже, это может быть домен платформы для обучения на платной основе. Такие домены изначально предполагались ко взлому — в них нет ничего ценного. Хорошим тоном является их исключение из области поиска в Bug Bounty программе, но к сожалению, иногда они случайно попадают в широкие зоны поиска. За учебные домены не предполагается оплата, а уязвимости на них исправлены не будут (домены CTF—соревнований тому яркий пример).

Партнёрский/брендированный домен. Создается для проверки аналитических гипотез или в рамках партнерств, и зачастую сервера, обслуживающие WEB—приложение, находятся не под управлением владельца Bug Bounty программы. Оплата труда хакера при нахождении уязвимостей в таких доменах зависит от конкретного случая и только если исправление ошибки возможно. При обнаружении таких старых или не используемых партнерских доменов их следует убрать, чтобы они не попадали в зону поиска в будущем, но это не всегда возможно.

Изолированный домен. Не несет угрозы инфраструктуре, специально спроектирован для защиты от утечек. Оплата напрямую зависит от угрозы и критичности данных внутри него. Уязвимости типа SSRF на таких доменах не принимаются и не оплачиваются… в программах VK так точно.

Совет №3: Вероятность найти уязвимость в домене, входящем в Wildcard, выше, но это и более рискованное дело, так как может встретиться один из этих неприятных доменов. Если клинок обоюдоострый — будь аккуратен.

Надеемся, эта информация поможет тебе не потратить свои силы впустую и выбрать лучшую цель для поиска ошибок.

Шпаргалка по составлению идеального отчёта

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

Образцовый отчёт должен содержать следующую информацию:

1. Правильно составить тему отчёта, указав название типа уязвимости, домена/приложения или IP—адрес и уязвимой “ручки” API.

2. В теле отчета описать вектор атаки:

• Если атака не требует аутентификации, то вектор должен быть оформлен в виде команды c URL;
• Если атака требует аутентификации и для её демонстрации достаточно GET—запроса, то вектор должен быть оформлен в виде полного URL, демонстрирующего ее исполнение, а также должна быть предоставлена информация о роли, необходимой для эксплуатации;
• В любом другом случае WEB—уязвимости, участвующие в векторе атаки, должны быть оформлены в виде примера запроса, который необходимо выполнить в Burp Suite (оформленного в виде блок кода);
• Бинарные уязвимости должны быть описаны подробно, с предоставлением кода и параметров сборки, если они необходимы при эксплуатации

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

4. Для приложений или бинарных уязвимостей, воспроизводимых в определенных условиях, указать версию приложения и/или окружения.

5. Завершить отчёт кратким описанием влияния на безопасность.

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

Пример отчёта среднего качества:

Пример хорошего отчёта:

Совет №4: Скупой платит дважды. Не жалейте время на хороший отчёт, он с большей вероятностью принесет вам вознаграждение и не придется отвлекаться на массу уточняющих вопросов.

Вместо заключения, или Топ—5 правил эффективности багхантера.

1. Ищите баги только в заявленных доменах. Этим вы убережете себя и от конфликта интересов с владельцем Bug Bounty программы и от последующего разочарования.
2. Подробно и корректно опишите алгоритм воспроизведения найденной уязвимости и влияние от нее. Помните, что все скрытые нюансы превращаются в дополнительные вопросы, которые впоследствии отвлекают и раздражают вас.
3. Не составляйте рекомендации по исправлению уязвимости (не тратьте на это свое время) — это зона ответственности внутреннего аналитика, а не хакера.
4. Собирайте подтверждения (пруфы). Обязательно вместе с отчётом предъявляйте все возможные PoC (скрипт, видео, скрин и т.д.), подтверждающие, что в данный момент времени вы смогли что—то проэксплуатировать*.
5. Избегайте конфликтов. Это всегда большая трата ресурсов и нерWow с обеих сторон. В любой спорной ситуации приведите качественные аргументы в вашу пользу и попросите пересмотреть выплату. В патовых ситуациях, при уверенности в своей правоте, обратитесь к владельцу платформы как к лицу с независимой экспертизой.

*Комментарий автора: Исследователи должны понимать, что это требование возникает не из вредности владельцев программ, а потому что именно на основании подтверждений происходит распределение финансов и принимаются решения по выплатам. За теоретическую возможность что-то сломать оплата не производится. Если исследователь очень хорошо описал теорию, но не смог применить ее на практике, то шансы получить деньги очень малы.

PS: Нам, как ребятам, отвечающим за работу программы Bug Bounty VK, интересно, чтобы исследователи приносили нам максимально сложные и дорогие уязвимости.

Следуйте нашим советам, принимайте участие в наших программах, общайтесь с нами и составляйте отчёты так, чтобы мы могли заплатить вам максимум.

• bug bounty program
• bug bounty
• поиск уязвимостей
• публичные сайты
• багхантинг

Источник: habr.com

Легкий способ заработать на 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 есть целый список.

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

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

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

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

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

Помимо этого, есть несколько вариантов его бесплатного использования. Также существует и множество других анализаторов кода.

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

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

Пример фильтрации результатов анализа. Кликните на картинку для увеличения.

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

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

На скриншоте показан интерфейс Visual Studio. Однако, пусть это не вводит вас в заблуждение. Анализатор можно использовать не только как плагин для Visual Studio, но и самостоятельно, в том числе в среде Linux и macOS.

Плюсы данного подхода

Во-первых, использование статического анализатора — это один из самых простых способов поиска ошибок. Чтобы использовать анализаторы кода, Wowсе не обязательно обладать какими-то специальными знаниями: достаточно лишь разбираться в языке, на котором написан проверяемый код.

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

В-третьих, анализаторы зачастую обладают большим знанием, чем человек. Что это значит? Давайте я поясню свою мысль на примере кода из ядра 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.

Заключение

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

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

Источник: pvs-studio.com