Самые высокооплачиваемые Bug Bounty программы


Оглавление (нажмите, чтобы открыть):

Программа Mamba Bug Bounty

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

Мы обязательно подтвердим получение вашего сообщения.

Размер вознаграждения

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

Критические сервисы:

  • Инъекции программного кода и операторов SQL – 180 000 р.;
  • Межсайтовый скриптинг (XSS) – 18 000 р.;
  • Межсайтовая подделка запросов (CSRF) – 18 000 р.;
  • Уязвимости в управлении сессией – 9 000р.;

Остальные сервисы:

  • Инъекции программного кода и операторов SQL – 60 000 р.;
  • Межсайтовый скриптинг (XSS) – 9 000 р.;
  • Межсайтовая подделка запросов (CSRF) – 9 000 р.;
  • Уязвимости в управлении сессией – 6 000р.;

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

KUNA Exchange: Программа вознаграждения за найденные уязвимости

Ответственное обнаружение

Вознаграждение

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

Список ниже показывает примерное вознаграждение за обнаружение уязвимостей:

Remote Code Execution – $5,000
Significant manipulation of account balance – $2,500
XSS/CSRF/Clickjacking affecting sensitive actions [1] – $2,500
Theft of privileged information [2] – $1,500
Partial authentication bypass – $500
Other XSS (excluding Self-XSS) – $500
Other vulnerability with clear potential for financial or data loss – $500
Other CSRF (excluding logout CSRF) – $125

[1] Sensitive actions include: depositing, trading, or sending money; OAuth or API Key actions
[2] Privileged information includes: passwords, API keys, bank account numbers, social security numbers or equivalent

Рейтинг лучших программ Bug Bounty за 2020 г. от платформы HackerOne

Это платформой пользуются все — от порно-провайдеров до армии США, давайте же посмотрим, какие же из их программ были наиболее финансово привлекательными в этом году?

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

Apple, Microsoft, Google и другие компании предлагают собственные программы Bug Bounty — как открытые, так и исключительно по приглашению. Вознаграждения по ним иногда достигают 200 тыс. долл. за наиболее серьезные изъяны, способные подвергнуть пользователей большому риску.

Вместе с тем теперь компании могут аутсорсить даже проведение самих программ Bug Bounty, при этом часто предлагая тестировщикам заманчивое финансовое поощрение за анализ своих продуктов.

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

Ниже представлены наиболее привлекательные программы Bug Bounty в 2020 г. по рейтингу HackerOne.

1. PornHub. В рамках запущенной в мае этого года программе Bug Bounty ресурса PornHub уже отправили свои отчеты и получили благодарность от компании 311 хакеров за работу над поиском дыр в безопасности веб-сайтов порно-провайдера.

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

Всего за обнаружение багов PornHub выплатил денежных вознаграждений на сумму 150 420 долл. Сервис начали взламывать уже через несколько дней после старта Bug Bounty.

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

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

И хотя эту максимальную сумму пока никто не получил, количество сообщений о багах повысилось на 50% после того, как LocalTapiola подняла планку вознаграждений. Всего были исправлены ошибки по 38 отчетам, и 40 хакеров получили благодарность.

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

Более 365 хакеров отправили заявки об уязвимостях, при этом в сервисе было исправлено 549 проблем. Полгода назад одному хакеру выплатили 15 120 долл. за сообщение о критической ошибке.

Всего через платформу HackerOne они заплатили 561 980 долл.

4. Snapchat. Предлагаемая сервисом отправки сообщений Snapchat программа Bug Bounty, запущенная два года назад, пользуется относительным успехом: на сегодняшний день по ней получили вознаграждения 125 экспертов по безопасности на общую сумму свыше 70 тыс. долл. Минимальная сумма, предлагаемая за сообщение о реальной ошибке, равняется 100 долл., но некоторые тестировщики ухитрились заработать 10 тыс. долл. при максимальной награде в 15 тыс. долл.

5. Uber. Участникам программы Bug Bounty сервиса для вызова такси Uber (среднее время отклика на сообщения составляет около одного дня) предлагается искать баги и на веб-сайте Uber, и в их мобильном приложении. Приветствуется обнаружение любых ошибок — от случаев межсайтового скриптинга (XSS) до дистанционного выполнения кода.

На сегодняшний день награду получили уже 466 исследователя, а максимальная премия эквивалентна 10 тыс. долл. Средний размер выплат варьируется от 759 до 1000 долл.

6. Hack the Pentagon. В Bug Bounty решило попробовать свои силы и правительство США, учредив программу Hack the Pentagon (хакни Пентагон). Эту программу запустили в марте, и длилась она 24 дня, причем за этот срок удалось закрыть 138 уязвимостей, а тестировщики в совокупности получили 70 тыс. долл. Наивысшей наградой в рамках этой Bug Bounty стала сумма в 3500 долл., а в среднем размер выплат составлял 588 долл.

Программа оказалась настолько успешной, что была учреждена новая программа, Hack the Army (хакни армию). Ее цель — побудить тестировщиков найти бреши в безопасности публичных интерфейсов армии США за вознаграждение в тысячи долларов.

$15 000 за ошибку. Как минский программист ушёл с работы в топ-5 багхантеров Facebook и топ-20 Google (+Гайд, как зарабатывать на багах)

