Благодаря найденной уязвимости я зарегистрировал CVE-2024-45244, попал на спикер-пати OffZone 2024 (как докладчик) и в топ-10 "Pentest Award 2025" (номинация Out Of Scope). А ведь этого всего могло бы и не быть, если бы я не продолжил настаивать на своём (невзирая на мнение моего тогдашнего тимлида). Уязвимость обнаружил несколько лет назад в процессе исследования безопасности коммерческого смарт-контракта. Сообщил тимлиду (отдел занимался безопасностью блокчейна) во всех подробностях, даже макет с результатами показал и описал. Но, тимлид проигнорировал мою находку. Он до этой работы не имел практического опыта в безопасности (был разработчиком). Врезалось в память, как он называл себя "самым компетентным по блокчейнам в отделе". После моего отказа на предложение добровольно стать "козлом отпущения", у него появились претензии к моей работе. Мол, это я ничего не смыслю в безопасности блокчейнов. В какой-то момент он даже позвал HR бизнес-партнёра на 3-х сторонний диалог (видимо, показать, что он не одинок во мнении насчёт моей компетенции). HR весь наш диалог молчала, "считая ворон". А в конце выдала гениальное: я не поспеваю за темпом компании в безопасности. И, вообще-то, очень плохо, что я не внимаю мнению руководителя - тимлидом абы кого не ставят (видимо, кейс с президентом Ельциным молодое поколение HR-ов и не знает). Учитывая, что у компании одной из целей был поиск CVE в блокчейнах, и на текущий момент в публичной плоскости у них так ни одной CVE в этой области не появилось - большой вопрос: кто за кем не поспел.

Сегодня, прочитав статью "Когда руководитель не руководитель. Синдром «Самого умного» я вспомнил не только разработчиков блокчейна, пафосно уверявших меня, что проблемы нет, они-то лучше меня знают свой продукт. А фикс - только чтоб меня успокоить (подробнее в статье "Как я зарегистрировал CVE и разозлил вендора"). Я также вспомнил своего бывшего тимлида. И ведь такие люди - не редкость. На одной из лекций психологу задали вопрос почему среди руководителей часто нарциссы? Ответ: обычный человек 10 раз подумает стоит ли идти в руководители. У нарциссов же это желанная цель: уже самой своей должностью показывать подчинённым кто в доме хозяин. Надо сказать, что такие люди любят публичный вынос "сора из избы". Пример с этим тимлидом - на картинке.

Что делать когда сталкиваешься с такими людьми? Это дело каждого. Но, лично я солидарен с психологом: не пытаться что-то им доказать, не вестись на провокации, и постараться не пересекаться в жизни (если нужно - сменить работу). Ну, и CVE, OFFZONE, Pentest award - те вещи, которые вряд ли бы появились, если бы не сменил работодателя.

Хотел как лучше, а получилось... или снова о качестве описания CVE

В статье "Как я зарегистрировал CVE и разозлил вендора" я писал:

Желательно, чтобы CVE были достаточно хорошо описаны. У CVE-2024-45244 на данный момент есть некоторые проблемы. Описание в части версий некорректно: на момент создания CVE версия 2.5.9 была крайней в своей ветке. Но, далее в этой ветке продолжился выпуск версий без фикса. Фикс для стабильных версий вышел в рамках версии 3.0.0. Я планирую обратиться в MITRE с целью улучшить содержательную часть CVE.

После моего обращения описание CVE было обновлено. Было:

Hyperledger Fabric through 2.5.9 does not verify that a request has a timestamp within the expected time window.

Стало:

Hyperledger Fabric through 3.0.0 and 2.5.x through 2.5.9 do not verify that a request has a timestamp within the expected time window.

Честно говоря, такое описание вводит меня в ступор. Например, версия 2.5.13 по такому описанию уязвима? С одной стороны да: она до 3.0.0. С другой - нет: она после 2.5.9. И, если я не ошибаюсь, в версиях 2.4.х проблема тоже есть.

Это уже не первый раз, когда описание CVE в части версий неточное - даже после обращения с целью сделать точнее. Ранее нечто похожее было с моей попыткой улучшить описание для CVE-2018-14847.

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

Проблема с описанием версий иногда обостряется из-за позиции вендора. Как я писал в статье:

