Архив метки: CVE

Первоначальные намётки по открытому фиду с уязвимостями - проект Vulrectory (пока пустой)

2 комментария

Первоначальные намётки по открытому фиду с уязвимостями - проект Vulrectory (пока пустой). По этому проекту хотелось бы в идеале получить обновляемый фид со всеми уязвимостями из NVD и БДУ, содержащий некоторые дополнительные поля, чтобы его можно было использовать как единственный источник данных в Vulristics. Сейчас если с помощью Vulristics приоритизировать, допустим, 100 CVE, то утилита будет делать запросы по каждой из этих CVE к различным источникам (как к бесплатным, так и к платному - Vulners), а затем комбинировать и анализировать данные. Таким образом, будут использоваться наиболее свежие данные, но генерация полного отчета займет довольно много времени. А за большое количество запросов бесплатные источники могут и побанить. Если же будет свой источник с уже подготовленными данными, который можно будет локально выкачать к себе, то можно будет запросто строить отчеты по десяткам тысяч уязвимостей без каких-либо внешних запросов. Сразу появится множество применений:

1. Оценка и приоритизация продетектированных уязвимостей (как для отдельных хостов, так и для инфраструктуры в целом!).
2. Оценка расхождений в результатах детектирования уязвимостей VM-продуктами и слепых пятен в базах знаний (детектов) VM-продуктов.
3. Vulnerability Intelligence - анализ всего входящего потока уязвимостей. Возможно с фокусом только на тех продуктах, которые используются в организации и без привязки к детектам в VM-решении.

В общем, как только можно будет работать с готовыми данными в оффлайне, всё сразу становится гораздо интереснее и удобнее. 😉

Какие дополнительные поля нужны Vulristics:

• Название уязвимого софта. Планирую переиспользовать детект продуктов по ключевым словам на основе описания CVE, который сейчас используется в Vulristics. Но лучше добавить ещё детект на основе CPE и парсинг генеренных описаний уязвимостей "имя софта> тип уязвимости>" (как у Microsoft). Также имя софта можно напрямую забирать из БДУ.
• Тип уязвимости. Планирую переиспользовать детект типа уязвимости по ключевым словам на основе описания CVE, который сейчас используется в Vulristics. Но лучше добавить ещё детектирование на основе CWE. Но это на крайний случай, т.к. к простановке CWE идентификаторов в NVD были вопросы.
• Наличие эксплоита. Если мы хотим, чтобы Vulrectory был бесплатным, то придется видимо ограничиться ссылками на эксплоиты из NVD и флажком "Наличие эксплойта" из БДУ. 🤷‍♂️ В Vulners их будет, конечно, гораздо больше (как вариант делать платную PRO версию?). Возможно есть какие-то открытые базы с признаками наличия эксплоитов на том же GitHub-е - нужно ресерчить.
• Признак эксплуатации вживую. Тут также видимо придется ограничиться бесплатным источником - CISA KEV и ресерчить наличие открытых источников по фактам эксплуатации.

В рамках этого же проекта можно для уязвимостей отображать не только CVSS, но и вектор/скор OSOKA (только Базовые и Эксплуатационные метрики, конечно). 🙂

В общем, пока какие-то такие мысли. Как вам?

Я в обосновании ответа чуток промахнулся, т.к

Добавить комментарий

Я в обосновании ответа чуток промахнулся, т.к. взял общее количество CVEшек с https://www.cve.org/About/Metrics, а не со страницы статистики NVD. А там эти значения различаются! 🙂 Но результат всё равно правильный. 😉

В комментах в ВК (а туда всё дублируется и вы можете там комментить) мне написали, что в последнем посте слишком много аббревиатур и непонятно даже в чём весь цимес

Добавить комментарий

В комментах в ВК (а туда всё дублируется и вы можете там комментить) мне написали, что в последнем посте слишком много аббревиатур и непонятно даже в чём весь цимес. Видимо я слишком усушил текст, чтобы в лимиты поста с картинкой уложиться, сорри. 😅 Дело вот в чем.

1. Есть уязвимость в архиваторе WinRAR, для которой Positive Technologies предварительно получили CVE идентификатор.

2. После того как уязвимость была исправлена, Mitre Corporation (они держат реестр CVE идентификаторов и являются апстримом для National Vulnerability Database) по какой-то причине начали использовать этот ранее выданный CVE идентификатор для какой-то другой уязвимости, которая к WinRAR никак не относится.

3. Можно подумать, что случилась какая-то ошибка и Mitre завели эту уязвимость WinRAR под другим CVE идентификатором. Но нет, других уязвимостей WinRAR с похожим описанием за 2021 год и позже не наблюдается. Просто забили.

