Pull to refresh

Comments 7

До сих пор не все наши сервисы и продукты выставлены на Bug Bounty платформу. Это сделано сознательно, так как часть сервисов, например, создана на основе opеn source решений: их развитием и поддержкой занимаются сторонние команды, поэтому мы считаем, что нет смысла их выставлять в рамках нашей Bug Bounty платформы, так как наша команда следит только за актуальностью данных сервисов.

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

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

У подобной методики оценки есть, как минимум, следующие недостатки:
  1. Эта система определения критичности непрозрачна для ресёрчера и выглядит как явное одобрение с вашей стороны пост-эксплуатации найденной уязвимости. Например, если ресёрчер найдёт у вас SQLi, то он будет пытаться её раскрутить до RCE в надежде продемонстрировать максимально возможную критичность. В процессе этого он может случайно получить доступ к данным ваших пользователей, защита которых, как мне кажется, должна быть на первом месте;
  2. В перспективе, когда количество репортов у вас будет не 72 в год, а 72 в неделю, вы столкнётесь с тем, что вы будете тратить непростительно много времени на определение критичности по этой методике. И как вы указали, субъективность будет только усугублять это – если критичность репорта и размер вознаграждения у вас определяется командой, а не одним человеком, то они (члены команды) будут очень часто и много спорить о критичности, а следовательно, и о размере вознаграждения;


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

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

Конечно мы понимаем, что в используемых нами opеn source решениях могут быть уже сейчас или находиться в дальнейшем проблемы безопасности. Мы стараемся решать эту проблему без использования программы Bug Bounty. Например, мониторить issue у проектов, исследовать их своими силами и т. д.
У нас нет цели сэкономить деньги, но в условиях ограниченности ресурсов нам важно эффективно распределить внимание багхантеров между нашими различными сервисами и получить информацию о проблемах безопасности.

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

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

В перспективе, когда количество репортов у вас будет не 72 в год, а 72 в неделю, вы столкнётесь с тем, что вы будете тратить непростительно много времени на определение критичности по этой методике. И как вы указали, субъективность будет только усугублять это – если критичность репорта и размер вознаграждения у вас определяется командой, а не одним человеком, то они (члены команды) будут очень часто и много спорить о критичности, а следовательно, и о размере вознаграждения;

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

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

Мы с Вами полностью согласны и видим в построении Bug Bounty процессов только положительные моменты. Спасибо!
Мы стараемся решать эту проблему без использования программы Bug Bounty. Например, мониторить issue у проектов, исследовать их своими силами и т. д.

Я забыл отметить момент с 0-day уязвимостями. Для них точно не может быть ни issue, ни security advisory, т.е. даже вендор может не знать о том, что проблема у него есть. Навскидку два примера, когда проблема была обнаружена только потому, что о ней было сообщено в стороннюю программу – раз и два.
Если мы Вас правильно поняли, то Вы опасаетесь, что в процессе исследования ресерчер сможет получить данные клиента. В рамках Bug Bounty программы это не является проблемой, так как между нами, Bug Bounty платформой и ресерчерами заключено соглашение о неразглашении данных (NDA).

И не только этого. Можно этот список продолжить, например, падением сервиса, которое произойдёт в процессе исследования ресёрчером и закончить банальным rm -rf /. Но это ни в какое сравнение не идёт с тем, что данные пользователей будут доступны третьим лицам. Я не думаю, что пользователи вашего сервиса будут рады тому, что какой-то ресёрчер из Уганды сдампил у вас базу с их данными, даже при условии, что ресёрчер принял условия оферты.
Одна из целей программы, как мне кажется, повышение уровня защищённости пользователей, и не стоит правилами самой же программы эту цель топтать в грязь.
Также стоит отметить, что при реальном инциденте вы не сможете отличить ресёрчера от нересёрчера, или нересёрчер, даже если вы его заметите, смело сошлётся на ваши правила программы и будет настаивать на том, что он просто пытался раскрутить уязвимость до максимального импакта. Скорее всего вы не пойдёте в суд с этим, а если и пойдёте, то, скорее всего, проиграете его.
Я забыл отметить момент с 0-day уязвимостями. Для них точно не может быть ни issue, ни security advisory, т.е. даже вендор может не знать о том, что проблема у него есть. Навскидку два примера, когда проблема была обнаружена только потому, что о ней было сообщено в стороннюю программу – раз и два.

Спасибо, это сильные примеры и отличная практика! Нашей Bug Bounty программе всего год, и мы пока успеваем концентрироваться только на сервисах собственной разработки. Уверены, всё впереди! Wait and see :)

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

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

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

К сожалению, так называемые не-ресерчеры уже пытались атаковать нас и ссылались на гипотетическую программу Bug Bounty. Нам кажется, что нельзя быть на 100% застрахованным и защищенным от таких ситуаций в любом случае. Этому миру нужно больше белых и этичных багхантеров!
Спасибо, очень полезная информация.
Жаль не нашел что-то подобное раньше, когда делали bounty программу в blockchain проекте.
Можно было сэкономить много времени.
Нашел дыру на вашем сайте (розыгрыш призов на черную пятницу), опубликовал на openbugbounty, но они так долго верифицировали ее (зачем то в ручную), что уже все закончилось, страница стала недоступна и они реджектнули репорт об уязвимости :))
Здравствуйте!

Проверили репорты. Ваш не нашли, к сожалению! Очень жаль, что ребята так долго реагировали.

Будем благодарны за новые репорты!
Sign up to leave a comment.