Привет! Меня зовут Уваров Петр, я руководитель команды VK Bug Bounty. Статья интересная, и у участника незнакомого с багбаунти может вызвать ряд вопросов. Давайте я проясню некоторые такие вопросы со стороны вендора:
От вендора без долгих раздумий с его стороны получил статус "Информативный". Проанализировал отчет и уяснил свою первую ошибку: уязвимость была описана мной "абстрактно" и действительно выглядела в отчете просто как "информация о чем-то.."
Любой отчет, который нам присылают, мы оцениваем со всех сторон, чтобы оценить общую угрозу и риски. Весь импакт был изначально оценен в первом отчете и в связи с тем, что угрозы для ИБ сервиса и пользователей не было, он был оценен как информативный. И когда точно такой же отчет, но уже другими словами, присылают второй раз, абсолютно логично закрыть его дубликатом. Также, как уже было сказано в отчете, мы не вправе мешать вам обратится в Роскомнадзор за пояснением.
Следующий мой отчет содержал комплекс из трех разных (более серьезных) уязвимостей. Рассматривался вендором уже дольше (неделю) и... "Дубль".
Тут все более прозаичнее. Так как автор, по его словам, "новичок", я объясню, что такое статус дубликат: Дубликат ставится тогда, когда проблема указанная в репорте, уже подсвечена либо другим исследователем, либо найдена в результате внутренних работ.
По одной уязвимости: ссылка на отчет другого багхантера, раскрывающго иной вектор с совершенно другим CWE. По второй - скриншот внутреннего трекера с сомнительным заголовком, больше напоминающим "узелок на память", без каких-либо деталей. Причем, под указанный заголовок можно было бы подвести 5-6 различных "похожих" уязвимостей.
Чтобы дать максимальное количество информации и быть прозрачными для исследователя, мы одновременно сделали линк на оригинальный репорт багхантера, а также приложили скриншот с внутреннего таск трекера для второй уязвимости в отчете. Т.к. в силу NDA мы не можем разглашать некоторые вещи, часть информации была скрыта. После обращения автора к платформе за медиацией, представителям платформы мы показали намаскированную задачу и описание, которое было в скриншоте, чтобы они убедились в валидности представленных нами доказательств. Это является обычным поведением при спорных ситуациях.
По третьей уязвимости - просто "дубль"... Без объяснений.. Без аргументов.. (очевидно потому, что две других уязвимости по мнению вендора оказались "дублями").
Тут автор или лукавит, или недоговаривает, т.к. информация была предоставлена в том же ответе и общий поинт ее был не в том, что это дубликат, а в том это валидное поведение. Описанное поведение было также продемонстрировано при медиации данного репорта.
Я бы хотел особенно коснуться вот этого:
К моему изумлению арбитр и в этом случае по итогу оказался "согласен с вендором", и несмотря на то, что:
я дал объективные и технически подтверждающие разность векторов и CWE в сравнении с отчетом другого багхантера, а контраргументы триажера оказались несостоятельными и технически бессильными.
У автора статьи и автора оригинальной уязвимости, буквально одинаковые адреса и параметры в отчетах. То, что описание отчетов отличается - не значит, что это разные уязвимости.
Подаю следующий отчет (по критичности - наиболее высокий). "Отклонён". Аргумент вендора: "PoC не соответствует правилам".
Позвольте я представлю скрин, который был дан в отчете:
Дополню от себя: Уязвимость про которую идет речь, может быть реализованна в двух случаях - или при эксплуатации MitM или если у злоумышленника есть доступ к компьютеру жертвы. В обоих случаях, такое в bug bounty не принимается по понятным для всех причинам - перехват трафика у пользователя или в корпоративных сетях не является ответственностью компании.
В недоумении снова заглядываю в "правила" и.. Ха-ха-хах.. Вендор их "пофиксил" (ну хоть какой-то "баг" я помог исправить и то хорошо), причем так, что пункты стали "безоговорочными".. На указание данного факта ответ вендора: "наша позиция неизменна" (та штош такое-то!), триаж данную ситуацию с изменением правил "на лету" никак не прокомментировал.
И снова моя цитата и скрин:
Если автор считает, что в нашем комментарии не указана позиция про изменение правил, то он может обратится к сообществу багхантеров, которое подтвердит, что все отчеты рассматриваются в соответствии с их временем сдачи, даже если правила были изменены.
Позиция автора понятны - он недоволен тем, как прошел его первый опыт в багбаунти, случились дубликаты. Но надо отметить, что в конкретно в этом случае и сообщество и платформа и вендор соглашаются с тем, что оснований для выплаты нет. Мы всегда рады дальнейшему вниманию к нашим сервисам и конструктивной критике — именно так можно становятся все лучше и лучше.
Я сравнивал именно максимальную стоимость 23 и 24 года. О том, что было раньше на hackerone не стоит говорить - цены были больше. Мы, со своей стороны, прикладываем усилия, чтобы повышать не только максимально возможные выплаты, но и в принципе стоимости в программах. Вот к примеру, недавно увеличили стоимость вознаграждений во всех наших программах. Если сложить это с накопительным бонусом от Bounty pass, то получается прям вкусно. А если говорить про принцип вознаграждения, то тут я согласен - багбаунти стоит рассматривать именно как инструмент для возможности отслеживания проблем во внутренних процессах ИБ. И по факту не важно какого рода проблема: связана она с внедрением CSP или с обучением персонала основам культуры ИБ - платить надо в зависимости от угрозы и риска которую несет уязвимость
Привет! Меня зовут Уваров Петр, я руководитель команды VK Bug Bounty.
Статья интересная, и у участника незнакомого с багбаунти может вызвать ряд вопросов. Давайте я проясню некоторые такие вопросы со стороны вендора:
Любой отчет, который нам присылают, мы оцениваем со всех сторон, чтобы оценить общую угрозу и риски. Весь импакт был изначально оценен в первом отчете и в связи с тем, что угрозы для ИБ сервиса и пользователей не было, он был оценен как информативный. И когда точно такой же отчет, но уже другими словами, присылают второй раз, абсолютно логично закрыть его дубликатом.
Также, как уже было сказано в отчете, мы не вправе мешать вам обратится в Роскомнадзор за пояснением.
Тут все более прозаичнее. Так как автор, по его словам, "новичок", я объясню, что такое статус дубликат: Дубликат ставится тогда, когда проблема указанная в репорте, уже подсвечена либо другим исследователем, либо найдена в результате внутренних работ.
Чтобы дать максимальное количество информации и быть прозрачными для исследователя, мы одновременно сделали линк на оригинальный репорт багхантера, а также приложили скриншот с внутреннего таск трекера для второй уязвимости в отчете. Т.к. в силу NDA мы не можем разглашать некоторые вещи, часть информации была скрыта. После обращения автора к платформе за медиацией, представителям платформы мы показали намаскированную задачу и описание, которое было в скриншоте, чтобы они убедились в валидности представленных нами доказательств. Это является обычным поведением при спорных ситуациях.
Тут автор или лукавит, или недоговаривает, т.к. информация была предоставлена в том же ответе и общий поинт ее был не в том, что это дубликат, а в том это валидное поведение. Описанное поведение было также продемонстрировано при медиации данного репорта.
Я бы хотел особенно коснуться вот этого:
У автора статьи и автора оригинальной уязвимости, буквально одинаковые адреса и параметры в отчетах. То, что описание отчетов отличается - не значит, что это разные уязвимости.
Позвольте я представлю скрин, который был дан в отчете:
Дополню от себя: Уязвимость про которую идет речь, может быть реализованна в двух случаях - или при эксплуатации MitM или если у злоумышленника есть доступ к компьютеру жертвы. В обоих случаях, такое в bug bounty не принимается по понятным для всех причинам - перехват трафика у пользователя или в корпоративных сетях не является ответственностью компании.
И снова моя цитата и скрин:
Если автор считает, что в нашем комментарии не указана позиция про изменение правил, то он может обратится к сообществу багхантеров, которое подтвердит, что все отчеты рассматриваются в соответствии с их временем сдачи, даже если правила были изменены.
Позиция автора понятны - он недоволен тем, как прошел его первый опыт в багбаунти, случились дубликаты. Но надо отметить, что в конкретно в этом случае и сообщество и платформа и вендор соглашаются с тем, что оснований для выплаты нет. Мы всегда рады дальнейшему вниманию к нашим сервисам и конструктивной критике — именно так можно становятся все лучше и лучше.
Я сравнивал именно максимальную стоимость 23 и 24 года. О том, что было раньше на hackerone не стоит говорить - цены были больше. Мы, со своей стороны, прикладываем усилия, чтобы повышать не только максимально возможные выплаты, но и в принципе стоимости в программах. Вот к примеру, недавно увеличили стоимость вознаграждений во всех наших программах. Если сложить это с накопительным бонусом от Bounty pass, то получается прям вкусно.
А если говорить про принцип вознаграждения, то тут я согласен - багбаунти стоит рассматривать именно как инструмент для возможности отслеживания проблем во внутренних процессах ИБ. И по факту не важно какого рода проблема: связана она с внедрением CSP или с обучением персонала основам культуры ИБ - платить надо в зависимости от угрозы и риска которую несет уязвимость