Я в обосновании ответа чуток промахнулся, т.к. взял общее количество CVEшек с https://www.cve.org/About/Metrics, а не со страницы статистики NVD. А там эти значения различаются! 🙂 Но результат всё равно правильный. 😉
Насчёт количества CVEшек в NVD и БДУ ФСТЭК. Годы летят и обычно не задумываешься насколько быстро растет реестр NVD CVE. А ведь там действительно 212793 идентификаторов на текущий на текущий момент. 😱 Я вполне помню момент, когда их было 50к. 🙂
Что, реально так много? Не ошибка? Нет, похоже всё правильно:
$ for i in `seq 2002 2023`; do wget https://nvd.nist.gov/feeds/json/cve/1.1/nvdcve-1.1-$i.json.zip; done
$ zcat nvdcve-1.1-* | grep '"ID" : "CVE-[0-9]*-[0-9]*"' | sort | uniq | wc -l
212793
Для интереса посмотрел, а сколько ссылок на CVE есть в БДУ ФСТЭК:
$ wget --no-check-certificate https://bdu.fstec.ru/files/documents/vulxml.zip
$ unzip vulxml.zip
$ cat export/export.xml | egrep -o "CVE-[0-9]*-[0-9]*" | sed 's/\/identifier>//g' | sort | uniq | wc -l
37757
Можем видеть, что сильно меньше. О причинах судить не берусь, но точно можно сказать, что воспринимать БДУ просто как downstream NVD неправильно. Туда попадает, мягко говоря, не всё, что есть в NVD. В прочем, в NVD тоже есть не всё, что есть в БДУ.
Управление уязвимостями в новых реалиях. Крутой доклад по VM-ной теме с недавно прошедшего Инфофорума. Представлял доклад Андрей Никонов, старший инженер-программист из Фродекс (Vulns.io). Видео в паблике не нашел, но есть даже лучше - слайды с текстом выступления.
Выписал тезисно:
1. Зарубежные VM-вендоры ушли - нет детектов, IT-вендоры ушли - нет обновлений.
2. Атаки на российские компаний множатся, утечки ПД и оборотные штрафы.
3. Рост отечественного ПО -> рост проблемы анализа защищенности этого ПО -> "VM-решения должны уметь работать с операционными системами и программами российского происхождения".
4. В достаточной степени отечественные VM-решения поддерживают отечественное ПО? Непонятно. "Никто открыто не публикует списки поддерживаемых ПО и не дает внятных ответов по степени покрытия российского софта".
5. Необходимы данные об уязвимостях отечественного ПО.
5.1. Западные компании "публикуют уязвимости, найденные в своих продуктах, причем эти данные являются общедоступными, несмотря на то, что большая часть ПО является коммерческим".
5.2. "Данные NVD также являются общедоступными, содержат огромное количество уязвимостей, но для проведения точного аудита годятся мало. В основном из-за того, что они используют собственный формат данных, и в них не указаны правила, по которым можно определить, является ПО уязвимым или нет". -> Ага, детект по CPE-шкам это зло.
5.3. Все ли вендоры одинаково описывают свои уязвимости? Далеко не все. OVAL стал довольно популярным. Но этого недостаточно.
5.4. У нас хорошие источники это БДУ ФСТЭК и OVAL RedOS. "Остальные вендоры, если и публикуют свои данные, то в намного более расслабленном режиме – обычно это выглядит как лента новостей или запись в блоге. Это очень сильно усложняет их обработку. Более того, не все вендоры публикуют данные открыто, хотя некоторые из них готовы предоставить данные по запросу или в случае приобретения сертификата на техническую поддержку."
5.5. Для прикладного ПО из 65 вендоров в базе ФСТЭК 3 публикуют данные об уязвимостях. А в реестре российского ПО 16000 программных продуктов!
5.6. Одной БДУ ФСТЭК недостаточно, т.к. "не указываются правила применимости той или иной уязвимости, для сканирования использовать эти данные проблематично". Данные в БДУ могут добавляться с запаздыванием, данные не всегда актуальны. Напрямую от вендора было бы быстрее.
6. Итог: "обратить внимание разработчиков российского ПО на важность поиска уязвимостей в своих продуктах, и выпуска обновлений безопасности".
Просьбы к регулятору:
"- принять единый стандарт описания уязвимостей или разработать собственный
- обязать разработчиков ОС и ПО вести базы данных уязвимостей в соответствии с принятым стандартом
- оказывать содействие компаниям при организации мероприятий Bug Bounty при условии публикаций найденных уязвимостей в базу ФСТЭК"
В целом, огонь! 🔥 Как раз такие доклады от VM-вендора и хочется видеть. Конкретно про детект уязвимостей и как делать его лучше. Очень сильно перекликается с моими собственными мыслями по этому поводу. Хочется надеяться, что регулятор прислушается.
Приоритизация уязвимостей это вещь ненадежная. В сентябрьском Microsoft Patch Tuesday была Information Disclosure уязвимость в компоненте согласования механизма аутентификации #SPNEGO Extended Negotiation (#NEGOEX) Security Mechanism (CVE-2022-37958). Ни один из VM вендоров не обратил на неё внимание.
13 декабря известная исследовательница из #IBM Security X-Force, Valentina Palmiotti, выложила видео с эксплуатацией этой уязвимости как Remote Code Execution. На видео в Linux виртуалке выполняется python скрипт, на виртуалке с Windows 10 появляется ошибка "Your PC will automatically restart in one minute".
Уязвимость может быть проэксплуатирована при попытке аутентификации по #RDP и #SMB. Возможно по #SMTP, #HTTP и т.д. при нестандартной конфигурации. Т.е. может быть хуже, чем #EternalBlue.
Microsoft внесла изменения в описание уязвимости. Теперь это Critical RCE. NVD естественно тормозит.
IBM опубликуют подробности только в Q2 2023, чтобы дать время на патчинг.
По наводке Александра Редчица посмотрел на CISA Known Exploited Vulnerabilities Enrichment Dashboard от Nucleus. Товарищи взяли CISA KEV и добавили туда данные EPSS (Score и Percentile), CVSS из NVD, а также Treat Intelligence фид от GreyNoise. Вроде ничего хитрого, но получилось занимательно.
1. Самое очевидное это то, что можно дополнительно приоритизировать уязвимости из CISA KEV для исправления.
2. С другой стороны здесь наглядно видны проблемы источников.
2.1. Если уязвимость эксплуатируется вживую, то почему эту эксплуатацию GreyNoise не видит? С одной стороны это может быть связано с ограничением фида GreyNoise - не по всем уязвимостям могут эксплуатацию отслеживать. С другой стороны это может быть связано с тем, что CISA берет признак эксплуатации от вендора, по факту это может быть "вероятная эксплутация в единичной таргетированной атаке в полнолуние и пятницу 13-е", а подробностей нет и не будет.
2.2. Вот Exploit Prediction Scoring System (EPSS) показывает "probability [0-1] of exploitation in the wild in the next 30 days (following score publication)". Весьма весело взять уязвимости "CVE-2022" с детектами от GreyNoise и увидеть, что EPSS для них вероятность появления эксплоита оценивала довольно низко. Выделил на скриншоте 20%. Иногда оценка даже в 1-2%, как например в случае с одной из уязвимостей Exchange ProxyNotShell. В общем, EPSS это далеко не серебряная пуля.
2.3. Также интересно посортировать по CVSS. Сразу вылезают проблемы с уязвимостями, которых нет в NVD. Проблемы сортировки в таблице (но это ладно). А самое интересное уязвимости с CVSS 7, т.е. меньше High. В данном случае укладываются в Medium. То есть горячий привет тем, кто жестко фильтрует по CVSS от High и выше.
Классная была задумка в NVD добавлять лейблы к ссылкам. Чтобы сразу было видно на какой объект ссылаются: почтовая рассылка, бюллетень вендора, бюллетень третьих лиц, патч, а самое ценное - эксплоит. То есть можно было бы только на основе NVD делать достаточно неплохую приоритизацию уязвимостей. Но реальность, к сожалению, грустнее:
1. На простановку лейблов всем так-то пофигу. На скриншоте log4shell. Для части ссылок на packetstorm проставлено, что это эксплоиты. Для части нет. Может это на самом деле не эксплоиты? Да нет, все верно, я обкликал и проверил. Просто ошибка операциониста, который ссылку добавлял.
2. Заинтересован ли кто-то быстро добавить в NVD ссылку на эксплоит, когда он появляется в паблике? Да видимо не особо. Разве что для очень громких уязвимостей.
3. Это общая беда, но в описании CVE могут писать про один тип уязвимости, допустим RCE, а эксплоит будет демонстрировать другую уязвимость, допустим DoS.
Выводы? Спасибо, что хотя бы так и бесплатно. 🙂 Но исключительно на данные из NVD лучше не полагаться.
Итак, вы решили начать разработку своего Vulnerability Management решения. Часть 3. На чем можно срезать углы?
Подводные камни подсветили, специализаций коснулись. В этой завершающей части посмотрим как можно быстро слепить VM-решение из того, что есть в паблике:
1. Весьма соблазнительно взять опенсурсный сканер и, несколько доработав его, начать продавать как коммерческий продукт или сервис. Например, взять OpenVAS/GVM, Nuclei, Nmap. Однако следует понимать, что вместе с наработками придется брать в нагрузку и немалое легаси. И возможно реализовать какую-то конкретную функциональность с нуля было бы проще, чем поддерживать форк проекта с историей. Кроме того за успешным опенсурсным сканером, как правило, стоит коммерческая компания, которая этот проект уже монетизирует и конкурентам не рада. Стоит ожидать, что вам будут вставлять палки в колеса, например через хитрое лицензирование (Nmap) или ограничение бесплатного публичного фида с детектами (OpenVAS/GVM). И тут уж как впишитесь.
2. Часто для того, чтобы по-быстрому добавить детектирование уязвимостей реализуют такую схему: детектирование CPE идентификатора установленного софта и поиск уязвимостей в базе NVD. Просто, быстро, универсально. Но далеко не всегда достоверно, т.к. ошибки могут быть и при детектировании CPE, и описании уязвимой конфигурации в NVD. Да и не всё всегда определяется версиями софта, свою роль могут играть патчи и их перекрытия. Продемонстрировать как такая схема работает можно на примере Nmap + Vulners plugin. Nmap тут отвечает за детект CPE, а Vulners за поиск по NVD.
3. Отдельная большая тема это SCAP/OVAL. Если кратко, то это набор открытых спецификаций для описания уязвимостей/мисконфигураций и того как их по этому описанию детектировать. Есть много бесплатного публичного контента: репозиторий CIS, DISA STIGs, профили PCI DSS от OpenSCAP, Windows уязвимости в коненте от ФСТЭК/АЛТЭКС-СОФТ, вендорский контент для Ubuntu, Debian, RHEL. Есть как минимум один опенсурсный SCAP/OVAL сканер, который все ещё развивается, это OpenSCAP от RedHat. Есть старые заброшенные проекты ovaldi и jovaldi. C открытыми SCAP/OVAL сканерами под Windows все традиционно тяжко, OpenSCAP в этом направлении шел, но не так давно под Windows его перестали поддерживать. Следует отметить, что продвигается эта тема в первую очередь американцами для контроля безопасности их государственной инфры (для военных и федеральных агентств в основном). Чуть менее чем все вакансии по SCAP/OVAL открываются в США и требуют американское гражданство и clearance, что намекает. 😉 Также они навязывают VM-вендорам поддерживать SCAP/OVAL, что те и делают, кто-то более формально, кто-то менее. В общем, есть соблазн в это дело крепко влезть, чтобы реюзнуть наработки. И есть как минимум одна success story у кого это получилось - RedCheck от АЛТЭКС-СОФТ. Также можно привести в пример индийскую компанию Secpod. Из минусов - спецификации там не особо простые и удобные, делать всё строго по ним достаточно тяжко, особенно реализовывать нестандартные проверки для нестандартных систем.
На этом мини-цикл про разработку VM я заканчиваю, но тему сканероделания конечно не оставляю. Дальше как раз планирую в очередной раз погружаться в SCAP/OVAL, следующий плановый эпизод будет про детектирование уязвимостей с помощью OpenSCAP.
Это мой личный блог. Всё, что я пишу здесь - моё личное мнение, которое никак не связано с моим работодателем. Все названия продуктов, логотипы и бренды являются собственностью их владельцев. Все названия компаний, продуктов и услуг, упоминаемые здесь, упоминаются только для идентификации. Упоминание этих названий, логотипов и брендов не подразумевает их одобрения (endorsement). Вы можете свободно использовать материалы этого сайта, но было бы неплохо, если бы вы разместили ссылку на https://avleonov.ru и отправили мне сообщение об этом на me@avleonov.com или связались со мной любым другим способом.