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

Ещё про PoC in GitHub

Ещё про PoC in GitHub

Ещё про PoC in GitHub. Вот я написал, что CVE-2023-36884 там есть. Но если присматриваться, то всё не так радужно. 😐 Давайте разберём.

Maxwitat/CVE-2023-36884-Scripts-for-Intune-Remediation-SCCM-Compliance-Baseline - скрипт для ремедиации
deepinstinct/Storm0978-RomCom-Campaign - IOC-и
zerosorai/CVE-2023-36884 - утилита для ремедиации
tarraschk/CVE-2023-36884-Checker - скрипт для детектирования уязвимости
or2me/CVE-2023-36884_patcher - утилита для ремедиации
ToddMaxey/CVE-2023-36884 - скрипт для ремедиации
ridsoliveira/Fix-CVE-2023-36884 - скрипт для ремедиации
raresteak/CVE-2023-36884 - информация для ремедиации

Пока нет там никакого POC-а. 🤷‍♂️

Т.е. "PoC in GitHub" было бы уместнее называть "CVE mentions in GitHub". Упоминания CVE-шек он подсветит, но контекст, разумеется, не покажет. Дальше только ручной анализ или какая-то хитрая автоматизированная классификация находок.

Посмотрел на гитхабе репозиторий PoC in GitHub

Посмотрел на гитхабе репозиторий PoC in GitHub

Посмотрел на гитхабе репозиторий PoC in GitHub. Там содержатся результаты автоматизированного поиска эксплоитов для CVE уязвимостей на GitHub. В настоящий момент там PoC-и для 4484 CVE идентификаторов. Выборочно проверил, вроде ок. Например, RCE уязвимость Office (CVE-2023-36884) из последнего Patch Tuesday там есть.

Распределение по годам:

CVE-1999-*: 4
CVE-2000-*: 4
CVE-2001-*: 10
CVE-2002-*: 14
CVE-2003-*: 6
CVE-2004-*: 9
CVE-2005-*: 7
CVE-2006-*: 13
CVE-2007-*: 18
CVE-2008-*: 21
CVE-2009-*: 22
CVE-2010-*: 25
CVE-2011-*: 27
CVE-2012-*: 39
CVE-2013-*: 64
CVE-2014-*: 128
CVE-2015-*: 144
CVE-2016-*: 185
CVE-2017-*: 323
CVE-2018-*: 407
CVE-2019-*: 504
CVE-2020-*: 684
CVE-2021-*: 747
CVE-2022-*: 739
CVE-2023-*: 340

Растёт общее число CVE-шек, растет и число эксплуатабельных CVE-шек. ⤴️ При этом никто не даёт гарантии, что PoC-и рабочие и что там нет рикролов или малварей. Будьте осторожны.

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

Американская микроблоггинговая площадка с птичкой перестаёт быть местом для сбора релевантной инфы по CVE-шкам

Американская микроблоггинговая площадка с птичкой перестаёт быть местом для сбора релевантной инфы по CVE-шкам

Американская микроблоггинговая площадка с птичкой перестаёт быть местом для сбора релевантной инфы по CVE-шкам.

1. В конце июня - начале июля количество сообщений с CVE сократилось с 1272 в рабочий день до 333 в рабочий день. А если не считать ботов, то, в среднем, с 500 в день до 66 в день. Видимо ИБ-шники куда-то мигрировали. Хотя возможно и просто сезонное.
2. Возможность бесплатного экспорта сообщений (в т.ч. с CVE-шками) убрали. 🤷‍♂️

Имхо, это очень даже позитивно. Нечего пользоваться замусоренными мейнстримными соцсеточками для обсуждения ИБ-вопросов, нужно формировать что-то специализированное, а-ля Peerlyst.

HTML код в NVD CVE description

HTML код в NVD CVE description

HTML код в NVD CVE description. Работаю сейчас над оптимизациями для детектирования уязвимого продукта и типа уязвимости по текстовому описанию в Vulristics. В процессе обнаружил вот такое. Спасибо, конечно, что не

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

Первоначальные намётки по открытому фиду с уязвимостями - проект 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 отказались по каким-то причинам идентификаторы выдавать.