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

В статье покажу этапы, очень похожие на стадии принятия Кюблер-Росс (отрицание, гнев, торг, депрессия и принятие), которые я наблюдал у разработчиков в процессе нашего с ними общения. Мы пройдём путь от отрицания наличия проблемы, через благодарность за информирование (о проблеме) до негодования в адрес MITRE и мой адрес.

Дисклеймер: в статье приведены скриншоты из моих личных переписок с разработчиками. Публикация таких переписок одной из сторон не требует согласия другой (согласно законодательства РФ).

Предыстория

Речь идёт о CVE-2024-45244. Вкратце: злоумышленник может перевести время на своём локальном компьютере — и именно это время будет взято уязвимым смарт-контрактом (если используются функции GetTxTimestamp()  и GetHistoryForKey() ). Манипуляция временем входит в OWASP Smart Contract Top 10 2023: SC03:2023 (после обновления в 2025 манипуляция временем покинула топ).
Импакт зависит от логики смарт-контракта, развёрнутого в блокчейне Hyperledger Fabric:
используется ли там отметка времени и как именно это влияет на бизнес-логику. Для
демонстрации я сделал уязвимый смарт-контракт, имитирующий цифровой финансовый
актив. Удалось заставить логику смарт-контракта начислять проценты на вклад будто прошёл год со вклада (в реальности прошло несколько минут). Описание уязвимого смарт-контракта и атаки на него есть в моей статье.
Т.к. проблема в общем виде известна минимум с 2019 года - изначально я не планировал оформлять CVE: задача была представить своё решение проблемы. К обсуждению моего решения в телеграмм-канале подключились разработчики. Они сочли, что проблемы нет - так что и решение бесполезно.

Отрицание

Один из разработчиков (Фёдор) засомневался в наличии описанной мной проблемы: начал призывать меня к честности. Моё предложение проверить самостоятельно всё изложенное мной в статье изначально посчитал ненужным - т.к. полагается на свои знания. Я всё же попытался у него узнать какая часть моего эксперимента неверная. Он почему-то решил, что я сдвинул время у клиента и сервера (т.е. разницы времени по сути и нет). И в этом минус моего эксперимента и предлагаемого решения. Второй разработчик (Артём, по его же словам состоит в Linux Foundation Security Committee) высказал ту же мысль. Фёдор заверил, что провёл эксперимент на стенде и проблема не подтверждается. Далее аргументация свелась к ссылкам на настройки по-умолчанию, препятствующие реализации атаки. А также на строчки кода, где происходит проверка согласно этим настройкам. Артём также в своих выводах полагался на знание исходного кода и свой опыт. Фёдор тоже пытался мне объяснить, что их с Артёмом аргументации, ссылок на код и настройки достаточно, чтоб сделать вывод: проблемы нет. Было ощущение попытки задавить авторитетом. Фёдор сказал, что я борюсь с ветряными мельницами. Артём заверил, что приложит усилия для борьбы с "мистической проблемой" (я снова улавливаю нотки сомнения в наличии проблемы).

Принятие

Причина, по которой я не удовлетворился доводами разработчиков (в т.ч. учитывая их явное превосходство в знании кода проекта) - профессиональная привычка доверять своим глазам. Я много лет занимаюсь поиском уязвимостей в разных продуктах. Наблюдательность не один раз приводила меня к обнаружению уязвимостей там, где я изначально их не искал (например, в этом случае). И различные разработчики периодически мне пытались доказать, что найденной мной проблемы якобы нет и им-то лучше знать как работает их код. Но, я со временем понял: есть разница между тем, что разработчик хотел сделать и что он в итоге сделал. Безусловно, блокчейн - штука своеобразная. И знания\опыт в информационной безопасности не гарантируют понимание сути проблем в блокчейне (может, именно поэтому эта проблема не всплыла в рамках публично доступных аудитов безопасности проекта от 2017 и 2021 годов). Но, у меня есть опыт поиска уязвимостей и в блокчейн проектах: я участник багбаунти программ в таких проектах (мой профиль на Stronghold). Поэтому, проверив свой эксперимент и убедившись в его корректности, я решил сообщить о находке через HackerOne, детально описав суть эксперимента. В процессе переписки через HackerOne, я получил подтверждение правильности эксперимента, благодарность за то, что подсветил ситуацию. А также ссылку на PR в github проекта (за авторством того самого Фёдора, кстати). Но, уязвимостью это не сочли.