Разработчики, имея больше информации о своём продукте, могли бы повлиять на более точное описание CVE. Но, вместо этого им захотелось устроить борьбу "за честь мундира".

В процессе подготовки статьи "Как я зарегистрировал CVE и разозлил вендора" я искал статьи с практическими результатами по подмене локального времени жертвы (при синхронизации через NTP). Это оказалось нелегко: чаще всего статьи были теоретическими. Но, я нашёл и довольно интересную статью от 07.11.2024: Quantitative Risk Analysis of Network Time Protocol (NTP) Spoofing Attacks. Часть вопросов, которые изучаются в статье:

• рассмотрены атаки на ntpd, NTPSec, chrony, и OpenNTPD;

• оценивается возможность максимального смещения времени атакой (в условиях защитных механизмов атакуемых утилит);

• рассматриваются сложности атак.

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

Помимо этих вопросов - вот вопросы, которые у меня остались.

• Когда именно происходит синхронизация времени через утилиты или в ОС в обычной жизни? И как часто? Т.е. сколько времени нужно ждать атакующему для возможности совершить атаку? Принудительный перезапуск утилиты не рассматриваем.

• DHCP предусматривает периодическое обновление данных - не только IP-адрес, шлюз по-умолчанию и DNS. А и NTP (пример настройки NTP для DHCP в маршрутизаторе MikroTik). И тут 2 варианта атаки: либо получен доступ к DHCP серверу, либо подмена DHCP-пакетов (при атаке "человек посередине"). Как эти варианты атаки скажутся на системное время различных ОС, сконфигурированных по-разному (в т.ч. если даже в ОС используется более безопасный вариант вроде NTPSec и др.)? Тем более, что подмена NTP-сервера через DHCP во многом лишена тех сложностей, что описываются в статье.

• UPD: другой вариант - отравить кэш локального DNS-сервера (если в качестве сервера времени прописано доменное имя). Допустим, клиенты получают время от 0.ru.pool.ntp.org. И в качестве DNS сервера у них прописан роутер MikroTik, подверженный CVE-2019-3978.

Было бы любопытно ознакомиться с существующими best practices синхронизации времени, учитывающими все вышеуказанные риски (либо хотя бы пытающиеся их учитывать).

Другие статьи на эту же тему:

• Securing NTP against MITM attacks (от 09.12.2022);

• Как синхронизация времени стала безопасной (от 09.06.2020).

Как потерять клиент-ориентированность при внедрении ИИ

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

Через день я попытался дозвониться до Оператора. Но, и там меня встретил виртуальный помощник Елена. До оператора я смог чудом пробиться через примерно 10 мин общения с помощником, отвечая по кругу на одни и те же вопросы Елены (было ощущение, что участвую в психологическом эксперименте). К слову, мне ещё повезло: у жены за 15 мин так и не хватило терпения пробиться к оператору через Елену. Когда я добрался до оператора - мне ответили, что я не могу никак отказаться от "услуг" Елены. На жалобу, что до оператора добраться нереально ответили в духе - плохо стараетесь, у других получается. Дело кончилось составлением жалобы на... Елену. Больше в этом квесте участвовать не хочу: мы с женой уходим с Мегафона.

UPD примерный диалог в попытке голосом позвать человека был таким:

- Оператор.
- Уточните: вопрос связан с недоступностью интернета?

- нет

- в вашей зоне обнаружены проблемы со связью, мы ими уже занимаемся. Есть ещё вопросы?

- Оператор

- Уточните: вопрос связан с недоступностью интернета?

- нет

- в вашей зоне обнаружены проблемы со связью, мы ими уже занимаемся. Есть ещё вопросы?

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

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

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

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

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

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

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

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

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

NotCVE-2025-0003 и NotCVE-2025-0004

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

• NotCVE-2025-0003

• NotCVE-2025-0004

Т.к. помимо самого компилятора Go, пострадал и Kubernetes:

The Go team has released a fix in Go versions 1.21.11 and 1.22.4 addressing a symlink race condition when using os.RemoveAll. The Kubernetes Security Response Committee received a report that this issue could be abused in Kubernetes to delete arbitrary directories on a Node with root permissions by a local non-root user with the same UID as the user in a Pod.

