Феномен: статьи не в тему Хабра всё равно иногда популярны

При отрицательном голосовании за статьи и карму на Хабре обязательно указывать причину. И авторы могут увидеть анонимно оставленные причины (как я понял - только для голосов за карму, за статьи - нет). Одна из причин - Статья\Тема не для Хабра (общий вариант при выборе причин минуса за карму и за статью). Тем не менее, часть статей, не вписывающихся в тематику, становятся очень популярными. Пример: статья Как поехавшие бабули отсудят у вас квартиру: самый полный разбор от юриста (+400 рейтинг, 526 в закладках). Эта статья по сути про сферу законодательства в недвижимости (кейс Долиной). А выбраны хабы "Финансы в IT", "Законодательство в IT". Другой пример - моя статья "Как я обжаловал попытку военкомата ограничить меня в правах" (+225 рейтинг, 529 в закладках). В хабах "Удалённая работа", "Законодательство в IT", "Лайфхаки для гиков". За эту статью я получил один минус в карму с формулировкой "Статья\Тема не для Хабра". Причина такого голосования ясна. При этом плюсов в карму я получил несколько десятков. И вот что интересно: подобные ситуации показывают проблему. С одной стороны авторы рискуют попасть в немилость пользователей и нахватать минусов (поднимая, как им кажется, важные вопросы, для которых нет нужного хаба на Хабре). Возможно, кто-то из авторов имеет интересные темы. Но, не стал их публиковать из-за этого. С другой - часть авторов угадали настрой пользователей (или им просто повезло). Я не знаю какой процесс создания на Хабре новых хабов. Но, очевидно, что даже создание хабов ситуацию полностью не решит. За последние 10 лет на Хабре и так уже появилось много новых хабов. И всё равно, как видно, есть статьи, которые не попадают под них, но популярны у читателей.

Использую ИИ для поиска фактов для статей на Хабр

При подготовке постов\статей стараюсь использовать ссылки, подтверждающие факты, на которые ссылаюсь (дабы было ясно, что факты эти не мной придуманы). Вижу, что и часть читателей тоже это оценивает позитивно (комментарий к одной статье, комментарий к другой). А, порой, нужно сослаться на статью, где тот или иной вопрос раскрывается подробнее.

В таких вопросах ИИ хорошо экономит время. Например, для статьи Как я обжаловал попытку военкомата ограничить меня в правах мне нужно было найти судебное решение, где шла речь о доставке гражданина в военкомат сотрудниками полиции (из-за его неявки по повестке). До написания статьи я самостоятельно находил подобные судебные решения: это нужно было лично мне для оценки ситуации, в которую я попал. В тот момент я не сохранил ссылку на решение для будущей статьи. И сами решения искал тогда не через ИИ, а через сайты вроде sudact.ru (на сайте — поиск по статье 21.5 КоАП). Это занимало много времени. Когда я занялся статьей — сразу подумал про повторный поиск, но уже через ИИ. Во‑первых, ожидал, что это будет быстрее. Во‑вторых, помнил: Алиса с некоторых пор умеет в ответах приводить источник. Так оно и вышло: вместо десятков минут самостоятельного поиска я нашёл искомое за 1 минуту по запросу:

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

А зачем покупаете WAF, который можно обойти?

С таким вопросом разработчиков периодически сталкиваюсь. Добавлю контекста. Работаю AppSec инженером в финтехе. Когда нахожу уязвимости — сообщаю разработчикам. Среди прочего - доношу мысль: если в данном случае можно смягчить потеницальные последствия угрозы через WAF — это не значит, что уязвимость не нужно исправлять в приложении. Нередко разработчики спорят. Примерный диалог:

— Ну, есть же WAF — на нём и делайте фикс, зачем нам-то в код лезть? WAF — он же для того и нужен, чтоб уязвимости устранять.
— WAF — не панацея: на нём мы сделаем правило. Но это не значит, что в самом приложении не нужно устранять.
— Почему?
— Например, потому, что практически любой WAF можно обойти.
— А зачем покупаете WAF, который можно обойти?

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

Эта история в очередной раз показывает: насколько бывают различны в оценке ситуации разработчики и "безопасники". Более интересный вариант — когда разработчики считают, что только они могут решать: что является уязвимостью, а что — нет (подробнее об этом я писал в статье "Как я зарегистрировал CVE и разозлил вендора").