Скриншот с HackerOne: изменение в коде есть, уязвимости - нет

Спустя время и Фёдор поблагодарил меня и даже признал ошибкой поведение блокчейна. Фикс для стабильных версий вышел 17.09.2024 в рамках версии 3.0.0 . При этом в ветке 2.5.х до сих пор продолжается выпуск версий без фикса.

Уроки от Артёма

Я написал через HackerOne (а не в гитхаб, о чём писал Артём). Поэтому Артём объясняет, что значит "правильно": когда нужно через HackerOne обращаться, когда - через гитхаб тикет открывать. При этом ссылки на правила не приводит, обучает "правильности" на примерах.

Скриншоты переписок с Артёмом: куда сообщать о проблеме

Попытка согласования доклада с разработчиками

В рамках подготовки к своему докладу на OffZONE 2024 я продолжил общение с разработчиками. В докладе хотел по возможности донести позицию разработчиков: почему они не считают это уязвимостью, какие меры рекомендуют для смягчения последствий (к этому времени фикса в стабильной версии ещё не было). О чём и сообщил через HackerOne. Заодно попытаться найти формулировки в докладе такие, которые не вызывали бы негативной реакции со стороны разработчиков (я много лет общаюсь с различными разработчиками относительно проблем безопасности и знаю, что некоторые достаточно болезненно воспринимают подобную информацию о своих продуктах). Да и изначально я планировал приводить в докладе цитаты разработчиков (впоследствии отказался от цитат) - по этой причине Артём пожелал ознакомиться с презентацией. Я отправил ему часть слайдов (те, где упоминаются разработчики). К этому моменту CVE не был зарегистрирован (CVE на слайдах был указан как факт, что разработчики не стали его открывать). Обратите внимание: Артём пока что называет CVE спорным, не более того.

Скриншоты переписок с Артёмом: обсуждение тезисов моего доклада

Артём сообщает об устранении проблемы за 2 недели (т.е. проблема - есть, уязвимости - нет).

Скриншот переписки с Артёмом: проблема устранена

Проблема должна решаться разработчиками смарт-контрактов. Но, как именно - не сообщается (и откуда разработчики в принципе должны узнать о наличии потенциальной проблемы?).

Скриншот переписки с Артёмом: проблему должны решать разработчики

В докладе на OffZONE 2024 я спросил зрителей считают ли они это уязвимостью или нет. Результат голосования - все сочли это уязвимостью (мнение Артёма насчёт этого голосования).

Гнев

Параллельно с подготовкой доклада на OffZONE я занялся регистрацией CVE. После дискуссии с разработчиками картина для меня поменялась. Теперь я воспринимал это не как архитектурную особенность by design, а как защиту, которая оказалась неполноценной. И это был повод оформить CVE. Что я и сделал (воспользовавшись этой статьёй). CVE-2024-45244 был опубликован 24.08.2024 (впоследствии появились аналогичные GHSA-48gg-32q2-4r6m и GO-2024-3099). Этот момент я считаю поворотным во всей истории: с тех пор отношение разработчиков ко мне стало явно негативным. Факт оформления CVE я не скрывал и сообщил об этом разработчикам через HackerOne. На что они сказали, что я должен отозвать CVE. Я предложил им донести свою позицию до MITRE самостоятельно - пусть там решают CVE это или нет.

Скриншот из HackerOne: реакция на CVE-2024-45244

Но, разработчики решили, что дело не в MITRE, а во мне. Что я якобы ввёл в заблуждение экспертов MITRE: составляя заявку на CVE я проигнорировал доводы разработчиков. Также сообщили, что назначение CVE, видимо, произошло автоматически - т.е. наличие CVE не означает, что в MITRE сочли это уязвимостью. И будут оспаривать CVE.

Скриншот из HackerOne: реакция на CVE-2024-45244 (продолжение)

Текст оспаривания CVE разработчиками тоже сохранился.

Скриншот из HackerOne: текст оспаривания CVE-2024-45244

Ну, и в финале отказали мне в запросе на публикацию отчёта HackerOne, сославшись на нарушение мной правил раскрытия информации об уязвимостях (попутно заблокировав возможности переписки на HackerOne). Отчёт на HackerOne до сих пор в закрытом доступе (ссылка на отчёт).

Скриншот из HackerOne: отказ в публикации отчёта HackerOne

