Про уязвимость 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-служб контроллеров и рабочих станций.

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

Всегда есть риски оказаться в заложниках изменившейся политической ситуации

Всегда есть риски оказаться в заложниках изменившейся политической ситуации

Всегда есть риски оказаться в заложниках изменившейся политической ситуации. Тут в новостях показывают задержанных и избитых в Азербайджане российских IT-шников. С одним из них, фронтендером и бывшим VK-шником Дмитрием Безуглым, мы в первом круге в известной американской соцсети. Не припомню, чтобы лично общались или даже переписывались, но вот сам факт. Всё близко. Судя по профилю, он уволился из VK и релоцировался в Тбилиси в августе 2022-го года, затем перебрался в Дубай. Ну и вот оказался в гостеприимном Азербайджане в ненужное время…

Задержанных подозревают в тяжких преступлениях, среди которых и "киберпреступления". Товарищи релоцированные ИБ-шники, примите к сведению! Вам такое дело пришить смогут куда проще, чем фронтендеру.

Лучи поддержки Дмитрию и другим задержанным соотечественникам. Хочется надеяться, что их вытащат, они вернутся на Родину и перестанут уже дурака валять.

Июньский 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

Ведётся ли сейчас информационная атака на мессенджер MAX?

Ведётся ли сейчас информационная атака на мессенджер MAX?

Ведётся ли сейчас информационная атака на мессенджер MAX? Ну, очевидно, ведётся. 🙂 Кто-то накидывает за деньги из условного Тбилиси. Кто-то бесплатно готов хаять любой российский продукт, которому оказывается господдержка. А возможно конкуренты ещё надеются стать нацмессенджером вместо MAX-а от VK.

Аргументы слабенькие:

🔹 То, что мобильный клиент сделали на основе ТамТам-а неудивительно. VK реюзнули свои же наработки.

🔹 То, что хранят "IP-адрес, контакты, время активности" - а какой мессенджер не хранит? 😅

🔹 То, что опенсурсные библиотеки используют, у которых сомнительные мантейнеры и контрибьюторы - скверно, но решаемо. Форкнут или перепишут под другие. А вы уверены в зависимостях у остальных приложений на вашем смартфоне? 😏

🔹 Юридическое оформление дочки сделали неаккуратно, да. Но какая разница, если за проектом всё равно большой VK?

Настоящие проблемы MAX-а в том, что он сыроват, в нём нет каналов и нет стимула им пользоваться пока работает Телега. Ждём осени. 😉

Блокировки работают, нужно больше блокировок!

Блокировки работают, нужно больше блокировок!

Блокировки работают, нужно больше блокировок! Частенько читаю в каналах коллег, что РКН следует прекратить "неэффективные" блокировки западных веб-сервисов. Моя позиция ровно противоположная - блокировки успешны, критически важны и их следует расширять.

🔹 Благодаря блокировкам западные сервисы перестают широко использоваться в стране. Кто сейчас выкладывает ролики только на YouTube или заводит чатик в Viber? 😏 И с Cloudflare будет также. Хочешь российский трафик? Переезжай на российский CDN!

🔹 Когда западные сервисы доминируют в стране, "сковырнуть" их невозможно. Они демпингом и маркетинговыми бюджетами душат любую конкуренцию. 🤷‍♂️ Блокировки вычищают рынок на 140+ млн. человек для российских компаний, создают рабочие места, дают шанс на развитие и будущую международную экспансию. 🚀

🔹 Блокировки затрудняют зарубежным "ЦИПСО" мытьё мозгов нашим ширнармассам и способствуют сохранению стабильности в стране. 😉

Плюсы превышают любые возможные минусы и неудобства. 👍

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

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