Хабр, привет! Меня зовут Александр Леонов. Я ведущий эксперт PT Expert Security Center и среди прочего отвечаю в компании за ежемесячные подборки наиболее критичных (трендовых) уязвимостей, обзоры которых мы каждый месяц публикуем на Хабре.

С 2020 года я развиваю проект Vulristics. Изначально это был мой личный инструмент для анализа уязвимостей из ежемесячных обновлений Microsoft Patch Tuesday. Но постепенно я расширял его функциональность. Теперь утилите можно подавать на вход любой набор идентификаторов CVE и БДУ.

Главная задача Vulristics — оценивать и приоритизировать уязвимости. Для этого утилита анализирует несколько ключевых факторов: наличие признаков публичной эксплуатации, наличие публичного эксплойта, тип уязвимости, популярность ПО, а также оценки CVSS (Common Vulnerability Scoring System) и EPSS (Exploit Prediction Scoring System).

В этой статье — история создания Vulristics и рассказ о том, как этот инструмент экономит часы ручной работы, помогая аналитику не утонуть в потоке уязвимостей.

Неважно, работаете ли вы как специалист по vulnerability management со стороны клиента или со стороны вендора: везде существует постоянная необходимость анализировать массивы уязвимостей, для того чтобы понимать, что они из себя представляют и насколько критичны. Это в итоге и подтолкнуло меня к разработке собственного инструмента. Исходный код проекта я сразу выложил в открытый доступ на GitHub, а процесс разработки освещал в своём Telegram‑канале «Управление уязвимостями и прочее» (кстати, у него есть лайв‑версия и английская версия).

Название Vulristics образовано от слов «vulnerability» и «heuristics». Для тех, кто не знает: эвристика — это метод анализа, основанный на косвенных признаках и практическом опыте, который позволяет оценивать угрозы даже при неполных данных. А данные об уязвимостях практически всегда неполные.

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

Сейчас проекту уже пять лет, а его история началась с необходимости анализировать уязвимости, для которых выходят патчи в рамках Microsoft Patch Tuesday. Во второй вторник каждого месяца Microsoft публикует отчёт об исправленных уязвимостях; сейчас их там каждый раз стабильно больше сотни. Многие VM‑вендоры сразу после выхода списка уязвимостей начинают их детальный разбор, чтобы быстро выпускать собственные отчёты и выделять наиболее критические угрозы.

Мне же хотелось проводить такой анализ независимо. Но вручную каждый раз обрабатывать эти списки уязвимостей крайне трудоёмко. Тогда у меня возник закономерный вопрос: как автоматизировать этот процесс? Очень хотелось сделать так, чтобы всё работало практически само, и в итоге мне удалось реализовать эту идею.

Теперь для анализа достаточно указать год и месяц — и то, что нам нужна информация по Microsoft Patch Tuesday.

И через несколько минут вы получите готовый отчёт.

Разбор отчёта Vulristics

Давайте пройдёмся по отчёту, показанному выше, потому что он достаточно типовой не только для Microsoft Patch Tuesday, но и для других наборов уязвимостей.

• Название и статистика. Для начала там есть название профиля (например, «Microsoft Patch Tuesday за апрель»). Видим статистику по уязвимостям: справа — по CVSS, слева — по Vulristics Vulnerability Score (собственный алгоритм приоритизации). Видим, что алгоритм Vulristics даёт больше разнообразия: есть не только уровни Critical, High, Medium и Low, но еще и Urgent (срочный). Также алгоритм Vulristics предоставляет больший разброс значений по сравнению с CVSS.

• Статистика по продуктам. Для каждой уязвимости детектируется, в каком продукте она находится. Для продукта есть параметр prevalence, который отражает, насколько этот продукт распространён. Это довольно субъективная штука. Если вы рассматриваете уязвимости в вашей конкретной инфраструктуре, то общая распространённость уязвимого продукта вам не должна быть важна — главное, что он есть в вашей конкретной инфраструктуре. Но если мы анализируем уязвимости в целом, как в случае с Patch Tuesday, то нам важно, что какие‑то уязвимости касаются суперраспространённых компонентов, например ядра Windows. А какие‑то уязвимости касаются софта Microsoft, который может быть достаточно редким.

• Типы уязвимостей. Для каждой уязвимости детектируется её тип (не CWE, а именно тип уязвимости, связанный с эксплуатацией). Мы видим, что у каждого типа своя критичность. Например, для Remote Code Execution критичность будет больше, чем для Spoofing. Также видим статистику по уязвимостям, попавшим в отчёт, с соответствующими типами.

• Комментарии к уязвимостям. Это интересная фишка, которую я не встречал у подобных утилит. Комментарии берутся из блогов уважаемых западных VM‑вендоров (например, Qualys, Tenable, Rapid7).

