Баги, которые от нас скрывают. Выбираем лучший сайт для поиска уязвимостей

Я в основном занима­юсь встра­иваемы­ми самос­борны­ми опе­раци­онны­ми сис­темами на осно­ве Linux. Поиск уяз­вимос­тей в ком­понен­тах этих ОС — нет­риви­аль­ная задача. В сво­ем док­ладе на PHDays 10 я говорил о том, что приш­лось соз­дать собс­твен­ное средс­тво для поис­ка уяз­вимос­тей, потому что каж­дое из име­ющих­ся бес­плат­ных решений меня чем‑нибудь да не устра­ивает. Но с тех пор прош­ло мно­го вре­мени, и, ког­да готовил док­лад, я решил про­верить, как обсто­ят дела сей­час. Так и родилась эта статья.

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

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

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

Штатный поисковик NVD

По­иск на сай­те NVD кажет­ся хорошим вари­антом: кто луч­ше зна­ет, как искать по базе NVD, если не ее сос­тавите­ли? Одна­ко сто­ит поис­кать уяз­вимос­ти в ядре Linux, и ока­зыва­ется, что не все так радуж­но.

До­пус­тим, мы исполь­зуем ста­рое доб­рое ядро 4.14, не забыва­ем и пат­чим его до пос­ледней на сегод­ня (11 апре­ля) вер­сии 4.14.230. Исполь­зуем рас­ширен­ный вари­ант поис­ка (Search Type: Advanced). Про­верить эту вер­сию в поис­ковике не вый­дет. Даже вер­сия 4.14.200 нез­накома NVD, а пос­ледняя из дос­тупных — 4.14.194 (21 августа 2020 года). NVD об этом чес­тно сооб­щает в при­меча­нии.

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

Не страш­но, пусть у нас будет вер­сия 4.14.194.

По­иско­вик выдал 460 резуль­татов, доволь­но хорошо для такого боль­шого про­дук­та.

Но поп­робу­ем обой­ти поиск толь­ко по извес­тным CPE, ведь NVD пре­дос­тавля­ет еще REST API (смот­ри до­кумен­тацию в PDF).

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

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

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

В ито­ге получа­ем доволь­но стран­ный резуль­тат — 1315 уяз­вимос­тей. Поч­ти на тысячу боль­ше!

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

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

Веб‑вер­сия не выводит уяз­вимос­ти, где иско­мый про­дукт помечен как Running on/with, то есть он прос­то работа­ет сов­мес­тно с уяз­вимым. Веб‑вер­сия выда­ет нам толь­ко уяз­вимос­ти ядра Linux, а REST API — еще и уяз­вимос­ти все­го ПО, что работа­ет на Linux. Здесь, пожалуй, пре­иму­щес­тво веб‑поис­ка налицо. Давай даль­ше рас­смат­ривать резуль­таты веб‑поис­ка NVD как некий эта­лон и пос­мотрим, что покажут дру­гие два сай­та.

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 Details. При­чем на сай­те 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 как раз и озна­чает, что уяз­вимы все пре­дыду­щие вер­сии, но почему‑то при перехо­де с вер­сии 1.2 на 2.0 этот флаг потерял­ся, и в опи­сании вер­сии 2.0 уже невоз­можно было раз­личить, где ука­заны отдель­ные вер­сии, а где их диапа­зон. NIST обновлял обе вер­сии опи­сания, но кто же захочет поль­зовать­ся вер­сией 1.2, ког­да есть 2.0? Поэто­му здесь CVE Details винить слож­но.

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

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