«1 dmitry» — так с некоторых пор в Google в шутку именуют выплату в 1337 долларов по bug bounty program. Android-разработчику Дмитрию Лукьяненко, в честь которого её так назвали, эта сумма в прошлом году приходила на счёт не менее 12 раз.

Год назад Дмитрий превратил своё хобби в бизнес — и теперь зарабатывает тем, что ищет уязвимости в продуктах Google и Facebook, работает с площадками HackerOne и BugCrowd. В рейтинге багхантеров Facebook за прошлый год он в первой пятёрке, в рейтинге Google — в топ-20.

Посмотреть код страницы и найти там скрытую от глаз информацию — не это ли настоящая социальная инженерия, которая без взлома открывает путь к цели? Настоящие легенды не брутфорсят миллионы паролей — иногда нужно замечать непривычное в привычных вещах. И раз ты читаешь этот абзац — возможно, в тебе есть тот самый талант, который присущ старым легендам хакерства? Давай проверим. Если ты окажешься одним из нас — получишь заслуженный приз. Он будет твой, если сможешь отыскать дальнейшие шаги этого импровизированного «квеста» в дневнике хакера, который мы оставили тут — https://vk.cc/99LDMA

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

​​Кстати, неожиданные уязвимости можно найти везде — даже в коде этой статьи.

С чего всё началось?


4 года назад в «Яндексе» я работал над библиотекой, которая отвечала за авторизацию в приложениях, — чтобы, авторизовавшись, к примеру, в «Яндекс.Картах», пользователь больше не проходил эту процедуру в «Яндекс.Музыке». В ходе работы мне нужно было решать задачи, относящиеся к межпроцессному взаимодействию, и мне стало интересно, как другие приложения обмениваются данными и работают с аккаунтами. Я скачал Android-клиент Vkontakte, хотел что-то посмотреть — и случайно обнаружил, что он позволяет моему приложению включать пользователей в любые группы даже без их ведома.

И что вы сделали — сообщили в службу поддержки Vkontakte об уязвимости?

Нет, я погуглил (Cмеётся), хоть и работал в «Яндексе». И нашёл bug bounty сервис HackerOne: он соединяет бизнес в лице Vkontakte, Mail.ru, DropBox, Yahoo, Twitter, Slack и багхантеров. С помощью этой площадки можно заявить об уязвимости — и получить компенсацию от компании-клиента. На сайте HackerOne есть программа каждой компании, в ней список требований к отчётам и перечень продуктов, которые участвуют в bug bounty.

Я всегда прилагаю к отчёту мини-Android-проект, чтобы те, кто его принимает, не тратили время на создание своего такого модуля. Просто скачали, нажали на кнопочку — и всё увидели сами.

Это считается «хорошим тоном»?

В мобильном багхантинге — да: все исследователи, с которыми я общаюсь, так делают. Сейчас я пришёл к тому, что в каждый отчёт помимо описания — самого proof of concept — включаю ещё видеоролик, вроде этого.

15 000 долларов за баг: «Подумал, что один нолик мне просто мерещится»

Сколько вам заплатили за первую найденную уязвимость?

Тысячу долларов. Если честно, я думал, будет больше.

Почему? Такие баги стоят больше?

Так мне тогда казалось…

Как скоро вы пришли к тому, что на поиске уязвимостей можно делать бизнес?

Я долго рассматривал это как хобби: у меня ведь была работа. Тем не менее, искать баги стал чаще — в Mail.ru, Dropbox, Uber: на HackerOne начали накапливаться деньги. Тогда я пошёл и оформил ИП. Мы с женой начитались «страшилок», как в Беларуси тяжело оформить ИП, и даже думали, не сделать ли это в Литве. Но потом решили попробовать «по упрощёнке» поработать. В итоге за два дня я получил документы и дал отмашку HackerOne отправить платёж.

Я стараюсь делать всё правильно. Вот почему я работаю с HackerOne, Facebook и Google — у них есть публичный договор: акты по нему подписываются в одностороннем порядке.

Почему это является плюсом?

Потому что вряд ли вы доберётесь до второй стороны. И вообще, отправляя отчёт, вы не знаете, получите ли деньги. Всегда есть опасение, что придёт ответ: «Спасибо! Мы уже знаем об этой уязвимости». Также никто заранее не оговаривает сумму вознаграждения. Поиск багов, по сути — та же рыбалка: смотришь, изучаешь, цепляешься за что-то глазом и давай «разматывать удочку». А что дальше, никто не знает: может щука, а может и старый башмак.

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

А в чём случайность?

В том, что тестировал-то я Android-приложение, и нежданно-негаданно нашёл проблему на сервере Facebook.

Если использовать вашу же метафору, на сколько потянула самая крупная ваша «рыба»?

На 15 000 долларов и тоже от Facebook: если честно, я даже подумал тогда, что один нолик мне просто мерещится. DropBox когда-то за аналогичный баг заплатила 4 000, и я был счастлив безмерно. Мне казалось, что и Facebook заплатит примерно столько же…

В чём заключалась уязвимость?

В том, что стороннее приложение могло без действий пользователя получить доступ к приватным данным мессенджера Facebook. Например, к базе данных с сообщениями или файлу с авторизованными токенами. Кстати, раньше я о ней никому не рассказывал.

Почему?

Говорят, деньги любят тишину: можно купаться в лучах славы, а можно тихо зарабатывать. Метод, с помощью которого я нашёл уязвимость в Facebook, точно такой же, как тот, что я использовал, чтобы обнаружить проблему в DropBox. Расскажи я о нём раньше и, возможно, до Facebook первым добрался бы кто-то другой.

