Архив метки: NVD

Детектирование известных (CVE, БДУ) уязвимостей без аутентификации (в режиме "Пентест"): излишество или необходимость? Есть такое мнение, что при детектировании уязвимостей внутренней инфраструктуры сканировать без аутентификации не нужно вовсе

Детектирование известных (CVE, БДУ) уязвимостей без аутентификации (в режиме Пентест): излишество или необходимость? Есть такое мнение, что при детектировании уязвимостей внутренней инфраструктуры сканировать без аутентификации не нужно вовсе

Детектирование известных (CVE, БДУ) уязвимостей без аутентификации (в режиме "Пентест"): излишество или необходимость? Есть такое мнение, что при детектировании уязвимостей внутренней инфраструктуры сканировать без аутентификации не нужно вовсе. Что достаточно расставить агенты по хостам. А те хосты, куда агенты установить нельзя, например сетевые устройства, достаточно сканировать с аутентификацией. Дескать сканы без аутентификации всегда менее достоверны, чем сканы с аутентификацией, и нужны они только для сканирования периметра или первичной инвентаризации сети. На мой взгляд, это не совсем правильно. Сканировать без аутентификации на наличие известных уязвимостей, обязательно нужно, особенно в случае хостов с веб-приложениями.

И связано это именно с особенностями детектирования уязвимостей при сканировании с аутентификацией. Возьмём Linux-хосты. Как правило, VM-вендоры при сканировании Linux-хостов с аутентификацией ограничиваются детектированием уязвимостей в пакетах из официального репозитория Linux-вендора. 🤷‍♂️ Просто потому, что эти уязвимости описываются в общедоступных бюллетенях безопасности или даже в виде формализованного OVAL-контента. Удобно. Научился работать с этим контентом и можно ставить галочку, что Linux-дистриб поддерживается VM-решением. А как насчёт уязвимостей софта, который отсутствует в официальном репозитории Linux-вендора? Вот тут всё сложнее.

Такой софт может быть установлен:

🔹 Из подключенного стороннего репозитория
🔹 Из пакета (вендорского или самосборного) стандартной пакетной системы дистрибутива (deb, rpm), который принесли на хост ручками
🔹 Из альтернативных пакетов для распространения софта (snap, flatpak, appimage и т.д.)
🔹 Из средств распространения модулей (pip, conda, npm и т.д.)
🔹 Из образа контейнера (docker, podman и т.д.)
🔹 Из исходников софта, при этом сборка софта может происходить на том же хосте или собранный софт может быть перенесён в виде бинарных файлов

В идеале, независимо от способа установки софта на хосте, сканер уязвимостей должен его корректно продетектировать, определить его версию, а по версии определить связанные уязвимости. 🧙‍♂️ Но на практике, из-за того что способов установки софта множество, это весьма нетривиальная задача. 🧐

В итоге мы получаем ситуацию: допустим, у нас есть какой-то коммерческий или опенсурсный софт на Linux-хосте (Zabbix, GitLab, Confluence, Jira). Рыская по хосту по SSH этот софт не так-то просто надёжно найти. А при взгляде на хост извне, он ищется тривиально: сканируем порты, находим web-GUI, зачастую на главной странице находим версию и по ней детектируем уязвимости. При этом мы вообще не зависим от конкретного способа установки и запуска софта на хосте. Главное, что мы сам веб-интерфейс приложения видим. 🤩

Такие "внешние" правила детектирования уязвимостей и самим гораздо проще разрабатывать, и открытой экспертизой можно воспользоваться. Фингерпринтинг для получения CPE в сочетании с поиском в NVD по CPE это, конечно, грязный способ. Зато массовый. 😏 И если грамотно подтачивать и фингепринтилку, и правила детектирования по CPE, то и количество фолзов можно уменьшить до приемлемого уровня. А если ещё и добавить валидацию с помощью проверок с попыткой эксплуатации уязвимости (подтянуть nuclei тот же), то значительный набор уязвимостей можно будет детектировать более чем надежно. 😉

В общем, "пентест"-сканирование для определения известных уязвимостей - must have и для внутрянки тоже, особенно для веб-приложений.

Более 826 новых уязвимостей добавили в NVD за один день 3 мая

Более 826 новых уязвимостей добавили в NVD за один день 3 мая

Более 826 новых уязвимостей добавили в NVD за один день 3 мая. Картинка из сервиса CVE.icu, который визуализирует изменения NVD. Также есть выгрузка этих уязвимостей. Большую часть из них, 709, добавили ZDI. А чего это они вдруг? 🤔

В ноябре прошлого года у меня был пост, что ряд трендовых уязвимостей, которые репортили ZDI, отображаются в NVD как "CVE ID Not Found". Так вот, похоже гении из Trend Micro ZDI наконец обратили внимание на то, что их CVE-шки до NVD не доходят и решили это пофиксить таким вот массовым импортом проблемных CVEшек. 🤷‍♂️ При этом наглядно продемонстрировав масштаб бедствия. 🙂

Не, ну так-то лучше поздно, чем никогда. Но задержку между заведением ZDI-CAN идентификатора и появлением уязвимости в NVD теперь будет занятно посчитать. 😏 Например, для эксплуатируемой в фишинговых атаках RCE - WinRAR CVE-2023-40477 она составила 260 дней. 🤠

