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

NVD включили заднюю в вопросе отключения CVE-фидов

NVD включили заднюю в вопросе отключения CVE-фидов

NVD включили заднюю в вопросе отключения CVE-фидов. Раньше обещали отключить генерацию архивов, содержащих JSON-файлы со всеми CVE-шками, 15 декабря 2023. Теперь пишут, что отключать пока не будут и по сути признают то, что:

🔹 массовая выгрузка CVE-шек оказалась нужна множеству потребителей
🔹 актуальная версия API-шки эффективно делать это не позволяет

Будут улучшать возможности массовой выгрузки данных из NVD через API, а пока этого не сделают, оставят генерацию файликов с выгрузками как есть.

Ура-ура, маленькая победа здравого смысла! 🎉

Это внушает небольшую надежду на то, что активности по фактическому ограничению доступа к данным NVD были вызваны не сознательной политикой, а обычной глупостью.

Про определение имени уязвимого продукта по CPE в Vulristics

Про определение имени уязвимого продукта по CPE в Vulristics

Про определение имени уязвимого продукта по CPE в Vulristics. Для тех, кто не в курсе, моя утилита, кроме прочего, решает задачку получения для CVE-шки описательной строки "тип уязвимости - уязвимый продукт". В итоге пришёл к выводу, что хоть метод определения имени уязвимого продукта по CPE хорош своей скоростью и универсальностью, но в качестве основного он не годится.

Проблема не в самих CPE, а в том как их используют в NVD: иногда для CVE их слишком много, иногда их вообще нет, иногда они нерелевантные. Возьмём, для примера, Log4Shell (CVE-2021-44228). Согласитесь, что для этой уязвимости было бы неплохо в качестве уязвимого продукта получить Apache Log4j2 или хотя бы Apache Log4j. И он там даже есть в виде a:apache:log4j. Но в общем случае автоматически выделить именно этот CPE идентификатор среди десятков других, связанных с этой CVE, задача такая себе. 🤷‍♂️ Теоретически это можно было бы делать, если бы была какая-то иерархия CPE, анализируя которую можно было бы понять, что a:apache:log4j имеет больший приоритет, т.к. это уязвимая либа, которую использую другие уязвимые продукты. Но этого нет. Тот же официальный CPE dictionary это просто перечень CPE идентификаторов со ссылками на сайты вендоров и прочие сайты без какого-либо дополнительного полезного контекста.

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

А детект по CPE оставить на случай, когда анализ текстового описания ничего не дал и лучше попробовать показать хоть что-то, чем Unknown Product.

Прожектор по ИБ, выпуск №15 (09.12.2023): Нейролингвистические атаки на ИИ

Прожектор по ИБ, выпуск №15 (09.12.2023): Нейролингвистические атаки на ИИ

🔸 Александр Леонов, "Управление уязвимостями и прочее"
🔸 Лев Палей, "Вести из Палей"
🔸 Максим Хараск, "Global Digital Space"

00:00 Здороваемся и смотрим статистику по прошлому эпизоду
01:56 Про конференцию Код ИБ Итоги 2023
08:14 Фишинговая атака на админов WordPress и настоящая RCE
13:39 У NVD превратятся в тыкву фиды и API 1.0, что делать?
17:36 Нейролингвистические атаки на ИИ и автоматическая конвертация BASH в Python
26:00 Стратегия развития области связи
34:17 Премия Киберпросвет
38:59 Прощание от Mr.X

Фиды NVD и API v1.0 превратятся в тыкву через неделю

Фиды NVD и API v1.0 превратятся в тыкву через неделю

Фиды NVD и API v1.0 превратятся в тыкву через неделю.

"The NVD plans to retire the remaining legacy data feeds as well as all 1.0 APIs on December 15th."

Если ваша организация забирает уязвимости из NVD напрямую, скачивая архивчики с JSON или используя API v1.0, то всё это поломается с 15 декабря. Имеет смысл проверить и перейти на NVD API v2.0 (учитывайте rate limits) или другие источники данных по CVE.

Выкачивать данные по всем CVE разом было очень удобно. Можно такой экспериенс сохранить? Видятся опции:

🔹 Бесплатный неофициальный NVD CVE фид от немецкого института FKIE на GitHub. Всё как у NVD, обновления раз в 2 часа.

🔹 Бесплатный официальный CVE фид от Mitre на GitHub. Нет CPE (есть affected продукты в другом формате), CWE и CVSS вендорский и не везде.

🔹 Платная коллекция данных NVD от Vulners, обогащённая инфой по активной эксплуатации, эксплоитам, AI Score и т.д. Требуется платный API и расширенная подписка. Про работу с коллекциями у меня был давнишний пост.

Фишинговая атака на администраторов сайтов на WordPress

Фишинговая атака на администраторов сайтов на WordPress

Фишинговая атака на администраторов сайтов на WordPress. Гениально и просто. 🙂 Админам сайтов приходит поддельное письмо, якобы от WordPressOrg, с призывом установить плагин для исправления RCE уязвимости CVE-2023-45124. На NVD для этой уязвимости CVE ID Not Found, но, учитывая какой там сейчас бардак, это бы и меня не особо смутило. 😅

В письме ссылка на фишинговый сайт с описанием вредоносного плагина, отзывами, оценками, всё как на официальном сайте с плагинами. Плагин скачивается как zip-архив. После установки и активации плагина создаётся админская учётка wpsecuritypatch, пароль от неё передается на сервер злоумышленников, устанавливается P.A.S. бэкдор, плагин и учётка скрываются в админке. 😈

Разумеется, похожую атаку могут проворачивать и для какой-нибудь другой CMS-ки, того же Битрикса. Будьте внимательнее.

NVD и ошибка 503

NVD и ошибка 503

NVD и ошибка 503. Последние пару дней наблюдаю ошибки при работе API NVD (services.nvd.nist.gov). На этот раз они связаны не с аутентификацией и rate limit, а с недоступностью сервиса.

В Vulristics пришлось добавить обработку 503 ошибки. В этом случае делается sleep на 5 секунд и повтор выполнения запроса. Иногда требуется сделать до 5 попыток 🙈, но в итоге отрабатывает. 🙂

Когда CVE это инцидент: затрояненный 3CX DesktopApp (CVE-2023-29059)

Когда CVE это инцидент: затрояненный 3CX DesktopApp (CVE-2023-29059)

Когда CVE это инцидент: затрояненный 3CX DesktopApp (CVE-2023-29059). Это давнишняя мартовская история. Пример того, на что иногда могут выдать CVE идентификатор. 3CX DesktopApp это десктопное приложение-мессенджер с возможностью совершать телефонные звонки. 29 марта этого года выяснилось, что некоторые версии этого приложения под Windows и MacOS были затроянены на стороне вендора. Качаешь приложения с официального сайта - получаешь троян (infostealer). Классическая Supply Chain Attack. Ситуация достаточно распространенная. Можно хотя бы вспомнить Free Download Manager. Но вот то, что под неё CVE завели - редкость.

Когда я попытался определить тип такой внесённой "уязвимости", это вогнало меня в лёгкий ступор. В описании только про "has embedded malicious code" и перечень версий. NVD также умыли руки и выставили NVD-CWE-noinfo (Insufficient Information).

В итоге я решил, что раз злоумышленники получили эффект равный эксплуатации RCE, то пусть будет "как бы RCE". 🙂