Архивы автора: Alexander Leonov

Об авторе Alexander Leonov

Привет! Меня зовут Александр. Я специалист по Управлению Уязвимостями. Подробнее обо мне можно прочитать здесь. Приглашаю подписаться на мой канал в Telegram @avleonovrus. Я обновляю его чаще, чем этот сайт. Вы можете обсудить мои посты или задать вопросы в @avleonovchat или в группе ВКонтакте. And I invite all English-speaking people to another telegram channel @avleonovcom.

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

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

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

🔹 Детектирование по 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) была устранена в мае прошлого года.

Как работает детектирование уязвимостей в Security Vision VM в режиме аудит?

Как работает детектирование уязвимостей в Security Vision VM в режиме аудит?Как работает детектирование уязвимостей в Security Vision VM в режиме аудит?Как работает детектирование уязвимостей в Security Vision VM в режиме аудит?Как работает детектирование уязвимостей в Security Vision VM в режиме аудит?Как работает детектирование уязвимостей в Security Vision VM в режиме аудит?Как работает детектирование уязвимостей в Security Vision VM в режиме аудит?

Как работает детектирование уязвимостей в Security Vision VM в режиме аудит?

🔹 Инвентаризациия хостов и расчёт уязвимостей в SV VM разнесены. Поэтому можно пересчитывать уязвимости без пересканирования.

🔹 В ходе инвентаризации с хостов собираются установленные продукты различного типа (CPE, Linux, Windows).

🔹 Детектирование уязвимостей сводится к сравнению установленных и уязвимых версий продуктов. Уязвимые продукты (CPE, Windows, Linux) описаны на одноименной вкладке карточки уязвимости. Их можно редактировать. ✍️👍

В описании уязвимого продукта задают:

🛍️ Для CPE: CPE ID, версии от и до, флажки "версия включена" и "исключение".

🛍️ Для Linux: данные по ОС (имя, код, версия), имя пакета и версию с исправлением.

🛍️ Для Windows: имя продукта (в т.ч. Service Pack), версию с исправлением и исправление (?).

Cработки по одному уязвимому продукту достаточно для детекта уязвимости. Установленные и безопасные версии видны на вкладках "Результаты" и "Рекомендации".

Казусы частно-государственного партнёрства в США

Казусы частно-государственного партнёрства в США

Казусы частно-государственного партнёрства в США. 🙂 Некоторые моменты бывают настолько прекрасны, что хочется, чтобы они длились вечно. Как эта сегодняшняя перепалка Маска с Трампом. 🔥 Я там верю обоим. 😅

Есть мнение, что для наибольшей эффективности нужно всё по максимуму отдать на откуп частникам. В доказательство показывают пальцем на Маска. Дескать, какой молодец. За что ни возьмётся - всё процветает. И машины, и ракеты, и спутниковый интернет. С черепицей, туннелями, гиперлупом, роботами и мозговыми имплантами похуже. Но не суть!

Думаю, если ситуация будет развиваться в том же ключе (🙏), то нам продемонстрируют:

🔻 В чём феномен Маска и где там на самом деле бюджетные деньги, за счёт которых всё и крутится.

🔻 Как супер-эффективный частный подрядчик может начать выкручивать руки государству, если лишить его этих самых бюджетных денюжек.

Хотя, думаю, до вывода из эксплуатации Dragon и отключения Starlink дело не дойдёт и Маска утихомирят. 🤷‍♂️