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

Изменения в источнике данных NVD для Vulristics

Изменения в источнике данных NVD для Vulristics. В NVD стали гораздо менее толерантно подходить к использованию своего API. После 5 последовательных запросов начинает отдаваться такое:

Это аффектило, в том числе и мой скрипт в Vulristics, который запрашивает данные из NVD. 😐

Согласно документации:

Публичный rate limit (без ключа API) составляет 5 запросов в скользящем 30-секундном окне; rate limit с ключом API составляет 50 запросов в скользящем 30-секундном окне.

Поэтому, если вы используете NVD API, ставьте sleep-ы. 🤷‍♂️

✅ Для Vulristics сделал поддержку аутентификации по ключу NVD и sleep-ы в 0.6 секунд при использовании ключа и 6 секунды без использования ключа.

Для получения ключа NVD API нужно указать организацию, тип организации и email в форме. Через несколько секунд на email придёт одноразовая ссылка, по которой отдаётся ключ.

Довольно занимательный кейс с Integer overflow в curl (CVE-2020-19909)

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

Довольно занимательный кейс с Integer overflow в curl (CVE-2020-19909). Уязвимость недавно завели на NVD с описанием:

"Уязвимость целочисленного переполнения в tool_operate.c в curl 7.65.2 из-за большого значения задержки повторной попытки."

Другой бы вендор взял, да добавил эту уязвимость куда-нибудь в бюллетень как давно исправленную. Но разрабы curl-а вступили в борьбу. Основное, что они пишут: мы не знаем кто завел эту CVE, у нас был похожий кейс на hackerone, мы его пофиксили в 7.66.0 в Сентябре 2019, но это была просто бага, а не уязвимость (явно не CVSS 9.8), CVE не заводили.

Ну и основной посыл: это наш софт, и мы должны решать уязвимость это или нет.

Согласен ли я с этим? Ну, скорее нет. Как VM-щику мне бы хотелось в NVD видеть в базе уязвимостей ВСЕ уязвимости независимо от позиции вендора. Даже, если это приведёт к какому-то количеству фолсов и публичных диспутов. Вендоры и так сдерживают заведение CVE как могут.

HTML код в NVD CVE description

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

HTML код в NVD CVE description. Работаю сейчас над оптимизациями для детектирования уязвимого продукта и типа уязвимости по текстовому описанию в Vulristics. В процессе обнаружил вот такое. Спасибо, конечно, что не

VM-вендоры не умеют детектировать уязвимости, которые эксплуатируются шифровальщиками

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

VM-вендоры не умеют детектировать уязвимости, которые эксплуатируются шифровальщиками. Прочитал отчёт "Index Update Q1 2023 RANSOMWARE Through the Lens of Threat and Vulnerability Management" по данным Securin и Ivanti. Товарищи анализируют информацию об уязвимостях, которые используются 356 шифровальщиками.

В отчёте утверждается, что есть 18 уязвимостей, эксплуатируемых шифровальщиками, которые не детектируются сканерами уязвимостей ТОПовых VM-вендоров (Tenable, Rapid7 и Qualys):

CVE-2010-1592
CVE-2012-3347
CVE-2013-0322
CVE-2013-2618
CVE-2013-3993
CVE-2015-2551
CVE-2015-7465
CVE-2017-15302
CVE-2017-18362
CVE-2017-3197
CVE-2017-3198
CVE-2017-6884
CVE-2019-16647
CVE-2019-16920
CVE-2019-5039
CVE-2019-9081
CVE-2020-36195
CVE-2021-33558

Эти уязвимости эксплуатируются 59 группировками шифровальщиков, среди которых Hive, Qlocker, QNAPCrypt и UEFI.

От меня: когда я призываю к открытости баз знаний VM-вендоров, я имею ввиду именно это. Любой VM-вендор умеет детектировать только часть из всех известных уязвимостей. Кто может сказать, что тех уязвимостей, которые он умеет детектировать, достаточно и в его слепой зоне точно нет ничего критичного? Вот имеем пример, когда исследователи, получив доступ к базам знаний (детектов) VM-вендоров, подтвердили проблему с полнотой. И это мы берём самый-самый топ критичных уязвимостей и самых крутых международных VM-вендоров.

