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

https://t.me/hacker_frei

Виталий Меньшов

Содержание статьи

• Штатный поисковик NVD
• CVE Details
• Vulners
• Итоги

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

Я в основном занима­юсь встра­иваемы­ми самос­борны­ми опе­раци­онны­ми сис­темами на осно­ве 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).

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

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 уяз­вимос­тей. Поч­ти на тысячу боль­ше!

Поп­робу­ем разоб­рать­ся. Сох­раня­ем все стра­ницы с резуль­татом поис­ка. Затем пря­мо в 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 году некото­рые мои зна­комые про­дол­жали им поль­зовать­ся, ста­раясь не замечать всех накопив­шихся недос­татков.

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

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

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

VULNERS

Ду­маю, об этом поис­ковике уже слы­шал каж­дый, кто в теме. Мне самому он бли­зок из‑за откры­тос­ти, которую про­паган­диру­ют его авто­ры. В откры­том дос­тупе как отдель­ные средс­тва для поис­ка уяз­вимос­тей, так и сама база (прав­да, теперь толь­ко для иссле­дова­телей).

INFO

«Хакер» под­робно писал о Vulners дваж­ды: в стать­ях «Vulners — Гугл для хакера» и «Ищем экс­пло­иты из Python, ска­ним уяз­вимые сер­веры и авто­мати­зиру­ем пен­тест».

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

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

На­вер­ное, опять что‑то не так делаю. Поп­робую пов­торить все то же самое, но через Vulners API Python wrapper. Запус­тим скрипт для поис­ка по иден­тифика­тору CPE:

import vulners

import json

vulners_api = vulners.Vulners(api_key="Здесь_должен_быть_ключ")

cpe_results = vulners_api.cpeVulnerabilities("cpe:/o:linux:linux_kernel:4.14.194")

cpe_NVD_list = cpe_results.get('NVD')

print("cpe:/o:linux:linux_kernel:4.14.194")

print(json.dumps(cpe_NVD_list, indent=2, sort_keys=False))

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

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

Но так получа­лось еще хуже.

Ви­димо, пер­вый вари­ант поис­ка был самым вер­ным, срав­ним с резуль­татами веб‑поис­ковика NVD.

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

По пер­вому впе­чат­лению осо­бой раз­ницы не вид­но, linux_kernel есть и там и там.

Срав­нил еще опи­сания этих двух уяз­вимос­тей в JSON, есть воз­можность заг­рузить их на сай­те для выб­ранных уяз­вимос­тей (см. при­мер и рисунок ниже).

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

Поп­робую свя­зать­ся с раз­работ­чиками Vulners. Может, они что‑то под­ска­жут!

ИТОГИ

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

По резуль­татам срав­нения дол­жен сде­лать вывод, что на дан­ный момент луч­ше все­го для не «пакети­рован­ных» дис­три­бути­вов поль­зовать­ся штат­ным поис­ком NVD, но имен­но веб‑вер­сией, она выда­ет луч­шие резуль­таты.

А задавать любую вер­сию, даже ту, которой нет в CPE, мож­но непос­редс­твен­но в URL-стро­ке, нап­ример так (номер вер­сии — в самом кон­це):

https://nvd.nist.gov/vuln/search/results?form_type=Advanced&results_type=overview&search_type=all&cpe_vendor=cpe%3A%2F%3Alinux&cpe_product=cpe%3A%2F%3Alinux%3Alinux_kernel&cpe_version=cpe%3A%2F%3Alinux%3Alinux_kernel%3A4.14.999

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

Развитие событий

Вот что мне уда­лось узнать у раз­работ­чиков Vulners.

Стро­ка поис­ка на сай­те, как я и пред­положил в перепис­ке, поз­воля­ет находить толь­ко уяз­вимос­ти с точ­ным соот­ветс­тви­ем уяз­вимой и иско­мой вер­сии про­дук­та. Мож­но задавать шаб­лон иско­мых вер­сий (1.9*, [86 TO 86.4]). А для поис­ка тех записей NVD, где ука­зан диапа­зон уяз­вимых вер­сий, нуж­но исполь­зовать Python API.

Ал­горитм Python API дорабо­тали пос­ле моего репор­та, и сей­час поиск по CPE выда­ет 470 записей, а срав­нение резуль­татов с сай­том NVD прак­тичес­ки всег­да в поль­зу Vulners.

Те­перь могу сме­ло рекомен­довать Vulners.com для поис­ка по NVD.

На самом деле кое‑какие пре­тен­зии к поис­ковикам у меня еще оста­лись. Нап­ример, они не най­дут уяз­вимость CVE-2020-16119, для которой нет пат­ча в upstream ядра. Поэто­му, воз­можно, мы еще про­дол­жим этот раз­говор.

Читайте ещё больше платных статей бесплатно: https://t.me/hacker_frei