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

Результаты опроса R-Vision: около 80% компаний считают качество сканирования ключевым критерием выбора VM-решений

Результаты опроса R-Vision: около 80% компаний считают качество сканирования ключевым критерием выбора VM-решений

Результаты опроса R-Vision: около 80% компаний считают качество сканирования ключевым критерием выбора VM-решений. В опросе приняли участие 83 респондента. Это были ИБ-cпециалисты различного уровня (от линейных сотрудников до CISO), работающие в компаниях разного размера (от SMB до Enterprise) и из различных отраслей (финансы, промышленность, ИТ, ГОСы, нефтегаз, ритейл, транспорт, телекомы, энергетика).

Результаты выглядят вполне адекватно:

🔹 Чем крупнее компания, тем более зрелый там VM-процесс.

🔹 Главный критерий выбора VM-решений - широкое покрытие ОС и приложений. Также важны скорость, стабильность и минимизация фолзов.

Хочется надеяться, что как можно больше VM-вендоров ознакомятся с результатами этого опроса и начнут уделять приоритетное внимание разработке правил детектирования уязвимостей и тестированию качества их работы. 🙏 То есть той базовой функциональности, без которой все остальные "высокоуровневые" фичи не имеют никакого смысла. 🤷‍♂️😉

Про уязвимость Remote Code Execution - Roundcube (CVE-2025-49113)

Про уязвимость Remote Code Execution - Roundcube (CVE-2025-49113)

Про уязвимость Remote Code Execution - Roundcube (CVE-2025-49113). Roundcube - популярный веб-клиент для работы с электронной почтой (IMAP) с открытым исходным кодом. Эксплуатация уязвимости позволяет аутентифицированному злоумышленнику выполнить произвольный код на сервере Roundcube Webmail. Причина уязвимости - Deserialization of Untrusted Data (CWE-502).

🔹 1 июня вендор выпустил исправленные версии 1.6.11 и 1.5.10. В течение 48 часов патч был проанализирован злоумышленниками и сообщения о продаже эксплойта появились в даркнете.

🔹 3 июня эксперты PT SWARM воспроизвели уязвимость.

🔹 С 5 июня публичные эксплоиты доступны на GitHub.

🔹 6 июня Кирилл Фирсов, исследователь, зарепортивший эту уязвимость, опубликовал подробный write-up. В нём он утверждает, что уязвимость присутствовала в коде 10 лет и что есть признаки её публичной эксплуатации.

🔹 16 июня появились сообщения об успешной атаке на немецкого почтового хостинг-провайдера с использованием этой уязвимости.

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

Три года назад, 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)

Про уязвимость 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

Июньский 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-вендоры: доверять, проверять, стимулировать

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

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

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

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

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

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

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

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

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

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

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