В ответ на письмо с отчётом ребята из команды безопасности Facebook сбросили мне статью — студенты какого-то университета проводили исследование и проверяли все мессенджеры на тот же вид уязвимости. Но мой отчёт пришёл на день-два раньше.

Конкуренция в вашем бизнесе высока?

В вебе очень. Один раз я нашёл XSS — это когда JS-код можно вставить в тело страницы, и он выполнится. Я был рад и горд неимоверно: ещё бы — «моя первая веб-уязвимость»! Но оказалось, меня опередили — пришёл ответ о «дубликате».

Мастер Йода рекомендует:  Недостижимый адрес Cloudflare опубликовала отчет о тестировании и правке сервиса 1.1.1.1

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

А как часто вам сообщают о «дубликате»?

К счастью, не часто — в 5-7% случаев.

Благодаря гранту Google я стал багхантером на постоянной основе

Почему вы сконцентрировались в основном на Google и Facebook? Ведь есть ещё Apple, Adobe, Microsoft и другие.

Я в основном работаю с Android-приложениями: декомпилирую их, а затем изучаю структуру, ищу компоненты, доступные для других приложений. Я пытался сделать всё то же и на iOS, но не преуспел: приложение с iPhone непросто даже скачать на компьютер — нужен, как я понимаю, рутованный телефон.

Что же до Google и Facebook, у них огромное количество больших сложных приложений под Android, в которых могут быть ошибки — это раз. Два — у этих компаний хорошие выплаты: минимум 500 долларов.

Почему не Microsoft, ведь у них вроде тоже есть Android-приложения — ответ прост: bug bounty на них не распространяется. В Microsoft платят только за уязвимости в Windows, а также в их браузере.

Помимо Google я отправляю уязвимости также в подразделение Android: у меня уже 11 официальных CVE (Common Vulnerabilities and Exposures. — прим. dev.by).

Ещё я хотел бы отметить, что уязвимости, которые я нахожу, — не критические. У нас разработчики могли бы и подзабить на такие: «Ой, да ладно! Это мелочь, да и вообще маловероятно…», но Facebook и Google даже низковероятные баги принимают за уязвимости и выплачивают вознаграждение в 1000-1300 долларов.

Правда ли, что кроме вознаграждения Google также даёт исследователям гранты?

Да, благодаря такому гранту я и стал багхантером на постоянной основе (Смеётся.).

В 2020 году у меня сложилась безвыходная ситуация: неожиданно уволили из стартапа.

Увольнение одним днём стало для меня шоком: «соломки» никто не подстелил, падать было больно. У меня ведь семья, кредит на машину — ещё порядка 15 000 долларов нужно было выплатить.

Неужели не было «подушки безопасности» в виде выплат с программ bug bounty?


Нет, мы никогда не складывали деньги под матрас — они уходили на строительство дома в Смолевичах. И я брался тогда за любые уязвимости, даже те, которым сегодня не стал бы уделять время.

Почему не стали бы?

Сейчас мне неинтересно искать уязвимости на проектах, где выплаты, прямо скажем, невысоки: в Mail.ru, к примеру, могли платить 150-300 долларов за уязвимость. Сегодня я понимаю, что уделяя столько же времени работе, можно получить больше только в Google и Facebook.

Как вы получили первый грант от Google?

Я знал, что Google даёт гранты на исследование уязвимостей. Написал руководителю программы — мы с ним раньше переписывались, он как-то спрашивал, не интересуют ли меня вакансии в Google. Тогда я отшутился: «Если вы откроете офис в Минске».

Прошло пару недель, и я получил перевод на сумму 1337 долларов — «1 dmitry». Снял офис, и работа пошла. Я подсчитал тут на досуге: за год Google назначил выплаты по 16 моим уязвимостям, из них 12 — «1 dmitry», и ещё несколько других.

Я искал баги также у Facebook и Telegram, а вот для HackerOne совсем перестал смотреть: в прошлом году они подключили сервис для отправки платежей, и он не работал с Беларусью. Только недавно мне удалось справиться с этой проблемой.

Каким образом?

У меня накопилась сумма, соизмеримая с двумя зарплатами разработчика в Беларуси, и я попросил прислать ее как раньше — по реквизитам.

Они ни в какую: «Не можем. Не получается», стали предлагать варианты: в биткоинах, через PayPal… К счастью, я познакомился в Лас-Вегасе с CEO HackerOne Мортеном Микосом, написал ему. И хоть он и говорит, что это «не его заслуга», через неделю служба поддержки разобралась и включила Беларусь в список стран, куда доходят платежи.

Business Insider отмечает, что вы получили несколько грантов от Google.

Да, пару в начале года по моей просьбе, и один совсем недавно — уже по инициативе Google. Если честно, мне самому уже неудобно просить: всё же небольшая подушка безопасности у меня есть. Но если дают, не отказываюсь.

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

Какие обязательства накладывает на багхантера получение гранта?

Есть разные гранты: чаще всего ты волен выбирать, что исследовать, но в ряде случаев тебе не оставляют выбора: «Надо это посмотреть!»

Я всегда выбирал Android-приложения. И, к счастью, преуспел. Что приятно, грант — не предоплата, если ты нашёл уязвимости, за них ты получишь отдельно. Но если ты не найдёшь ничего, никто не потребует вернуть деньги.

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

