Что такое VMware ESXi и зачем он вообще нужен

Гипервизор появился как способ уместить двадцать серверов в одном. Для системных администраторов это удобство. Для злоумышленников: шанс зашифровать двадцать машин одним исполняемым файлом. Именно поэтому VMware ESXi стал главной целью ransomware-групп в последние годы.

Чтобы понять, почему атаки на ESXi так болезненны, нужно сначала разобраться в его архитектуре.

В обычном серверном rack стоят физические машины: одна гоняет почтовый сервер, другая базу данных, третья веб-приложение. Купить и поддерживать каждый сервер отдельно дорого, а ресурсы на них чаще всего используются на 10-20% мощности. Виртуализация решает эту проблему: одно физическое железо делится на несколько изолированных виртуальных машин, каждая из которых думает, что работает на своём собственном сервере.

Rack стандартизированная металлическая конструкция для монтажа серверного и сетевого оборудования, где все размеры привязаны к единице «U» (rack unit) равной 1,75 дюйма или 44,45 мм. Стойка превращает разрозненное железо в упорядоченную систему с предсказуемой геометрией, охлаждением и кабельной инфраструктурой.

По типу ESXi относится к гипервизорам первого типа (Type 1, bare-metal). Он устанавливается напрямую на серверное железо и запускается без промежуточной операционной системы. Под ним нет Windows или Linux, только тонкий слой vmkernel, который управляет физическими ресурсами и распределяет их между виртуальными машинами. Такой подход снижает накладные расходы и уменьшает потенциальную поверхность атаки по сравнению с гипервизорами второго типа вроде VirtualBox или VMware Workstation.

Для управления несколькими хостами ESXi используется vCenter Server. Без него каждый физический сервер с ESXi управляется изолированно через локальный веб-интерфейс. С vCenter появляется централизованная консоль, возможность переносить виртуальные машины между хостами без остановки (vMotion), автоматическое распределение нагрузки (DRS) и перезапуск машин при сбое оборудования (High Availability). VMware, ESXi и vCenter вместе образуют то, что принято называть vSphere.

Цифры по распространению говорят сами за себя. ESXi занимает большую часть корпоративного рынка виртуализации и работает в большинстве серьёзных дата-центров. Банки, страховые компании, телеком, производство: почти везде, где есть серверная комната с несколькими стойками, с высокой вероятностью найдётся хост с ESXi.

Почему ESXi стал приоритетной целью для ransomware

Логика проста до неудобства.

Ransomware-группа, взломавшая один физический сервер в традиционной инфраструктуре, зашифровала один сервер. В виртуализованной среде взлом гипервизора означает доступ ко всем виртуальным машинам на нём одновременно. Если их двадцать, всё зашифровывается за одну сессию. Если несколько хостов ESXi управляются через vCenter, компрометация сервера управления открывает все хосты разом.

Дополнительный фактор: ESXi работает на Linux-подобном ядре и шифровальщик для него пишется один раз. Он не требует отдельных версий под Windows-машины, не нужно обходить разные EDR-решения на каждом эндпоинте. Атакующий разворачивает один Linux-бинарник, останавливает виртуальные машины, шифрует файлы дисков и уходит.

Группы Babuk, Nevada, Royal, BlackBasta, LockBit: у каждой из них есть ESXi-энкодеры для Linux. После утечки исходного кода Babuk в 2021 году порог разработки упал ещё ниже: новый ESXi-шифровальщик стало можно собрать на основе готового, просто изменив несколько параметров.

Ещё один момент, который часто упускают: ESXi шифруется иначе, чем обычная файловая система Windows. Атакующий целится в конкретные расширения файлов виртуальных дисков: .vmdk, .vmx, .vmxf, .vmsd, .vmsn, .vswp, .vmss, .nvram, .vmem. Зашифровать конфигурационный файл .vmx достаточно, чтобы виртуальная машина перестала запускаться, даже если данные на диске (.vmdk) не тронуты. Именно это позволило части жертв ESXiArgs восстановить данные без оплаты выкупа.