Почему так вышло? Кто его знает, Mitre нам не расскажут. Можно предположить такую логику Mitre: "вы, Positive Technologies, под санкциями, мы от вас больше уязвимости принимать не будем". В итоге сложилась ситуация, когда один и тот же CVE идентификатор CVE-2021-35052 используется для ссылки на две совершенно разные уязвимости. Коллизия. 🤷‍♂️

Разумеется, это очень странное и контрпродуктивное поведение со стороны Mitre. Но дело не только в них. Было несколько похожих эпизодов с западными IT-вендорами, когда PT на сообщение об уязвимости либо не отвечали, либо в acknowledgement не ставили. А, например, в случае с Citrix сначала добавили acknowledgement, потом тихонько убрали, а после публичного обсуждения вернули назад. Насколько я понимаю, такое было не только с PT, но и с Digital Security, и с другими исследовательскими компаниями под американскими санкциями.

В общем, здорово, что у нас есть национальная база уязвимостей в виде БДУ ФСТЭК, где есть, кроме прочего, и уязвимости для которых Mitre отказались по каким-то причинам идентификаторы выдавать.

Коллизии CVE идентификаторов

2 комментария

Коллизии CVE идентификаторовКоллизии CVE идентификаторов

Коллизии CVE идентификаторов. Вспомнился давнишний кейс с WinRAR. Помимо неоднозначной функциональности в WinRAR иногда находят и уязвимости. В 2021 эксперт Positive Technologies Игорь Сак-Саковский нашел RCE уязвимость в WinRAR. Она НЕ связана с открытием вредоносного архива. Дело в окне-нотификации об окончании триального периода. Если провести MiTM атаку, можно выполнять код на хосте с уязвимой версией WinRAR: "запуск приложений, получение информации о хосте и запуск калькулятора". Эксплуатация не самая простая, но уязвимость была, вендор её признал и исправил в 6.02, а PT получил для неё CVE-2021-35052.

Теперь смотрим эту CVE в NVD. EoP в Kaspersky PM?! 🙄 Номер CVE отдали ZDI! Хотя бюллетень ZDI от 29 ноября 2021, а у PT пресс-релиз вышел 26 октября 2021. То, что я имел ввиду под "мусор про Twitter заводят, а нормальных исследователей прокатывают".

PS: В БДУ это BDU:2021-05327 без CVE. По CVE-2021-35052 в БДУ ничего не ищется.

CVE для рекомендательного алгоритма Twitter-а

Добавить комментарий

CVE для рекомендательного алгоритма Twitter-а

CVE для рекомендательного алгоритма Twitter-а. 🤡 Для какого только мусора CVEшки не заводят. Представляете, в Твиттере можно было массово заминусить автора и у него от этого репутационный скор уменьшался. Да не может быть! 😱 На NVD ещё в "UNDERGOING ANALYSIS". Даже интересно, что они в CVSS напишут и в CPE. Не удивлюсь, если как для обычного DoS. 😅 Похлеще музыкального клипа ломающего жёсткие диски.

А нормальных исследователей с реальными критичными уязвимостями мурыжат и прокатывают. И так у них всё.

Microsoft продолжают чудачить

1 комментарий

Microsoft продолжают чудачить. Принесли новую уязвимость. Проигрывание музыкального клипа Janet Jackson - Rhythm Nation (1989) ломает некоторые жесткие диски в некоторых ноутбуках ~ 2005-го года выпуска. Причем не только если клип проигрывается на самом устройстве, но и просто на соседнем устройстве. Есть в этом клипе какие-то частоты, которые с чем-то там в жестком диске резонируют. 😄 Звучит как лютый бред, но вот CVE-шка есть, CVE-2022-38392:

"A certain 5400 RPM OEM hard drive, as shipped with laptop PCs in approximately 2005, allows physically proximate attackers to cause a denial of service (device malfunction and system crash) via a resonant-frequency attack with the audio signal from the Rhythm Nation music video."

Заведена по посту в майкрософтовском блоге. Пишут, что неназванный "major computer manufacturer" зафиксил уязвимость добавлением кастомного аудио-фильтра:

"The manufacturer worked around the problem by adding a custom filter in the audio pipeline that detected and removed the offending frequencies during audio playback."

На самом деле демонстирует отсутствие какого-либо входного барьера при заведении CVE. CVE Numbering Authorities могут завести практически что угодно, с каким-угодно обоснованием, вплоть до совсем анекдотических.