Вы не единожды участвовали в закрытых конференциях по безопасности от HackerOne, BugCrowd и Google. Как багхантеры на них попадают?

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

Эти отчёты исследователи отправляют на самом мероприятии, а команда по безопасности принимает их и обрабатывает, выставляя на табло суммы и баллы. В Лондоне я занял четвёртое место из 20 возможных, а также попал в категорию Show&Tell. Как я понял, это очень круто.

Почти по такому же принципу работает и конкурент HackerOne — BugCrowd. Я был на их мероприятии в Майами и занял там первое место. Но неделю спустя уязвимость, обнаруженную одним из участников пересмотрели, и он переместился на первую строчку, а я получил «серебро».

Один раз я сам напросился на такой live hacking event. Facebook пригласили меня в Лас-Вегас в то время, когда там проходили конференции по безопасности Black Hat и DefCon. Я узнал, что в Вегасе будет проводить своё мероприятие и HackerOne, и написал им.

Значит ли это, что почти любой желающий может попасть на соревнования такого рода?

Думаю, не любой: всё же мероприятия закрытые. Бывает, в новостях на hackerone.com и bugcrowd.com проскакивают анонсы, но кто заказчик, никогда не раскрывается. «Охотнику» с рейтингом, полагаю, не откажут: я же написал — и бинго, мне разрешили участвовать. Однако в таком случае все расходы лягут на ваши плечи.

Кстати, есть ещё вариант: у вас может быть знакомый из тех, кто точно едет на такую конференцию. На мероприятие от HackerOne мне тоже предлагали взять с собой «+1», если мой попутчик самостоятельно оплатит дорогу.

Сейчас я надеюсь, что моего друга из Латвии позовут ещё на одно мероприятие от HackerOne, и он возьмёт меня «+1». У него очень высокий рейтинг — он входит в двадцатку лучших исследователей на HackerOne.

«Вернуться в найм было «планом Б»

Россиянка Алиса Шевченко «взламывает» компьютерные системы крупных компаний по их заказу и зарабатывает около 160 000 долларов в год. Вы для себя не думали над похожим развитием «карьеры»?

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

Как они узнали о вас?

Сотрудники компании были у меня в друзьях в Facebook. Видели фото с мероприятия от Google.

То самое, на котором вы держите в руках огромный чек на 2337 долларов (Дмитрий получил сумму в 500 + 500 + 1337прим. dev.by)?

Оно. С чеком, кстати, вышла забавная история: когда я возвращался из Лас-Вегаса, рядом со мной сидел парень со здоровенным чеком на 25 000 долларов, который загораживал весь проход. Мы потом познакомились — оказалось, это киберспортсмен Никита Марчинский, в позапрошлом году он выиграл в Quake Champions ещё больше — 175 000 долларов.

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

За год у вас не появлялось желание всё бросить и вернуться в «найм»?

Нет, хотя изначально это был «план Б».

Никогда не жалели, что отказались от предложения менеджера Google?

Нет, мне комфортно на родине. Когда Google купил AIMatter, я искренне говорил, что не хотел бы уезжать из Беларуси.

​«Памятка» от Дмитрия Лукьяненко, как начать зарабатывать на поиске багов:

  • Не у всех компаний есть программы bug bounty — не стоит искать уязвимости там, где вас не просят.
  • И уж тем более не советую эти уязвимости где-то публиковать, высказывая «праведный гнев», что вам не заплатили ни копейки.
  • Воспользуйтесь проверенными ссылками: HackerOne, BugCrowd, Google, Facebook, Yandex.

  • Выбирайте компании, у которых есть публичные договора. И не забудьте оформить ИП.
  • Перед тем, как отправить баг, обязательно прочтите условия участия в bug bounty program.
  • Не расстраивайтесь, если узнаете, что у вас «дубликат». На встрече в Google мне рассказывали, как в один день им пришло три отчёта об одной и той же уязвимости.
  • В нашей гонке банк «срывает» первый, поэтому если вы что-то нашли — не тяните с отправкой отчёта.
  • Читайте об уязвимостях, просматривайте открытые отчёты. Возможно, уязвимость уже закрыли, но у вас появится своя идея, как обойти защиту.​

​Хотите почувствовать себя багхантером — найдите в коде этой статьи уязвимость, которая станет подсказкой, что делать дальше. ​

Как баг-баунти платформы помогают компаниям защищаться от хакеров

Что такое баунти-платформы, как они работают, и в чем смысл таких программ для бизнеса, в своей колонке для AIN.UA рассказывает Марк Савчук, менеджер по коммуникациям в Hacken.

Сегодня хакерские атаки становятся обыденным делом. Оно и неудивительно – согласно отчету MсAfee и Center for Strategic and International Studies, мировая экономика теряет около $600 млрд в год из-за киберпреступности.

Спрос на услуги по кибербезопасности также бьет рекорды. В 2020 году размер отрасли составит более $96 млрд. На фоне возникновения все новых угроз рождаются новые инновационные решения и методы борьбы с киберпреступниками. Одним из таких решений являются баг-баунти программы.

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

Первая баг-баунти программа стартовала в 1983 году. Компания Hunter & Ready тестировала свою операционную систему Versatile Real-Time Executive. Любой, кто нашел баг и сообщил об ошибке, мог получить Volkswagen Beetle.