Кампания ESXiArgs: как выглядела атака на 3000+ серверов

3 февраля 2023 года французский CERT-FR и облачный провайдер OVH объявили тревогу: тысячи серверов ESXi по всему миру атаковал новый шифровальщик. К концу первой недели было компрометировано больше 3200 устройств. Серьёзнее всего пострадали Франция, США, Германия, Канада и Великобритания.

Атака эксплуатировала CVE-2021-21974, уязвимость переполнения кучи (heap overflow) в сервисе OpenSLP, который ESXi запускает по умолчанию на порту 427. Patch для неё VMware выпустил ещё 23 февраля 2021 года. Разрыв между патчем и массовыми атаками составил почти два года.

OpenSLP расшифровывается как Open Service Location Protocol, сетевой сервис обнаружения ресурсов. По умолчанию он открыт на всех установках ESXi без аутентификации. Злоумышленнику, находящемуся в той же сети или имеющему доступ к порту 427 из интернета, не нужны никакие учётные данные: достаточно отправить специально сформированный запрос, который переполняет буфер и приводит к выполнению произвольного кода с правами root.

Rapid7 в разгар кампании обнаружила около 18 000 уязвимых ESXi-серверов, доступных из интернета. Из них часть уже была взломана, часть оставалась под угрозой. Атака была полностью автоматизированной: скрипт проверял доступность порта 427, эксплуатировал уязвимость, останавливал виртуальные машины командой kill к процессу VMX, после чего шифровальщик проходился по файлам дисков.

Деталь, которая помогла части жертв: шифровальщик в ряде случаев шифровал только конфигурационные файлы, оставляя плоский файл диска (.vmdk-flat) нетронутым. Турецкие исследователи Энес Сёнмез и Ахмет Айкач из YoreGroup Tech Team разработали процедуру восстановления, которую CISA впоследствии оформила в официальный recovery-скрипт ESXiArgs-Recover. Успех восстановления составлял примерно две трети случаев при наличии нужных навыков.

Главный вывод кампании: не zero-day, не сложная цепочка из нескольких уязвимостей, не социальная инженерия. Двухлетний непропатченный баг в сервисе, который вообще не нужен большинству организаций, плюс открытый порт наружу.

Что произошло с VMware после покупки Broadcom

В ноябре 2023 года Broadcom завершил приобретение VMware за $61 млрд. Следом последовала волна изменений в лицензировании, которая задела большинство существующих клиентов сильнее, чем любая кибератака.

С 15 января 2024 года прекратилась продажа бессрочных (perpetual) лицензий на все продукты VMware. В феврале 2024 года была закрыта бесплатная версия ESXi Hypervisor: Broadcom объявил о прекращении её общей доступности (End of General Availability). Лицензирование перешло на подписочную модель с тарификацией по ядрам процессора. При этом минимум считается как 16 ядер на один CPU, даже если физически их меньше.

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

Практический эффект для небольших и средних организаций оказался ощутимым: стоимость лицензирования выросла, модель «купил один раз» исчезла, бесплатного варианта для лабораторий и тестовых сред больше нет. Часть организаций начала миграцию на Proxmox VE (открытый гипервизор на базе KVM и Debian), другие рассматривают Hyper-V или XCP-ng.

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

Как атакуют ESXi сегодня

Уязвимость OpenSLP из CVE-2021-21974 уже не актуальна для обновлённых систем: VMware отключил OpenSLP по умолчанию начиная с ESXi 7.0 U2c и ESXi 8.0. Однако устаревших установок по всему миру осталось много, и атаки продолжаются по нескольким векторам.

В июле 2024 года Microsoft задокументировала CVE-2024-37085, уязвимость обхода аутентификации через Active Directory в ESXi. Если хост ESXi добавлен в домен AD и там создана группа с конкретным именем, любой пользователь этой группы получает полный административный доступ к гипервизору. Группы Storm-0506, Storm-1175, Manatee Tempest и Octo Tempest использовали эту уязвимость для развёртывания Black Basta и Akira ransomware.

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