Для некоторых источников комментарии к уязвимостям Microsoft Patch Tuesday находятся автоматически в корпоративных блогах по году и месяцу. Если этот механизм по каким‑то причинам не работает (например, изменился движок корпоративного блога и поэтому автоматический поиск перестал работать), можно помочь инструменту и задать URL отчёта вручную.

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

Как выглядит карточка конкретной уязвимости?

На карточке выше мы видим:

• тип уязвимости,

• уязвимый продукт,

• идентификатор уязвимости (CVE),

• критичность уязвимости, выраженную словами и цифрой,

• описание уязвимости,

• ключевые слова, по которым определился тип уязвимости и уязвимый продукт.

В таблице видим критерии, влияющие на критичность:

• Признак эксплуатации вживую. Берётся из нескольких источников (например, AttackerKB и CISA KEV).

• Признак наличия публичного эксплойта. Может подгрузиться из Vulners.com, NVD и других источников.

• Критичность уязвимости. В нашем примере Security Feature Bypass и она оценена в 0,9.

• Популярность продукта (prevalence). У нас Chromium и оценка 0,8.

• CVSS и EPSS. CVSS — всем известная метрика оценка критичности, которая получается путём заполнения опросника. EPSS (Exploit Prediction Scoring System) описывает вероятность появления эксплойта в ближайшие 30 дней.

Каждый из компонентов берётся со своим весом. Веса для эксплуатации вживую и наличия эксплойта — наибольшие, а для CVSS и EPSS — самые маленькие.

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

Комментариев может быть много.

Например, для одной уязвимости компания Tenable пишет, что она эксплуатировалась в malware PipeMagic, а ZDI пишет про то, с какими уязвимостями она может сочетаться. Я не учитываю комментарии при расчёте критичности, но они подсвечивают уязвимости, на которые стоит обратить внимание.

Также в комментариях отмечаются уязвимости, для которых патчи появились не в день Patch Tuesday (второй вторник каждого месяца), а между двумя Patch Tuesday. Это позволяет сформировать более расширенный отчёт, включив туда, например, уязвимости браузера Microsoft Edge.

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

Далее в отчёте идет наглядное деление на группы, которые позволяют сразу увидеть, сколько у нас вообще уязвимостей, например, с признаком эксплуатации вживую. В рассматриваемом выпуске Microsoft Patch Tuesday их было три. Они сгруппированы сначала по типу уязвимости, а затем по уязвимым продуктам.

Следующая группа — это уязвимости с публичным эксплойтом. У них нет признака эксплуатации вживую, но зато есть работающий публичный эксплойт. Таких уязвимостей было шесть.

Ну а дальше идут все остальные уязвимости, на которые, возможно, стоит обращать внимание в меньшей степени.

Автоматически сгенерированные отчёты значительно упрощают работу аналитику уязвимостей. В частности, мне такие отчёт помогают быстро выпускать посты с описанием Microsoft Patch Tuesday для CVE‑уязвимостей в Telegram‑канал.

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

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

Можно подать на вход список CVE (простой текст, разделённый переносами строк) и список комментариев (например, на каких хостах уязвимости обнаружены). И так же получить отчёт.

Можно проверить и одну конкретную уязвимость. Я написал небольшой shell‑скрипт для этого.

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

Отчёт для одной уязвимости выглядит похоже.

Мне это нужно, когда я делаю обзоры конкретных трендовых уязвимостей для Telegram‑канала.

Работа с JSON

Чтобы автоматизировать работу, можно подавать данные не списками, а JSON‑файлами.

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

Linux Patch Wednesday

Что это такое? Это ещё один мой проект. Мы знаем день, когда нужно посмотреть новые уязвимости Microsoft, это второй вторник месяца, Patch Tuesday. Но аналогичного единого дня для уязвимостей Linux нет. Линуксовый мир очень фрагментирован: есть ядро, множество проектов для системного и прикладного софта, множество дистрибутивов. Но ничто не мешает посмотреть, какие уязвимости исправлялись за последний месяц вендорами Linux‑дистрибутивов, и собрать их в списки Linux Patch Wednesday, выходящие в третью среду каждого месяца.

Я формирую списки на основе OVAL‑контента для разнообразных дистрибутивов (Ubuntu, Debian, RPM‑based, отечественных дистрибутивов). Для тех вендоров, у кого нет OVAL‑контента, я беру бюллетени безопасности или листы рассылки. И тоже выпускаю обзоры уязвимостей в Telegram‑канале.

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

Какие источники данных использует Vulristics?

• Microsoft. Полезное описание, CVE, CVSS‑вектор. Есть Temporal Score, но он не обновляется. Я использую API без ключа.

• NVD. Описание, ссылки (иногда на эксплойты), CWE, CPE. Работать лучше с API‑ключом, чтобы не превысить лимиты.

