Архив метки: vulnerability

Три года назад, 3 июля 2022 года, я начал вести телеграм-канал "Управление Уязвимостями и прочее"

Три года назад, 3 июля 2022 года, я начал вести телеграм-канал "Управление Уязвимостями и прочее". 🙂🎉🎂 За прошедший год количество подписчиков выросло с 6000 до более чем 9000! Большое спасибо всем, кто читает, лайкает и репостит, а также участвует в обсуждениях в чате и live-канале!

Собираюсь продолжать в том же духе. Буду писать всякое про уязвимости, средства анализа защищённости, VM-практики, свои (и чужие) опенсурсные проекты и требования регуляторов. Безусловно, при каждом удобном случае продолжу топить за девестернизацию российского IT. 😉

Не знаю уж, что настанет раньше: переход психологически (и юридически) значимой отметки в 10к подписчиков или прекращение стабильной работы Telegram в России. 🤷‍♂️🙂 Вполне возможно, что второе. Но, думаю, в любом случае останемся на связи.

Про уязвимость Elevation of Privilege - Windows SMB Client (CVE-2025-33073)

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

Про уязвимость Elevation of Privilege - Windows SMB Client (CVE-2025-33073). Уязвимость из июньского Microsoft Patch Tuesday. Для эксплуатации уязвимости злоумышленник может выполнить вредоносный скрипт, чтобы заставить хост жертвы подключиться к атакующему серверу по SMB и пройти аутентификацию. В результате злоумышленник может получить привилегии SYSTEM.

🔹 Детали эксплуатации уязвимости были опубликованы 11 июня (на следующий день после MSPT) на сайтах компаний RedTeam Pentesting и Synacktiv.

🔹 Эксплоиты для уязвимости доступны на GitHub с 15 июня.

🔹 Исследователи PT ESC подтвердили эксплуатабельность уязвимости и 24 июня опубликовали ликбез, варианты эксплуатации и информацию по методам детектирования.

Помимо установки обновления, для устранения уязвимости необходимо настроить принудительное требование подписи SMB для SMB-служб контроллеров и рабочих станций.

Информации об эксплуатации вживую пока нет.

Июньский Linux Patch Wednesday

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

Июньский Linux Patch Wednesday. В этот раз 598 уязвимостей, почти в 2 раза меньше, чем в мае. Из них 355 в Linux Kernel. Для 3 уязвимостей есть признаки эксплуатации вживую (CISA KEV):

🔻 SFB - Chromium (CVE-2025-2783)
🔻 MemCor - Chromium (CVE-2025-5419)
🔻 CodeInj - Hibernate Validator (CVE-2025-35036). Уязвимость эксплуатируется в атаках на Ivanti Endpoint Manager Mobile (EPMM), отслеживается по CVE-2025-4428.

Ещё для 40 (❗️) уязвимостей доступны публичные эксплоиты или имеются признаки их существования. Из них можно выделить:

🔸 RCE - Roundcube (CVE-2025-49113)
🔸 EoP - libblockdev (CVE-2025-6019)
🔸 DoS - Apache Tomcat (CVE-2025-48988), Apache Commons FileUpload (CVE-2025-48976)
🔸 InfDisc - HotelDruid (CVE-2025-44203)
🔸 DoS - ModSecurity (CVE-2025-47947)

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

VM-вендоры и Linux-вендоры: доверять, проверять, стимулировать

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

VM-вендоры и Linux-вендоры: доверять, проверять, стимулировать. Моё мнение относительно правильного детектирования уязвимостей в Linux-дистрибах. 🙂

🔹 В идеале бюллетени безопасности (или публичный трекер) Linux-вендора должны содержать информацию обо всех известных уязвимостях во всех пакетах, доступных в репозитории Linux-вендора. И VM-вендор должен детектировать уязвимости в пакетах ОС исключительно на основе этой информации.