Получив доступ к гипервизору с правами root или administrator, злоумышленник может остановить все виртуальные машины командой через CLI, зашифровать файлы дисков, а после перезагрузки машины не запустятся. Резервные копии, которые хранятся на тех же виртуальных дисках или в общей NFS/SAN-сети, доступной с хоста ESXi, тоже попадают под шифрование.

Как защитить ESXi

Большинство успешных атак на ESXi не требовали сложных техник. Они эксплуатировали базовые проблемы конфигурации, которые устраняются без специализированных инструментов.

Управленческий интерфейс не должен смотреть в интернет. Порты 443 (веб-консоль), 902 (VMware Remote Console), 427 (OpenSLP, если включён) должны быть доступны только из сети управления, изолированной от интернета и от пользовательских сегментов. Фундаментальное требование, которое нарушается регулярно.

OpenSLP нужно отключить, если он не используется. На подавляющем большинстве установок он не нужен. Команды для отключения:

/etc/init.d/slpd stop
esxcli network firewall ruleset set -r CIMSLP -e 0
chkconfig slpd off

Обновления нужно ставить. Звучит банально, но ESXiArgs атаковала двухлетние непропатченные серверы. Патчинг ESXi требует краткой перезагрузки хоста с предварительной миграцией виртуальных машин на другой хост (vMotion). При наличии кластера это выполняется в плановом режиме без остановки сервисов.

Многофакторная аутентификация для vCenter и ESXi снижает риск компрометации через подбор паролей. Интеграция с Active Directory удобна, но требует аккуратной настройки: CVE-2024-37085 показала, что неправильная конфигурация AD-интеграции открывает полный доступ к гипервизору.

Резервные копии должны храниться изолированно от основной сети ESXi. Если Veeam Backup & Replication находится в той же сети, что и гипервизоры, и атакующий получил доступ к хосту ESXi, резервные копии также могут быть уничтожены до развёртывания шифровальщика.

Чеклист для проверки ESXi-инфраструктуры:

[√] Порт 443 (веб-консоль) закрыт из интернета [√] OpenSLP отключён или порт 427 заблокирован на файрволе [√] Установлены актуальные патчи ESXi [√] Резервные копии хранятся в изолированной сети [ ] Включена многофакторная аутентификация для vCenter [ ] Настроен мониторинг входов и изменений конфигурации на хостах [ ] Проверена конфигурация AD-интеграции (нет группы ESX Admins с неконтролируемым членством) [x] Интерфейс управления доступен напрямую из интернета [x] Резервные копии хранятся на NFS-шаре, монтированной на хостах ESXi

Что делать с лицензированием сейчас

Для организаций, которые используют ESXi и ещё не разобрались с последствиями смены лицензионной политики Broadcom, ситуация выглядит так.

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

Новые подписки считаются по ядрам. Минимальный размер ядер на один физический CPU: 16. Если в сервере стоят два процессора по 8 ядер, лицензируется 32 ядра (2×16 минимум), не 16. Для небольших серверов это существенно увеличивает стоимость.

Альтернативы с открытым кодом: Proxmox VE на базе KVM и QEMU, XCP-ng на базе XenServer, oVirt/Red Hat Virtualization на базе KVM. У каждого есть ограничения по экосистемной интеграции, но функциональность для большинства корпоративных задач покрывается. Proxmox в последние два года получил значительный прирост пользователей именно благодаря лицензионным изменениям VMware.

Миграция с ESXi на другую платформу занимает время и несёт риски. Виртуальные машины нужно конвертировать (VMDK в QCOW2 или аналог), проверить совместимость драйверов внутри ВМ, перенастроить сетевые конфигурации. Делать это в спешке под давлением заканчивающегося контракта: плохая идея. Планировать переход нужно заранее, с тестовым окружением и запасом времени.


#кибербезопасность #информационнаябезопасность #инфобез #технологии #IT #безопасностьIT #безопасностьсети #киберугрозы #защитаданных #инновации #программирование #киберриски #безопасность

Оставьте комментарий