Лучшие сайты для поиска уязвимостей

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

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

Какие есть варианты по поиску уязви­мостей для этих компонентов? В этом случае мы будем рассматривать только бесплатные варианты — Бюджет, как всегда, ограничен:

• штат­ный поис­ковик NVD;
• CVE Details — популя­рен чуть ли не боль­ше самого CVE;
• Vulners — спе­циали­зиро­ван­ный поис­ковик по уяз­вимос­тям, раз­работ­чики которо­го заяв­ляют, что неп­рерыв­но добав­ляют новые источни­ки и даже исполь­зуют ИИ для опре­деле­ния кри­тич­ности уяз­вимос­ти.

CVE Details

Это популярный сайт, статистику которого можно увидеть во многих статьях и отчетах. Но можно ли его использовать в качестве средства поиска уязвимостей? Конечно! И сначала я был в восторге от умной стороны, которая оставила менее сотни из полутора тысяч CVE ядра Linux. Только позже выяснилось, что здесь не все так просто.

Про­буем искать уяз­вимос­ти, исполь­зуем поиск по вер­сии и вво­дим наз­вание ядра сог­ласно CPE (linux:linux_kernel) и его вер­сию.

Результат —No matches. Насколько я понимаю, сайт нашей версии тоже не знает. Используя метод последовательного перехода на более раннюю версию, нам удалось установить, что самая старая поддерживаемая версия интересующей нас ветки — 4.14.141. Смотрим на результат: уязвимостей чуть более 50.

Это гораз­до мень­ше, чем выда­ет NVD (470 для вер­сии 4.14.141). Срав­ним переч­ни най­ден­ных уяз­вимос­тей. Раз­личия в резуль­татах поис­ка про­демонс­три­рую на двух при­мерах: CVE-2019-17351 и CVE-2019-17133.

По какой-то причине уязвимости с одинаковым описанием обрабатываются по-разному. Веб-поиск NVD находит обе уязвимости, в то время как CVE Details находит только CVE-2019-17351. CVE-2019-17133 не указан в результатах поиска, а версия 4.14.141 не указана как уязвимая версия в описании в сведениях о CVE. Более того, на странице NVD уязвимые версии этих двух CVE отображаются одинаково корректно.

Причину такого поведения CVE Details можно найти на странице, описывающей, как работает сайт. Оказывается, сайт получает данные из RSS-канала об изменениях в XML-описании уязвимостей. NVD официально прекратила обновление XML-описаний 9 октября 2019 года и перешла исключительно на JSON. Но упущение уязвимостей с этим не связано. Давайте посмотрим поглубже и найдем в архивах Интернета файл nvdcve-2.0-2019.xml — это как раз описание всех CVE 2019 года в формате XML. Кстати, поле pub_date содержит значение 2019-10-15T03: 00: 00, то есть фактически NIST продолжал обновлять XML некоторое время после крайнего срока.

Так вот, зна­чение полей vulnerable-software-list порази­тель­ным обра­зом пол­ностью соот­ветс­тву­ет тому, что мы видим на cvedetail.com.

Дело в том, что разработчики NVD раньше экспериментировали и для некоторых записей пытались указать все уязвимые версии, а для некоторых просто указали диапазон версий (последняя уязвимая версия). CVE Details просто не знает, как анализировать эти диапазоны версий.

Для CVE-2019-17133 диапазон версий действительно указан изначально. Если вы загрузите другой файл — nvdcve-2019.xml (то же описание, но с использованием формата поля версии 1.2, а не 2.0), то вы увидите там следующее.

Флаг prev просто означает, что все предыдущие версии уязвимы, но по какой-то причине этот флаг был утерян при переходе с v1.2 на v2.0, а в v2.0 больше нельзя было различать, где какие ревизии были указаны, а где их объем есть. NIST обновил обе версии описания, но кто хочет использовать версию 1.2, когда это 2.0? Так что здесь сложно винить детали CVE.

Пе­реход NVD на JSON пло­хо ска­зал­ся на CVE Details, ста­тис­тика уяз­вимос­тей на сай­те крас­норечи­ва.

В 2019 году в деталях CVE отсутствовало 5000 уязвимостей и не было ни одной уязвимости за период 2020-2021 годов, сайт просто перестал обновляться. Но у него все еще есть поклонники, и в 2020 году некоторые из моих друзей продолжили им пользоваться, стараясь не замечать всех накопившихся недостатков.

Кста­ти, уди­витель­но, но как толь­ко я уже было закон­чил работать над этой стать­ей, сайт CVE Details впер­вые за пос­ледние пол­тора года обно­вил­ся!

Но, к сожале­нию, с этим обновле­нием была уда­лена даже име­ющаяся под­дер­жка вер­сий. И теперь, нап­ример, и CVE-2019-17133, и CVE-2019-17351 выг­лядят вот так.

Бо­юсь, теперь поль­зовать­ся CVE Details для сколь­ко‑нибудь эффектив­ного поис­ка по вер­сиям будет сов­сем невоз­можно.