• EPSS. Удобный и быстрый API, который даёт вероятность появления эксплойта за 30 дней. Качество не всегда высокое, но API работает без аутентификации.

• БДУ ФСТЭК. Пожалуй, самый недооцененный источник. Есть описания уязвимостей и продуктов, однако также можно найти признаки эксплуатации вживую и данные о наличии публичного эксплойта. Я выкачиваю и парсю XML‑выгрузку целиком: это позволяет быстро сформировать данные по всем BDU‑уязвимостям.

• Rapid7 AttackerKB. Платформа экспертных оценок, где специалисты делятся подробными данными об эксплуатации уязвимостей вживую.

• Vulners.com. Коммерческая база. Наиболее ценное — ссылки на эксплойты с GitHub и других паков. Бесплатно — только 10 запросов, но исследователи могут получить бесплатный неограниченный ключ.

• Custom Data Source. Это JSON‑файлы, где можно вручную задать любые параметры для уязвимости. Полезно, если есть свой набор данных.

Каждый из этих источников можно отключать — тогда какие‑то данные не будут использоваться, но это ничего не поломает. В настройках можно также прописать SOCKS‑прокси для обхода блокировок (например, для доступа к комментариям с сайта Tenable).

Как же в Vulristics детектируется уязвимый продукт и тип уязвимости?

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

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

А если софт другой, то может возникнуть следующая ситуация. Допустим, есть уязвимость для Erlang/OTP. И для этой CVE в NVD нет CPE. Все мы понимаем, что у NVD сейчас не лучшие времена, данные появляются с задержкой. Но из‑за этого уязвимый продукт не детектируется, и мы не учитываем распространённость этого продукта при расчёте итоговой эксплуатабельности. Выглядит это некрасиво, и приоритет считается не совсем правильно.

А как добавить поддержку этого софта? Очень просто. Заходим в файл product.json (это такой JSON‑файлик, где написаны правила детектирования) и добавляем туда новый софт Erlang/OTP.

Имя софта будет использоваться как ключевое слово при детекте. Можно добавить дополнительные ключевые слова, описание этого софта, его prevalence (то есть распространённость), вендора и ещё много необязательных кастомных полей.

Добавляем, перезапускаем утилиту. Всё, оно работает. Продукт определился, и теперь в отчёте стало красиво!

Рассмотрим ещё одно правило детектирования продукта на примере Python.

Обратим внимание на параметр detection_priority — приоритет детектирования. Он нужен, потому что если Vulristics будет искать в описании уязвимости по слову «Python», то он может ошибочно отнести, например, уязвимости модуля requests к уязвимостям интерпретатора Python.

Чтобы этого избежать, мы можем понизить приоритет правила детектирования для Python. Тогда сначала отработают более специфичные правила для модулей, которые ищут, например, «Python Requests», и только если они не сработают, система вернётся к общему правилу Python. Так уязвимости в модулях будут определяться правильно.

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

Детектирование типа уязвимости

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

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

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

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

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

Итак, мы подходим к завершению. HTML‑отчёт с таблицами удобен для визуального просмотра, когда нужно анализировать данные вручную. Но если стоит задача интеграции с другими системами, HTML уже не помощник.

Для таких случаев можно легко выгружать результаты в формате JSON. Достаточно указать, что результирующим форматом должен быть JSON (или, как вариант, HTML и JSON одновременно), и показать, куда сохранить файл. На выходе мы получаем все результаты в виде структурированного JSON.

Это открывает возможности для автоматизации работы. Можно выстраивать пайплайны и интегрировать Vulristics в любые автоматизированные процессы, требующие анализа уязвимостей.

Рассмотрим пример. Допустим, у нас есть сканер, который детектирует уязвимости на хостах. В комментариях к списку CVE мы можем указать, на каких именно хостах была обнаружена каждая уязвимость. Затем мы формируем JSON‑файл, где прописываем сам список уязвимостей, комментарии, а также желаемое имя и префикс для результирующего файла.

Этот файл подаётся на вход Vulristics. В параметрах указываем, что хотим получить результат в JSON. Утилита быстро пробегается по всем источникам данных, обрабатывает их и формирует отчёт.

Структура JSON‑отчёта состоит из двух основных частей. Первая — это разбивка по продуктам: для каждого продукта перечислены все CVE, которые его касаются, а также все связанные параметры (те же, что отображаются в HTML‑отчёте).

Вторая часть — детальная информация по каждой уязвимости. Для каждой CVE прописывается, к какому продукту и типу уязвимости она относится. Все компоненты, влияющие на эксплуатабельность, учитываются с теми же весами, что и в HTML‑отчёте. Здесь же присутствует итоговый показатель критичности уязвимости — Vulristics Vulnerability Score (VVS).

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

Заключение

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

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

Александр Леонов

Ведущий эксперт PT Expert Security Center