Из сообщения в гитхабе Kubernetes видно насколько заразительна тенденция вместо регистрации CVE называть фикс проблемы безопасности хардерингом:

The Go team has not issued a CVE for this, as it is considered a hardening issue, and the SRC is following that decision as well.

Собственно, в случае с Docker в этом году было то же самое, для них это тоже хардеринг (моё обращение в MITRE так и не привело к появлению CVE, поэтому я зарегистрировал NotCVE-2025-001).

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

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-2025-0001

Прошёл месяц с момента моего обращения в MITRE про нежелание разработчиков  делать CVE из-за фикса в Docker Engine 28.0.0. От MITRE никаких новостей больше не было. Поэтому я обратился в NotCVE (об этом сервисе я делал заметку). Спустя буквально пару дней меня оповестили о создании идентификатора NotCVE-2025-0001.
Проект NotCVE пока ещё мало известен. По этой причине по запросу "NotCVE-2025-0001" пока далеко не во всех поисковиках что-то можно найти (в Гугл нашёл 1 запись, в Яндексе и DuckDuckGo - ничего). Да и идентификаторов в NotCVE пока всего лишь 6. Очень надеюсь, что проект обретёт популярность и количество идентификаторов увеличится. И в первую очередь - из-за повышения осведомлённости об этом проекте и увеличении обращений (из-за нежелания разработчиков признавать проблему и создавать CVE). В данном случае показательно, что идентификатор NotCVE-2025-0001 завели по моему обращению несмотря на то, что проблему нашёл не я. Я просто не смог пройти мимо, увидев нежелание разработчиков регистрировать CVE.

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. По такому случаю сделал ключевое слово "не бага а фича" - надеюсь, в дальнейшем по этому выражению на Хабре станет проще находить соотвествующие статьи\посты.

Продолжая тему взаимодействия с MITRE насчёт CVE. В прошлый раз я обращался к MITRE из-за нежелания вендора Docker создавать CVE. Теперь же я попытался внести уточнение к существующей записи CVE-2018-14847, описание которой не слишком точное:

MikroTik RouterOS through 6.42 allows unauthenticated remote attackers to read arbitrary files and remote authenticated attackers to write arbitrary files due to a directory traversal vulnerability in the WinBox interface.

По такому описанию можно подумать, что уязвимы абсолютно все версии ниже 6.42. На самом деле это не так. Более точное описание есть у вендора MikroTik:

Versions affected:

• Affected all bugfix releases from 6.30.1 to 6.40.7, fixed in 6.40.8 on 2018-Apr-23

• Affected all current releases from 6.29 to 6.42, fixed in 6.42.1 on 2018-Apr-23

• Affected all RC releases from 6.29rc1 to 6.43rc3, fixed in 6.43rc4 on on 2018-Apr-23

Но, и оно не совсем правдивое. Как минимум версия 6.28 уязвима (проверял используя этот эксплоит). Я обратился в MITRE через эту форму (выбрал "Request an update to an existing CVE Entry"), объяснив всё это. В итоге MITRE лишь добавили ссылку на описание уязвимости от вендора (обновление от 28.04.2025). Это в очередной раз подтверждает, что при оценке угроз не стоит полностью полагаться ни на CVE, ни на информацию от вендора. О чём говорю не только я. Был у меня личный опыт, показывающий неточность в описании уязвимых версий со стороны вендора: Cisco UCS Manager. А если пытаться смотреть на CVE, указанные вендором по этой проблеме - так каши в голове становится лишь больше: в CVE речь о версиях bash (а какая версия bash в какой прошивке и оборудовании есть - в CVE не указывается).

В феврале 2025 вышел релиз Docker Engine 28.0.0, устранивший проблемы безопасности:

Fix a security issue that was allowing remote hosts to connect directly to a container on its published ports. moby/moby#49325
Fix a security issue that was allowing neighbor hosts to connect to ports mapped on a loopback address. moby/moby#49325

В официальном блоге вышла статья с подробностями проблемы и возможными сценариями атак. Но, CVE заводить разработчики не захотели. Я не знаю какими принципами руководствовались разаботчики. По мне слова "Fix a security issue" тождественны созданию CVE. Я обратился в MITRE с описанием ситуации через эту форму (выбрал Request type - other). И получил такой ответ:

