BGP-перехват позволил подменить обновления Virtualizor
Virtualizor сообщил о BGP-перехвате, который позволил злоумышленникам перенаправить трафик Softaculous и доставить изменённый пакет обновления отдельным установкам платформы. Окно инцидента продолжалось приблизительно с 28 августа 20:57 UTC до 30 августа 06:10 UTC. Хостинг-провайдер AlbaHost заявил, что признаки компрометации с root-доступом обнаружены на 5 из 34 проверенных гипервизоров Virtualizor.
Как была доставлена подмена
По данным Virtualizor, маршрут для сервисов Softaculous был объявлен несанкционированно и трафик направлялся на сервер атакующих. Во время перенаправления злоумышленники получили действующий сертификат Let's Encrypt, поэтому пользователи не видели предупреждений браузера о недоверенном сертификате.
Сервер Virtualizor, проверявший обновления в этот период, мог получить модифицированный пакет. Клиент обновления не выполнял криптографическую проверку пакета и не мог отклонить его по этому признаку. Компания не назвала диапазон затронутых версий и не располагает исчерпывающим списком систем, получивших вредоносный пакет.
Virtualizor 1 сентября выпустил Patch 9 с инструментом Security Analyzer для веток release candidate и stable. В уведомлении об инциденте релиз обозначен как Virtualizor 3.2.9.9, а в примечании к выпуску — как Virtualizor 3.2.9 Patch 9. Криптографическая подпись пакетов остаётся запланированной, но пока не реализованной мерой.
Признаки закрепления на хосте
AlbaHost сообщил, что вредоносные команды были внедрены в три штатных файла Virtualizor и позднее выполнялись заданием root cron. Код добавлял контролируемый атакующим ключ к учётной записи root, при отсутствии среды устанавливал Java 17, загружал Java-полезную нагрузку и запускал её с правами root.
Полезная нагрузка закреплялась через службу systemd и создавала несанкционированную учётную запись proxyuser. В журналах провайдера зафиксирован успешный SSH-вход с паролем в эту учётную запись с адреса 193.32.127[.]248. В проверенной среде AlbaHost не подтвердил модификацию клиентских VPS и отдельно не подтвердил выгрузку базы данных.
Что проверить операторам
Virtualizor рекомендует проверить каждый сервер, а не только определённые версии. В числе известных индикаторов — служба /etc/systemd/system/java-jre-update.service, файл полезной нагрузки /usr/lib/jvm/.cache/jre-runtime.dat, изменённые файлы globals.php, _universal.php и zzvirtservice в каталоге Virtualizor, а также следы незнакомых ключей SSH, пользователей, cron-задач и исходящих соединений.
Операторам следует запустить официальный сканер, сменить все API-ключи Virtualizor, ограничить доступ к API и SSH доверенными IP-адресами и удалить неизвестные ключи. При положительном результате поставщик просит до исправления обратиться в поддержку для сохранения доказательств. Изменённые основные файлы нужно восстанавливать из доверенного источника или переустанавливать; AlbaHost считает чистую пересборку единственным надёжным долгосрочным способом восстановления хоста с подтверждённой root-компрометацией.
Пользователям клиентской зоны, входившим в период инцидента или вводившим платёжные данные, Virtualizor советует сменить пароль, проверить активность аккаунта и выписки по карте. Для бизнеса практический вывод состоит в том, что проверка обновлений и контроль целостности пакетов должны рассматриваться как часть защиты инфраструктуры: без подписи пакета защищённое TLS-соединение не гарантирует его подлинность.