
Комментарии 21
По существу:
1. О первом отчете:
Весь импакт был изначально оценен в первом отчете и в связи с тем, что угрозы для ИБ сервиса и пользователей не было
Здесь, касательно угрозы - я дал вам возможные сценарии. И не согласен с вашем мнением исходя из значимости MAX и в принципе отсутствия данных фич в других мессенджерах в том исполнении, как она реализована у вас (и что это за собой может повлечь). Но, вопрос спорный, поэтому его приостановил, до ответа госоргана с разъяснениями (мне почему-то кажется, что ответ с их стороны будет положительный).
По данному отчету - вполне нормальная пауза в споре.
_______________________
2. О втором отчете (который "дубль весь"):
У автора статьи и автора оригинальной уязвимости, буквально одинаковые адреса и параметры в отчетах. То, что описание отчетов отличается - не значит, что это разные уязвимости
Это ложь. В моем отчете НЕТ параметров, а другой багхантер НЕ демонстрировал адреса
Чтобы дать максимальное количество информации и быть прозрачными для исследователя, мы одновременно сделали линк на оригинальный репорт багхантера
Спор между мной и арбитражем остановился на полном молчании арбитража в ответ на мое исследование, подтверждающее разность векторов. В письме я это описал подробно с цитированием технически несостоятельных контраргументов арбитра и могу сказать уверенно: если бы другой исследователь знал о моём векторе - он обязательно описал бы его, потому что это максимально критичный сценарий. Но он этого не сделал - значит, вектор был неизвестен.
И я не "повторил" отчёт другого багхантера, а расширил вектор до максимально опасного сценария.
Это не дубликат, а независимая, более критичная уязвимость, которая делает вектор и импакт другого багхантера - "второстепенным".
Вы проигнорировали техническую разницу, оставив мои аргументы и прямые вопросы без ответа.
И если вы не можете объяснить, почему разные CWE, разные векторы, разный импакт - это "одна и та же уязвимость" - ваше решение теряет всякую легитимность.
>> По третьей уязвимости - просто "дубль"... Без объяснений.. Без аргументов.. (очевидно потому, что две других уязвимости по мнению вендора оказались "дублями").
Тут автор или лукавит, или недоговаривает, т.к. информация была предоставлена в том же ответе и общий поинт ее был не в том, что это дубликат, а в том это валидное поведение.
А на последующие вопросы-то ("считаете ли это уязвимостью", "безусловно безопасным") - так и не ответили (ни вы, ни арбитраж)? И аргументы также проигнорировали..
Также вы пишете:
Дубликат ставится тогда, когда проблема указанная в репорте, уже подсвечена либо другим исследователем, либо найдена в результате внутренних работ.
Если вы считаете, что скриншот с заголовком, под который можно подвести что угодно с полным отсутствием тела как такового (то есть - (!)ноль информации) - может быть принят мной как аргумент "дубля", то вот цитата из Положения о программах:
3.3. Отчету, содержащему данные о ранее известной Клиенту Уязвимости, может быть присвоен статус «Дубликат», если:
Отчет представляет собой описание Уязвимости, которая ранее была известна .. что было обозначено явным образом ..
И "явного образа" я не увидел ни в заголовке, ни в отмашке арбитра "у нас нет причин не доверять вендору", а его полемика "мы можем запросить подробности у вендора" (при уже де-факто принятом решении) - так и осталась полемикой, из чего могу сделать один вывод - пруфа просто нет.
____________________________
3. О третьем отчете:
Уязвимость про которую идет речь, может быть реализованна в двух случаях - или при эксплуатации MitM или если у злоумышленника есть доступ к компьютеру жертвы
Я и не спорил про MitM, а продемонстрировал другой (рабочий) PoC без MitM и без доступа к компьютеру жертвы арбитру - ответа так и не получил. Ни в арбитраже, ни здесь.
_______________________
4. Касательно изменения правил постфактум:
Весьма любопытно
Вы пишете:
..>> триаж << данную ситуацию с изменением правил "на лету" никак не прокомментировал. ..
Здесь вы отвечаете на мой черновик, существовавший еще до публикации статьи. Понимаю, что с вами им поделилась команда Standoff365 на этапе его "модерации", но в той самой финальной версии статьи, которую вы видите сейчас - до "выхода в эфир" я исправил ошибочные термины и в данном контексте значится "арбитраж" (можете проверить, перечитав статью, де-факто после ее публикации никаких правок я не вносил)
Ирония в том, что именно моя опечатка ("триаж" вместо "арбитраж") - доказательство того, что вы читали мой черновик до публикации, (а не финальную статью), а значит знали о моих аргументах заранее и всё равно выбрали путь отрицания.
Но это мелочи.. Пусть просто как ремарка в спойлере висит. ;)
Вы пишете:
Если автор считает, что в нашем комментарии не указана позиция про изменение правил..
В статье я писал:
>> "..арбитр никак не прокомментировал сам факт изменения правил постфактум, за исключением: "ваш отчет рассматривается по предыдущим".
Я подчеркнул сам факт изменения правил постфактум с "разделением борща пополам" и то, что ваши совместные с арбитражем последующие действия и полемика - исключают предыдущие правила (и в целом упоминание всуе терминов, касающихся предыдущей версии).
"Как есть", то бишь..
Но, как я и сказал - это не суть и не очень важно в контексте того, что я подал вам PoC без MitM и в принципе без разницы сейчас - по старым или по новым правилам вы его рассматриваете (вернее - не рассматриваете, т.к. ответа на PoC без MITM я так и не получил)
Ну как-то оценивать ваш кейс по представленным деталям невозможно, так как ваше слово против их. НО
я задался дополнительной целью — добиться системных изменений: ввести прозрачные гарантии для исследователей, закрепить их право на обращение в регуляторы при нарушении закона, и сделать bug bounty в России не инструментом сокрытия рисков, а реальным щитом национальной цифровой безопасности.
https://www.kommersant.ru/doc/8141928 партия о вас подумала, и скоро все белые хакеры должны будут быть зарегистрированы в ФСБ.
Как выше уже отметили - не хватает технических данных абсолютно. Опишите хоть импакт. В особенности интересно про критического уровня багу. SQL-inj/RCE/IDOR/ ещё что серверное, намекните хоть.
Привет! Меня зовут Уваров Петр, я руководитель команды VK Bug Bounty.
Статья интересная, и у участника незнакомого с багбаунти может вызвать ряд вопросов. Давайте я проясню некоторые такие вопросы со стороны вендора:
От вендора без долгих раздумий с его стороны получил статус "Информативный".
Проанализировал отчет и уяснил свою первую ошибку: уязвимость была описана мной "абстрактно" и действительно выглядела в отчете просто как "информация о чем-то.."
Любой отчет, который нам присылают, мы оцениваем со всех сторон, чтобы оценить общую угрозу и риски. Весь импакт был изначально оценен в первом отчете и в связи с тем, что угрозы для ИБ сервиса и пользователей не было, он был оценен как информативный. И когда точно такой же отчет, но уже другими словами, присылают второй раз, абсолютно логично закрыть его дубликатом.
Также, как уже было сказано в отчете, мы не вправе мешать вам обратится в Роскомнадзор за пояснением.
Следующий мой отчет содержал комплекс из трех разных (более серьезных) уязвимостей. Рассматривался вендором уже дольше (неделю) и...
"Дубль".
Тут все более прозаичнее. Так как автор, по его словам, "новичок", я объясню, что такое статус дубликат: Дубликат ставится тогда, когда проблема указанная в репорте, уже подсвечена либо другим исследователем, либо найдена в результате внутренних работ.
По одной уязвимости: ссылка на отчет другого багхантера, раскрывающго иной вектор с совершенно другим CWE.
По второй - скриншот внутреннего трекера с сомнительным заголовком, больше напоминающим "узелок на память", без каких-либо деталей. Причем, под указанный заголовок можно было бы подвести 5-6 различных "похожих" уязвимостей.
Чтобы дать максимальное количество информации и быть прозрачными для исследователя, мы одновременно сделали линк на оригинальный репорт багхантера, а также приложили скриншот с внутреннего таск трекера для второй уязвимости в отчете. Т.к. в силу NDA мы не можем разглашать некоторые вещи, часть информации была скрыта. После обращения автора к платформе за медиацией, представителям платформы мы показали намаскированную задачу и описание, которое было в скриншоте, чтобы они убедились в валидности представленных нами доказательств. Это является обычным поведением при спорных ситуациях.
По третьей уязвимости - просто "дубль"... Без объяснений.. Без аргументов.. (очевидно потому, что две других уязвимости по мнению вендора оказались "дублями").
Тут автор или лукавит, или недоговаривает, т.к. информация была предоставлена в том же ответе и общий поинт ее был не в том, что это дубликат, а в том это валидное поведение. Описанное поведение было также продемонстрировано при медиации данного репорта.
Я бы хотел особенно коснуться вот этого:
К моему изумлению арбитр и в этом случае по итогу оказался "согласен с вендором", и несмотря на то, что:
я дал объективные и технически подтверждающие разность векторов и CWE в сравнении с отчетом другого багхантера, а контраргументы триажера оказались несостоятельными и технически бессильными.
У автора статьи и автора оригинальной уязвимости, буквально одинаковые адреса и параметры в отчетах. То, что описание отчетов отличается - не значит, что это разные уязвимости.
Подаю следующий отчет (по критичности - наиболее высокий).
"Отклонён". Аргумент вендора: "PoC не соответствует правилам".
Позвольте я представлю скрин, который был дан в отчете:

