Bug hunters *

Штраф - не только за утечку персональных данных, но и за иные пользовательские данные

30.05.2025 в силу вступили поправки в КоАП 13.11. Среди прочего - добавлены пункты про утечку идентификаторов (п 12-14). И здесь же - пояснение что такое "идентификаторы":

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

Возможно, причина в том, что на практике юридический вопрос "что есть персональные данные" компании трактуют очень субъективно (оставляя на откуп триажерам и не привлекая юристов). И законодатель решил, что теперь всё, что так или иначе относится к пользователю - если не персональные данные, так идентификаторы (id пользователя, номер транзакции, размер платежа и т.д.).

Пример из собственной практики: один известный банк на мой отчёт в багбаунти об утечке данных индивидуальных предпринимателей (совокупность: ФИО, телефон, размер перевода, электронные почты - личная и компании) ответил:

раскрывается нечувствительная и общедоступная информация о мерчанте. Платежных карт там нет, адрес email и телефон юрлица являются публичными данными.

Это при том, что согласно статьи 5 ФЗ "О государственной регистрации юридических лиц и индивидуальных предпринимателей" от 08.08.2001 N 129-ФЗ - в общедоступных гос реестрах нет телефонного номера, а адрес электронной почты - только при указании таких сведений в заявлении о государственной регистрации.

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

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

MITRE не принимает видео доказательства из YouTube

В декабре 2024 я обратился в MITRE для регистрации CVE. Среди прочего приложил ссылки на YouTube с демонстрацией уязвимости. Через месяц мне пришёл ответ о создании CVE-2024-57695. Его статус - RESERVED. Более мне ничего не сообщали. Спустя 5 месяцев я решил поинтересоваться в связи с чем статус не меняется - в прошлый раз процесс регистрации публично доступного CVE занял около 2-х недель. И ответ пришёл неожиданный:

We do not currently accept youtube videos as the initial public reference.

Что мешало сообщить об этом в течение полугода - непонятно. Так что имейте ввиду, если соберётесь регистрировать CVE.

OpenRedirect в IBM Instana (NotCVE-2025-0002)

Instana - платформа для мониторинга приложений и инфраструктуры. Эту особенность я нашёл пару месяцев назад совершенно случайно. Забавно, что год назад на собеседовании я не смог ответить на вопрос: что такое OpenRedirect (описан в CWE-601) - растерялся. А сейчас вот сам нашёл. Проблема довольно тривиальна: с помощью специально сформированной ссылки можно заставить браузер жертвы выполнить произвольный GET-запрос. Жертва должна быть авторизована в Instana. Пример ссылки:

https://instana.com/auth/signIn?returlUrl=https%3A%2F%2Fsite.com%2Fchangepassword%3Fuser%3Dadmin%26newpassword%3Dtest

На рисунке ниже виден результат перехода по подобной ссылке: сервер отвечает кодом 302 и через location перенаправляет пользователя на нужный ресурс.

Изначально я пытался зарегистрировать CVE. Продукт Instana принадлежит IBM. А IBM является CNA партнёром MITRE (подробнее про CNA). Т.е. для регистрации CVE нужно обращаться не к MITRE, а к IBM напрямую. Что я и сделал. Ответ от IBM был таков:

We need to see more impact beyond phishing. If you are able to chain this issue with further exploitation (ex: token theft, xss bypass, SSRF, etc…) then please let us know. You will see that other vulnerability programs (example: google) take a similar stance on open redirects.

We recommend taking a look at the following external resources for further information on open redirect issues we would be interested in addressing:

• https://www.youtube.com/watch?v=84nYxHwbCpU

• https://blog.detectify.com/industry-insights/the-real-impact-of-an-open-redirect/

We thank you for your efforts in helping keep IBM products secure. Please reference any further communication related to this issue via your original HackeOne ticket so we can better track this finding.