Разумеется, сравнение по детектируемым CVE идентификаторам это далеко не идеальный способ обнаружить проблемы с полнотой, но это простой способ и какое-то представление он даёт. Поэтому, призываю всех пушить отечественных VM-вендоров, чтобы информация о детектируемых уязвимостях была публичной и общедоступной для стороннего анализа. Ну или хотя бы доступной регуляторам, чтобы регуляторы сами контролировали адекватность баз знаний (детектов) VM-вендоров.

В отчёте также есть критика CVSS, NVD и CISA KEV из-за некорректного учёта эксплуатируемых шифровальщиками CVE:

• 30% CVE не имеют CVSS v2 или v3 в NVD
• 2 CVE имеют severity Low, 57 Medium в NVD
• 2 CVE находятся в статусе Rejected в NVD (CVE-2015-2551 и CVE-2019-9081)
• только 68% CVE содержатся в CISA KEV, требуется добавить ещё 131

Первоначальные намётки по ОСОКА

5 комментариев

Первоначальные намётки по ОСОКА. 🙂 Думаю должно быть три группы метрик:

▪️Базовые
▪️Эксплуатационные
▪️Инфраструктурные

1. Базовые метрики будут ровно такие же как в CVSS v3.0/3.1. Почему? Это текущий стандарт, использующийся с 2015 года. Для большей части уязвимостей из NVD можно будет взять CVSS v3 Base вектор как он есть. Для уязвимостей, у которых доступен только CVSS v2 Base вектор есть более-менее рабочие способы конвертации в v3, которые можно будет взять за основу. Когда CVSS v4 появится в NVD, проблемы с конвертацией v4->v3 будут только из-за исключения метрики Scope, её придется как-то генерить, скорее всего из Impact Metrics для Subsequent Systems (но это неточно). Также для User Interaction будет 3 значения, а не два, но это тривиально схлопывается. В общем, оставаться на базовых метриках полностью повторяющих CVSS v3 нам должно быть достаточно комфортно.

2. Эксплуатационные предлагаю сделать такие:

Exploit Maturity: Not Defined (X), High (H), Functional (F), Proof-of-Concept ℗, Unreported (U) - эту штуку можно заполнять через анализ баз эксплоитов/малварей и получать из CVSS Temporal вектора некоторых вендоров (например Microsoft).

Exploitation Activities: Not Defined (X), Reported ®, Unreported (U) - это можно заполнять на основе баз отслеживающих эксплуатацию типа CISA KEV или AttackerKB. Фактов эксплуатации in the wild никогда не было в CVSS и не будет в 4.0 - преимущество ОСОКи. 😉

Exploitation Probability: Not Defined (X), High (H), Medium (M), Low (L) - это можно заполнять на основе EPSS. Я думаю, что EPSS пока ещё полный шлак, но возможно такие системы скоро станут гораздо лучше и неплохо бы заранее их поддержать.

Кажется с такими метриками по эксплуатации можно будет не упахиваться ручным описанием и получить приоритизацию с учётом того, что нужно зафиксить ASAP.

3. Инфраструктурные думаю лучше взять ровно как в методике ФСТЭК, чтобы повысить шансы на официальное признание. 😉 Кроме того, они в принципе неплохие. Во всяком случае всяко лучше абстрактного CVSS Environmental. Хотя и придется все активы покрыть VM-процессом и знать об активах хотя бы их тип и доступность на периметре.

Тип компонента информационной системы, подверженного уязвимости
- Не определено
- Компоненты ИС обеспечивающие реализацию критических процессов (бизнес-процессов), функций, полномочий
- Серверы
- Телекоммуникационное оборудование, система управления сетью передачи данных
- Рабочие места
- Другие компоненты

Количество уязвимых активов
- Не определено
- Более 70%
- 50-70%
- 10-50%
- Менее 10%

