Архив рубрики: Уязвимости

Требования к мероприятиям по Управлению Уязвимостями согласно новому приказу ФСТЭК №117

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

Требования к мероприятиям по Управлению Уязвимостями согласно новому приказу ФСТЭК №117

Требования к мероприятиям по Управлению Уязвимостями согласно новому приказу ФСТЭК №117. Приказ устанавливает требования о защите информации, содержащейся в ГИС, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений. Приказ опубликован 17.06.2025, вступает в силу с 01.03.2026. Он заменяет приказ ФСТЭК №17.

Требования к Управлению Уязвимостями раскрыты в пункте 38. Они устанавливают:

🔹 Общую структуру процесса: выявление, оценка, приоритизация, контроль устранения.

🔹 Сроки устранения уязвимостей критического и высокого уровня или исключение возможности их эксплуатации компенсирующими мерами. 24 часа и 7 дней соответственно. Для остальных уязвимостей сроки определяются внутренним регламентом.

🔹 Необходимость сообщать о выявлении уязвимостей, отсутствующих в БДУ ФСТЭК, в течение 5 рабочих дней.

Как видим, требования более чем облегчённые. Особенно если сравнивать с ранними драфтами. 😉

Книга "Эффектная приоритизация уязвимостей" от издательства 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/Internet Shortcut Files (CVE-2025-33053). Для эксплуатация жертва должна кликнуть на зловредный .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-вендор - его проблемы.