Нежелание признавать уязвимость со стороны разработчиков - не такая уж и редкость. В моей практике бывало, что разработчики даже пытались оспаривать CVE. Я решил вместо дальнейших исследований по повышению импакта обратиться в NotCVE - сервис как раз для подобных случаев (делал об этом сервисе заметку). Тем более уже был опыт взаимодействия с ними. И буквально через пару дней получил ответ, что уязвимости назначен идентификатор NotCVE-2025-0002.

Проблема замечена в версии User interface v1.293.809 + Backend Tag v3.293.425-0. В этой версии проблемы нет: User interface Tag 1.267.675 + Backend Tag 3.267.347-0

NotCVE - ещё одна база уязвимостей

В процессе подготовки статьи (Как я зарегистрировал CVE и разозлил вендора) искал информацию об уязвимостях, которые не были признаны разработчиками. И натнулся на проект NotCVE (он же !CVE). Проект появился как минимум с октября 2023 года. Удивительно, что в рунете практически нет упоминания этого проекта (нашёл только ссылку на этот ресурс на сайте БДУ).
Миссия проекта - предоставить общее пространство для уязвимостей, которые не признаны производителями, но при этом представляют собой серьезные проблемы безопасности. Если исследователь столкнулся с трудностями при присвоении CVE, авторы проекта готовы помочь - содействуя присвоению CVE. Либо, если это окажется безуспешным, присвоив NotCVE. База уязвимостей, которым присвоили NotCVE, пока скромная (всего 5 штук). Есть 3 варианта поиска, производящих поиск одновременно по базам CVE и NotCVE: с поддержкой фильтра по версиям, CVSS, наличию эксплоита, типу воздействия (у меня, правда, поиск по версиям плохо отработал - может, неверно составил запрос).

В часто задаваемых вопросах на сайте проекта приводят такой список причин обращаться к NotCVE:

• Проблема безопасности, которую производитель считает своей особенностью.

• Проблема безопасности, технически корректная, но выходящая за рамки модели угроз производителя.

• Отклонения CVE по причине окончания срока службы и поддержки.

• Проблема, которая может считаться уязвимостью по мнению MITRE, но не по мнению поставщика.

• Опубликованная проблема безопасности, которой не присвоен CVE по истечении 90 дней.

• Опубликованная проблема безопасности без присвоенного CVE.

Также есть опубликованное электронное письмо от представителей NotCVE (от 2023 года). Среди прочего там указано:

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

Моя личная практика это тоже подтверждает: разработчики Hyperledger Fabric всячески отказываются называть найденную мной проблему уязвимостью (CVE-2024-45244). И даже предлагали мне самому отозвать CVE. А когда я отказался - пытались оспорить назначение CVE, но безуспешно (подробности - в статье "Как я зарегистрировал CVE и разозлил вендора"). Более того, проблему исправили в версии 3.0.0 (см. поиск по тексту "TimeWindowCheck" в описании релиза 3.0.0) - вышла 20.09.2024. И не хотят исправлять в ветке 2.5.х (в которой продолжается выпуск новых версий после 20.09.2024). В связи с чем описание CVE-2024-45244 (в части уязвимых версий) сейчас не актуально.

Возможно, и я обращусь к NotCVE по нескольким потенциальным проблемам:

• IBM отказался признавать уязвимость в Instana, о которой я им сообщил на днях (UPD: назначено NotCVE-2025-0002);

• MITRE назначила CVE (CVE-2024-57695) найденной мной уязвимости 13-летней давности (сообщил им лишь в декабре 2024) ещё в январе 2025. Но, статус до сих пор RESERVED (подробнее об этом статусе);

• Docker отказался присваивать CVE (UPD: назначено NotCVE-2025-0002).

P.S. По такому случаю сделал ключевое слово "не бага а фича" - надеюсь, в дальнейшем по этому выражению на Хабре станет проще находить соотвествующие статьи\посты.

Как Яндекс.Маркет обманул меня и игнорировал 2 месяца