О поддержке opensource - как показателе безопасности

Случались ситуации, когда компании использовали open source, который перестал развиваться. И в этом open source находили уязвимости. Итог: компаниям сложно ликвидировать уязвимости в используемом open source. По этой причине рождались предложения: дабы не попасть в такую ситуацию - при выборе open source проверять, что проект ещё поддерживается. Мысль здравая. Но, и тут могут быть нюансы. Пример - проект JasperReports (для Java). Судя по репозиторию - проект поддерживается. 16 сентября 2025 была опубликована информация об уязвимости в проекте (критического уровня: 9.8 по шкале CVSS v3.1 - CVE-2025-10492). А 19 сентября 2025 разработчик сообщил, что фикс выйдет только для коммерческой версии.

Онлайн сервис проверки конфига nginx на безопасность (Gixy-Next)

На Хабре уже упоминался Gixy как средство проверки безопасности\хардеринга nginx (статья раз, статья два). Недавно появился ещё один проект, основанный на форке Gixy: Gixy-Next (репозиторий, сайт проекта). Из интересного: прямо на сайте есть возможность проверить конфиг nginx (если по какой-то причине не хочется устанавливать приложение). В тексте найденных проблем - ссылки на страницы с подробным описанием типа ошибки.

Когда HR не помогает: как компании игнорируют выгорание и конфликты

Появилась новость, что каждый второй сталкивается с выгоранием. На днях услышал ответ одного руководителя на вопрос: "что делать, если подчинённый чувствует, что выгорает?". После его ответа - порадовался, что не работаю с ним:

Задача руководителя - чтоб у подчинённого не было времени подумать, что ты выгорел.

Я около 8 лет был руководителем. И никогда не думал также. Даже когда только стал руководителем и по сути не имел опыта руководства.

Сейчас в ИТ-компаниях нередко можно встретить HR BP (HR бизнес-партнёр). В теории они должны помогать в проблемах - в т.ч. и с выгоранием. Я работал в нескольких компаниях и, к сожалению, редко видел пользу от этих людей. В одной фирме за 5 мин разговора HR BP 3-жды меня перебила. А на моё замечание о недопустимости такого поведения сказала, что будет перебивать когда захочет и не нужно указывать ей как ей со мной общаться. Перестала перебивать только после того, как я сказал, что повешу трубку, если продолжит в том же духе. Также был свидетелем, как в другой очень известной фирме (на секундочку: не первый год входит в разные ТОП, в т.ч. на Хабре за 2025 год в топ-20) руководитель HR BP моему коллеге на жалобу, что один из директоров покрывает его матом - ответила: "просто нужно заслужить уважение директора". И это в фирме, где согласно вакансии, на должность HR BP берут с дипломом психолога (специально искал вакансию). Если руководитель HR BP говорит, что "нужно заслужить уважение" - значит, он не собирается искать пути решения, он транслирует политику компании: если тебя унизили - сам виноват. Грош цена диплому такого психолога. Если ему как профессиональному психологу такое неприемлемо - мог бы уйти. Но, нет, его всё устраивает. И когда у меня самого началась конфликтная ситуация с другим руководителем - я уже догадывался, что HR BP мне не поможет. Но, по правилам нужно было с ним пообщаться. Я упомянул 5 самых острых накопившихся проблемных ситуаций. Мы не обсудили по существу ни одну. Ответ был примерно: "у вас конфликт - вы и разбирайтесь" (а завуалированно - что-то вроде: "конфликт могут разрешить в той точке, где он появился, две стороны сами должны вернуться в ту точку и решать конфликт"). До руководителя HR BP я пообщался с HR BP, закреплённым за нашим отделом. Так та, присутствуя при разговоре со мной и другой стороной конфликта - "считала ворон", абсолютно не понимая сути разговора. А потом выдала гениальное: "наша компания - пионер в этой области, ты просто не поспеваешь за её темпами". Как она пришла к такому выводу, "считая ворон" - сие загадка. Когда руководитель умудрился сломать нам доступ к youtrack (именно там описывались задачи, и руководитель очень любил их там изменять) - ответ HR BP на это был: "твоя должность предполагает самостоятельное выполнение задач, не дожидаясь уточнения задачи". Зачем тогда мы пользуемся youtrack - ещё одна загадка. И самое интересное: в том же году компания делала анонимное голосование о проблемах на работе. Как оказалось - это нужно было для доклада на конференции, а не для того, чтоб внутри самой компании что-то менять.

