Компания "RESOLUTE ATTACK" приветствует вас, и сегодня мы хотим рассказать нашим читателям о новой уязвимости гипервизора VMware ESXi.
В феврале этого года мы уже слышали о массированной атаке по всему миру на данный гипервизор, но это была совсем другая история о вымогателе ESXiArgs, в ходе которой злоумышленники использовали уязвимости, такие как CVE-2021-21974 и CVE-2020-3992, в атаках на серверы с выходом в Интернет.
И снова уязвимость VMware ESXi на повестке дня.
Давайте разбираться.
Описание CVE-2023-20867
Американская ИБ-компания Mandiant обнаружила, что VMware Tools содержит уязвимость обхода аутентификации в модуле vgauth.
Компания VMware оценила серьезность этой уязвимости как низкую с максимальным базовым баллом по классификации CVSS 3.0, равным 3.9 балла, потому что для её эксплуатации требуется, чтобы злоумышленник уже получил root-доступ в целевой системе, например, через украденные учетные данные ESXi. Но данная уязвимость активно эксплуатируется китайской хакерской группировкой, известной как "UNC3886", для целевых APT-атак. Злоумышленники ранее нацеливались на жертв с помощью уязвимостей нулевого дня в брандмауэрах и продуктах виртуализации, а сейчас их цель - устройства и платформы, которые традиционно не имеют решений EDR ( это сетевые устройства, массивы SAN и VMware. хосты ESXi) и используют эксплойты нулевого дня на этих платформах.
Данная уязвимость представляет собой обход аутентификации, который можно использовать, когда злоумышленник имеет доступ с привилегированной учетной записью к хосту ESXi, а на целевой гостевой машине должно быть установлено приложение для управления программным обеспечением VMware Tools. Как только субъект получает этот доступ, CVE-2023-20867 позволяет злоумышленнику выполнять привилегированные действия на скомпрометированном хосте ESXi без необходимости аутентификации на гостевых системах Windows, Linux и PhotonOS (vCenter).
Более того, эксплойт обходит традиционные действия по ведению журнала, выполняемые либо на хосте ESXi, либо на гостевой виртуальной машине и «события регистрации не генерируются по умолчанию при успешном использовании CVE-2023-20867», — сообщили в компании Mandiant, а это может привести к более серьезными проблемами в процессе реагирования на инциденты.
Клиенты VMware c 13 июня 2023 года могут исправить уязвимость, обновив свой экземпляр VMware Tools до версии 12.2.5.
Компаниям рекомендуется использовать комплексный подход к обеспечению безопасности, который включает не только обновления программного обеспечения, но и рекомендации по усилению защиты.
История обнаружения
В конце 2022 года американская ИБ-компания Mandiant сообщила о новой вредоносной системе, развернутой китайской группировкой UNC3886, которая затронула хосты VMware ESXi, серверы vCenter и виртуальные машины Windows (ВМ).
Благодаря непрерывным исследованиям и расследованиям в области безопасности, проведенным в прошлом году, компания Mandiant обнаружила дополнительные методы, которые UNC3886 использовала в нескольких организациях, чтобы не попасть в поле зрения решений EDR, в том числе:
- Сбор учетных данных для сервисных учетных записей с сервера vCenter для всех подключенных хостов ESXi со встроенного сервера vPostgreSQL, встроенного в vCenter Server Appliance.
- Использование CVE-2023-20867, позволяющей выполнять привилегированные команды в Windows, Linux и гостевых ВМ PhotonOS (vCenter) без проверки подлинности учетных данных гостя со взломанного хоста ESXi и без ведения журнала по умолчанию на гостевых ВМ
- Развертывание бэкдоров на хостах ESXi с использованием альтернативного семейство адресов объекта Socket в пространстве имен в VMCI, для бокового перемещения и постоянного сохранения. Это семейство адресов позволяло напрямую переподключаться с любой гостевой ВМ к бэкдору скомпрометированного хоста ESXi независимо от сегментации сети или действующих правил брандмауэра.
- Возможность вмешиваться в работу служб ведения журналов и отключать их в затронутых системах, тем самым оставаясь невидимыми.
В этой статье мы дадим подробное описание пути атаки (с использованием коммуникационных сокетов VMCI).*
*По материалам компании Mandiant.
Эксплуатация уязвимости
А как же злоумышленник получил креды служебной учетной записи для компьютеров ESXi, нацелившись на сервер vCenter, к которому были подключены хосты ESXi?
Злоумышленник использует креды учетной записи vpxuser вместе с командой, которую он намеревался выполнить на гостевой виртуальной машине, запустив Python скрипт.
Эти и подобные скрипты позволили злоумышленнику выполнить следующие действия:
- получить в открытом виде пароли всех учетных записей службы vpxuser подключенного хоста ESXi со скомпрометированного сервера vCenter через подключенную базу данных vPostgreSQL;
- получить список всех хостов ESXi, подключенных к серверу vCenter, а также гостевых виртуальных машин, которые размещены на каждом из подключенных хостов ESXi.
- добавить/удалить в список разрешенных IP-адресов нужную службу (по умолчанию sshServer) на всех подключенных хостах ESXi.
Рассмотрим эти действия более подробно.
Ход выполнения
1. Сбор учетных данных vpxuser
Учетная запись vpxuser - это привилегированная учетная запись службы, которая автоматически создается на хосте ESXi при первом подключении к серверу vCenter.
Пароль для этого пользователя зашифрован и хранится в базе данных vPostgreSQL на сервере vCenter и по умолчанию автоматически меняется каждые 30 дней.
vCenter в основном использует эту учетную запись службы для административных действий, таких как перемещение виртуальных машин между разными хостами ESXi и изменение конфигураций работающих виртуальных машин.
Участники группировки UNC3886 использовали эту служебную учетную запись для развертывания вредоносных пакетов установки vSphere (VIB файлы), которые содержали бэкдор VIRTUALPITA или VIRTUALPIE.
В марте 2022 года исследователь Pentera Юваль Лазар опубликовал руководство, касающееся уязвимости повышения привилегий, CVE-2022-22948, в котором описывалось, как можно получить учетные данные vpxuser на сервере vCenter. Благодаря этой уязвимости по прежнему можно получить зашифрованные учетные данные пользователя vpxuser и взломать их, если злоумышленник смог получить root-доступ к серверу vCenter.
2. Перечисление хостов ESXi и гостевых машин
После получения учетных данных vpxuser злоумышленник использовал дополнительный сценарий для сопоставления хостов ESXi и соответствующих им гостевых ВМ.
Python скрипт использовал ту же базу данных vPostgreSQL, в которой хранятся учетные данные vpxuser, для перечисления всех хостов ESXi, подключенных к серверу vCenter, а также гостевых виртуальных машин, размещенных на каждом хосте ESXi.
3. Управление брандмауэром хоста vCenter и хоста ESXi
После определения доступных хостов ESXi и гостевых ВМ другой Python скрипт был использован для обновления списка разрешенных IP-адресов для любой службы на всех хостах ESXi, подключенных к серверу vCenter, для которого был запущен этот скрипт.
Это позволило злоумышленникам быстро внести изменения в брандмауэры нескольких хостов ESXi одновременно и по умолчанию активировало бы IP-адреса с SSH подключением к хостам ESXi.
Это также предоставило злоумышленнику простой способ замести следы, удалив тот же IP-адрес после развертывания вредоносного VIB файла, предлагая альтернативные способы повторного подключения позже.
С удаленным SSH-доступом и кредами для служебной учетной записи vpxuser на хоста ESXi были развернуты бэкдоры через зловредные VIB файлы, что позволило вредоносному ПО, упакованному внутри, выполняться каждый раз при перезапуске хоста ESXi.
VIB файлы содержали бэкдоры VIRTUALPITA и VIRTUALPIE, которые прослушивали порты TCP или VMCI.
4. Эксплуатация хоста ESXi
Установка вредоносных VIB файлов
Злоумышленники использовали манипуляцию временной меткой до установки вредоносных VIB файлов, чтобы скрыть свою активность, чтобыло видно из определенных событий в vmkwarning.log.
Скрипты установки выполнили следующие действия на целевом хосте ESXi:
- Сохранили текущее состояние брандмауэра и системное время
- Отключили брандмауэр
- Задали уровень принятия VIB как PartnerSupported
- Извлекли время установки VIB из файла: /var/db/esximg/vibs/esx-base-*.xml
- Установили системные часы на полученное время установки VIB файлов.
- Установили вредоносный VIB файл с помощью команды: esxcli software vib install -f --no-sig-check
- Перезапустили брэндмауэр
- Установили системные часы обратно на текущую дату и время
Объяснение гостевых операций VMware
Обычно для запуска Guest Operation, администратор должен пройти аутентификацию на гостевой машине с помощью одного из следующих методов:
- NamePasswordAuthentication
- SAMLTokenAuthentication
- SSPIAuthentication
- TicketedSessionAuthentication
Группировка UNC3886 выполняет вызовы API гостевых операций при взаимодействии с виртуальными машинами с хоста ESXi.
Злоумышленники смогли обойти аутентификацию с помощью гостевых виртуальных машин на хосте ESXi при выполнении гостевых операций и, следовательно, не генерировали никаких событий аутентификации в доступных журналах после успешной эксплуатации.
Эта информация была ответственно раскрыта VMware и после создания исправления уязвимость получила название CVE-2023-20867.
Злоумышленник реализовал эксплойт, запустив Python скрипт, который внедряется в работающий процесс /bin/vmx, в частности, нацеливаясь на userCredentialType, который выполняет проверки аутентификации перед выполнением гостевой операции.
На рис. 3 показан исходный код vixCommand.h с GitHub (https://github.com/vmware/open-vm-tools/blob/master/open-vm-tools/lib/include/vixCommands.h) и определено 10 типов аутентификации, встроенных в vmtools.
Вызов по умолчанию, вызванный попыткой выполнения гостевой операции, требует ввода имени пользователя и пароля (VIX_USER_CREDENTIAL_NAME_PASSWORD - тип 1) перед выполнением гостевой операции.
Эксплойт изменяет вызов userCredentityType на тип 3, который не выполняет проверки подлинности перед выполнением операции Guest.
Расследование Mandiant в отношении UNC3886 выявило дополнительные скрипты Python, которые позволили им выполнять действия на гостевых виртуальных машинах с скомпрометированных хостов ESXi. Злоумышленник использовал Python команды, приведенные в таблице 2, для изменения процесса /bin/vmx и выполнения нескольких типов гостевых операций.
Как уже упоминалось, для успеха этого эксплойта требуется доступ к административной учетной записи, такой как учетная запись vpxuser или root хоста ESXi, и vmtools, установленные на гостевой виртуальной машине.
В настоящее время при успешном использовании CVE-2023-20867 по умолчанию не создаются события регистрации. Успешное выполнение гостевых операций на гостевой виртуальной машине Windows не генерирует идентификатор события Windows 4624 или 4634 в Windows, поскольку эксплойт обходит любые требования проверки подлинности на гостевой виртуальной машине.
В Linux успешное выполнение гостевых операций с использованием этого эксплойта приводит к тому, что никакие действия не регистрируются в журналах доступа Linux.
5. Злоупотребление сокетом VMCI
Что такое сокет VMCI?
UNC3886 развертывает бэкдоры VIRTUALGATE и VIRTUALPITA с использованием сокетов VMCI для бокового перемещения и сохранения устойчивости.
На высоком уровне сокеты VMCI — это конечные точки, обеспечивающие связь с малой задержкой и высокой пропускной способностью между хостом ESXi и его гостевыми виртуальными машинами по каналу, локализованному на «голом железе», на котором запущен хост ESXi.
Поскольку этот трафик локализован на «голом железе», нет никаких механизмов безопасности, ограничивающих любую гостевую виртуальную машину или хост ESXi от инициации соединения с другой, как показано на рис. 4.
Хосты ESXi присутствуют в виртуализированной среде. Пока коммуникационный сокет клиент-сервер имеет варианты с установлением соединения и без установления соединения, очень похожие на TCP и UDP, он невидим для широко используемых сетевых инструментов, таких как tcpdump, netstat, nmap и Wireshark без пользовательских конфигураций, поскольку он принадлежит к другому семейству адресов сокетов.
Определение семейства адресов объекта Socket в пространстве имен
Сокет — это двусторонний канал связи, который действует как конечная точка для отправки и получения данных между несколькими процессами на одном компьютере или между несколькими компьютерами в сети.
Поскольку сокеты только отправляют и получают информацию, необходимо было сформулировать стандарты, чтобы полученную информацию можно было правильно интерпретировать.
Семейства адресов сокетов были созданы как стандартизированные форматы структур данных для обеспечения независимой связи через сокеты данных.
Сокеты VMCI попадают в собственное семейство адресов.
Важно помнить, что программа должна иметь код для интерпретации и подтверждения информации, передаваемой в сокеты. Если информация не соответствует критериям ожидаемого семейства адресов, она, скорее всего, будет удалена.
Маршрутизируемые идентификаторы VMCI
Подобно тому, как частные IP-адреса используются для уникальной идентификации конечных точек в локальной сети, сокеты VMCI используют идентификатор конечной точки, называемый идентификатором контекста (CID), для маршрутизации трафика в виртуализированной среде.
Хост ESXi всегда будет иметь два статических CID:
- 0 – CID с сокетами VMCI, видимыми только для хоста ESXi
- 2 – CID, маршрутизируемый к гостевым машинам и от них при открытом сокете VMCI.
CID для каждой гостевой виртуальной машины может можно найти на хосте ESXi в файле .vmx для виртуальной машины под /vmfs/volume/<Volume-ID>/<Virtual-Machine-Name>.vmx
Следующие строки в файле .vmx можно использовать для получения CID виртуальной машины:
vmci0.id = "<CID>"
Как злоумышленник может использовать это?
Группировка UNC3886 использовала нескольких бэкдоров VMCI, развернутых как вредоносные VIB файлы на хостах ESXi.
Этот открытый канал связи между гостем и хостом, где любая роль может действовать как клиент или сервер, позволил новым средствам сохраняемости восстановить доступ к заблокированному хосту ESXi, пока бэкдор развернут и злоумышленник получает первоначальный доступ к любой гостевой виртуальной машине.
Это привлекательно для злоумышленников по множеству причин, включая, но не ограничиваясь:
- Возможностью обойти сегментацию сети, обычно необходимую для доступа к узлу ESXi
- Обходом большинства проверок безопасности для открытых портов прослушивания и странного поведения NetFlow
- Восстановлением доступа к узлу ESXi, для которого требуется только доступ к любой виртуальной машине.
В сочетании с CVE-2023-20867, после восстановления доступа к хосту ESXi злоумышленник может выполнять действия без аутентификации с учетными записями с наивысшими привилегиями на любой виртуальной машине, работающей под этим хостом ESXi.
Если vCenter существует как виртуальный компьютер под хостом ESXi, злоумышленник может продолжить сбор всех подключенных учетных данных vpxuser для всех хостов ESXi, подключенных к vCenter, и продолжить боковое перемещение по среде.
Заключение
Эта статья еще раз подтверждает глубокое понимание группировкой UNC3886 тем, связанных с ESXi, vCenter и платформой виртуализации VMware.
UNC3886 по-прежнему нацелены на устройства и платформы, на которых традиционно отсутствуют решения EDR, и использует эксплойты нулевого дня на этих платформах.
UNC3886 продолжает создавать проблемы для расследования инцидентов, отключая и вмешиваясь в службы ведения журналов, выборочно удаляя события журнала, связанные с их действиями. Очистка действий злоумышленников задним числом, выполненная в течение нескольких дней после публичного раскрытия их деятельности, показывает, насколько они бдительны.
Организации должны сохранять бдительность и следить за тем, чтобы они не только контролировали свою сеть на уровне операционной системы, но и продолжали исправлять, обслуживать и контролировать устройства, на которых работает базовая инфраструктура.
Благодарим за внимание!
С любовью от RESOLUTE ATTACK!