Thanks for the submission. We will treat this as a dispute/escalation request and reach out to Docker next. Hopefully that will spur them on to assign (it often does) but if not, we will take a look at assignment. 

Once we hear back we'll let you know if they changed their mind and decided to assign or what the next steps will be.

Надеюсь, CVE заведут. Мне и моим коллегам по цеху по безопасности гораздо удобнее оценивать безопасность архитектуры, имея единый источник проблем безопасности (база CVE). А не рыскать по всему интернету, пытаясь собрать воедино информацию о проблемах безопасности конктерных продуктов, придумывая какие-то запросы, вовзращающие релевантную информацию. Даже если описание в самом CVE сухое - всегда проще искать подробности по уникальному идентификатору CVE, чем выдумывать разные запросы для каждого конктерного продукта.

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

Некоторые контейнеры (docker, например) могут внутри себя использовать iptables. Это означает, что и port knocking можно реализовать прямо в контейнере. Популярные вопросы: зачем нужен port knocking и какой смысл делать его в контейнере? Port knocking может снизить обнаружение сервиса (вместо попыток бороться с последствиями, когда сервис уже обнаружен: брутфорс, эксплуатация уязвимости). В случаях, когда нельзя использовать ACL. Особенно актуально в условиях, когда компании не успевают оперативно устранять уязвимости. В контейнере эта мера может быть полезной как подстраховка: если firewall (на хостовой системе или роутере) внезапно ослабнут правила защиты. Также это поможет разгрузить правила firewall хостовой системы.
Безусловно, port knocking, как и любая технология, не является "серебряной пулей". И в общем смысле не является заменителем какой-то другой. Но, используя port knocking совместно с другими решениями, можно существенно повысить безопасность сервисов. Внедрение данной защиты также потенциально увеличит доступное время для устранения уязвимости (пока её не начнут пытаться эксплуатировать на защищаемом сервисе). Использование port knocking также приводит к уменьшению логов. А, значит, логи проще обрабатывать. Кроме того, эта мера поможет решить проблему безопасности: доступности портов контейнеров NotCVE-2025-0001 (если используется docker версии ниже 28).
О проблемах на практике при внедрении port knocking, вариантах решения самых частых проблем и нюансах использования в docker контейнерах рассказано в этой статье. Сам скрипт для использования port knocking в docker контейнере тут.

В этом году я впервые поучаствовал как спикер на конференции по безопасности OFFZONE. Поводом для доклада стало желание закрыть гештальт: на одной из предыдущих работ мою находку о потенциальной проблеме в Hyperledger Fabric проигнорировал тимлид. И я решил довести её до конца самостоятельно. Этот путь занял практически всё лето. Дедлайн по подаче докладов - до 15 июля. В июне я сделал PoC код, показывающий суть проблемы. Ещё месяц заняла реализация защиты. Это был мой первый open source проект. Пришлось попотеть: хотелось сделать проект понятный для использования другими. Для этого нужно было: написать понятный код, снабдить его комментариями и сделать юнит-тесты. Я не профи программист, код писать не люблю. Пришлось себя перебороть ради достижения этой цели. Я подал заявку на доклад ещё не закончив это дело. В начале августа мой доклад одобрили. Тогда же я предложил своё решение в сообществе Hyperledger Fabric. Некоторые разработчики стали доказывать, что проблемы нет: в тестах не подтверждается + приводили код проекта, где реализованы механизмы защиты. Доклад оказался под угрозой. Я бросился проверять ещё раз. Убедившись в своей правоте создал заявку в HackerOne. Вскоре появилось исправление. Но, разработчики не признали, что это уязвимость. И я самостоятельно занялся присвоением CVE идентификатора. Уже после доклада уязвимости был присвоен CVE. Закрыв гештальт, снова убедился: хороший тимлид направления безопасности с опытом только разработчика - исключение из правила.

Думаю, можно, наконец, поставить точку в вопросе: является ли манипуляция временем со стороны клиента в блокчейне 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 разработчик пытался оспорить, что это уязвимость - не вышло (подробнее в статье Как я зарегистрировал CVE и разозлил вендора).

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

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