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

После продолжительного перерыва выпустил англоязычную видяшку и блогопост

После продолжительного перерыва выпустил англоязычную видяшку и блогопост. Разбираю там то, что произошло за последние 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

16:14 About the results of 2023
18:45 What about 2024?

📘 Blogpost
🎞 VKVideo

Прожектор по ИБ, выпуск №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

Детект типа уязвимости по 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…" и уязвимостей с таким странным описанием, что даже ручной их разбор весьма затруднен.

В общем, праздничные дни прошли весьма плодотворно, доволен. 😇

NVD включили заднюю в вопросе отключения CVE-фидов

NVD включили заднюю в вопросе отключения CVE-фидов

NVD включили заднюю в вопросе отключения CVE-фидов. Раньше обещали отключить генерацию архивов, содержащих JSON-файлы со всеми CVE-шками, 15 декабря 2023. Теперь пишут, что отключать пока не будут и по сути признают то, что:

🔹 массовая выгрузка CVE-шек оказалась нужна множеству потребителей
🔹 актуальная версия API-шки эффективно делать это не позволяет

Будут улучшать возможности массовой выгрузки данных из NVD через API, а пока этого не сделают, оставят генерацию файликов с выгрузками как есть.

Ура-ура, маленькая победа здравого смысла! 🎉

Это внушает небольшую надежду на то, что активности по фактическому ограничению доступа к данным NVD были вызваны не сознательной политикой, а обычной глупостью.

Про определение имени уязвимого продукта по CPE в Vulristics

Про определение имени уязвимого продукта по CPE в Vulristics

Про определение имени уязвимого продукта по CPE в Vulristics. Для тех, кто не в курсе, моя утилита, кроме прочего, решает задачку получения для CVE-шки описательной строки "тип уязвимости - уязвимый продукт". В итоге пришёл к выводу, что хоть метод определения имени уязвимого продукта по CPE хорош своей скоростью и универсальностью, но в качестве основного он не годится.

Проблема не в самих CPE, а в том как их используют в NVD: иногда для CVE их слишком много, иногда их вообще нет, иногда они нерелевантные. Возьмём, для примера, Log4Shell (CVE-2021-44228). Согласитесь, что для этой уязвимости было бы неплохо в качестве уязвимого продукта получить Apache Log4j2 или хотя бы Apache Log4j. И он там даже есть в виде a:apache:log4j. Но в общем случае автоматически выделить именно этот CPE идентификатор среди десятков других, связанных с этой CVE, задача такая себе. 🤷‍♂️ Теоретически это можно было бы делать, если бы была какая-то иерархия CPE, анализируя которую можно было бы понять, что a:apache:log4j имеет больший приоритет, т.к. это уязвимая либа, которую использую другие уязвимые продукты. Но этого нет. Тот же официальный CPE dictionary это просто перечень CPE идентификаторов со ссылками на сайты вендоров и прочие сайты без какого-либо дополнительного полезного контекста.

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

А детект по CPE оставить на случай, когда анализ текстового описания ничего не дал и лучше попробовать показать хоть что-то, чем Unknown Product.

Прожектор по ИБ, выпуск №15 (09.12.2023): Нейролингвистические атаки на ИИ

Прожектор по ИБ, выпуск №15 (09.12.2023): Нейролингвистические атаки на ИИ

🔸 Александр Леонов, "Управление уязвимостями и прочее"
🔸 Лев Палей, "Вести из Палей"
🔸 Максим Хараск, "Global Digital Space"

00:00 Здороваемся и смотрим статистику по прошлому эпизоду
01:56 Про конференцию Код ИБ Итоги 2023
08:14 Фишинговая атака на админов WordPress и настоящая RCE
13:39 У NVD превратятся в тыкву фиды и API 1.0, что делать?
17:36 Нейролингвистические атаки на ИИ и автоматическая конвертация BASH в Python
26:00 Стратегия развития области связи
34:17 Премия Киберпросвет
38:59 Прощание от Mr.X

Фиды NVD и API v1.0 превратятся в тыкву через неделю

Фиды NVD и API v1.0 превратятся в тыкву через неделю

Фиды NVD и API v1.0 превратятся в тыкву через неделю.

"The NVD plans to retire the remaining legacy data feeds as well as all 1.0 APIs on December 15th."

Если ваша организация забирает уязвимости из NVD напрямую, скачивая архивчики с JSON или используя API v1.0, то всё это поломается с 15 декабря. Имеет смысл проверить и перейти на NVD API v2.0 (учитывайте rate limits) или другие источники данных по CVE.

Выкачивать данные по всем CVE разом было очень удобно. Можно такой экспериенс сохранить? Видятся опции:

🔹 Бесплатный неофициальный NVD CVE фид от немецкого института FKIE на GitHub. Всё как у NVD, обновления раз в 2 часа.

🔹 Бесплатный официальный CVE фид от Mitre на GitHub. Нет CPE (есть affected продукты в другом формате), CWE и CVSS вендорский и не везде.

🔹 Платная коллекция данных NVD от Vulners, обогащённая инфой по активной эксплуатации, эксплоитам, AI Score и т.д. Требуется платный API и расширенная подписка. Про работу с коллекциями у меня был давнишний пост.