FirstVDS: работа вендора над устранением уязвимости в VMmanager 6 всё ещё продолжается

20 октября 2026 года в FirstVDS предупредили клиентов, что работа вендора над устранением уязвимости в системе управления виртуализацией VMmanager 6 (решение входит в продуктовый портфель ГК «Астра») всё еще продолжается. «Доступ к панели виртуализации для клиентов пока останется закрытым, и, скорее всего, надолго. Основные функции управления серверами мы переносим в личный кабинет, работа уже идёт. Не исключаем, что в дальнейшем так и оставим: всё управление будет в личном кабинете», — пояснили в FirstVDS.

Параллельно отдел эксплуатации пересматривает политики безопасности внутренней инфраструктуры с учётом новых угроз и готовит доработки внутренней сети и систем обслуживания серверов.

Заказ виртуальных серверов доступен. Обработка и выдача серверов пока может занимать больше времени, чем обычно.

Поддержка работает в обычном режиме, создавать обращения снова можно. Если нагрузка резко вырастет, мы можем на время приостановить приём новых обращений, чтобы быстрее ответить на уже поступившие. В это время общие вопросы по инциденту можно задать в нашем Telegram-чате. Вопросы по конкретным услугам решаем только через обращения.

VMmanager — российская платформа серверной виртуализации, разработанная компанией ISPsystem, входящей в группу компаний (ГК) «Астра», предназначенная для создания, управления и мониторинга виртуальной ИТ-инфраструктуры.

18 октября 2026 года в FirstVDS сообщили, что злоумышленники получили доступ к части сетевой инфраструктуры компании и данным некоторых клиентов через уязвимость в системе управления виртуализацией VMmanager 6.

Внимание! Инцидент безопасности.

17 октября злоумышленники получили доступ к части нашей инфраструктуры через уязвимость в системе управления виртуализацией VMmanager 6.

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

Расследование продолжается, если что-то обнаружим, сразу напишем владельцам серверов, которых это касается.

Что произошло:

Злоумышленники запустили на части серверов нашей инфраструктуры программу для кражи данных. Она подключала диски клиентских виртуальных серверов в режиме только для чтения и копировала с них:

  • пароли, ключи доступа (SSH, API, облачные сервисы) и токены;

  • конфигурационные файлы и историю команд;

  • криптокошельки;

  • пользовательские файлы.

Собранные данные отправлялись на сервер злоумышленников.

Атака затронула не всю инфраструктуру, а только часть узлов виртуализации. Пострадали клиентские серверы, которые на них работали. Программа ничего не меняла на дисках виртуальных серверов и не запускалась внутри них. Поэтому на самом сервере следов атаки нет, и он работает как обычно.

Если вы получили уведомление в личном кабинете, считайте, что данные с сервера были скопированы.

Что уже сделали:

Сразу после обнаружения атаки мы отключили внешний доступ к системе управления виртуализацией, через которую она была проведена. Именно это сейчас защищает инфраструктуру от повторной атаки тем же способом.

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

Пока уязвимость не будет полностью устранена, доступ к системе останется закрытым.

Что нужно сделать вам, если вы получили уведомление в личном кабинете: Главный риск — в том, что злоумышленники воспользуются украденными паролями и ключами. Поэтому важно сменить их как можно скорее.

1. Криптокошельки: в первую очередь переведите средства на новые кошельки, созданные на другом, чистом устройстве.

2. Пароли и ключи: смените все пароли, SSH-ключи, API-ключи и токены, которые хранились на сервере: root и пользователей, базы данных, панели управления сайтами, почту, облачные сервисы, CI/CD, платёжные системы.

3. Отзовите старые ключи, а не просто создайте новые: в облачных консолях, GitHub/GitLab, у платёжных провайдеров.

4. Проверьте журналы входов на самом сервере и в сервисах, ключи от которых на нём лежали: не было ли входов с незнакомых адресов после 17 октября. Если злоумышленник успел войти до смены паролей, проверьте ~/.ssh/authorized_keys, новых пользователей, задания cron и службы systemd.

5. Если на сервере были персональные данные ваших клиентов, проконсультируйтесь с юристом об обязанности уведомить Роскомнадзор.

Постмортем будет опубликован после закрытия инцидента и завершения расследования. Будем обновлять данный пост по мере появления информации.

UPD. 15:25 МСК: отправили дополнительные уведомления владельцам серверов, на нодах которых нашли признаки возможной компрометации. Если вам пришло письмо, действуйте по инструкции из него.

UPD 19.10, 7:20 МСК: Ночью вендор выпустил ещё одно исправление, оно уже установлено. Уязвимость пока закрыта не полностью: вендор не рекомендует открывать доступ к панели и готовит следующие патчи. До их выхода доступ остаётся закрытым. Сообщим, как только будут новости.

Источник: habr.com

0 0 голоса
Рейтинг новости
1
0
Подписаться
Уведомить о
0 комментариев