История о том, как Яндекс Маркет проводил акцию «Колесо призов», где можно было выиграть iPhone, но вместо этого я получил скидку на настольные игры.

🔹 Что случилось:

Я крутанул колесо, и мне выпал iPhone. На экране явно был изображён телефон. Однако после остановки колеса мне засчитали… скидку на настолки.

Обратите ещё внимание, как криво наполовину недовылезла картинка со скидкой

🔹 Что я сделал:

Я обратился в поддержку 19 января 2025, но они тянули с ответом 2 месяца (!). Когда, наконец, ответили, заявили, что «это просто ошибка анимации», а приз «выбирается случайно». То есть сама игра вводит пользователей в заблуждение, показывая одно, но засчитывая другое.

Здравствуйте, Андрей!

Разобрались в работе колеса призов и выявили ошибку — дело в том, что некорректно отображается анимация. После обновления приложения до версии 7.1.1 ошибки быть не должно.

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

🔹 Обратился в Роспотребнадзор:

Мне ответили, что акции, бонусы и скидки не подпадают под Закон о защите прав потребителей, так что они помочь не могут.

🔹 Итог:

Яндекс признал баг, но вместо того, чтобы признать ошибку честно, они просто сказали «так и должно быть». То есть… если приложение показывает вам iPhone, это ничего не значит.

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

#ЯндексМаркет #обман #КолесоПризов #багилиобман #яндекс

Недавно создал инструмент для работы с google dorks, он позволяет создавать свои списки с google dorks, редактировать, удалять и делиться ими. Конечно же он с UI интерфейсом!
Можете опробовать и протестировать его: https://github.com/jionin‑real/DorkingBase

Программеры Vivaldi сделали кривой Dark Mode

(Видео ниже)

Если поднять яркость экрана, то очень бледный цвет виден. Примерно 5% от белого оригинала. Представьте, сколько можно потерять времени, если отлаживать код в Vivaldi. Я отложил примерно сутки с перерывами. Вместо танков. Спасибо, Вивальди.

Вы будете искать потерянные div и span в Vivaldi часами.

CHROME, EDGE не имеют таких проблем.

Больше всего возмущает такой низкий уровень проблемы. То, что сами разрабы (все абсолютно) не пользуются своим собственными продуктами, это уже давно мне известно. И Вивальди здесь впереди всех, лидер этой банды. Они там всей толпой сидят в Светлой Теме, слепят глаза себе и нам. Багов не видят. Могу еще перечислить. У них там система bug-report cкрыта, разумеется. Но их номера давно перевалили за 100 000. Этой информации достаточно, чтобы перестать писать тудой.

Не могу утверждать что через Vivaldi вообще не виден Белый Свет. По крайней мере, color: этого поста -- активно белый. Но у меня нет других мыслей, кроме ихнего кривого Dark Mode.

Я допускаю, что есть более простое объяснение. Жду его в комментах, очень интересно заполнить свои и вивальдовские пробелы. Заранее согласен на свой позор.

Жду разъяснений, в том от числе и от самих Vivaldi :)

P.S. это также видно на YouTube Shorts

Думаю, можно, наконец, поставить точку в вопросе: является ли манипуляция временем со стороны клиента в блокчейне Hyperledger Fabric уязвимостью? Как я писал ранее, разработчики попытались оспорить назначение идентификатора CVE (и даже хотели, чтоб я сам как-то отозвал этот идентификатор). Мне неизвестно, как складывалось общение разработчиков с MITRE: они общались напрямую. О факте оспаривания я узнал в конце августа (из переписки с разработчиками на HackerOne). И вот вчера запись о CVE-2024-45244 была обновлена: выставлен рейтинг уязвимости. Буду считать это точкой в вопросе оспаривания со стороны разработчиков.

В итоге
Разработчик выпустил фикс. Но, исправление сейчас недоступно для стабильных версий: фикс присутствует лишь в ветке main. Какого-либо информирования пользователей об уязвимости со стороны разработчиков я не нашёл (на странице проекта в github в списке уязвимостей не значится). Не нашёл и рекомендаций от разработчика: что делать пользователям, которые используют версию без исправлений? Со своей стороны могу предложить в качестве защиты свою разработку: Оракул времени.

