Архив за месяц: Июнь 2025

Книга "Эффектная приоритизация уязвимостей" от издательства O'FAILY

Книга Эффектная приоритизация уязвимостей от издательства O'FAILY

Книга "Эффектная приоритизация уязвимостей" от издательства O'FAILY. 🙂 На фоне громкого релиза провокационной книги от Ever Secure (кстати, 20-го июня у них автограф-сессия в Музее Криптографии), мне подумалось: а как бы могла выглядеть аналогичная книга "с тёмной стороны" на тему VM-а? Чтобы в ней были подчёркнуто вредные советы и при этом было guilty pleasure в том, чтобы её полистать. 😎😈

В итоге сформировалась идея руководства для VM-щика, который хочет стать откровенным и успешным козлом:

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

Ну, с другой стороны, книга могла бы научить, как такое поведение выявлять и пресекать. 😉

Июньский Microsoft Patch Tuesday

Июньский Microsoft Patch Tuesday

Июньский Microsoft Patch Tuesday. Всего 81 уязвимость, приблизительно столько же было и в мае. Из них 15 уязвимостей были добавлены между майским и июньским MSPT. Есть 3 уязвимости с признаками эксплуатации вживую:

🔻 RCE - WEBDAV (CVE-2025-33053). Уязвимость связана с использованием режима Internet Explorer в Microsoft Edge и других приложениях. Для эксплуатация жертва должна кликнуть на зловредный URL.
🔻 SFB - Chromium (CVE-2025-4664)
🔻 Memory Corruption - Chromium (CVE-2025-5419)

Для одной уязвимости на GitHub заявлен PoC, но работоспособность его сомнительна:

🔸 EoP - Microsoft Edge (CVE-2025-47181)

Из остальных можно выделить:

🔹 RCE - Microsoft Office (CVE-2025-47162, CVE-2025-47164, CVE-2025-47167, CVE-2025-47953), KPSSVC (CVE-2025-33071), SharePoint (CVE-2025-47172), Outlook (CVE-2025-47171)
🔹 EoP - SMB Client (CVE-2025-33073), CLFS (CVE-2025-32713), Netlogon (CVE-2025-33070)

🗒 Полный отчёт Vulristics

Детектирование уязвимостей "поиском по версиям" - серебряная пуля?

Детектирование уязвимостей поиском по версиям - серебряная пуля?

Детектирование уязвимостей "поиском по версиям" - серебряная пуля? Я бы хотел жить в мире, где наличие уязвимости в продукте однозначно определялось простым поиском по его версии в некоторой базе. 🙏 Но реальность сложнее. 🤷‍♂️

🔹 Детектирование по CPE идентификаторам на основе данных из NVD требует расчёта логических выражений (потенциально с большой вложенностью). Это уже не совсем поиск, ближе к расчёту статусов в OVAL-е. 😉

🔹 Для правильного детектирования уязвимостей по версиям пакетов в Linux необходимо сравнивать версии согласно алгоритмам системы управления пакетами (RPM, DEB и т.д.), а не как строки. Тоже не простой поиск. Логика расчёта уязвимостей может требовать проверять версию дистрибутива и версию ядра. Т.е. нужны не только версии продуктов. 🧐

🔹 Детектирование уязвимостей Windows может включать проверку значений в реестре. Т.е. не только версии.

Поэтому, имхо, лучше не ограничиваться только этим подходом к детектированию, а исходить из потребностей. 😉

При всём моём принятии любых подходов к детектированию уязвимостей, есть одна вещь, которая мне однозначно не нравится

При всём моём принятии любых подходов к детектированию уязвимостей, есть одна вещь, которая мне однозначно не нравится

При всём моём принятии любых подходов к детектированию уязвимостей, есть одна вещь, которая мне однозначно не нравится. Когда VM-вендор реализует некоторый подход к детектированию (условный Best Detection & Scanning Method 😏) и начинает применять его везде и всегда как самый лучший и правильный.

Частенько оказывается, что гибкость реализованного подхода недостаточна, чтобы получать качественные результаты детектирования уязвимостей для некоторых типов активов. Гладко было на бумаге, да забыли про овраги. 🤷‍♂️

Правильным решением такое ситуации выглядит:

