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

Тоже напишу об уязвимости VMmanager 6, через которую поломали инфраструктуру FirstVDS

Тоже напишу об уязвимости VMmanager 6, через которую поломали инфраструктуру FirstVDS

Тоже напишу об уязвимости VMmanager 6, через которую поломали инфраструктуру FirstVDS. FirstVDS - провайдер VDS-хостинга, позволяющий арендовать виртуальные серверы для размещения сайтов, запуска приложений и решения других задач. 18 октября в канале компании сообщили об инциденте безопасности. Днём ранее, 17 октября, злоумышленники воспользовались уязвимостью в системе управления виртуализацией VMmanager 6, получили доступ к части инфраструктуры и запустили на некоторых серверах программу для кражи данных.

VMmanager - продукт иркутской компании ISPsystem, входящей в группу компаний "Астра". Хостинг-провайдеры используют его для создания виртуальных серверов и управления ими. Эксплуатация уязвимости (обозначу как "VMleaker6") позволила злоумышленникам получать доступ к серверам клиентов, в том числе к дискам виртуальных машин. По имеющимся данным, вредоносная программа подключала диски в режиме чтения и копировала хранившуюся на них информацию на сервер злоумышленников. Среди потенциально скомпрометированных данных - файлы, пароли, ключи доступа, токены, конфигурационные файлы, базы данных, резервные копии и данные криптокошельков. 😱

В таких ситуациях возможны два варианта: либо уязвимость была известна, но FirstVDS не установили обновление безопасности вовремя, либо злоумышленники проэксплуатировали 0day-уязвимость, от которой провайдер не мог защититься в рамках Vulnerability Management процесса.

Судя по всему, мы имеем дело со вторым вариантом:

🔻 Ещё 14 октября в ИБ-каналах ходили неподтверждённые данные о 0day-уязвимости VMmanager 6, проэксплуатированной у нескольких хостинг-провайдеров и позволяющей злоумышленнику получить root-доступ к гипервизору, то есть доступ ко всем виртуальным серверам на ноде. Также сообщали, что уязвимость эксплуатируется через интерфейс панели, поэтому под ударом те хостеры, которые дают клиентам прямой доступ к ней.

🔻 Эксперты FirstVDS сообщали о промежуточном патче и работе ISPsystem над окончательным исправлением.

🔻 В последние несколько дней ISPsystem выпускает обновления безопасности VMmanager одно за другим. С 14 октября были выпущены обновления 2026.09.1-1, 2026.09.1-2, 2026.09.1-3, 2026.09.1-4 и 2026.09.1-5. Последние четыре обновления были выпущены начиная с 18 октября (раз в день и два раза в день). При этом не указано, какие именно уязвимости исправляются, - приведён только текст "Исправление ошибок безопасности".

Что тут скажешь: от эксплуатации 0day-уязвимостей никто не застрахован. Злоумышленник может самостоятельно наресёрчить уязвимость в используемом ПО или купить эксплойт на чёрном рынке. Особенно опасны ситуации, когда админка доступна из внешней сети или компрометация инфраструктуры провайдера клиентом-злоумышленником позволяет получить доступ к данным других клиентов. Тут напрашивается параллель с недавней RCE в cPanel (CVE-2026-87899), приводившей к компрометации клиентов shared-хостингов.

К FirstVDS особых вопросов нет: они обнаружили инцидент, сообщили о нём и дали клиентам рекомендации. К ISPsystem вопросов больше. Вендор выпускает обновления безопасности VMmanager, но публичных бюллетеней с описанием исправленных уязвимостей нет. В БДУ ФСТЭК информация о новых уязвимостях, связанных с инцидентом, тоже пока не появилась. Это выглядит как silent patching. 😔 ИМХО, для зрелого вендора такой подход недопустим: нужны публичные бюллетени с описанием уязвимостей, исправлений и workaround-ами. А пока нет даже новости на сайте. 🤷‍♂️ Будем следить за развитием ситуации и ждать открытой коммуникации от вендора.

Upd. Новость добавили.

Безусловные регулярные обновления - путь реалиста

Безусловные регулярные обновления - путь реалиста

Безусловные регулярные обновления - путь реалиста. Ставшие публичными кейсы Silent Patching-а демонстрируют беспомощность Vulnerability Management-а перед реальностью, в которой мы знаем об уязвимостях продуктов только то, что нам по доброй воле сообщает вендор. Дал информацию вендор - мы разбираем CVE-шки и умничаем о приоритетах их устранения в конкретной инфре. Не дал - мы пребываем в сладких иллюзиях, что всё безопасно вплоть до начала массовых инцидентов. 🤷‍♂️

Можно сколько угодно ворчать, что вендор не должен иметь возможности скрывать инфу по уязвимостям в собственных продуктах. Но они скрывают! 🙂

Единственный вариант снизить риски - принять реальность такой, как она есть. Наши знания об уязвимостях ограничены. Видишь в инфре не обновленный до последней версии софт - обнови его! Семь бед - один apt-get update && apt-get upgrade! 😅 Может обновление не исправляет критичную уязвимость, а может исправляет. 😉 Достоверно нам об этом знать не дано. 🤷‍♂️

Про Silent Patching на примере кейса Аспро

Про Silent Patching на примере кейса Аспро

Про Silent Patching на примере кейса Аспро. Эта компания предлагает услуги по запуску и миграции сайтов с использованием своего решения на базе 1С-Битрикс.

14 октября 2024 года центр кибербезопасности белорусского хостинг-провайдера HosterBy сообщил об обнаружении цепочки взломов веб-сайтов на основе решения Аспро (по большей части интернет-магазинов). RCE уязвимость связана с использованием небезопасной PHP-функции unserialize. Уязвимы версии Аспро:Next до 1.9.9.

6 февраля 2025 в блоге Аспро вышел пост, в котором они презентовали бесплатный скрипт-патчер, исправляющий уязвимость. 👍 Но там же они пишут, что сами нашли и исправили эту уязвимость ещё в 2023 году, но "намеренно не афишировали детали".

✅ Те, кто платили Аспро за поддержку и обновлялись до последней версии, были в безопасности.

❌ А те, кто обновлялись только при детекте уязвимости - нет. Информации по уязвимости не было. Ни CVE, ни BDU. 😏

И вендор ответственности за сокрытие не несёт. 🤷‍♂️

На предложение спрашивать с вендоров за уязвимости можно возразить, что они просто начнут свои уязвимости замалчивать

На предложение спрашивать с вендоров за уязвимости можно возразить, что они просто начнут свои уязвимости замалчивать

На предложение спрашивать с вендоров за уязвимости можно возразить, что они просто начнут свои уязвимости замалчивать. И сейчас отечественные вендоры не любят сообщать об уязвимостях в своих продуктах, а так совсем ягнятки замолчат. 🤐

И тут я сформулирую предложение, без которого первое не работает. Если вендор знает об уязвимости в версии своего продукта, используемой у клиентов, и этот факт замалчивает, то это должно классифицироваться как КРАЙНЕ серьёзное нарушение. Если такая ситуация вскрывается, то

🔹 сертификат продукта должен отзываться, лицензия вендора анулироваться, назначаться крупный штраф

🔹 ответственный (гендир) должен лично нести за это уголовную ответственность

По какой статье? Имхо, стоит расширить 274.1, т.к. такое замалчивание создаёт риски для КИИ.

Следует сделать так, чтобы между публикацией информации об уязвимости (и последующим объяснением с регулятором) и замалчиванием вендору ВСЕГДА рационально было бы сделать выбор в пользу первого.