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

Результаты опроса 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). 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 года, я начал вести телеграм-канал "Управление Уязвимостями и прочее". 🙂🎉🎂 За прошедший год количество подписчиков выросло с 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). Продетектируется больше уязвимостей, но вендор, скорее всего, посчитает их фолсами и обновлений не выпустит. 🤷‍♂️

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