Влияние на эффективность защиты периметра системы, сети
- Не определено
- Уязвимое программное, программно-аппаратное средство доступно из сети «Интернет»
- Уязвимое программное, программно-аппаратное средство недоступно из сети «Интернет»

Конечно, нужно будет конкретные формулировки подправить, чтобы было единообразна с другими метриками, а подробности убрать в руководство по заполнению, но по смыслу должно быть ровно так как в методике ФСТЭК.

Как вам?

Спросили сегодня как по инвентаризационным данным из GLPI получать cpe-идентификаторы для последующего детектирования уязвимостей

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

Спросили сегодня как по инвентаризационным данным из GLPI получать cpe-идентификаторы для последующего детектирования уязвимостей. Сам я таким не занимался. Согласен, что получить из результатов инвентаризации cpe-идентификаторы это проблема. Но основная проблема в том, что получившиеся cpe-идентификаторы тоже достаточно бесполезны, т.к. если детектировать уязвимости с помощью них по данным из NVD, можно обнаружить, что они не всегда мапятся качественно и разбирать получившиеся false positive ошибки придется руками. Возьмем, например, CVE-2020-1102. Все версии sharepoint_server 2016 и 2019 всегда уязвимы что ли? Там патчи есть, их установку нужно учитывать.

Я скептически отношусь к разработке собственных универсальных утилит для детектирования уязвимостей (специализированных, например детектилки по бюллетеням конкретного Linux дистрибутива - это делать реально). Разработку универсальных средств детектирования лучше оставить VM-вендорам, у которых большой штат специалистов и они занимаются этим на фулл-тайм. А на стороне клиента лучше сосредоточиться на приоритизации уже продетектированных уязвимостей.

Алексей Лукацкий задаётся вопросом: будет ли ФСТЭК переходить на CVSS 4.0?

4 комментария

Алексей Лукацкий задаётся вопросом: будет ли ФСТЭК переходить на CVSS 4.0? Мне это тоже интересно.

Имхо, CVSS это не священная корова и держаться за него не стоит:

1. CVSS это результат заполнения довольно сомнительного и субъективного опросника. То, что у ресерчера, вендора и у NVD не совпадают CVSS для одной и той же уязвимости это норма.
2. CVSS v2, v3 и v4 несовместимы между собой. Сейчас в NVD есть уязвимости без CVSS, только с v2, с v2 и с v3, только с v3. Будьте уверены, что переход на v4 зоопарк усугубит. Нужно ли это и в БДУ тянуть?
3. Положа руку на сердце, кто при приоритизации уязвимостей полагается исключительно на CVSS? Это один из факторов. И не самый важный. Основная ценность CVSS, что Base метрики предоставляются NIST-ом открыто и бесплатно. А Temporal метрики никто не предоставляет, поэтому их и не используют. Не говоря уж об Environmental, которые надо самим заполнять.

Поэтому я бы рекомендовал не переходить на CVSS v4, а сделать следующее:

1. Создать свой опросник с калькулятором а-ля CVSS. Также с векторами (записываемыми в строчку) и скорами. Назвать как-нибудь оригинально, например "Общая Система Оценки Критичности Автоматизируемая" (ОСОКА). 😉 Какой конкретно это должен быть опросник - предмет отдельного обсуждения. Я бы делал его максимально простым и кратким, пусть даже в ущерб точности оценки. Лишь бы базовый скор явно критичных уязвимостей был около 10, а явно некритичных был около 0. Инфраструктурный компонент из методики оценки критичности уязвимостей также учесть в ОСОКА (сделать как в Environmental метриках CVSS).
2. САМОЕ ГЛАВНОЕ! Выпустить методические указания как использовать CVSS v2, v3, v4 в качестве входящих данных для получения вектора ОСОКА. Очень желательно, чтобы базовая часть ОСОКА автоматом получалась из Base метрик CVSS v2, v3, v4, иначе скорее всего это не взлетит.
3. В перспективе заменить все упоминания CVSS и методику оценки критичности уязвимостей ФСТЭК на ОСОКА.

Александр В. Леонов

Управление Уязвимостями и прочее