С начала года количество новых CVE идентификаторов в NVD уже перевалило за 10000, а обработали они пока только 42% от общего количества. Более того, если смотреть данные за прошлый месяц, за этот месяц и за текущую неделю, то получается, что обрабатывают они только 3-5% новых CVE. 🤷♂️ В общем, не похоже, что кризис NVD собирается заканчиваться, несмотря на все заверения. Про новый консорциум тоже пока нет новостей.
Архив метки: NVD
NIST передаст управление базой NVD отраслевому консорциуму
NIST передаст управление базой NVD отраслевому консорциуму. Заявление сделала Tanya Brewer, руководитель программы NIST NVD, на VulnCon. У меня туда доступа нет, читаю пересказы и реакции. Письменное заявление обещают опубликовать на сайте NVD до 29 марта.
Среди причин, приведших к кризиcу NVD, озвучили следующее:
🔻Годовой бюджет NIST сократили на 12%. До жалких $1,46 млрд. 😅 Интересно сколько из этого уходило на NVD.
🔻Заканчивается контракт с подрядчиком, который работал над NVD вместе с NIST. Предположительно это Huntington Ingalls Industries. Почему-то компания, которая строит военные корабли. 🤷♂️
🔻Внутренние дискуссии по отказу от одних стандартов (CPE) и внедрению других (Package URLs)
🔻И вообще "за этим стоит история, она длинная, запутанная и очень административная".
Но после передачи дел новому консорциуму всё попрёт:
"Мы не собираемся закрывать NVD; мы находимся в процессе решения текущей проблемы. А затем мы снова сделаем NVD надёжным и заставим его расти". 😏
Повелитель CVEшек: кризис NVD
Повелитель CVEшек: кризис NVD. На сайте NVD сейчас висит баннер:
"NIST в настоящее время работает над созданием консорциума для решения проблем программы NVD и разработки улучшенных инструментов и методов. Во время этого перехода вы увидите временные задержки в анализе. Приносим извинения за неудобства и просим вас проявить терпение, пока мы работаем над улучшением программы NVD."
Фактически это привело к тому, что NVD полностью прекратили обогащать данные по CVE (CVSS, CWE, CPE). И в мировом около-VM-ном комьюнити нарастают панические настроения. Все привыкли использовать общедоступный контент NVD и относились к его обновлению как к чему-то разумеющемуся. Оказалось, что всё может прекратиться и разбираться откуда брать технические данные для каждой уязвимости придётся самим. 🤷♂️ Самоорганизовываться, как детишкам в "Повелителе мух" Голдинга. 🙂🐚🐷🪰
Я пока верю, что это временные трудности, которые решатся реорганизацией NVD. Но если нет, то занятно будет посмотреть к чему это приведёт. 🌝
VulnCheck выложили диаграмму по проблемам описания CWE в NVD
VulnCheck выложили диаграмму по проблемам описания CWE в NVD. Я 7 лет назад тоже делал что-то подобное, но тут за прошлый год и в контексте топовых CNA (CVE Numbering Authorities). Выглядит прикольно. В чём суть: CNA часто не запариваются формальным описанием типа уязвимости (а CWE, Common Weakness Enumeration, это по сути он и есть) и либо оставляют это поле пустым, либо лепят туда "мало данных", "другое". 🤷♂️
Причём я подозреваю, что там, где CWE выставлены это, в основном, что-то неконкретное типа CWE-119 Buffer Errors (во всяком случае это был самый популярный CWE идентификатор 7 лет назад). Даже если на основании описания можно предположить и более конкретный тип уязвимости. Выглядит как направление для дальнейшего анализа и тыкания уважаемых CNA палочкой. 🤔😉
Ну и интересно, а как с этим дела в нашей БДУ.
После продолжительного перерыва выпустил англоязычную видяшку и блогопост
После продолжительного перерыва выпустил англоязычную видяшку и блогопост. Разбираю там то, что произошло за последние 3 месяца. В первую очередь в плане улучшений Vulristics. Во вторую - смотрю какие были интересные уязвимости в Microsoft Patch Tuesday, Linux Patch Wednesday и из остальных. Ну и подвожу итоги 2023, а также намечаю направления работы на 2024.
Из занимательного:
🔻 Подсветил 7 уязвимостей из Microsoft Patch Tuesday, для которых за последние 3 месяца появились PoC-и/эксплоиты. Как правило это совсем не те уязвимости, на которые указывали VM-вендоры в своих обзорах. 😏
🔻 В Linux Patch Wednesday за последние 3 месяца было 90 уязвимостей с PoC-ами/эксплоитами (и это не считая тех, про которые известно, что они в активной эксплуатации). 🙈
Постараюсь по англоязычным блогопостам с видяшками вернуться в ежемесячный режим. 😇 Формат хоть и муторный, но полезный.
November 2023 – January 2024: New Vulristics Features, 3 Months of Microsoft Patch Tuesdays and Linux Patch Wednesdays, Year 2023 in Review
Hello everyone! It has been 3 months since the last episode. I spent most of this time improving my Vulristics project. So in this episode, let’s take a look at what’s been done.
Also, let’s take a look at the Microsoft Patch Tuesdays vulnerabilities, Linux Patch Wednesdays vulnerabilities and some other interesting vulnerabilities that have been released or updated in the last 3 months. Finally, I’d like to end this episode with a reflection on how my 2023 went and what I’d like to do in 2024.
New Vulristics Features
00:32 Vulristics JSON input and output
02:37 CPE-based vulnerable product names detection
04:16 CWE-based vulnerability type detection
3 Months of Vulnerabilities
07:03 Linux Patch Wednesday
11:22 Microsoft Patch Tuesdays
13:59 Other Vulnerabilities
Прожектор по ИБ, выпуск №18 (13.01.2024): Герои Оземпика in-the-middle
Прожектор по ИБ, выпуск №18 (13.01.2024): Герои Оземпика in-the-middle
🔸 Александр Леонов, "Управление уязвимостями и прочее"
🔸 Лев Палей, "Вести из Палей"
🔸 Максим Хараск, "Global Digital Space"
Первый выпуск в новом году, накопилось много новостей. 🙂
00:00 Здороваемся, обсуждаем новый ноутбук Льва без камеры, радуемся относительно большому количеству просмотров прошлого выпуска
03:10 Внезапно про обновление Heroes III с новыми замками
05:15 Несколько минут здорового самопиара. Говорим про видео-проекты: Ответь за 5 секунд (в последнем я участвовал), ИИ несёт бред, Собираем карьеру
09:20 Закладка в прошивке светодиодной гирлянды
13:04 NVD включили заднюю в вопросе отключения СVЕ-фидов
15:39 Итоги 2023 года от Qualys Threat Research Unit
21:47 Январский Microsoft Patch Tuesday и MitM
29:14 Июньская Authentication Bypass уязвимость Sharepoint (CVE-2023-29357) в активной эксплуатации; конкурс: на что заменить Sharepoint?
32:15 Cisco исправили критичную Arbitrary File Upload / RCE уязвимость в Unity Connection (CVE-2024-20272); конкурс: на что заменить CUC?
37:45 Атаки на Ivanti Connect Secure / lvanti Policy Secure с использованием 0Day RCE уязвимости (CVE-2023-46805, CVE-2024-21887)
41:06 Курьёзная критичная уязвимость в GitLab - восстановление пароля от аккаунта на левый email (CVE-2023-7028); конкурс стихов 😅
44:10 ИС Антифишинг от Минцифры
45:38 Всемирный совет церквей (WCC) был атакован вымогателями
48:50 МВД России предупреждает о новых способах мошенничества
50:24 Цукерберг берет деньги за отказ от сбора и использования личных данных под целевую рекламу
51:29 Почти 170 случаев утечек персональных данных россиян зафиксированы в 2023 году
54:41 Прощание от Mr.X про Оземпик
Детект типа уязвимости по CWE в Vulristics
Детект типа уязвимости по CWE в Vulristics. Теперь Vulristics может детектировать тип уязвимости не только по ключевым словам (выражениям), но и по CWE идентификаторам из NVD. Для каждого типа уязвимости в Vulristics можно указать набор соответствующих CWE идентификаторов. Некоторые CWE идентификаторы я уже таким образом смапил на типы уязвимостей Vulristics. Но, разумеется, не все. Всего CWE идентификаторов больше 600! Буду добавлять их по мере необходимости.
Кроме того, я сделал следующие изменения в детектах типов уязвимостей в Vulristics:
🔹 Добавил новый тип уязвимости Incorrect Calculation для массовых некритичных уязвимостей, которые не связаны с памятью (и поэтому не попадают в Memory Corruption). Например, "Divide By Zero" или "Integer Overflow". Фактически такие уязвимости являются просто багами, т.к. из описания непонятно как злоумышленник может их эксплуатировать. Если они приводят к падению приложения или к RCE, то почему бы про это не написать? А если не приводят, то в чём тогда беда? Как по мне, лучше бы для таких проблем вообще не заводили CVE. Но по факту их заводят. И особенно часто для Linux. Поэтому и детектировать тип для таких "уязвимостей" приходится. Теперь они будут валиться в Incorrect Calculation с относительно невысокой критичностью (такой же как у Memory Corruption).
🔹 Меня начали подбешивать Path Traversal уязвимости, которые по факту дают злоумышленнику возможность читать и писать произвольные файлы. 🤷♂️ Поэтому для таких уязвимостей буду использовать типы Arbitrary File Reading (уже была) и Arbitrary File Writing (новая).
🔹 Подкрутил веса для типов уязвимостей. Логика такая: чем более конкретен тип и чем более понятно как этот тип уязвимости может использоваться злоумышленником, тем больше вес. Но вещь это, конечно, крайне субъективная и я её, скорее всего, буду подкручивать ещё много раз. В моменте выглядит так:
Remote Code Execution 1.0
Code Injection 0.97
XXE Injection 0.97
Command Injection 0.97
Authentication Bypass 0.95
Arbitrary File Writing 0.95
Security Feature Bypass 0.90
Elevation of Privilege 0.85
Information Disclosure 0.83
Arbitrary File Reading 0.83
Cross Site Scripting 0.8
Open Redirect 0.75
Path Traversal 0.7
Denial of Service 0.7
Memory Corruption 0.5
Incorrect Calculation 0.5
Spoofing 0.4
Tampering 0.3
Unknown Vulnerability Type 0
Сейчас кажется, что XSS и Open Redirect низковаты. Но, с другой стороны, они в большей степени на социалку завязаны, так что может и норм. 🤔 В любом случае, тип уязвимости хоть и влияет достаточно сильно на итоговую критичность, но в меньшей степени чем наличие эксплоита и признак эксплуатации вживую.
Кроме детектирования типа уязвимости по CWE, я также оптимизировал сочетание детектирования имени уязвимого продукта по CPE и по ключевым словам (выражениям). Если кратко, то сначала приоритет отдается имени продукта непосредственно заданному в источнике данных, затем имени продукта определенному эвристически из шаблонного описания (для Microsoft), затем имени продукта определенному по ключевым словам (выражениям), затем имени продукта определенному по идентификаторам CPE. В CPE-детектах отдаём наивысший приоритет первому идентификатору типа a (application), если его нет, то h (hardware), если и его нет, то о (operating system).
Для демонстрации я перегенерил последние Linux Patch Wednesday отчёты:
🗒 Ноябрьский LPW
🗒 Декабрьский LPW
Довёл их практически до идеального состояния. Название продукта и тип уязвимости НЕ детектируются только для заглушек "This candidate has been reserved…" и уязвимостей с таким странным описанием, что даже ручной их разбор весьма затруднен.
В общем, праздничные дни прошли весьма плодотворно, доволен. 😇