🔹 Если VM-вендор в ходе проверок обнаруживает, что в бюллетенях Linux-вендора описаны не все уязвимости, он должен ему об этом сообщить. ✉️ Если реакции нет, VM-вендор должен реализовать правила детектирования по своей логике. В том числе, "опускаясь до базового дистриба".

🔹 При отсутствии реакции VM-вендор должен сообщить регуляторам (ФСТЭК и Минцифры?) о том, что Linux-вендор пренебрегает своими обязанностями по описанию и устранению уязвимостей. Желательно, чтобы это влияло на присутствие ОС в реестре и наличие у неё сертификата. 😉

Стоит ли опускаться до базового дистрибутива при детектировании уязвимостей Linux?

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

Стоит ли опускаться до базового дистрибутива при детектировании уязвимостей Linux? Возьмём деривативный Linux-дистрибутив. Например, Astra Linux CE, использующий помимо собственных также пакеты Ubuntu и Debian.

Есть 2 подхода к детектированию уязвимостей:

🔹 Используем только информацию об уязвимостях от вендора. Берём бюллетени безопасности вендора, генерим на основе них правила детектирования ("версия пакета X -> уязвимость"). И детектируем, и устраняем уязвимости по рекомендациям вендора.

🔹 Используем информацию об уязвимостях от вендора, но и опускаемся до базового дистрибутива. Т.е. предыдущий вариант плюс смотрим на пакеты, которые похоже были взяты из базового дистриба (Ubuntu, Debian) и используем для их проверки правила детектирования для этого базового дистриба (OVAL-контент Ubuntu, Debian). Продетектируется больше уязвимостей, но вендор, скорее всего, посчитает их фолсами и обновлений не выпустит. 🤷‍♂️

Как считаете, какой подход более правильный? 🤔

Добавил поддержку OVAL-контента для ALT Linux в Linux Patch Wednesday

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

Добавил поддержку OVAL-контента для ALT Linux в Linux Patch Wednesday. Теперь я отслеживаю когда были исправлены те или иные CVE-шки в пакетах ALT Linux и учитываю это при формировании ежемесячных бюллетеней. Чем больше источников данных по исправляемым уязвимостям в Linux дистрибутивах, тем адекватнее становятся бюллетени. 👍 Особенно если эти Linux дистрибутивы независимые, а не деривативы. 😇

Итого, сейчас в генераторе LPW используется 7 источников в формате OVAL:

🔹 Debian
🔹 Ubuntu
🔹 Oracle Linux
🔹 RedOS
🔹 AlmaLinux
🔹 Red Hat
🔹 ALT Linux

И ещё один источник в формате листов рассылки Debian.

С обзором июньского Linux Patch Wednesday я припозднился (в связи с этими доработками и отпуском), но планирую в скором времени его выпустить (upd. выпустил). Тем более что уязвимостей там не так уж много - 598. 🙂

Главные преимущества MaxPatrol VM на российском рынке

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

Главные преимущества MaxPatrol VM на российском рынке. Меня попросили накидать пункты для внутреннего использования, но пусть в паблике тоже будет. 🙂

🔹 Качество детектирования. Если считать с первого XSpider, команда PT уже 27 лет занимается детектированием уязвимостей. Здесь своя школа подготовки именно экспертов-сканеристов. Когда в одном вендоре десятки человек на full-time занимаются улучшением методов детектирования, а в другом "полтора землекопа" пилят исключительно CPE-детекты, разница в качестве детектирования будет очевидна при сколько-нибудь внимательном рассмотрении.

🔹 Настоящие трендовые уязвимости. Это не просто зеркало CISA KEV. За этим стоит процесс непрерывного отслеживания состояния огромного количества уязвимостей. Плюс экспертиза лучшей на рынке пентестерской команды.

🔹 PDQL. Собственный язык запросов позволяет работать с уязвимостями и активами максимально гибко. На мировом рынке похожее есть у Qualys, на отечественном только у PT.