Как я создал инструмент анализа уязвимостей, которым пользуюсь каждый день

С 2020 г. я развиваю собственный проект Vulristics (от слов «Vulnerability» и «Heuristics»). Главная задача утилиты — оценка и приоритизация уязвимостей. Она принимает на вход любой набор идентификаторов CVE и БДУ и генерирует по ним аналитические отчеты — тем самым экономит кучу времени и помогает не тонуть в потоке уязвимостей.

С чего все началось: Microsoft Patch Tuesday 

Все мы знаем, что каждый второй вторник месяца Microsoft публикует отчет об исправленных уязвимостях. Сразу после этого многие VM-вендоры начинают его детальный разбор, чтобы быстро выпустить собственные отчеты и выделить наиболее опасные угрозы.

Это, конечно, хорошо, но мне хотелось проводить собственный, независимый анализ. Обрабатывать списки уязвимостей вручную — задача крайне трудоемкая, поэтому возник закономерный вопрос: как автоматизировать процесс, чтобы все происходило практически без моего участия? Ответом на него стала утилита Vulristics. Я освещал процесс разработки в своем Telegram-канале и сразу выложил исходный код проекта на GitHub. Для анализа Microsoft Patch Tuesday достаточно указать год и месяц, и через несколько минут вы получите готовый отчет.

Разбираем отчет

Сразу за названием профиля идет статистика по уязвимостям (см. рис. 3). Справа — распределение по CVSS, слева — по Vulristics Vulnerability Score (собственный алгоритм приоритизации). Отмечу, что алгоритм Vulristics дает больше разнообразия: помимо Critical, High, Medium и Low, в нем есть категория Urgent. Кроме того, разброс значений здесь заметно шире, чем в CVSS. 

Для каждой уязвимости утилита детектирует связанный с ней софт. Параметр prevalence показывает, насколько широко распространен тот или иной продукт, но это довольно субъективная штука. Если вы анализируете уязвимости в своей инфраструктуре, популярность софта роли не сыграет — главное, что он есть у вас. Но в случае с Microsoft Patch Tuesday она все-таки важна, ведь одни уязвимости касаются ядра Windows, а другие — довольно редкого софта.

Также утилита определяет тип уязвимости. У каждого типа своя критичность: например, для Remote Code Execution показатель будет выше, чем для Spoofing. Кроме того, Vulristics показывает статистику/распределение по всем типам уязвимостей в отчете.

Наконец, комментарии — интересная фишка, которую я не встречал в других подобных утилитах. Ссылки на комментарии для Microsoft Patch Tuesday автоматически подтягиваются из блогов некоторых западных VM-вендоров (в том числе Qualys, Tenable и Rapid7). Если механизм по каким-то причинам не работает (например, поменяли движок блога), можно задать URL отчета вручную.

Карточка уязвимости

В карточке уязвимости отражены: ее тип, связанный продукт, идентификатор CVE, уровень критичности, описание и ключевые слова (по которым определился тип уязвимости и уязвимый софт). Кроме того, в таблице собраны критерии, влияющие на уровень критичности уязвимости:

• Признаки эксплуатации in the wild. Берутся из нескольких источников, например AttackerKB и CISA KEV.
• Признаки наличия публичного эксплойта. Могут подгружаться из Vulners.com, NVD и других источников.
• Критичность уязвимости. В примере на рис. 8 Security Feature Bypass оценена в 0,9.
• Популярность продукта (prevalence). У Chromium оценка 0,8.
• CVSS и EPSS (Exploit Prediction Scoring System описывает вероятность появления эксплойта в ближайшие 30 дней).

Каждый критерий обладает своим весом. Самые «тяжелые» — признаки эксплуатации вживую и наличие эксплойта, а самые «легкие» — CVSS и EPSS.

Следом идут комментарии, и их может быть много… В примере на рис. 9 Tenable указывает, что уязвимость эксплуатировалась в malware «PipeMagic», а ZDI описывает ее возможные сочетания с другими уязвимостями. Я не учитываю комментарии при расчете критичности, но они подсвечивают важные моменты, на которые стоит обратить внимание.

Также Vulristics может учитывать уязвимости, которые вышли в промежутке между двумя Patch Tuesday и формировать расширенные отчеты. Такие «дополнительные» уязвимости отмечаются в отчете комментарием MS PT Extended (см. рис. 10).

Группы уязвимостей

После карточек уязвимостей идет наглядное разделение на группы: уязвимости с признаками эксплуатации in the wild, уязвимости с публичными эксплойтами и все остальные (см. рис. 11–12). 

Анализ произвольных уязвимостей

С Microsoft Patch Tuesday разобрались. А что, если нам нужно проанализировать рандомный набор уязвимостей? Например, собранный в процессе сканирования инфраструктуры или же очередную подборку из рассылки регулятора.

Для этого достаточно подать на вход утилиты список CVE/BDU (простой текст, разделенный переносами строк) и комментарии (см. рис. 14). Можно проверить и всего одну уязвимость: в примере на рис. 15 я написал для этого небольшой shell-скрипт.

Vulristics проходит по источникам, делает запрос для каждой уязвимости, вытаскивает данные, приводит к нормализованному виду и обрабатывает. Пример вывода скрипта для анализа одной уязвимости представлен на рис. 16.

Отмечу, что для автоматизации процесса можно подавать данные не списками, а в виде JSON-файлов. В них можно задать и список уязвимостей, и комментарии, и настройки результирующего файла. К примеру, я использую этот метод в своем проекте Linux Patch Wednesday.