Как видно из хронологии изменений CVE-2024-45244, запись несколько раз обновлялась. При этом она ни разу не находилась в статусе RESERVED (об этом статусе). В отличие от другого зарегистрированного мной CVE-2024-57695, который в этом статусе уже более полугода (т.к. MITRE не принимает видео доказательства из YouTube). Что отрицает факт автоматического назначения и публикации деталей по CVE (о чём говорят разработчики). Знакомые, взаимодействовашие с MITRE по служебным обязанностям, подтверждают, что MITRE не публикуют подробности CVE, если у них есть вопросы или сомнения по уязвимости.

Торг (+ депрессия?)

Спустя более полугода в телеграмм канале блокчейна снова появилось обсуждение той ситуации. Теперь виновен в CVE не только я, но и MITRE. В сообщениях можно увидеть, что со мной якобы пытались о чём-то договориться. А также сетование на стремление сделать из мухи слона (за KPI): что с моей стороны, что со стороны MITRE.

Артём:

• указал, что исправление внесено не из-за того, что это уязвимость, а чтобы меня успокоить (рекомендую ознакомиться с содержимым ссылки, текст автора этого заслуживает);

• удивился возможности зарегистрировать CVE без согласия разработчиков (моя субъективная интерпретация этого сообщения);

• продолжил настаивать, что MITRE создали CVE не углубляясь в суть проблемы;

• MITRE, видимо финансово заинтересованы в CVE (свои KPI);

• я якобы тоже финансово заинтересован в CVE;

• MITRE не отвечают;

• в попытке отозвать CVE участвовал сотрудник из Linux Foundation Security Group, но это не принесло результата;

• CVE назначается при малейшем подозрении на какие-либо проблемы (интересно: почему это плохо?);

• со мной пытались о чём-то договориться (может, речь про призывы на HackerOne отозвать CVE по принципу Тараса Бульбы: ты породил ты и отзывай?);

• сказал, что я якобы называю уязвимость критической (не приводя подтверждений), на основании чего набиваю свою значимость на надуманной проблеме.

  Видимо, Артём подзабыл мою оценку уровня проблемы из нашей с ним переписки.

Скриншот переписки с Артемом: я оцениваю серьёзность CVE-2024-45244

А что имел ввиду Фёдор, рассказывая про двоечника и CVE - я вообще не понял (может, до кого-то дойдёт).

Почему это не уязвимость (по мнению разработчиков)

Здесь соберу тезисы от разработчиков почему, по их мнению, уязвимости нет. Тезисы были разбросаны (по времени и месту), решил попробовать собрать всё вместе.

Начну с моего любимого: Артём пишет, что за 10 лет проблема никому не мешала.

Скриншот переписки с Артемом: за 10 лет проблема никому не мешала

А любимое - потому, что я очень часто слышу такую аргументацию от разных разработчиков. Недавно так ответил разработчик по другому проекту, когда я указал на необходимость перейти с HTTP на HTTPS при передаче данных (конкретику рассказывать не могу из-за соглашения о неразглашении между мной и моим работодателем). Но, слышать такое от участника LF Security Committee ранее не приходилось.

Ещё один классический тезис - так и должно быть, такой дизайн.

Скриншот переписки с Артемом: такой дизайн ПО

Следующее - вопрос описания API (и его интерпретации).

Скриншоты переписки с Артемом: проблема в API

Разработчики смарт-контрактов должны быть достаточно квалифицированными.

Скриншот переписки с Артемом: разработчики смарт-контрактов должны быть достаточно квалифицированными

Вот тут остановимся. Видимо, речь идёт об использовании API функций GetTxTimestamp()  и GetHistoryForKey() (ссылки на коммит от 20.06.2022). А могут ли разработчики смарт-контрактов писать правильно, если "АПИ недостаточно подробно описан и может быть неверно интерпретирован"? Ну, наверное, из-за всей этой ситуации описание API исправили, проблем с интерпретацией теперь нет. Давайте посмотрим коммит посвежее... и там не поменялось! Ну, наверное для Go забыли, сделали для JS и Java? Нет ни для JS, ни для Java. Интересно: где же взять разработчикам смарт-контрактов информацию о том, как не наступать на грабли?

Для полноты картины - тезис Артёма, что я изначально написал код смарт-контракта с багом (так в этом и суть PoC). А как написать код без бага? Может, Артём знает? Может, и знает, но не сказал: ведь, по его словам, универсального решения нет.

