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

Валерий Шевченко (krevetk0), независимый исследователь, один из ведущих багхантеров Германии и автор блога «Поросенок Петр», рассказал порталу Cyber Media о специфике оценки уязвимостей на разных багбаунти-платформах, опыте взаимодействия с триажерами и существующих стандартах в этой сфере.

Cyber Media: Насколько могут отличаться подходы к оценке репортов в рамках одной платформы?

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

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

Cyber Media: Насколько часто оценка критичности, найденного бага у исследователя и триажера, расходятся? По каким причинам это случается чаще всего?

Валерий Шевченко: Стоит разделять понятие «триажер».

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

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

И вот здесь начинается неприятность. Триажер платформы просто проверяет валидность истории. Триажер программы зачастую полагается на «экспертность» триажера платформы и предпочитает принять репорт по тому уровню критичности, который выставил триажер платформы. Ну и подумайте сами – может ли триажер платформы, не работая в компании и не разбираясь в бизнес-рисках, правильно оценить критичность репорта?! Конечно, нет.

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

Cyber Media: Есть ли какие-то единые стандарты или практики, на которые исследователь может сослаться в случае несогласия с триажером?

Валерий Шевченко: Я в своем канале стараюсь делиться с читателями такими полезными знаниями. И вот одним из «оберегов» для исследователей теперь может стать документ со стандартами платформы H1.

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

Один из моих «любимых» моментов, когда приносишь репорт с доступом к PII, а его определяли как High, потому что CVSS считает такой репорт без влияния на integrity. Но при этом с точки зрения бизнеса зачастую такое событие — это Critical. Теперь же в стандартах описано что если репорт определяется как Mass PII утечка – вот тогда его нужно считать Critical. Ну и в стандартах описано много других интересных моментов.

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

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

Cyber Media: Если говорить о составлении репорта, на что стоит обратить внимание и что указать, чтобы минимизировать вероятность конфликта во взглядах между багхантером и триажером?

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

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

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

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

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

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

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

Однажды мне удалось поработать с классным менеджером программы. И его философия была простой: «если мне достаточно бюджета в security на bug bounty, то я предпочту переплатить исследователю осознанно, чтобы исследователь вернулся ко мне снова, с новым отчетом».

В таком подходе буквально покупается лояльность исследователей. Но при этом исследователь действительно будет сфокусирован в одной программе и не будет распыляться на другие. Неоспоримый факт, что программа имела всегда репорты от самых крутых исследователей платформы. И такого добиваются далеко не все программы.

Cyber Media: Стоит ли спорить из-за критичности отчета и делать meditation request?

Валерий Шевченко: Я не помню случаев, где спор с программой заканчивался каким-то положительным результатом. И почти никогда не работает там, где кастомер платит ежегодный доступ на платформу и резервирует на счету платформы bounty pool.

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

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

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

Если же история из области явного нарушения полиси собственной программы, то я подниму meditation request и предложу платформе проанализировать историю. Ну а дальше я постараюсь добиться public disclosure, чтобы другие исследователи не наступили на мои грабли.

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

Есть еще багбаунти-платформы, где кастомер не резервирует bounty pool на платформе, а просто дает «дерзкое обещание» что заплатит заявленное вознаграждение за определенные виды уязвимостей. В итоге, когда доходит до уязвимостей – такие ребята начинают включать дурачка. Знаю даже пару примеров, как мои знакомые не увидели обещанного вознаграждения от компании. Но увидели, как из списка программ исключили такую компанию на платформе.