Со временем баг-баунти программы получали все большую популярность. Компании Microsoft, Google, Facebook стали запускать свои собственные баг-баунти программы. Однако так поступали лишь большие компании. Для всех остальных баг-баунти программы были недоступны. Причины заключались в следующем:

  • Проблема номер один – это медийность. Только самые большие компании имели достаточный visibility, чтобы привлечь «критическую массу» хакеров, чтобы получить хороший результат. К тому же, зачем белому хакеру работать с каким-то ноу-неймом, как он будет уверен, что ему действительно заплатят за его работу? Большие компании – более безопасный выбор. Да и могли себе позволить заплатить достойную «баунти» за найденные уязвимости.
  • Второе – компания должна иметь достаточно квалифицированный персонал в IT-департаменте, чтобы грамотно обрабатывать поток найденных багов, который присылают ресерчеры. Потому баг-баунти программы в основном и проводились high-tech-компаниями.

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

Что из себя представляет баг-баунти платформа?

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

Как проходит процесс баг-баунти на платформе?

  1. Первым делом компания-клиент и баг-баунти платформа совместно составляют «скоуп работ». Этот документ четко описывает, какие именно ресурсы клиента подлежат тестированию, за какие именно уязвимости будут выплачены награды и в каком размере.
  2. Запуск баг-баунти программы. Составленный скоуп работ публикуется на сайте и баг-баунти платформа инициирует маркетинговые активности, чтобы привлечь свое сообщество белых хакеров к данной баг-баунти программе. Начинается сам процесс – белые хакеры ищут уязвимости в продукте.
  3. Ресерчеры (они же белые хакеры) присылают отчеты о найденных уязвимостях через баг-баунти платформу, с описанием самой уязвимости и часто с рекомендациями как ее устранить.
  4. Триаж-команда баг-баунти платформы верифицируют баги, которые присылают хакеры. Как только баг был верифицирован и клиент исправил уязвимость в своем продукте – белый хакер получает баунти, то есть, деньги. Одновременно с этим ему начисляют репутацию. На платформах существуют специальные лидборды для рейтингования хакеров.

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

До появления баг-баунти платформ и программ фактически не существовало простого и легального способа хакерам зарабатывать деньги. Теперь же, они могут помогать бизнесу, получать достойную заработную плату (размер баунти может доходить и до $100 000 за одну уязвимость) и получать публичное признание.

Мастер Йода рекомендует:  Разработка консольных приложений и автоматизация задач на PHP старый добрый язык как знакомая

В чем конкурентное преимущество баг-баунти платформ?

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

  1. Количество доступных специалистов. В стандартном тесте на проникновение, будет принимать не более 2-5 специалистов. В то время как баг-баунти платформа обладает в своем распоряжении сотнями белых хакеров. Как правило, эти люди с разных уголков света и имеют разную специализацию , что повышает шанс того, что ресерчеры найдут уязвимость в продукте (их больше и у них разный бэкграунд).
  2. Время тестирования. Опять же – стандартный тест на проникновение длится около от нескольких недель до нескольких месяцев в зависимости от объема работы и является точечной оценкой конкретной версии продукта, в то время как баг-баунти программы могут длится годы и являются непрерывным механизмом по оценке безопасности. И все это время ресерчеры будет пытаться найти уязвимость в вашем продукте.
  3. Система вознаграждения. При проведении стандартного теста на проникновение компания заплатит в любом случае – получит она результат или нет. В то время как система вознаграждения в баг-баунти программах основана на оплате за результат, т.е. за каждый верифицированный баг.

Почему компании дают себя хакнуть?

Напоследок главный вопрос – почему компании добровольно отдают свои продукты на растерзание белым хакерам?

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

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

Однако паниковать не стоит. Передовые технологии и новые подходы к кибербезопасности смогут защитить компании завтра. На каждого хакера есть свой белый хакер.

Бизнес без опасности

Бизнес безопасности или безопасность бизнеса? О том и о другом в одном блоге. Имеющий мозг да применит его (6+)


Страницы