Дополню от себя: Уязвимость про которую идет речь, может быть реализованна в двух случаях - или при эксплуатации MitM или если у злоумышленника есть доступ к компьютеру жертвы. В обоих случаях, такое в bug bounty не принимается по понятным для всех причинам - перехват трафика у пользователя или в корпоративных сетях не является ответственностью компании.
В недоумении снова заглядываю в "правила" и.. Ха-ха-хах.. Вендор их "пофиксил" (ну хоть какой-то "баг" я помог исправить и то хорошо), причем так, что пункты стали "безоговорочными"..
На указание данного факта ответ вендора: "наша позиция неизменна" (та штош такое-то!), триаж данную ситуацию с изменением правил "на лету" никак не прокомментировал.
И снова моя цитата и скрин:

Если автор считает, что в нашем комментарии не указана позиция про изменение правил, то он может обратится к сообществу багхантеров, которое подтвердит, что все отчеты рассматриваются в соответствии с их временем сдачи, даже если правила были изменены.
Позиция автора понятны - он недоволен тем, как прошел его первый опыт в багбаунти, случились дубликаты. Но надо отметить, что в конкретно в этом случае и сообщество и платформа и вендор соглашаются с тем, что оснований для выплаты нет. Мы всегда рады дальнейшему вниманию к нашим сервисам и конструктивной критике — именно так можно становятся все лучше и лучше.
Очень хороший отрывочек)
Жаль, что сам не имею права раскрыть его пошире. Ну и ладно..
Может по остальным вопросам ответы найдете и выложите их тут? ;)
Лично мое мнение - вы сейчас в очень уязвимой позиции так как доводы @s3n_q более аргументированы
А ваши доводы сейчас как раз выглядят не аргументированными и по сути завязаны на том что вам не дали ссылки на отчеты других пользователей и не ответили так как вы бы хотели.
Ну то-есть по опыту работы с bug bounty могу сказать что реально большая часть импактов уходит в дубликаты так как самые простые находят достаточно быстро и найти их не сложно.
Насколько знаю, согласно правилам, вы не можете раскрывать: PoC, шаги воспроизведения, скриншоты с чувствительными данными.
Историю триажа (допустим с замыливанием каких-то отдельных частей) так-же можете раскрывать - не думаю что @s3n_q будет сильно против ))
Лично мое мнение - вы сейчас в очень уязвимой позиции так как доводы @s3n_q более аргументированы
Ниже - мои дополнительные контраргументы. Если есть что возразить - буду раз ответить на любые вопросы по существу.
.. завязаны на том что вам не дали ссылки на отчеты других пользователей ..
Ну, это искажение фактов. Я нигде не просил "выдать ссылки на отчеты", или приведите цитату, где Вы это вычитали?
.. большая часть импактов уходит в дубликаты так как самые простые находят достаточно быстро и найти их не сложно. ..
В статье помимо "дубликатов" (без ответов на встречные вопросы) затрагиваются "информативные" (спорные) и "отклоненные" (также - без ответов на встречные вопросы и представленные аргументы). Но в целом с вами согласен, что это имеет место быть, если доказательства дублей легитимные и бесспорные. Иначе это выглядит как "прикрытие газеткой" уязвимостей.
Историю триажа (допустим с замыливанием каких-то отдельных частей) так-же можете раскрывать - не думаю что @s3n_q будет сильно против ))
Спасибо за совет, но воздержусь пожалуй..;)
Ну, это искажение фактов. Я нигде не просил "выдать ссылки на отчеты", или приведите цитату, где Вы это вычитали?
Конечно я очень утрировал, но по своему опыту могу сказать что маловероятно, что команда VK заинтересована в том чтобы вас как-то обманывать, скрывать или неправомерно закрывать отчеты.
У VK интерес к поиску багов намного больше чем ваш интерес в получении вознаграждения и получении признания за вклад.
VK и другие компании прекрасно понимают, что как только создатут ситуацию при которой ваши права будут нарушены - сообщество баг хантеров россии, которое признаем итак не большое, станет еще меньше.
По своему опыту репортов в MAX могу сказать что так-же несколько были помечены как дубликаты, а по одному я получил выплату. Пускай я все еще не согласен с критичностью и размером выплаты, но во время триажа модератор так-же услышал мои доводы и изменил уровень с Medium на High
По существу:
1. О первом отчете:
Весь импакт был изначально оценен в первом отчете и в связи с тем, что угрозы для ИБ сервиса и пользователей не было
Здесь, касательно угрозы - я дал вам возможные сценарии. И не согласен с вашем мнением исходя из значимости MAX и в принципе отсутствия данных фич в других мессенджерах в том исполнении, как она реализована у вас (и что это за собой может повлечь). Но, вопрос спорный, поэтому его приостановил, до ответа госоргана с разъяснениями (мне почему-то кажется, что ответ с их стороны будет положительный).
По данному отчету - вполне нормальная пауза в споре.
_______________________
2. О втором отчете (который "дубль весь"):
У автора статьи и автора оригинальной уязвимости, буквально одинаковые адреса и параметры в отчетах. То, что описание отчетов отличается - не значит, что это разные уязвимости
Это ложь. В моем отчете НЕТ параметров, а другой багхантер НЕ демонстрировал адреса
Чтобы дать максимальное количество информации и быть прозрачными для исследователя, мы одновременно сделали линк на оригинальный репорт багхантера
Спор между мной и арбитражем остановился на полном молчании арбитража в ответ на мое исследование, подтверждающее разность векторов. В письме я это описал подробно с цитированием технически несостоятельных контраргументов арбитра и могу сказать уверенно: если бы другой исследователь знал о моём векторе - он обязательно описал бы его, потому что это максимально критичный сценарий. Но он этого не сделал - значит, вектор был неизвестен.
И я не "повторил" отчёт другого багхантера, а расширил вектор до максимально опасного сценария.
Это не дубликат, а независимая, более критичная уязвимость, которая делает вектор и импакт другого багхантера - "второстепенным".
Вы проигнорировали техническую разницу, оставив мои аргументы и прямые вопросы без ответа.
И если вы не можете объяснить, почему разные CWE, разные векторы, разный импакт - это "одна и та же уязвимость" - ваше решение теряет всякую легитимность.
>> По третьей уязвимости - просто "дубль"... Без объяснений.. Без аргументов.. (очевидно потому, что две других уязвимости по мнению вендора оказались "дублями").
Тут автор или лукавит, или недоговаривает, т.к. информация была предоставлена в том же ответе и общий поинт ее был не в том, что это дубликат, а в том это валидное поведение.
А на последующие вопросы-то ("считаете ли это уязвимостью", "безусловно безопасным") - так и не ответили (ни вы, ни арбитраж)? И аргументы также проигнорировали..
Также вы пишете:
Дубликат ставится тогда, когда проблема указанная в репорте, уже подсвечена либо другим исследователем, либо найдена в результате внутренних работ.
Если вы считаете, что скриншот с заголовком, под который можно подвести что угодно с полным отсутствием тела как такового (то есть - (!)ноль информации) - может быть принят мной как аргумент "дубля", то вот цитата из Положения о программах:
3.3. Отчету, содержащему данные о ранее известной Клиенту Уязвимости, может быть присвоен статус «Дубликат», если:
Отчет представляет собой описание Уязвимости, которая ранее была известна .. что было обозначено явным образом ..
И "явного образа" я не увидел ни в заголовке, ни в отмашке арбитра "у нас нет причин не доверять вендору", а его полемика "мы можем запросить подробности у вендора" (при уже де-факто принятом решении) - так и осталась полемикой, из чего могу сделать один вывод - пруфа просто нет.
____________________________
3. О третьем отчете:
Уязвимость про которую идет речь, может быть реализованна в двух случаях - или при эксплуатации MitM или если у злоумышленника есть доступ к компьютеру жертвы
Я и не спорил про MitM, а продемонстрировал другой (рабочий) PoC без MitM и без доступа к компьютеру жертвы арбитру - ответа так и не получил. Ни в арбитраже, ни здесь.
_______________________
4. Касательно изменения правил постфактум:
Весьма любопытно
Вы пишете:
..>> триаж << данную ситуацию с изменением правил "на лету" никак не прокомментировал. ..
Здесь вы отвечаете на мой черновик, существовавший еще до публикации статьи. Понимаю, что с вами им поделилась команда Standoff365 на этапе его "модерации", но в той самой финальной версии статьи, которую вы видите сейчас - до "выхода в эфир" я исправил ошибочные термины и в данном контексте значится "арбитраж" (можете проверить, перечитав статью, де-факто после ее публикации никаких правок я не вносил)
Ирония в том, что именно моя опечатка ("триаж" вместо "арбитраж") - доказательство того, что вы читали мой черновик до публикации, (а не финальную статью), а значит знали о моих аргументах заранее и всё равно выбрали путь отрицания.
Но это мелочи.. Пусть просто как ремарка в спойлере висит. ;)
Вы пишете:
Если автор считает, что в нашем комментарии не указана позиция про изменение правил..
В статье я писал:
>> "..арбитр никак не прокомментировал сам факт изменения правил постфактум, за исключением: "ваш отчет рассматривается по предыдущим".
Я подчеркнул сам факт изменения правил постфактум с "разделением борща пополам" и то, что ваши совместные с арбитражем последующие действия и полемика - исключают предыдущие правила (и в целом упоминание всуе терминов, касающихся предыдущей версии).
"Как есть", то бишь..
Но, как я и сказал - это не суть и не очень важно в контексте того, что я подал вам PoC без MitM и в принципе без разницы сейчас - по старым или по новым правилам вы его рассматриваете (вернее - не рассматриваете, т.к. ответа на PoC без MITM я так и не получил)
Почти всегда после появление нового, подтвержденного PoC который был не учтен в правилах и у которого есть определенная специфика, правила обновляются чтобы новые хантеры не использовали этот PoC - это разумно.
У правил всегда есть ревизия и история изменений и для вашего отчета актуальная ревизия правил соответствует ревизии на момент отправки отчета и это мне подтверждала команда VK.