Подробнее о том, как работает Vulristics

Источники данных

Vulristics работает со следующими источниками:

• Microsoft. Есть полезное описание, CVE, CVSS-вектор, а также Temporal Score, но он не обновляется. Я использую API без ключа.
• NVD. Описание, ссылки (иногда на эксплойты), CWE, CPE. Работать лучше с API-ключом, чтобы не превысить лимиты.
• EPSS. Удобный и быстрый API, который дает вероятность появления эксплойта в течение 30 дней. Качество не всегда высокое, но API работает без аутентификации.
• БДУ ФСТЭК. Пожалуй, самый недооцененный источник. В нем есть описания самих уязвимостей и уязвимых продуктов, а также признаки эксплуатации вживую и данные о наличии публичных эксплойтов. Я выкачиваю и парсю файл XML-выгрузки целиком.
• Rapid7 AttackerKB. Экспертная платформа, где делятся подробными данными об эксплуатации уязвимостей вживую.
• Vulners.com. Самое ценное здесь — ссылки на эксплойты с GitHub и других паков. Это коммерческая база, но исследователи могут получить бесплатный неограниченный ключ.
• Custom. JSON-файлы, где можно вручную задать любые параметры уязвимостей. Полезно, если есть свой набор данных.

Любой источник можно отключить, не нарушая работу утилиты. Также можно прописать в настройках SOCKS-прокси для обхода блокировок: например, чтобы получить доступ к комментариям из блога Tenable.

Детектирование уязвимых продуктов

С софтом Microsoft все работает гладко, так как Microsoft генерирует описания уязвимостей по шаблону, который включает тип уязвимости и соответствующий продукт. В остальных случаях возможны нюансы. Допустим, у нас есть уязвимость в Erlang/OTP, для которой нет CPE в NVD. Уязвимый продукт не продетектируется, и мы не сможем учесть его популярность при расчете критичности.

Как в этом случае добавить поддержку нового софта? Все просто: заходим в product.json (там прописаны правила детектирования) и добавляем туда Erlang/OTP. Имя софта будет использоваться как ключевое слово при детекте. При необходимости можно также добавить дополнительные ключевые слова, описание софта, его prevalence, указать вендора и т. д.

Рассмотрим еще одно правило детектирования уязвимого продукта на примере Python (см. рис. 26).

Обратите внимание на параметр detection_priority (приоритет детектирования). Он нужен, чтобы избежать ошибок: к примеру, при поиске по ключевому слову «Python» Vulristics может отнести уязвимости модуля Requests к уязвимостям интерпретатора. Для решения проблемы можно понизить приоритет правила детектирования. Тогда сначала отработают более специфичные правила для модулей (например, которые ищут «Python Requests»), а только после этого утилита вернется к общему правилу для продукта. Так уязвимости в модулях будут определяться правильно.

Еще один полезный параметр —  short_cpe — обрезанные CPE-идентификаторы. Это запасной вариант: если не сработал эвристический анализ и детект по ключевым словам, Vulristics пытается определить продукт по CPE из National Vulnerability Database. При его наличии утилита точно поймет, что уязвимость относится к Python.

Определение типов уязвимостей 

Типы уязвимостей определяются схожим образом — по ключевым словам. Для большинства типов есть стандартные формулировки. Например, для Information Disclosure это могут быть «information exposure» или «sensitive data».

Также можно задать привязку к CWE-идентификаторам. Если CWE указан в NVD или БДУ, Vulristics использует его для определения типа уязвимости. 

Отметим, что у каждого типа есть базовая критичность. Скажем, Elevation of Privilege по умолчанию будет критичнее, чем Information Disclosure.

Процесс улучшения детектов довольно прост. Если система ошиблась, нужно найти в описании уязвимости характерное словосочетание и добавить в список ключевых слов в конфиге. Чем больше правил, тем лучше работает утилита.

Интеграция и автоматизация

HTML-отчет с таблицами удобен, когда данные нужно анализировать вручную. Для интеграции с другими системами можно выгружать результаты в виде структурированного JSON-файла — нужно просто указать это в конфиге. 

Таким образом можно выстраивать пайплайны и интегрировать Vulristics в любые автоматизированные процессы, требующие анализа уязвимостей. Предположим, у нас есть сканер, который детектирует уязвимости на хостах. Формируем JSON, который будем подавать на вход Vulristics. Прописываем в нем список уязвимостей, комментарии к ним (там можно указать, где именно была обнаружена каждая уязвимость), а также имя и префикс результирующего файла. 

JSON-отчет состоит из двух частей. Первая — это разбивка по продуктам: для каждого из них перечислены CVE и связанные параметры (те же, что в HTML-отчете). Вторая часть содержит детальную информацию по уязвимостям. Все критерии, влияющие на эксплуатабельность, учитываются с теми же весами, что и в HTML-отчете. Здесь же указан итоговый показатель критичности — Vulristics Vulnerability Score (VVS), который можно использовать в системе управления уязвимостями для более корректной и контролируемой приоритизации. Также во второй части отчета содержатся признаки эксплуатации in the wild, данные о наличии эксплойтов и комментарии. 

***

Развитие Vulristics продолжается. В ближайших планах — расширение числа источников, а также внедрение ИИ для определения уязвимых продуктов и типов уязвимостей. 

Исходный код утилиты открыт по лицензии MIT — ее можно использовать в любых проектах! Буду рад узнать о ваших кейсах ;)