Архив блога

  • ►2020 (95)
    • ►ноября (3)
    • ►октября (6)
    • ►сентября (5)
    • ►августа (8)
    • ►июля (13)
    • ►июня (7)
    • ►мая (12)
    • ►апреля (9)
    • ►марта (7)
    • ►февраля (13)
    • ►января (12)
  • ►2020 (150)
    • ►декабря (6)
    • ►ноября (10)
    • ►октября (9)

    • ►сентября (17)
    • ►августа (4)
    • ►июля (11)
    • ►июня (18)
    • ►мая (14)
    • ►апреля (7)
    • ►марта (15)
    • ►февраля (23)
    • ►января (16)
  • ►2020 (162)
    • ►декабря (20)
    • ►ноября (15)
    • ►октября (11)
    • ►сентября (16)
    • ►августа (10)

    • ►июля (12)
    • ►июня (12)
    • ►мая (13)
    • ►апреля (11)
    • ►марта (15)
    • ►февраля (13)
    • ►января (14)
  • ►2020 (220)
    • ►декабря (15)
    • ►ноября (22)
    • ►октября (17)
    • ►сентября (13)
    • ►августа (12)
    • ►июля (15)
    • ►июня (29)

    • ►мая (21)
    • ►апреля (14)
    • ►марта (27)
    • ►февраля (22)
    • ►января (13)
  • ►2015 (228)
    • ►декабря (18)
    • ►ноября (25)
    • ►октября (27)
    • ►сентября (16)
    • ►августа (6)
    • ►июля (20)
    • ►июня (19)
    • ►мая (18)
    • ►апреля (20)

    • ►марта (25)
    • ►февраля (20)
    • ►января (14)
  • ►2014 (197)
    • ►декабря (15)
    • ►ноября (16)
    • ►октября (14)
    • ►сентября (15)
    • ►августа (7)
    • ►июля (17)
    • ►июня (19)
    • ►мая (16)
    • ►апреля (17)
    • ►марта (21)
    • ►февраля (21)

    • ►января (19)
  • ▼2013 (211)
    • ►декабря (19)
    • ►ноября (6)
    • ►октября (16)
    • ►сентября (19)
    • ►августа (14)
    • ▼июля (16)
      • Мегарегулятор
      • Так готова Россия к информационному противоборству.
      • Cisco покупает Sourcefire
      • Финансовая эффективность программ Bug Bounty для р.
      • Мои статьи об оценке эффективности ИБ
      • Что ждет финансовую отрасль с точки зрения нормати.
      • Разъяснение ФСТЭК по 17-му и 21-му приказам
      • Лебедь, рак и щука информационной безопасности
      • Чернильница бешеного принтера перед каникулами вып.
      • Новое указание Банка России по защите информации в.
      • EMC покупает Aveksa
      • Безопасность критических инфраструктур. Международ.
      • А что думают в ФСТЭК и ФСБ о SmartTV и электронных.
      • Мои критерии выбора участия в мероприятии по ИБ
      • Security for Dummies
      • Измерение эффективности ИБ (презентация с курса)
    • ►июня (23)
    • ►мая (17)
    • ►апреля (23)
    • ►марта (20)
    • ►февраля (17)
    • ►января (21)
  • ►2012 (255)
    • ►декабря (18)
    • ►ноября (19)
    • ►октября (27)
    • ►сентября (18)
    • ►августа (12)
    • ►июля (22)
    • ►июня (18)
    • ►мая (20)
    • ►апреля (29)
    • ►марта (27)
    • ►февраля (22)
    • ►января (23)
  • ►2011 (340)
    • ►декабря (33)
    • ►ноября (29)
    • ►октября (35)
    • ►сентября (27)
    • ►августа (34)
    • ►июля (42)
    • ►июня (33)
    • ►мая (20)
    • ►апреля (23)
    • ►марта (22)
    • ►февраля (19)
    • ►января (23)
  • ►2010 (267)
    • ►декабря (25)
    • ►ноября (21)
    • ►октября (22)
    • ►сентября (20)
    • ►августа (19)
    • ►июля (21)
    • ►июня (24)
    • ►мая (22)
    • ►апреля (24)
    • ►марта (26)
    • ►февраля (21)
    • ►января (22)
  • ►2009 (300)
    • ►декабря (24)
    • ►ноября (26)
    • ►октября (35)
    • ►сентября (24)
    • ►августа (27)
    • ►июля (22)
    • ►июня (23)
    • ►мая (21)
    • ►апреля (28)
    • ►марта (26)
    • ►февраля (29)
    • ►января (15)
  • ►2008 (106)
    • ►декабря (8)
    • ►ноября (13)
    • ►октября (20)
    • ►сентября (9)
    • ►августа (2)
    • ►июля (11)
    • ►июня (6)
    • ►мая (3)
    • ►апреля (13)
    • ►марта (10)
    • ►февраля (9)
    • ►января (2)
  • ►2007 (56)
    • ►декабря (14)
    • ►ноября (2)
    • ►октября (10)
    • ►сентября (12)
    • ►августа (17)
    • ►мая (1)