Скриншот переписки с Артемом: универсального решения нет

Артём пишет, что разработчики смарт-контракта каким-то чудным образом должны проверять время, а не блокчейн:

вопрос решения задач со временем просто вынесли на клиента

А разработчикам об этом как-то сообщили?

Артём пишет, что проблема имеет чисто академический интерес и без модели безопасности - не стоит внимания. Имелось ввиду, что помимо PoC и описания шагов для воспроизведения ситуации я ещё должен модель безопасности описывать? Я-то привык, что разработчики после изучения отчёта багхантера сами выпускают бюллетень безопасности с описанием кто (из потребителей продукта) и при каких условиях может столкнуться с проблемой.

Ещё один вариант: архитектура такова, что транзакцию (с отметкой времени) отправляет не злоумышленник, а бэк сервис. И если бек скомпрометирован - проблемы будут сильно больше, чем отправка транзакции с неверным временем.

Картинка сценария, когда пользователь напрямую не вызывает проблемную функцию

Судя по логике, единственной компрометацией бека считается RCE. При этом, есть и другие варианты. Например, подмена времени при попытке синхронизации локального времени операционной системы. Довольно подробно вопрос изучается тут (из личного опыта пентеста добавлю: не рассмотренным вариантом является компрометация маршрутизатора, который по DHCP может клиенту сообщать адрес сервера NTP). Ну, и не стоит забывать такую банальность, как севшая батарейка на материнской плате.

Почему я считаю это уязвимостью

Я придерживаюсь терминологии, что уязвимость - это недостаток, через который может быть реализована угроза безопасности информации. В данном случае речь о нарушении достоверности данных (как части целостности). А условия реализации атаки влияют лишь на оценку уровня уязвимости (угрозы), а не самого факта наличия уязвимости. Условия возникновения угрозы безопасности продемонстрированы в моём PoC.

Лично у меня - стойкое ощущение, что разработчики сами запутались: как же должен работать код по задумке. Сначала целых 2 разработчика отрицали факт проблемы и говорили, что защита уже предусмотрена. Потом выяснилось (с моей помощью), что работает не совсем так и зависит от версии или конфигурации. Даже устроили дискуссию о необходимости дополнительной проверки времени.

Скриншот из HackerOne про дискуссию разработчиков

Риторический вопрос: что включала дискуссия - как на самом деле работает код или нужно ли делать фикс только для того, чтобы меня успокоить?
После этого доводы про "так и задумано" напоминают мем "не бага, а фича" (и ещё - ситуацию из жизни, когда представитель кафе уверял, что разваливающийся сырник - это такой рецепт). Но, даже если так действительно было задумано - небезопасный дизайн входит в OWASP Top 10 2021 (A04:2021).

Потребителей блокчейна (в т.ч. разработчиков смарт-контрактов) общедоступным способом не уведомили об этих "граблях": ни до, ни после освещения проблемы мной. Даже после того, как разработчики признали проблемность описания API-функции. Как можно донести по-другому информацию о потенциальной проблеме? Через CVE (что я и сделал).

Очень избирательный подход в плане освещения потенциальных проблем для потребителей: про фантомные чтения написали аж для нескольких функций (1, 2, 3, 4, 5, 6, 7). А про манипуляцию временем - нигде.

Метка времени нужна для детерминизма в блокчейне. Но, её можно реализовать по-разному. В т.ч. так, чтобы этой проблемы не было. Например, в EVM блокчейнах метка времени присваивается не транзакции, а всему блоку. При этом реализован механизм проверки корректности времени при валидации блоков. Т.о., возможно, речь идёт об архитектурной проблеме. И если изначально задаться подобными вопросами на уровне модели угроз (а не перекладывать это на других) - может быть, проблемы не было бы вовсе.

Как я уже упоминал, манипуляция временем входит в OWASP Smart Contract Top 10 2023: SC03:2023. И исключение из OWASP Smart Contract Top 10 2025 не означает, что манипуляции временем теперь - вообще не уязвимость.

Учитывая всё это - странным выглядит перекладывание проблемы то на потребителей (мол, они должны как-то использовать продукт безопасно), то на меня и MITRE (за публикацию CVE якобы "на ровном месте"). Жаль, что все силы потрачены на попытки оспорить CVE и ноль - на редактирование описания API-функций.

О CVE