Интересное продолжение истории о получении CVE для уязвимости в блокчейне Hyperledger Fabric. Разработчики не признают уязвимость. Это при том, что они внесли изменения, устраняющие проблему. Когда я им сообщил, что по моему обращению в MITRE присвоен идентификатор CVE - сказали, что нужно отозвать CVE: код ведь работал так, как и задумано. Как я понял, разработчики сочли, что MITRE создали идентификатор CVE автоматически, не вникая в суть моего обращения (что противоречит практике моих знакомых, у которых MITRE в ряде случаев запрашивало дополнительные данные перед назначением CVE). По этой причине, разработчики пытаются оспорить CVE (UPD: судя по обновлению от 12.09.2024, оспорить не вышло). Видимо, про уязвимость небезопасного дизайна из OWASP Top 10, они не слышали. Кроме того, по классификации, уязвимость попадает в OWASP Smart Contract Top 10: Timestamp Dependence. Допускаю, что разработчики об этом не знают. К сожалению, я им сообщить этого не могу: моё обращение на HackerOne разработчики закрыли, что заблокировало возможность мне добавлять текст к обращению. Я, кстати, не слышал, чтоб какой-либо идентификатор CVE был аннулирован. UPD: бывают отозванные CVE: CVE-2023-4881.

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

Подробности - в статье "Как я зарегистрировал CVE и разозлил вендора"

Манипуляция временем транзакции в блокчейне Hyperledger Fabric - уязвимость (теперь официально).
Мне удалось добиться назначения идентификатора CVE (CVE-2024-45244) уязвимости, связанной с манипуляцием времени транзакции (о чём писал на Хабре) в блокчейне с открытым исходным кодом Hyperledger Fabric. Разработчик выпустил исправление, но не счёл это уязвимостью (о чём я узнал в переписке, по моему обращению на HackerOne). В итоге, мне пришлось самостоятельно заниматься процессом назначения CVE (воспользовавшись найденной мной на Хабре статьёй). Между обращением в MITRE и назначением CVE прошло чуть менее 2-х недель. UPD 13.09.2024 разработчик пытался оспорить, что это уязвимость - не вышло.

Согласно результатам голосования на моём докладе на конференции по кибербезопасности OFFZONE, все участники согласились, что манипуляция временем транзакции является уязвимостью. Исправление сейчас недоступно для стабильных версий (т.е., в ветке 2.4 и 2.5 исправлений нет, а ветка 3.0.0 не является стабильной). В качестве защиты, можно воспользоваться моей open source разработкой.

Блокчейн активно используется в разных сферах: цифровые валюты центробанков (Беларусии, Нигерии), операторами информационных систем цифровых финансовых активов, электронное голосование, энергетика, здравоохранение и др.

VK повышает вознаграждение этичным хакерам до 7,2 млн рублей💸

Такие выплаты будут ждать исследователей безопасности программы «Почта, Облако и Календарь» с 30 июня по 30 июля 2023 года. Вознаграждение удвоится за все уязвимости, найденные на стороне сервера (server side).

🔥Максимальная награда за баг критического уровня опасности составит 7,2 миллиона рублей!

«Информационная безопасность — один из стратегических приоритетов для VK. Если говорить о выплатах в рамках нашей программы багбаунти, важно охватить всех исследователей, которые готовы искать новые уязвимости и получать вознаграждение. Такой инструмент, как повышение выплат, позволяет сосредоточиться на определенных продуктах и повысить их безопасность», — отметили в компании.

Всего на Standoff 365 Bug Bounty зарегистрировано 5700 исследователей, они сдали 2200 отчетов и получили более 32 млн рублей.

Начать искать баги и делать сервисы VK безопаснее можно прямо сейчас!