Когда WAF - не помощник
Наткнулся на ситуацию, когда митигация эксплуатации API-метода была бы возможна при блокировке POST-запроса по правилу "если тело запроса более n-байт". Но, используемый WAF в такое не умеет (вендор подтвердил, завел задачку на подумать о такой функции). Представьте: на сайте можно выбрать 3 из 5 категорий кэшбека. Но, ограничение проверяется лишь на фронте. Ничего не мешает обратиться к методу напрямую, указав все 5 параметров в теле POST-запроса:

{
 "CODE_1": "1",
 "CODE_2": "1",
 "CODE_3": "1",
 "CODE_4": "1",
 "CODE_5": "1",
 }

Где разный CODE - последовательность символов (одинаковой длины), которая означает один из кэшбеков (красота, аптеки, рестораны и т.д.). Для митигации (пока разработчики исправляют уязвимость) можно было бы прикинуть максимальное количество байт примерно до (чтоб был небольшой люфт по байтам: чуть более 3-х запросов, но, длина из 4 параметров уже точно не попадала):

{
 "CODE_1": "1",
 "CODE_2": "1",
 "CODE_3": "1",
 "CODE_4":
 }

Как оказалось, подобного правила нет в различных WAF (поспрашивал коллег, почитал документацию некоторых популярных WAF). Правда, тут нужно быть внимательным: иногда представители вендора\интегратора ошибочно считают, что у них это есть. Но, в процессе обсуждения выясняется, что речь идёт о другом. О максимальном размере тела POST-запроса, общим для всех методов (защита от DoS). Либо речь идёт о составлении описания правила, где блокируются запросы, не попадающие под описание правила. Но, в данном случае все 5 параметров в запросе корректны (согласно swagger-схеме). Интересно: какие из существующих WAF уже сейчас умеют в подобные правила (максимальный размер тела запроса для конкретного метода)?

Внедрение WAF\антибот может ослабить TLS

После внедрения WAF\антибот систем стоит проверить настройки TLS у серверов. Я случайно обнаружил, что для некоторых доменов появилась поддержка устаревших шифров или протоколов. Для проверки есть онлайн-сервис SSL Labs. Вот как выглядел результат проверки через этот онлайн-сервис до внедрения WAF и после (пришлось объединить в одну картинку т.к. формат поста не позволяет более одной картинки). Видно, что появилась поддержка TLS 1.0 и 1.1.

Если я правильно понимаю, злоумышленник, имеющий возможность провести атаку "человек посередине", может в каких-то случаях повлиять на согласование протокола между сервером и клиентом и заставить их использовать устаревший протокол TLS. Что даст возможность расшифровывать и\или модифицировать трафик между клиентом и сервером.

Администратор WAF и антибот систем решил проблему и подтвердил, что проблема была связана с их настройкой. Как именно исправляется ситуация я не в курсе.

Если кого-то интересует оценка сложности проведения атак на TLS (при плохой конфигурации) - возможно, стоит обратить внимание на подобные курсы.

Поиск скомпрометированных зависимостей через Dependency Track

На днях стало известно о компрометации почти 2-х десятков npm-пакетов (подробнее в этой статье). Зловредный код может похищать криптовалюту. Это не первый раз, когда в зависимости попадает зловред (например, в 2022 году зловред удалял данные).

Один из вариантов поиска наличия скомпрометированных пакетов среди сотен проектов - использование Dependency Track. При этом поиск возможен и в транзитивных зависимостях тоже. На картинке ниже показан процесс. Заходим в раздел "Components", вводим название в формате "pkg:npm/$name$". Далее остаётся отсортировать по версии и найти среди них скомпрометированную (сейчас это легко - нужно смотреть самую старшую версию). Можно поиск производить сразу по конкретной версии. Пример:

pkg:npm/simple-swizzle@0.2.3

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

Если знаете альтернативные варианты поиска скомпрометированных пакетов другими средствами - напишите в комментариях.

Благодаря найденной уязвимости я зарегистрировал 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

Upd: угрозе назначен идентификатор BDU:2025-12555

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 не указывается).