Команда площадки Standoff Bug Bounty всегда стремится поддерживать открытый диалог с исследователями и компаниями. Хотим отметить, что уже предоставляли все необходимые подтверждения и развернутые обоснования нашей позиции в этом кейсе, что, к сожалению, не находит полного отражения в данной публикации. Тем не менее, мы остаёмся открыты к конструктивному диалогу и готовы дать дополнительные разъяснения в случае необходимости.
Здрасьте команда)
Хороший ответ. Очень жаль, что не получил на свои вопросы.
Или вы ответили (и вендор тоже)?
Странно, не вижу ни на почте ни в отчётах.
Я про те, которые подразумевают ответ "да/нет", а также дополнительное исследование другого CWE, которое опровергает ваши утверждения.
Ответов я пока не получил, кроме "наш диалог завершен" и странное предложение "мира, дружбы, жвачки" в отдельной переписке..
Ответьте же (только в почте, не здесь. Здесь не интересно, ибо я ничего не могу возразить аргументированно по существу, так как не собираюсь в бан раньше времени - я ж по правилам)..
раскрывающего иной вектор с совершенно другим CWE.
Автор, вы неоднократно ссылайтесь в статье на некие CWE. Поясните пожалуйста о чем конкретно идёт речь?
Более, чем озвучил - указать не могу, во избежание раскрытия деталей (даже косвенных). Но и сама статья не предполагает "технический" разбор (о чем указал в прологе) посему употребления с моей стороны будут исключительно "этот CWE", "другой CWE", "идентичный CWE" и т.п.
Не обессудьте.
посему употребления с моей стороны будут исключительно "этот CWE", "другой CWE", "идентичный CWE" и т.п.
Аргументация так сказать, больше в минус, чем в плюс.
статья не предполагает "технический" разбор
Как раз-таки наоборот. Завуалировать можно как угодно. Достаточно написать - "я никогда не находил рце в Максе и вряд ли найду". Этого будет достаточно для понимания критичности, а с юридической стороны вам не стоит опасаться.
Из вашего комментария ещё выше:
Здесь, касательно угрозы - я дал вам возможные сценарии. И не согласен с вашем мнением исходя из значимости MAX и в принципе отсутствия данных фич в других мессенджерах
Из этого косвенно можно предположить, что логаут не убивает куки, позволяя проделать нечто на ГУ, к примеру. Но тогда не срабатывает ваше:
во избежание раскрытия деталей (даже косвенных).
Возможно я заблуждаюсь в своём умозаключении, но вы опубликовали пост в открытом пространстве и вероятно ждали поддержки. А как человек, отправлявший репорты в баг баунти ВК, интересуюсь темой взаимодействия багхантеров и вендоров.
Исходя из моего (пока небольшого) опыта багхантинга и с учётом пристального мониторинга каждого моего слова командой VK и Standoff365 - я пока не могу позволить себе вальяжно и уверенно разбрасываться даже завуалированными частями отчётов, позволяющими выкинуть меня из платформы "за разглашение".
Здесь "разбор действий команды VK и Standoff365". В частности - о полном их молчании в ответ на представленные аргументы и заданные прямые вопросы, где ответ предполагает "да"/"нет".
Хотелось бы заметить, что такая ситуация с багхантингом не только у нас в СНГ. На зарубежных платформах solidity-аудита, типа той же immunefi не раз сталкивался, что на предоставленный PoC для high-баги на сотню или даже $десяток тыс вендор просто удаляет конкурс или меняет условия, а посредники-модеры потом "дико извиняются". Короче даже на децентрализованных насколько это возможно сервисах, с отточеными trustless механизмами возникают подобные казусы. ZKP-подходы к PoC при этом ещё хоть как-то роляют, если вендор хочет увидеть детали найденной баги, будь добр пусть платит в контракт и автоматически получает док-во. Но такого сервиса мало, он всё ещё предсказуем, и по сути чаще всего видится ситуация в духе "модеры пилят и откатывают tvl с подставными корешами аудиторами". А потом компании пишут крутые отчёты о том как их крутой блокчейн фонд взломали на 300ккк, обанкротив несчастное фермерское сообщество из Колорадо, плак плак. О, да неужели?
Не в защиту конкретной программы, но во многих интервью багхантеры говорили, что ВК старается максимально докрутить импакт по полученной уязвимости.
И если багу сдали как SQLi, а там есть выход на RCE через SQLi, то в итоге её примут по максимальному импакту, соответсвенно два хангтера могут сдать одну и ту же уязвимость под разные CWE, а по факту у одного будет дубль.
..И если багу сдали как SQLi, а там есть выход на RCE через SQLi, то в итоге её примут по максимальному импакту..
Фигурально выражаясь (зеркально оперируя Вашим примером): другой бахгантер сдал "SQLi", а позже я принес "RCE через SQLi"" и меня задублили..
Bug bounty в РФ: когда вендор молчит, а платформа подыгрывает