Поисковик NVD

Веб-сайт NVD – хороший вариант для поиска в базе данных NVD. Кто лучше знает, как искать в базе информации NVD, если не ее составитель? А вот найти уязвимости в ядре Linux, как выясняется, не так просто.

Допустим, мы используем старое доброе ядро ​​4.14, не забудьте и пропатчите его до последней версии 4.14.230 на сегодня (11 апреля). Мы используем опцию расширенного поиска (Тип поиска: Расширенный). Вы не сможете проверить эту версию в поисковой системе. Даже версия 4.14.200 незнакома NVD, а последняя доступная — 4.14.194 (21 августа 2020 г.). NVD честно сообщает об этом в заметке.

Дело в том, что веб-интерфейс поисковой системы позволяет использовать только версии продукта из словаря CPE (Common Platform Enumeration). Если проигнорировать это предупреждение и ввести нужную версию 4.14.230, то, нажав кнопку поиска, мы получим более четырех тысяч уязвимостей всех версий ядра Linux.

Поисковая система выдала 460 результатов, что очень хорошо для такого большого продукта.
Но давайте попробуем пропустить поиск только известных CPE, потому что NVD также предоставляет REST API (см. Документацию в формате PDF).

Фор­миру­ем сле­дующий поис­ковый зап­рос:

https://services.nvd.nist.gov/rest/json/cves/1.0?cpeMatchString=cpe:2.3:o:linux:linux_kernel:4.14.194.&startIndex=0

Ре­зуль­таты выда­ются в виде фай­ла JSON, по умол­чанию по 20 штук на стра­нице, если не хочет­ся все это объ­еди­нять, то мож­но дописать к поис­ковому зап­росу такую стро­ку:

&resultsPerPage=1400

Но здесь нужно рассчитывать на удачу, сервер NVD для защиты от DDoS иногда не отвечает на такие жадные запросы. По большей части мне повезло, и мне удалось получить до 2000 результатов на странице.

А вот в итоге, мы получаем странный результат – 1315 уязвимостей. 

Ре­зуль­таты поис­ка через REST API

Попробуем выяснить. Сохраняем все страницы с результатом поиска. Затем мы ищем все идентификаторы CVE в HTML и JSON прямо в Notepad ++, сортируем и сравниваем их.

Даже если выборочно проверять уязви­мость, которой нет в результатах веб-поиска, сразу видно ее характерный признак.

В веб-версии не отображаются уязвимости, в которых искомый продукт помечен как Running on/with, то есть просто работает вместе с уязвимым. Веб-версия дает нам только уязвимости ядра Linux, а REST API также дает нам уязвимости во всем программном обеспечении, работающем в Linux. Здесь, пожалуй, налицо преимущество веб-поиска. Давайте рассмотрим результаты веб-поиска NVD в качестве ориентира и посмотрим, что показывают два других сайта.

Vulners

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

Сейчас попробуем поизучать уязви­мость нашего подопытного ядра версий 4.14.194, оставив лишь записи NVD. Результат впечатляет: всего одна уяз­вимость!

 Постараюсь воспроизвести все то же самое, но через интерфейс Vulners API Pythон wrapper. В качестве примера возьмем скрипт для поиска по идентификатору CPE.

import vulners

Для получе­ния бес­плат­ного клю­ча нуж­но зарегис­три­ровать­ся на сай­те, и вот резуль­тат, но опять жидень­кий — все­го 55 уяз­вимос­тей.

Про­бовал искать и по‑дру­гому.

Но так еще хуже.

На мой взгляд — первый из вариантов поиска наиболее вероятен, он же и самый верный. Срав­ним с резуль­татами веб‑поис­ковика NVD.

Возь­мем, нап­ример, CVE-2018-7754 и CVE-2018-7755. Пер­вая — в обо­их спис­ках, вто­рая толь­ко в NVD. Срав­ним их меж­ду собой.

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

Но, чес­тно говоря, сущес­твен­ной раз­ницы меж­ду опи­сани­ями CVE-2018-7754 и CVE-2018-7755 не нашел (диапа­зоны уяз­вимых вер­сий есть и в добав­ленных полях affectedSoftware, и во взя­тых с NVD cpeConfiguration).

Итоги

Мы рассмотрели исследование уязвимостей NVD для дистрибутивов, где единственным сопровождающим, возможно, является вы, и где исследование уязвимостей еще не поставлено на поток, как в Red Hat или Ubuntu.

Основываясь на результатах сравнения, я должен сделать вывод, что на данный момент для разделенных дистрибутивов лучше использовать стандартный поиск NVD, но наилучшие результаты дает веб-версия.
И вы можете определить любую версию, даже ту, которой нет в CPE, прямо в строке URL, например, вот так (номер версии в конце):

А вот для широко применяемых дис­три­бутивов ОС, Vulsner будет лучшим вариантом.