Категории

  • законодательство (597)
  • персональные данные (432)
  • тенденции (300)
  • ФСТЭК (298)
  • консолидация (250)
  • поглощения (246)
  • ФСБ (227)
  • выставки (202)
  • угрозы (175)
  • Россия (139)
  • SCADA (134)
  • Банк России (133)
  • стандарты (133)
  • обучение (123)
  • криптография (119)
  • SOC (105)
  • оценка соответствия (101)
  • управление инцидентами (94)
  • метрики (83)
  • цена безопасности (81)
  • Роскомнадзор (74)
  • Интернет-ресурсы (73)
  • НПС (72)
  • Разное (71)
  • стратегия (68)
  • проблемы ИБ-компаний (60)
  • психология (60)
  • Юмор (58)
  • экономика (57)
  • безопасность бизнеса (56)
  • Threat Intelligence (55)
  • философия (53)
  • заблуждения (50)
  • Минкомсвязь (46)
  • наука (46)
  • облачная безопасность (45)
  • геймификация (42)
  • cloud (40)
  • аутентификация (38)
  • SIEM (37)
  • повышение осведомленности (37)
  • риски (35)
  • лицензирование (34)
  • антивирус (32)
  • SDLC (31)
  • DLP (30)
  • CISO (29)
  • PCI DSS (28)
  • архитектура (25)
  • кибервойна (25)
  • международная ИБ (25)
  • аутсорсинг (24)
  • мобильный офис (23)
  • хакеры (23)
  • BYOD (22)
  • кибербезопасность (22)
  • APT (21)
  • ISO 27001 (19)
  • киберпреступность (18)
  • электронные платежи (18)
  • NIST (17)
  • Web (17)
  • США (17)
  • IPS (16)
  • видео (16)
  • кризис (16)
  • маркетинг (16)
  • CERT (15)
  • ДБО (15)
  • история (14)
  • классификация (14)
  • аудит (13)
  • виртуализация (13)
  • атрибуция (12)
  • госорганы (12)
  • стартап (12)
  • ЭЦП (11)
  • биометрия (11)
  • внутренние угрозы (11)
  • книги (11)
  • open source (10)
  • Интернет (10)
  • кредитные карты (10)
  • троян (10)
  • IoT (9)
  • Social Media (9)
  • культура ИБ (9)
  • спам (9)
  • уязвимости (9)
  • NBAD (8)
  • Usability (8)
  • ВТО (8)
  • МинОбороны (8)
  • аналогии (8)
  • статьи (8)
  • терминология (8)
  • AI (7)
  • Совет Безопасности (7)
  • опыт (7)
  • foresight (6)
  • ООН (6)
  • СУБД (6)
  • блокчейн (6)
  • непрерывность бизнеса (6)
  • поибешечки (6)
  • ОДКБ (5)
  • ФАИТ (5)
  • страхование (5)
  • таможенный союз (5)
  • этика (5)
  • M2M (4)
  • МВД (4)
  • Олимпиада (4)
  • СНГ (4)
  • СОРМ (4)
  • кадры (4)
  • мошенничество (4)
  • перлюстрация (4)
  • политика ИБ (4)
  • русский язык (4)
  • сканеры безопасности (4)
  • NGFW (3)
  • UTM (3)
  • VoIP (3)
  • Wi-Fi (3)
  • Интернет-маньяки (3)
  • женщины (3)
  • кибертерроризм (3)
  • мобильные платежи (3)
  • служебная тайна (3)
  • тендер (3)
  • CIP (2)
  • ISACA (2)
  • RF >

22.07.2013

Финансовая эффективность программ Bug Bounty для разработчиков

О программах Bug Bounty слышали многие. Это программа финансового вознаграждения, получаемого независимыми исследователями, находящими уязвимости в программном обеспечении того или иного производителя. Такие программы есть у многих компаний — Facebook, Microsoft, Google, Avast, PayPal, Mozilla, Qiwi, Yandex. И это только верхушка айсберга — наиболее полный список приведен на сайте Bugcrowd.

Часто возникает вопрос, в чем смысл запуска такой программы? Зачем платить кому-то деньги, если можно нанять в QA-департамент грамотных исследователей, которые за зарплату будут ежедневно искать дыры и это никогда не станет достоянием общественности? Так-то оно так, но с финансовой точки зрения оказалось, что программы Bug Bounty имеют вполне себе измеримую пользу в денежном выражении. Например, Google и Mozilla затратили за 3 года действия своих программ около 400 тысяч долларов, что меньше, чем инвестиции в специалистов, которые за эти же три года смогли бы найти такое же количество уязвимостей.

Разумеется речь идет о достаточно высокооплачиваемых специалистам, годовой доход которых может достигать 80-100 тысяч долларов. Уже 2 штатных специалиста, занятых поиском уязвимостей, обойдутся компании-разработчику дороже, чем выплата по программе Bug Bounty. А ведь еще стоит учитывать и различные отчисления, которые могут увеличить «стоимость» специалиста в 2-3 раза по сравнению с «чистой» зарплатой.

Значит ли это, что работать исследователем в компаниях, производителях ПО, невыгодно и лучше уйти на вольные хлеба, занимаясь самостоятельными исследованиями. Увы, нет. Согласно последнему исследованию «An Empirical Study of Vulnerability Reward Programs», наиболее удачливый фрилансер смог «заработать» у Google немногим больше 105 тысяч долларов, а лидер у Mozilla — около 140 тысяч долларов в год (до вычета налогов). И это верхушка списка. На самом деле средний заработок исследователя-фрилансера гораздо ниже. Большинство внешних исследователей Mozilla получили от 3-х до 6-ти тысяч долларов, а у Google и того меньше — от 500 до 1000 долларов.

Что в итоге? Для компании-разработчика — создание Bug Bounty является выгодной затеей. За меньшие деньги она получает больший результат. А вот для внешних исследователей делать ставку только на такой способ зарабатывания денег не стоит — это скорее подработка или хобби, чем способ заработать себе на хлеб с маслом.

5 коммент.:

Для сравнения было бы интересно увидеть суммы заработка исследователей при продаже найденных уязвимостей на «черном» рынке. До вычета налогов :).

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

