Архивы автора: Александр Леонов

Об авторе Александр Леонов

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

БОСПУУ и/или результативный подход? Как правильно заметил Алексей Лукацкий в сегодняшнем посте, я начал формулировать своё видение оценки состояния VM-процесса в ответ на его материалы про измерение результативности VM-решения (поломают нас или нет) с использованием временных оценок Time to Notify/eXploit/Patch/Eliminate и т.д

БОСПУУ и/или результативный подход? Как правильно заметил Алексей Лукацкий в сегодняшнем посте, я начал формулировать своё видение оценки состояния VM-процесса в ответ на его материалы про измерение результативности VM-решения (поломают нас или нет) с использованием временных оценок Time to Notify/eXploit/Patch/Eliminate и т.д

БОСПУУ и/или результативный подход? Как правильно заметил Алексей Лукацкий в сегодняшнем посте, я начал формулировать своё видение оценки состояния VM-процесса в ответ на его материалы про измерение результативности VM-решения (поломают нас или нет) с использованием временных оценок Time to Notify/eXploit/Patch/Eliminate и т.д.

Тема интересная, но я и из первого поста, и из отдельного поста про TTE не понял конкретный механизм как это считать. 🤔 Для каждой CVE и актива организации? Так-то фиг угадаешь, когда конкретная уязвимость эксплуатироваться начнёт. А если это "общая температура по больнице", то какой в ней смысл? Пока это выглядит утопично и требующим детализации.

В БОСПУУ же я собираю конкретные измеримые вещи, которые точно приведут к улучшению VM-а. И повысят шансы успешного противодействия злоумышленникам.

Насколько? Это как раз и можно попробовать прикинуть с помощью результативного подхода. Но, имхо, это опциональное дополнение, не база.

Обновил июньский Linux Patch Wednesday и перевыпустил отчёт Vulristics

Обновил июньский Linux Patch Wednesday и перевыпустил отчёт Vulristics

Обновил июньский Linux Patch Wednesday и перевыпустил отчёт Vulristics. Общее количество уязвимостей снизилось с 1053 до 1040. Видимо для них стали доступны более ранние таймстемпы фиксов. Но уязвимости с признаком эксплуатации вживую и с публичным эксплоитом это не зацепило, они остались теми же.

🗒 Отчёт Vulristics по июньскому Linux Patch Wednesday

Базовая Оценка Состояния Процесса Управления Уязвимостями (БОСПУУ): предварительная схема по текстовому описанию

Базовая Оценка Состояния Процесса Управления Уязвимостями (БОСПУУ): предварительная схема по текстовому описанию

Базовая Оценка Состояния Процесса Управления Уязвимостями (БОСПУУ): предварительная схема по текстовому описанию. Конечно, требуется дальнейшая детализация и расширение. Мне в первую очередь интересна оценка используемых средств детектирования. 😎

Upd. Обновленная версия 0.0.6

Базовая Оценка Состояния Процесса Управления Уязвимостями (БОСПУУ)

Базовая Оценка Состояния Процесса Управления Уязвимостями (БОСПУУ)

Базовая Оценка Состояния Процесса Управления Уязвимостями (БОСПУУ). Как правильно отслеживать и развивать Vulnerability Management процесс? Имхо, нет единственно правильного способа. Если уязвимости в инфраструктуре своевременно исправляются, аудиторы вас нахваливают, а пентестеры грустят, значит всё норм. 👍 Но некоторые свои соображения я сформулирую под названием БОСПУУ. 😉

Общая оценка состоит из 3 компонентов:

🔸 Оценка используемых средств детектирования уязвимостей (полнота базы детектов, достаточность способов детектирования, оперативность доставки детектов)

🔸 Оценка охвата инфраструктуры VM-процессом (несканируемые активы и сети, активы без ответственных, активы без SLA по устранению уязвимостей, уязвимости без тасков)

🔸 Оценка выполнения SLA по патчингу для скоупов активов. Каждый скоуп разбиваем на группы активов по критичности: целевые, ключевые, обычные. Для каждой группы отслеживаем выполнение SLA по плановому и приоритетному исправлению уязвимостей.

upd. Схема

По поводу критичной уязвимости Authentication Bypass - Veeam Backup & Replication (CVE-2024-29849)

По поводу критичной уязвимости Authentication Bypass - Veeam Backup & Replication (CVE-2024-29849)

По поводу критичной уязвимости Authentication Bypass - Veeam Backup & Replication (CVE-2024-29849). Veeam B&R - клиент-серверное ПО для централизованного резервного копирования виртуальных машин в средах VMware vSphere и Microsoft Hyper-V.

Уязвимость нашли в компоненте Backup Enterprise Manager - веб-консоль для управления и создания отчетов. Неаутентифицированный злоумышленник может войти в веб-консоль от имени любого пользователя. CVSS 9.8.

🔸 Уязвимость была исправлена вендором 21 мая.

🔸 Через 3 недели, 10 июня, исследователь под ником SinSinology выложил в своём блоге разбор этой уязвимости (на основе анализа патча) и PoC для неё.

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

До 2022 года продукты Veeam были популярны в России и наверняка остаётся ещё много инсталляций. 🤔

Обязательно обновляйтесь!

По случаю пятницы поделюсь одним своим загоном

По случаю пятницы поделюсь одним своим загоном

По случаю пятницы поделюсь одним своим загоном. В одной небольшой азиатской стране есть небольшой ИБ-вендор, который предлагает сервис по управлению поверхностью атаки и редтимингом. И ещё публикует крутые ресёрчи по уязвимостям. И всё у них хорошо кроме названия.

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

И вот каждый раз, когда надо бы этого вендора публично упомянуть я загоняюсь:

🔸 Просто писать как есть. Слово общеупотребительное, на английском, разница в букву - вроде норм. Или не норм? 🤔
🔸 Написать, что это вот не те, которые запрещённые и в реестре, просто совпадение. Вроде правильно, но мегастранно. 🤷‍♂️
🔸 Вообще не ссылаться на них от греха подальше. 🙈🙂

По поводу критичных уязвимостей Remote Code Execution - VMware vCenter (CVE-2024-37079, CVE-2024-37080)

По поводу критичных уязвимостей Remote Code Execution - VMware vCenter (CVE-2024-37079, CVE-2024-37080)

По поводу критичных уязвимостей Remote Code Execution - VMware vCenter (CVE-2024-37079, CVE-2024-37080). vCenter это продукт для централизованного управление виртуальной инфраструктурой на платформе VMware vSphere.

Обе уязвимости были исправлены 17 июня. У них одинаковое описание и CVSS 9.8.

Уязвимости связаны с переполнением кучи в реализации протокола DCERPC. Злоумышленник, имеющий сетевой доступ к vCenter Server, может отправить специально подготовленный сетевой пакет и потенциально получить RCE.

Публичного эксплоита и признака эксплуатации вживую пока нет, однако:

🔸 Уязвимости очень похожи по описанию на прошлогоднюю эксплуатируемую RCE уязвимость vCenter (CVE-2023-34048). И CVSS вектор такой же.

🔸 "Скриншот vSphere Client", интерфейса для vCenter, стал своеобразным мемом злоумышленников, подтверждающим, что в ходе атаки им удалось скомпрометировать виртуальную инфраструктуру организации. Цель очень лакомая!

Обязательно обновляйтесь!