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

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

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

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Captcha
captcha
Reload