🔹 Публично признать проблему, покаяться перед клиентами.
🔹 Реализовать подход, обеспечивающий наилучшее качество детектирования.

Но VM-вендоры могут вместо этого включать режим "пренебречь - вальсируем". 😐 Тоже понятно почему: доработка требует ресурсов, а клиенты фолсы могут и не заметить. 😉 Такие кейсы, имхо, следует аккуратно подсвечивать и стимулировать вендоров к повышению качества детектирования.

Про уязвимости Elevation of Privilege - Windows Common Log File System Driver (CVE-2025-32701, CVE-2025-32706)

Про уязвимости Elevation of Privilege - Windows Common Log File System Driver (CVE-2025-32701, CVE-2025-32706)

Про уязвимости Elevation of Privilege - Windows Common Log File System Driver (CVE-2025-32701, CVE-2025-32706). Обе уязвимости из майского Microsoft Patch Tuesday и для них сразу были признаки эксплуатации вживую. Common Log File System (CLFS) - это служба ведения журналов общего назначения, которая может использоваться программными клиентами, работающими в пользовательском режиме или режиме ядра.

Последствия эксплуатации этих уязвимостей идентичны: злоумышленник может получить привилегии SYSTEM. Идентичны и CVSS векторы (Base Score 7.8).

В чём различия? Тип ошибки: для CVE-2025-32701 это CWE-416: Use After Free, а для CVE-2025-32706 это CWE-20: Improper Input Validation. За информацию по CVE-2025-32701 благодарят MSTIC, а в случае CVE-2025-32706 - Google TIG и CrowdStrike ART.

Публичных эксплоитов пока нет. 🤷‍♂️ Подробностей по эксплуатации тоже. Но вполне вероятно, что уязвимости используют шифровальщики, как и EoP в CLFS (CVE-2025-29824) из апрельского MSPT. 😉

Важно ли, что именно у сканера уязвимостей "под капотом"?

Важно ли, что именно у сканера уязвимостей под капотом?

Важно ли, что именно у сканера уязвимостей "под капотом"? На презентации Сканер-ВС 7 Александр Дорофеев поднял интересную тему сравнения подходов к детектированию уязвимостей. Поделюсь своим мнением:

🔹 Я видел много разных сканеров уязвимостей, и у меня сейчас нет предпочтений в том, как должна описываться логика детектирования уязвимостей. Глядя со стороны клиента, мне без разницы, что у сканера "под капотом": NASL/NSE/NucleiTemplates, SCAP/OVAL/NVD CPE Configurations, свои форматы описания логики на основе XML и YAML, любые таблички с версиями или произвольные скрипты. 🤷‍♂️

🔹Я даже не против, если для разных типов сканирования и/или разных типов активов будут использоваться различные подходы к детектированию. Вообще пофиг - хоть на таро гадайте. 🃏😏

Определяющим для меня является только одно - итоговое качество детектирования: чтобы количество ошибок первого и второго рода в результатах было минимальным. А как этого добивается VM-вендор - его проблемы.

Про уязвимость Elevation of Privilege - Microsoft DWM Core Library (CVE-2025-30400)

Про уязвимость Elevation of Privilege - Microsoft DWM Core Library (CVE-2025-30400)

Про уязвимость Elevation of Privilege - Microsoft DWM Core Library (CVE-2025-30400). Уязвимость, исправленная в рамках майского Microsoft Patch Tuesday, касается компонента Desktop Window Manager. Это композитный оконный менеджер, входящий в состав Windows, начиная с Windows Vista. В случае успешной эксплуатации злоумышленник может поднять свои привилегии до уровня SYSTEM. Для уязвимости сразу были признаки эксплуатации вживую. Подробностей по атакам пока ещё нет.

Судя по секции Acknowledgements, эксплуатацию этой уязвимости обнаружили исследователи Microsoft Threat Intelligence Center. А они редко делятся подробностями. 🤷‍♂️ Придётся подождать, когда эксплуатацию уязвимости зафиксируют другие исследователи либо когда появится публичный эксплойт. Сейчас на GitHub есть один репозиторий с PoC-ом, но его работоспособность под большим вопросом. 🤔

Предыдущая активно эксплуатируемая EoP уязвимость в DWM Core Library (CVE-2024-30051) была устранена в мае прошлого года.