Вау-вау, палехчи командир! Баг-Баунти это развлечение не для профессионалов (с точки зрения профита). Ни одна баг-баунти не заменит internal security team. Во-первых качество работы: так называемые вайт-хаты, находят действительно что-то уникальное и сложное в единичных редких случаях. В основном они выполняют задачу «покрытие кода» по масштабному скопу на предмет простых и типовых проблем. И, наверное, сравнивать баг-баунти программы по конкретному продукту и по веб-скоупу не совсем корректно. Заведите себе хоть 10 баг-баунти программ, но качество кода вы не улучшите. «Нахождение багов» != «процесс безопасной разработки». Поэтому с финансовой точки зрения баг-баунти ничего не заменяет, а лишь дополняет. А потом, разбор сотни другой треш -отчетов о «very high critical security vulnerability CVSS 4.5 XSS» так же требует средств. Баг-баунти это для тех, кто понимает что и для чего делает, у кого есть секурити-команда и внутренние ресурсы, не ТОЛЬКО финансовые. Если человек говорит, что баг-баунти заменит внутренних спецов, то он вообще проф. непригоден и не понимает о чем говорит. А еще не плохо бы знать, что в баг-баунти развлекаются спецы, тока ради ЧСВ, а не ради денег. Масса же хантеров — скрипт-киддию. То есть те, кто ожидают гору уникальных убер-отчетов с офигенными и хитрыми векторами, то таких будет ОЧЕНЬ не много. А вот разбирать 100 дубликатов по self-xss, это вот вам. Так что выгода, лишь в покрытии кода, ПР, мы вот например не деньгами а телефонами раздаем, так что еще и реклама 8) Ну и иногда действительно находят что-то интересное. Но со всем этим должен кто-то потом работать. тут то и загвоздка, ведь баг-хантер только сказал что «у вас все плохо». А насколько плохо, в чем суть проблемы, какие риски, форензика,а как фиксить это пока девелопер увел тикет в следующий релиз, причины. действия. На кого эти вопросы вешать, если есть только девелоперы, сисадмины и менеджер проекта ну и самый крутой и находчивый убер-CISO, и ессно в IT Security каждый из них шарит весьма посредственно (в среднем, самородки и таланты исключаем, так как не системно).

Охотничья лицензия на баги

С сегодняшнего дня мы с помощью платформы HackerOne запускаем программу Kaspersky Lab Bug Bounty, которая позволит внешним экспертам поискать баги в продуктах «Лаборатории Касперского» и получить награду за найденные уязвимости. Мы уже достаточно давно думали о подобном шаге и в 2015 году провели закрытую программу Bug Bounty. По ее результатам было решено сделать программу публичной и дать возможность всем внешним ресерчерам поучаствовать в ней.

Охотничья лицензия на баги #KLBH

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

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

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

Тем более что у нас есть несомненное преимущество перед большинством других разработчиков программного обеспечения. Защитные решения постоянно обновляются. И я говорю не только об обновлении баз — в продуктах «Лаборатории Касперского» уже несколько лет работает метод мгновенной доставки обновлений до конечного пользователя. Это позволяет моментально установить обновленные модули на большинство продуктов и тем самым оперативно закрыть уязвимости, если они будут найдены. Благодаря этой системе (хотя на самом деле благодаря слаженной работе команды разработчиков, исследователей и этой системы) в прошлом году нам удалось закрыть несколько серьезных ошибок за 24 часа.

Программы, подобные Kaspersky Lab Bug Bounty, — это еще один уровень надежности при разработке #KLBH

Наша программа Kaspersky Lab Bug Bounty официально запускается 2 августа этого года совместно с HackerOne — специализированной платформой для поиска уязвимостей. Продлится она до февраля 2020 года.

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

Bug Bounty: Узнайте что такое этичный хакинг и как на нём заработать

Как работает Bug Bounty программа. Кто такой белый хакер?

Чему вы научитесь?

  • Как обнаруживать баги
  • Как стать “white hat” (белым) хакером
  • Как заработать посещая сайты

Содержание

Раздел 1: Введение
Раздел 2: Знакомство с Burp suite
Раздел 3: Сбор информации
Раздел 4: Использование nmap для сбора информации
Раздел 5: Знакомство с Bug bounty
Раздел 6: Тестирование сессий
Раздел 7: Тестирование аутентификации
Раздел 8: Тестирование клиентской стороны
Раздел 9: Тестирование на проверку ввода
Раздел 10: Раздел 10: Уязвимости, связанные с загрузкой файлов
Раздел 11: Сломанная аутентификация
Раздел 12: Непроверенные переадресации

Описание

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

Сообщая об ошибках — можно заработать!

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

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

Такие известные компании как Facebook или Google тратят баснословные суммы на Bug Bounty программы, поэтому при должном подходе, у вас есть возможность неплохо на этом заработать.

Например, Google платит минимум 100 долларов за один отчёт об ошибке. Тогда как Facebook в этом вопросе полагается на множество факторов, таких как простота использования, качество отчёта и возможное влияние ошибки на безопасность. Однако, если Facebook платит награду за так называемые баунти, то это минимум 500 долларов (стоит отметить, что найденные ошибки с очень низким уровнем риска не квалифицируются в качестве баунти).

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

Кто такой белый хакер и как им стать

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

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

Поэтому, это не просто хобби, но ещё и способ заработка, а также возможность найти неплохую работу.

Всё для новичков

Будучи новичком в этой сфере, вы откроете для себя много нового и интересного в мире высоких технологий. Поэтому, если вы знаете основы HTML/JS, Burp Suite и имеете представление о таких технологиях как HTTP, HTTPS и т.д., то наш курс точно будет для вас интересен.

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

Узнайте ещё больше про 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?

Нарушаете во всех случаях, если это явно не разрешено вам владельцем сайта.
Т.е если у вас есть разрешение от владельца — никакого нарушения нет, у вас правомерный доступ.
Если разрешения нет — доступ неправомерный, статья 272 УК со всеми вытекающими.

Разрешение может быть опубликовано в любой форме. Хотя если возникнут вопросы, и придется доказывать свою правоту, желательно иметь разрешение в письменной форме.

Мастер Йода рекомендует:  Не вставляйте в консоль скопированный из Интернета код!
Добавить комментарий