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

VulnCheck (Vulnerability Intelligence вендор и CNA) выстроили занимательный конвейер регистрации CVE-идентификаторов для активно эксплуатирующихся уязвимостей через взаимодействие с мониторинговой организацией Shadowserver

Добавить комментарий

VulnCheck (Vulnerability Intelligence вендор и CNA) выстроили занимательный конвейер регистрации CVE-идентификаторов для активно эксплуатирующихся уязвимостей через взаимодействие с мониторинговой организацией Shadowserver

VulnCheck (Vulnerability Intelligence вендор и CNA) выстроили занимательный конвейер регистрации CVE-идентификаторов для активно эксплуатирующихся уязвимостей через взаимодействие с мониторинговой организацией Shadowserver. Такой конвейер работает без участия вендоров уязвимого ПО и особенно полезен для регистрации уязвимостей в продуктах вендоров, которые по каким-то причинам совсем не инициируют регистрацию CVE или делают это со значительной задержкой (например, в случае некоторых вендоров из Китая).

Схема процесса:

🔎 Обнаружение эксплуатации: Shadowserver Foundation фиксируют, что для конкретной уязвимости наблюдается эксплуатация вживую, при этом CVE-идентификатор у уязвимости отсутствует.

🧪 Проверка информации: VulnCheck валидируют информацию и подтверждают, что для уязвимости ранее действительно не было зарегистрировано CVE.

📚 Сбор источников: собираются все релевантные публичные источники по уязвимости, включая, при наличии, патчи и репорты CERT-ов, государственных агентств и записи из альтернативных баз уязвимостей.

🆔 Публикация CVE: после подтверждения уязвимости ей присваивается CVE-идентификатор с привязкой к году первоначального раскрытия (например, CVE-2021-4473, если уязвимость была раскрыта в CNVD в 2021 году). В качестве CNA выступают сами VulnCheck.

📡 Распространение: опубликованный CVE-идентификатор передаётся обратно в Shadowserver для использования в детектировании, а также добавляется в VulnCheck KEV. Дополнительно рассылаются уведомления подписчикам по email и Slack.

VulnCheck приводят примеры заведённых по такому процессу уязвимостей:

🔻 CVE-2026-22679 - уязвимость удалённого выполнения команд без аутентификации в Weaver (Fanwei) E-cology 10.0. Первые признаки эксплуатации зафиксированы Shadowserver Foundation 31.03.2026.

🔻 CVE-2021-4473 - уязвимость внедрения команд в Tianxin Internet Behavior Management System. Первые признаки эксплуатации зафиксированы Shadowserver Foundation 01.06.2024.

Итого. В таком процессе уязвимости фиксируются и оформляются на основе наблюдаемой эксплуатации и threat intelligence без обязательного участия вендора ПО. При этом регулятор, отвечающий за ведение базы уязвимостей, не перегружается операционной работой конвейера по сбору данных и заведению новых идентификаторов. 👍

🇷🇺 В российском контексте подобный подход можно было бы использовать для ускоренного заведения уязвимостей в БДУ ФСТЭК по факту их эксплуатации без активного участия в процессе регулятора и вендоров уязвимого ПО. Но для этого нужно фактически выдать некоторым российским Vulnerability Intelligence организациям полномочия по заведению идентификаторов БДУ, фактически аналогичные CNA, что, конечно, имеет свои плюсы и минусы. 🤔

О национальных базах уязвимостей, в частности китайских

1 комментарий

О национальных базах уязвимостей, в частности китайскихО национальных базах уязвимостей, в частности китайских

О национальных базах уязвимостей, в частности китайских.

В Китае две основные государственные базы уязвимостей:

- https://www.cnnvd.org.cn/ Chinese National Vulnerability Database поддерживается China Information Security Evaluation Center
- https://www.cnvd.org.cn/ China National Vulnerability Database поддерживается National Computer Network Emergency Technical Handling Coordination Center, CNCERT/CC, подразделение Ministry of Industry and Information Technology

Зачем вообще нужны национальные базы уязвимостей, когда есть NVD? Обычно такие базы создаются при гос. органе, который, кроме прочего, должен предупреждать компании и организации о появлении опасных уязвимостей требующих оперативного исправления. Чтобы это делать нужна как минимум страница с профилем уязвимости. Делать это ссылкой на американскую базу мало того, что довольно унизительно, но ещё и ненадежно. Сегодня NVD публично доступна, а завтра, например, ограничат доступ по IP или даже сделают хитрую закрытую регистрацию. Тогда что? А они могут. Или если появилась информация о новой уязвимости в софте, который в западном мире вообще не представлен, то получается нужно в обязательном порядке репортить её в MITRE/NVD и ждать пока они добавят (если вообще добавят)? Тоже как-то не очень. Опять же данные в NVD дополнительными полями не расширишь, в случае каких-то выявленных проблем в описании по-быстрому не поправишь. Зависимость.

В общем, даже если национальная база уязвимостей это буквальный клон NVD, все равно её существование видится вполне оправданным. При условии конечно, что её наполнение не хуже, чем NVD. Обеспечивать это пока NVD публично доступна, дело довольно простое. Дергаешь фиды и раскладываешь их к себе. А если NVD вдруг перестанет быть доступной публично, то и статус её в мире довольно оперативно изменится. А если же национальная база лучше по наполнению (по количеству уязвимостей, их описанию или поддержке продуктов), то и тем более оправдано.

Единственная сложность в том, что национальные базы уязвимостей обычно ведутся на национальных же языках. Ну, имеют право. Но в наш век дешевого и достаточно качественного автоматического перевода, это перестает быть чем-то непреодолимым. Тем более, что описания уязвимостей достаточно однотипные. И вот ребята из Vulners эту проблему успешно решают. Они добавили поддержку CNVD сразу на английском! https://vulners.com/search?query=type:cnvd Теперь работать с CNVD не сложнее чем с NVD. Это ли не круто, товарищи?! 🙂