При построении (или анализе уже построенной) информационной системы один из этапов - проверка составных частей системы на известные уязвимости: это позволяет оценить какие варианты атаки возможны и как их можно смягчить (либо принять риск, оценив, что решение проблемы в конкретном случае не требуется т.к. отсутствует серьёзное влияние). Для этой цели важным элементом являются централизованные базы знаний об уязвимостях различных компонентов. База CVE и является одним из таких источников. Конечно, желательно, чтобы CVE были достаточно хорошо описаны. Хотя, этого не всегда удаётся добиться, по уникальному идентификатору CVE проще более точно искать информацию о проблеме, нежели выдумывать уникальные запросы не имея CVE.

У CVE-2024-45244 на данный момент есть некоторые проблемы. Например, указано CWE-294. Что вряд ли подходящий вариант. Импакт сильно зависит от бизнес-логики смарт-контрактов: если в смарт-контракте не используются функции GetTxTimestamp()  и GetHistoryForKey() - импакта нет вовсе. Если используется, например, только для вывода времени операции на чеке - тоже нет импакта. А вот когда идёт расcчет финансов на основании времени операций (что я и показал в PoC) - импакт уже существенный. В этом смысле определение уровня угрозы для CVE имело объективные сложности. И уровень "medium" кажется вполне честной "золотой серединой". Описание в части версий некорректно: на момент создания CVE версия 2.5.9 была крайней в своей ветке. Но, далее в этой ветке продолжился выпуск версий без фикса. Учитывая слова Фёдора, есть ощущение, что описание в части версий всё же останется не совсем корректной. И разработчики, имея больше информации о своём продукте, могли бы повлиять на более точное описание CVE. Но, вместо этого им захотелось устроить борьбу "за честь мундира".
Описание CVE также очень сухое. Поиск в интернете по "CVE-2024-45244" ведёт на страницы с неким расширенным субъективным толкованием различных авторов. Но, эти толкования больше похожи на "испорченный телефон" и лично у меня вызывают лишь недоумение. Учитывая, что вендор отклонил запрос на опубликование моего отчёта в HackerOne, найти технические подробности по проблеме не так уж и просто (хотя, можно ориентироваться на мой PoC в github). Я планирую обратиться в MITRE с целью улучшить содержательную часть CVE (не только автор, но и любой человек может обратиться в MITRE с этой же целью).

Заключение

К сожалению, попытки игнорирования проблем безопасности - не такая уж редкость со стороны разработчиков. Про нежелание разработчиков заводить CVE говорят и другие люди. И такой подход приводит к "медвежьей услуге": при анализе систем на безопасность могут не учитываться особенности систем, влияющих на безопасность при определённых условиях. Просто потому, что разработчик не стал заводить CVE. Именно эта проблема и стала поводом для появления сервиса NotCVE.org (делал заметку о сервисе). Сервис, по сути, и является ещё одной централизованной базой, где можно искать проблемы безопасности: как те, для которых есть CVE, так и те, для которых CVE нет. Создатели сервиса отмечают: в определённых случаях CVE зарегистрировать не получится даже через MITRE (мой опыт это тоже подтверждает). В этом году я зарегистрировал в этом сервисе 4 идентификатора. Их всех объединяет нежелание вендора создавать CVE. Само исправление вендоры часто называют не уязвимостью, а хардерингом. А в одном случае вендор отказался создавать CVE просто потому, что недостаточно импакта.

В этой статье также отмечаются популярность проблемы с триажом в багбаунти. Всё это стоит учитывать и при выборе должности: не всегда профессиональный поиск уязвимостей (хорошее понимание технологий) означает отсуствие взаимодействия с людьми.
Причина же подобных ситуаций часто в том, что разработчики и "безопасники" по-разному воспринимают ситуацию. Разработчики могут действительно лучше знать код своего продукта, чем багхантер. Но, иногда разработчики могут и запутаются в условиях работы собственного продукта. Кроме того, у профессиональных багхантеров часто знаний о потенциальных угрозах и способах их реализации больше, чем у разработчиков. В данной истории это также прослеживается: разработчики полагали, что для манипуляции временем должен быть скомпроментирован бэк. Хотя на самом деле, это далеко не единственный вариант. А иногда причина - в неумении человека признавать ошибки (свои или коллег).

Другие мои статьи по теме:

• Манипуляция временем транзакции в блокчейне Hyperledger Fabric

• Оракул времени для блокчейна Hyperledger Fabric

• Мой вклад в безопасность блокчейна Hyperledger Fabric