ESXiArgs: тысячи серверов VMware зашифрованы через дыру двухлетней давности

В начале февраля 2023 по мировой инфраструктуре VMware ESXi прокатилась волна, которую сложно назвать иначе как катастрофой для тех, кто оказался на её пути. Тысячи хостов ESXi зашифрованы ransomware-кампанией, получившей название ESXiArgs. Вектор атаки - CVE-2021-21985, уязвимость двухлетней давности. Патч существовал с мая 2021 года. И тем не менее.

Мы прошлись по клиентским инфраструктурам сразу, как только первые отчёты появились в публичном пространстве. Вот что нашли и что сделали.

Что за CVE и почему это работало

CVE-2021-21985 - уязвимость в vSphere Client, плагин Virtual SAN Health Check. CVSS 9.8. Remote code execution без аутентификации, если порт 427 (SLP - Service Location Protocol) доступен из сети. Уязвимость раскрыта в мае 2021, патч VMware выпустила тогда же.

Но патч - это одно, а реальное состояние хостов в production - другое. ESXi-серверы имеют репутацию «поставил и забыл»: работает, не трогай. Плановые обновления гипервизора нередко откладываются годами, особенно если поверх него крутятся критичные VM и окно обслуживания появляется раз в несколько месяцев. Результат - флот из тысяч незапатченных хостов с торчащим в интернет портом 427.

Атака ESXiArgs использовала ещё одну особенность: после компрометации шифруются файлы конфигурации VM (.vmdk, .vmx, .vmxf, .vmsd, .nvram), что фактически делает виртуальные машины неработоспособными без дескриптора. VMFS-тома при этом нередко остаются нетронутыми - но об этом жертвы узнавали уже постфактум, после паники.

Что мы проверяли у клиентов

Первый вопрос был простым: какие хосты ESXi у нас вообще есть и какой у них патч-уровень. Звучит элементарно - на практике у нескольких клиентов этот вопрос потребовал времени.

Версия ESXi. esxcli system version get на каждом хосте. ESXi 6.5, 6.7, 7.0 - всё потенциально уязвимо без соответствующих патчей. У двух клиентов обнаружились хосты на 6.7 без обновлений с 2020 года - именно те самые «работает, не трогай».

Статус SLP. Сервис SLP (slpd) включён в ESXi по умолчанию и исторически не нужен большинству окружений. Проверка: esxcli system slp stats get или просто chkconfig slpd. Включён - значит поверхность атаки открыта даже при наличии патча, потому что могут быть другие уязвимости в том же стеке.

Доступность порта 427 извне. Это отдельный вопрос. Management-интерфейс ESXi в идеале не должен быть доступен из интернета и вообще из production-сети - только из выделенного management-сегмента. На практике у некоторых клиентов vmkernel-адаптер висит в той же сети, что и VM. Иногда это вынужденно, иногда - просто так исторически сложилось.

Что делали

Отключили SLP там, где он не нужен. А он не нужен практически нигде в типичном корпоративном окружении - это протокол обнаружения сервисов, оставшийся с времён, когда vCenter умел меньше. esxcli system slp set --slpd-enabled=false, добавить в профиль хоста, чтобы не вернулось после перезагрузки.

Поставили патчи. Там, где была возможность - без откладывания. ESXi 7.0 Update 3c или новее закрывает CVE-2021-21985. Для 6.7 патч тоже есть, для 6.5 - дата end of general support уже прошла в октябре 2022, что само по себе отдельный разговор.

Проверили сетевую изоляцию management-интерфейсов. Вот здесь оказалась самая содержательная работа. Management VLAN - не новая концепция, но реализована она часто кое-как. Либо VLAN есть, но в него кроме vmkernel-адаптеров ESXi попало ещё что-то. Либо firewall-правила на межсетевом экране слишком широкие - «management» разрешён из всей корпоративной сети, а не только с рабочих мест администраторов.

Минимальная нормальная конфигурация выглядит так:

• отдельный VLAN для management-трафика (ESXi, vCenter, iDRAC/iLO, IPMI)
• доступ в этот VLAN только с jump-хоста или через VPN с MFA
• ESXi firewall настроен явно: разрешены только нужные сервисы, ssh по умолчанию выключен если не используется активно
• никаких прямых маршрутов из production-сетей и тем более из интернета

У одного из клиентов мы обнаружили, что порт 443 vCenter был проброшен наружу «для удалённой работы администраторов». Без VPN, без MFA - просто логин-пароль. CVE-2021-21985 там был закрыт, но сама история с открытым vCenter - это уже другой риск, который мы закрыли заодно.

Что показал этот эпизод

Главное, что вскрыла ESXiArgs-кампания - не то, что CVE старые. Старые CVE были всегда. Проблема в том, что ESXi как класс инфраструктуры выпадает из привычного патч-менеджмент-цикла. Серверные ОС обновляются через WSUS или Ansible. Контейнеры пересобираются. А гипервизор - он просто работает, и его никто не трогает.

Второй момент: SLP включён по умолчанию уже много лет, хотя VMware сама рекомендовала его отключить ещё в 2021 году. Это означает, что хосты, которые поставили даже после публикации CVE, всё равно могли остаться с открытым vektором - если не прочитали KB или не прошли по чеклисту.

Мы добавили проверку статуса SLP и patch-level ESXi в стандартный чеклист аудита. Раньше это было опциональным пунктом. Теперь - обязательным.

История с ESXiArgs ещё не закончена - волна атак продолжается, и сколько хостов в итоге окажется зашифровано, станет понятно позже. Но реакция «проверить и закрыть» требовала нескольких часов, а не недель. Кто ждал - рисковал без нужды.