Архив рубрики: Темы

Первые впечатления от июльского Microsoft Patch Tuesday

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

Первые впечатления от июльского Microsoft Patch TuesdayПервые впечатления от июльского Microsoft Patch Tuesday

Первые впечатления от июльского Microsoft Patch Tuesday. Выглядит довольно интересно. 🙂

Сгенерил отчёт Vulristics, пока даже без комментариев Vulnerability Management вендоров. Как появятся обзоры, перегенерю.

Из того, что однозначно бросается в глаза это Remote Code Execution - Microsoft Office (CVE-2023-36884). У этой уязвимости даже нормальное описание, а не минимальная генерёнка. Эксплуатируется в реальных атаках.

Также активно эксплуатируемые:

🔻Security Feature Bypass - Windows SmartScreen (CVE-2023-32049)
🔻Security Feature Bypass - Microsoft Outlook (CVE-2023-35311)
🔻Elevation of Privilege - Windows Error Reporting Service (CVE-2023-36874)
🔻Elevation of Privilege - Windows MSHTML Platform (CVE-2023-32046)

Уязвимостей Exchange нет, но есть любопытная Remote Code Execution - Windows Active Directory Certificate Services (AD CS) (CVE-2023-35350).

Свежие EoP в Linux и RCE у Apple устройств

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

Свежие EoP в Linux и RCE у Apple устройств

Свежие EoP в Linux и RCE у Apple устройств.

EoP в Linux Kernel с 6.1 по 6.4 (CVE-2023-3269, StackRot). Непривилегированный локальный пользователь может использовать эту уязвимость для компрометации ядра и повышения своих привилегий. Полный код эксплоита и подробное описание будут опубликованы не позднее конца июля.

RCE у Apple устройств (CVE-2023-37450). Активно эксплуатируется. Находится в WebKit (движок Safari и всех веб-браузеров на iOS и iPadOS) и триггерится при обработке специально созданного (вредоносного) веб-контента. Обновления для macOS Ventura 13.4.1, Safari 16.5.2 в macOS Big Sur/Monterey, iOS/iPadOS 16.5.1.

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

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

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

Про оптимизации для детектирования уязвимого продукта и типа уязвимости по текстовому описанию в Vulristics. Выходные прошли плодотворно. 🙂 Получилось очень сильно ускорить эти операции. Теперь обработка уже скаченных данных (с опцией --rewrite-flag "False") проходит за несколько секунд. Конкретно за ~3 секунды для 100 уязвимостей из последнего MS Patch Tuesday. Раньше уходило несколько минут. Что сделал:

1. Для генеренных описаний Microsoft, например "Microsoft Excel Remote Code Execution Vulnerability", тип уязвимости и продукт теперь напрямую выпарщиваются из описания, без поиска по ключевым словам.
2. Переписал универсальный поиск по ключевым словам на основе products.json. Сократил использование тяжелых функций без ущерба для детектов.

Узкое место снова скачивание данных из источников. Это должно решиться после перехода на свой фид. Думаю, что генерацию такого фида можно реализовывать как фичу Vulristics. Таким образом улучшая Vulristics, приближаюсь к реализации фида. 😉

HTML код в NVD CVE description

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

HTML код в NVD CVE description

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

Инфраструктурные метрики ОСОКА

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

Инфраструктурные метрики ОСОКА

Инфраструктурные метрики ОСОКА. Предлагаю вот такие метрики с маппингом на показатели/значения из методики оценки уровня критичности уязвимостей ФСТЭК.

Т.е. инфраструктурная часть вектора для "десктопной уязвимости, которой подвержены 20% десктопов, без возможности эксплуатации на периметре" будет выглядеть так:

AT:D/AS:M/PS:N

Первоначальные намётки по открытому фиду с уязвимостями - проект Vulrectory (пока пустой)

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

Первоначальные намётки по открытому фиду с уязвимостями - проект Vulrectory (пока пустой). По этому проекту хотелось бы в идеале получить обновляемый фид со всеми уязвимостями из NVD и БДУ, содержащий некоторые дополнительные поля, чтобы его можно было использовать как единственный источник данных в Vulristics. Сейчас если с помощью Vulristics приоритизировать, допустим, 100 CVE, то утилита будет делать запросы по каждой из этих CVE к различным источникам (как к бесплатным, так и к платному - Vulners), а затем комбинировать и анализировать данные. Таким образом, будут использоваться наиболее свежие данные, но генерация полного отчета займет довольно много времени. А за большое количество запросов бесплатные источники могут и побанить. Если же будет свой источник с уже подготовленными данными, который можно будет локально выкачать к себе, то можно будет запросто строить отчеты по десяткам тысяч уязвимостей без каких-либо внешних запросов. Сразу появится множество применений:

1. Оценка и приоритизация продетектированных уязвимостей (как для отдельных хостов, так и для инфраструктуры в целом!).
2. Оценка расхождений в результатах детектирования уязвимостей VM-продуктами и слепых пятен в базах знаний (детектов) VM-продуктов.
3. Vulnerability Intelligence - анализ всего входящего потока уязвимостей. Возможно с фокусом только на тех продуктах, которые используются в организации и без привязки к детектам в VM-решении.

В общем, как только можно будет работать с готовыми данными в оффлайне, всё сразу становится гораздо интереснее и удобнее. 😉

Какие дополнительные поля нужны Vulristics:

• Название уязвимого софта. Планирую переиспользовать детект продуктов по ключевым словам на основе описания CVE, который сейчас используется в Vulristics. Но лучше добавить ещё детект на основе CPE и парсинг генеренных описаний уязвимостей "имя софта> тип уязвимости>" (как у Microsoft). Также имя софта можно напрямую забирать из БДУ.
• Тип уязвимости. Планирую переиспользовать детект типа уязвимости по ключевым словам на основе описания CVE, который сейчас используется в Vulristics. Но лучше добавить ещё детектирование на основе CWE. Но это на крайний случай, т.к. к простановке CWE идентификаторов в NVD были вопросы.
• Наличие эксплоита. Если мы хотим, чтобы Vulrectory был бесплатным, то придется видимо ограничиться ссылками на эксплоиты из NVD и флажком "Наличие эксплойта" из БДУ. 🤷‍♂️ В Vulners их будет, конечно, гораздо больше (как вариант делать платную PRO версию?). Возможно есть какие-то открытые базы с признаками наличия эксплоитов на том же GitHub-е - нужно ресерчить.
• Признак эксплуатации вживую. Тут также видимо придется ограничиться бесплатным источником - CISA KEV и ресерчить наличие открытых источников по фактам эксплуатации.

В рамках этого же проекта можно для уязвимостей отображать не только CVSS, но и вектор/скор OSOKA (только Базовые и Эксплуатационные метрики, конечно). 🙂

В общем, пока какие-то такие мысли. Как вам?

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

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

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

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