PS: окончательная цифра за 3 мая - 847 CVE, но не суть.

Выступление и дискуссия на PHDays 2024

Выступление и дискуссия на PHDays 2024

Выступление и дискуссия на PHDays 2024. В этом году я заявил на CFP рассказ про кризис в NVD (честно говоря, я предполагал, что к маю он закончится, но куда там 🌝) и развитие ресёрча уникальных уязвимостей БДУ. 👨‍💻

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

Планируем собрать представителей от БДУ, VM-вендоров, IT-вендоров, клиентов и обсудить:

🔹 Как нам жить в дивном мире, где американцы сначала политизировали ведение главной мировой базы уязвимостей, а теперь, как оказалось, вообще это не тянут? 🤷‍♂️

🔹 Чего нам не хватает в нашей российской базе БДУ? Как сделать её ещё полнее, а работу с ней ещё эффективнее? Как мы (каждый со своей стороны) можем этому способствовать?

🔹 Качество детектирования известных уязвимостей VM-продуктами. Удовлетворительно ли оно сейчас и как можно его улучшить?

В общем, приходите, должно получиться интересно. 🙂

С начала года количество новых CVE идентификаторов в NVD уже перевалило за 10000, а обработали они пока только 42% от общего количества

С начала года количество новых CVE идентификаторов в NVD уже перевалило за 10000, а обработали они пока только 42% от общего количества

С начала года количество новых CVE идентификаторов в NVD уже перевалило за 10000, а обработали они пока только 42% от общего количества. Более того, если смотреть данные за прошлый месяц, за этот месяц и за текущую неделю, то получается, что обрабатывают они только 3-5% новых CVE. 🤷‍♂️ В общем, не похоже, что кризис NVD собирается заканчиваться, несмотря на все заверения. Про новый консорциум тоже пока нет новостей.

NIST передаст управление базой NVD отраслевому консорциуму

NIST передаст управление базой NVD отраслевому консорциуму

NIST передаст управление базой NVD отраслевому консорциуму. Заявление сделала Tanya Brewer, руководитель программы NIST NVD, на VulnCon. У меня туда доступа нет, читаю пересказы и реакции. Письменное заявление обещают опубликовать на сайте NVD до 29 марта.

Среди причин, приведших к кризиcу NVD, озвучили следующее:

🔻Годовой бюджет NIST сократили на 12%. До жалких $1,46 млрд. 😅 Интересно сколько из этого уходило на NVD.
🔻Заканчивается контракт с подрядчиком, который работал над NVD вместе с NIST. Предположительно это Huntington Ingalls Industries. Почему-то компания, которая строит военные корабли. 🤷‍♂️
🔻Внутренние дискуссии по отказу от одних стандартов (CPE) и внедрению других (Package URLs)
🔻И вообще "за этим стоит история, она длинная, запутанная и очень административная".

Но после передачи дел новому консорциуму всё попрёт:

"Мы не собираемся закрывать NVD; мы находимся в процессе решения текущей проблемы. А затем мы снова сделаем NVD надёжным и заставим его расти". 😏

Повелитель CVEшек: кризис NVD

Повелитель CVEшек: кризис NVD

Повелитель CVEшек: кризис NVD. На сайте NVD сейчас висит баннер:

"NIST в настоящее время работает над созданием консорциума для решения проблем программы NVD и разработки улучшенных инструментов и методов. Во время этого перехода вы увидите временные задержки в анализе. Приносим извинения за неудобства и просим вас проявить терпение, пока мы работаем над улучшением программы NVD."

Фактически это привело к тому, что NVD полностью прекратили обогащать данные по CVE (CVSS, CWE, CPE). И в мировом около-VM-ном комьюнити нарастают панические настроения. Все привыкли использовать общедоступный контент NVD и относились к его обновлению как к чему-то разумеющемуся. Оказалось, что всё может прекратиться и разбираться откуда брать технические данные для каждой уязвимости придётся самим. 🤷‍♂️ Самоорганизовываться, как детишкам в "Повелителе мух" Голдинга. 🙂🐚🐷🪰

Я пока верю, что это временные трудности, которые решатся реорганизацией NVD. Но если нет, то занятно будет посмотреть к чему это приведёт. 🌝

VulnCheck выложили диаграмму по проблемам описания CWE в NVD

VulnCheck выложили диаграмму по проблемам описания CWE в NVD

VulnCheck выложили диаграмму по проблемам описания CWE в NVD. Я 7 лет назад тоже делал что-то подобное, но тут за прошлый год и в контексте топовых CNA (CVE Numbering Authorities). Выглядит прикольно. В чём суть: CNA часто не запариваются формальным описанием типа уязвимости (а CWE, Common Weakness Enumeration, это по сути он и есть) и либо оставляют это поле пустым, либо лепят туда "мало данных", "другое". 🤷‍♂️

Причём я подозреваю, что там, где CWE выставлены это, в основном, что-то неконкретное типа CWE-119 Buffer Errors (во всяком случае это был самый популярный CWE идентификатор 7 лет назад). Даже если на основании описания можно предположить и более конкретный тип уязвимости. Выглядит как направление для дальнейшего анализа и тыкания уважаемых CNA палочкой. 🤔😉

Ну и интересно, а как с этим дела в нашей БДУ.