0:00:00.000,0:00:18.746
36c3 preroll
0:00:18.746,0:00:25.030
Herald: So like many operators, in my[br]group, we actually use a lot of ESXi
0:00:25.030,0:00:27.870
servers. You would think that after using[br]these things for 10 years, I would know
0:00:27.870,0:00:35.050
how to speak, but I do not. We use these[br]for virtualizing machines. Some of... some of
0:00:35.050,0:00:39.920
these actually runs on sandboxes or, you[br]know, run kind of dubious software on it.
0:00:39.920,0:00:45.530
So we really do want to prevent these[br]processes from jumping from the virtual
0:00:45.530,0:00:54.489
environment to the hypervisor environment.[br]We have today - we have - f1yyy, he wants
0:00:54.489,0:01:02.620
to be known by f1yyy, so I'm respecting[br]that; and he's from Triton Security Labs,
0:01:02.620,0:01:09.670
and he's going to show us how the exploits[br]that he discovered in the, I think it was
0:01:09.670,0:01:15.490
the last Chinese GeekPwn capture the flag.[br]He's gonna show us how these things work,
0:01:15.490,0:01:21.970
and was that I would like to help. I would[br]like to ask you, to help me, welcome f1yyy
0:01:21.970,0:01:23.645
onto the stage.
0:01:23.645,0:01:28.630
applause
0:01:28.630,0:01:41.671
f1yyy: Hello. Thanks for the introduction.[br]Good evening, everybody. I'm f1yyy a
0:01:41.671,0:01:49.130
Senior Security Researcher at Chaitin[br]Technology. I'm going to present The Great
0:01:49.130,0:01:56.880
Escape of ESXi; Breaking Out of a[br]Sandboxed Virtual Machine. We have
0:01:56.880,0:02:05.460
demonstrated this exploit chain before at[br]GeekPwn 2018. I will introduce our
0:02:05.460,0:02:12.060
experience of escaping the sandbox on the[br]ESXi. I will also introduce the work we
0:02:12.060,0:02:23.020
have done about the sandbox on the ESXi.[br]Now let's start it. We come from the
0:02:23.020,0:02:28.690
Chaitin Security Research Lab. We have[br]researched many practical targets in
0:02:28.690,0:02:35.750
recent years, including PS4 jailbreak,[br]Android rooting, IoT offensive research,
0:02:35.750,0:02:43.740
and so on. Some of us also play CTF with[br]Team b1o0p and Tea Deliverers. We recently
0:02:43.740,0:02:51.720
own the championship at HITCON final. We[br]are also the organizer of the Real World
0:02:51.720,0:02:58.680
CTF. We've created some very hard[br]challenges this year. So if you are
0:02:58.680,0:03:09.400
interested in it, we welcome you to[br]participate in our CTF game. Now, before
0:03:09.400,0:03:16.150
we start our journey to escaping the[br]virtual machine, we need to figure out
0:03:16.150,0:03:24.930
what is virtual machine escape? I like to[br]ask some of you that, did anyone use the
0:03:24.930,0:03:32.130
virtualization software? If you have used[br]the virtualization software, like VMware
0:03:32.130,0:03:41.200
Workstation, Hyper-V, VirtualBox and so[br]on, please raise your hand. Okay, okay,
0:03:41.200,0:03:50.250
okay. Thanks, thanks, thanks. Many. So if[br]you are a Software Engineer or a Security
0:03:50.250,0:03:58.930
Researcher, you'll probably have used[br]virtualisation software, but if anyone has
0:03:58.930,0:04:03.730
heard of the word virtual machine escape,[br]if you have heard of that, please raise
0:04:03.730,0:04:12.870
your hand again. Oh, oh, surprised.[br]Thanks, thanks, thanks. It surprises me
0:04:12.870,0:04:20.560
that all you know about that, but I have[br]to introduce that again. What's virtual
0:04:20.560,0:04:25.240
machine escape? You know, in most[br]circumstances the host OS runs on the
0:04:25.240,0:04:32.690
hypervisor and the hypervisor will handle[br]some sensitive instructions executed by
0:04:32.690,0:04:40.090
the guest OS. Host OS emulates virtual[br]hardware and handles RPC requests from the
0:04:40.090,0:04:49.500
guest OS. That's the architecture of[br]normal virtualization software. And the
0:04:49.500,0:04:59.340
guest OS is isolated from each other and[br]cannot affect the host OS. However, if
0:04:59.340,0:05:04.660
there are some bugs, or if there are some[br]vulnerabilities existing in the host OS,
0:05:04.660,0:05:13.150
it's possible for the guest OS to escape[br]from the virtualization environment. They
0:05:13.150,0:05:21.139
can exploit these vulnerabilities. And[br]finally, they can execute arbitrary code
0:05:21.139,0:05:30.880
on the host. So this is the Virtual[br]Machine Escape. Then why we chose ESXi as
0:05:30.880,0:05:39.220
our target? The first reason is we know[br]that more and more companies are using or
0:05:39.220,0:05:48.552
plan to use private cloud to store its[br]private data, including these companies
0:05:48.552,0:05:56.670
and the vSphere is an enterprise solution[br]offered by VMware. It's popular between
0:05:56.670,0:06:02.600
companies. If you are a Net-Manager of a[br]company, you may know about VMware
0:06:02.600,0:06:11.810
vSphere. And the ESXi is the hypervisor[br]for VMware vSphere, so it's widely used in
0:06:11.810,0:06:17.810
private cloud. That's the first reason.[br]The second one is that it's a challenging
0:06:17.810,0:06:24.740
target for us. There are several[br]exploitations of VMware Workstation in
0:06:24.740,0:06:30.790
recent years. Hackers escape from the[br]VMware Workstation by exploiting some
0:06:30.790,0:06:38.520
vulnerabilities. These vulnerabilties[br]exist in graphic cards, network cards and
0:06:38.520,0:06:48.820
USB devices and so on. But, there has been[br]no public escape of ESXi before, so it's a
0:06:48.820,0:06:58.311
challenging target for us and we love[br]challenge. Then why is the ESXi so
0:06:58.311,0:07:04.930
challenging? The first reason I think is[br]that there are little documents about its
0:07:04.930,0:07:13.640
architecture. The only thing we have found[br]is a white paper offered by VMware. The
0:07:13.640,0:07:20.490
white paper only includes some definitions[br]and pictures without details. So let's
0:07:20.490,0:07:29.460
take a brief look at the architecture of[br]ESXi first. ESXi is an Enterprise bare-
0:07:29.460,0:07:35.800
metal hypervisor and it includes two[br]parts. The kernel, it uses VMKernel
0:07:35.800,0:07:42.069
developed by VMware and the User Worlds[br]and the other part, the User Worlds. The
0:07:42.069,0:07:51.476
VMKernel is a POSIX-like operating system.[br]And it is uses an in-memory filesystem. It
0:07:51.476,0:07:59.291
means that all files stored in this system[br]are not persistent. And the VMKernel also
0:07:59.291,0:08:08.470
manages hardware and schedules resource[br]for ESXi. VMKernel also includes VMWare
0:08:08.470,0:08:15.335
drivers, I/O Stacks and some User World[br]APIs offered to the User Worlds. And the
0:08:15.335,0:08:25.560
word "User World" is used by VMWare to[br]refer the processes running in VMKernel
0:08:25.560,0:08:31.770
operating system and the word "User World"[br]means that a group of these processes.
0:08:31.770,0:08:38.300
This process can only use a limited /proc[br]directory and limited signals and it can
0:08:38.300,0:08:45.070
just use some of the POSIX API. For[br]example, there are some User Worlds
0:08:45.070,0:08:55.880
processes like hosted, ssh, vmx and so on.[br]Then this is the architecture of ESXi. I
0:08:55.880,0:09:02.814
would like to give you an example to show[br]how a virtual machine works on ESXi. The
0:09:02.814,0:09:09.249
VMX process in the User World can[br]communicate with the VMM by using some
0:09:09.249,0:09:18.829
undocumented customized system call. And[br]the VMM will initialize the environment
0:09:18.829,0:09:27.420
for the guest OS. When guest OS executes[br]some sensitive instructions, it will cause
0:09:27.420,0:09:35.490
a VMExit and return to VMM. The VMX[br]process also emulates virtual hardware and
0:09:35.490,0:09:41.449
handles RPC requests from the guest.[br]That's how a virtual machine works on
0:09:41.449,0:09:49.336
ESXi. Then, how can we escape from the[br]virtual machine on ESXi? If there is a
0:09:49.336,0:09:57.779
vulnerability in the virtual hardware of[br]the VMX, we can write a driver, or write
0:09:57.779,0:10:07.410
an exploit, to escape from it. The driver[br]will communicate with the virtual hardware
0:10:07.410,0:10:14.480
and it can exploit the vulnerability. And[br]finally we can execute shellcode in the
0:10:14.480,0:10:19.850
VMX process. So it means that we have[br]successfully escaped from the virtual
0:10:19.850,0:10:28.269
machine on the ESXi. So the second reason[br]about why ESXi is so challenging, is that
0:10:28.269,0:10:40.279
User World API. The VMX uses many[br]undocumented and customized system calls
0:10:40.279,0:10:46.519
and if you want to reverse some code of[br]VMX it is hard for you to understand which
0:10:46.519,0:10:55.629
API the VMX is using. But luckily we found[br]two system call tables after compromising
0:10:55.629,0:11:04.660
the k.b00 field. There are 2 system call[br]tables we found with symbols so this field
0:11:04.660,0:11:11.740
will be useful if we want to reverse some[br]code of the VMX. This is the second
0:11:11.740,0:11:20.870
reason. Thirdly, there are some security[br]mitigations here, including ASLR and NX.
0:11:20.870,0:11:27.410
It means that we need to link some address[br]information before we start our exploit
0:11:27.410,0:11:34.670
to break the randomness of the address[br]space. Furthermore after testing we found
0:11:34.670,0:11:43.970
that there is another mitigation on the[br]ESXi. There is a sandbox that isolates the
0:11:43.970,0:11:50.720
VMX process. So even if you can execute[br]some shellcode in the VMX process you can
0:11:50.720,0:11:57.949
not execute any commands, you can not read[br]any sensitive fields, unless you escape
0:11:57.949,0:12:06.720
from the sandbox either. And finally, we[br]think that the VMX of ESXi has a smaller
0:12:06.720,0:12:13.651
attack surface. After comparison of the[br]VMX binary between the Workstation and the
0:12:13.651,0:12:20.920
ESXi we found that there are some function[br]that have been moved from the VMX in User
0:12:20.920,0:12:28.079
World to the VMKernel. For example the[br]packet transmission function in the e1000
0:12:28.079,0:12:37.679
net card has been moved from the VMX to[br]the VMKernel. And if you have read some
0:12:37.679,0:12:44.569
security advisories published by VMware[br]recently, you can notice that there are
0:12:44.569,0:12:52.850
many vulnerabilites existing in the packet[br]transmission part of the e1000 net card.
0:12:52.850,0:13:00.689
And all these vulnerabilites only affect[br]Workstation. So we think that the VMX of
0:13:00.689,0:13:09.540
ESXi has a smaller attack surface. Now[br]let's start the journey of escaping from
0:13:09.540,0:13:17.600
the ESXi. Let's overview the entire[br]exploit chain first. We use 2 memory
0:13:17.600,0:13:23.709
corruption vulnerabilites in our exploit.[br]The first one is an uninitialized stack
0:13:23.709,0:13:31.529
usage vulnerability which CVE Number is[br]CVE-2018-6981. And the second is an
0:13:31.529,0:13:40.825
unitialized stack read vulnerability and[br]the CVE number is CVE-2018-6982. And we
0:13:40.825,0:13:46.799
can do arbitrary address free by using the[br]first vulnerability, and we can get
0:13:46.799,0:13:52.906
information leakage from the second one.[br]After combining of these two
0:13:52.906,0:14:00.059
vulnerabilites we can do arbitrary[br]shellcode execution in VMX process. And
0:14:00.059,0:14:09.589
finally we use a logic vulnerability to[br]escape the sandbox of VMX and reverse a
0:14:09.589,0:14:16.959
root shell from the ESXi. So that's the[br]entire exploit chain we use. Now let's
0:14:16.959,0:14:24.329
start the first one. The first[br]vulnerability is an uninitialized stack
0:14:24.329,0:14:32.749
usage vulnerability. It exists in VMXNET3[br]netcard. When the VMX VMXNET3 netcard
0:14:32.749,0:14:39.939
tries to execute command[br]UPDATE_MAC_FILTERS it will us a structure
0:14:39.939,0:14:47.749
on the stack, the PhysMemPage structure.[br]This structure is used to represent the
0:14:47.749,0:14:54.410
memory mapping between the guest and the[br]host. And it's also been used to transport
0:14:54.410,0:15:01.809
data between the guest and the host. Then[br]the VMXNET will call function
0:15:01.809,0:15:07.799
DMA_MEM_CREATE to initialize the structure[br]on the stack first, then it will use this
0:15:07.799,0:15:16.379
structure to execute this command. And[br]finally it uses PhysMemRelease to destroy
0:15:16.379,0:15:23.410
the structure, the physical memory page[br]structure. So it seems that there are no
0:15:23.410,0:15:30.829
problems here. But if we look at the[br]function DMA memory create, we can notice
0:15:30.829,0:15:39.609
that there is a check before the[br]initialization of the PhysMemoryPage
0:15:39.609,0:15:47.399
structure. It will check the argument[br]address and the argument size and if the
0:15:47.399,0:15:54.410
check passes then it will initialize the[br]structure. But if the check fails, it will
0:15:54.410,0:16:02.350
never initialize the structure on the[br]stack. And finally we found that we can
0:16:02.350,0:16:13.269
control the address argument by writing a[br]value to one of the registers of VMXNET3.
0:16:13.269,0:16:18.389
What is worse is that in function[br]PhysMemoryRelease there are no checks
0:16:18.389,0:16:24.819
about if the PhysMemoryPage structure had[br]been initialized and it just frees a
0:16:24.819,0:16:34.189
pointer of this structure. So that's it[br]about it. If we can pad the data on the
0:16:34.189,0:16:42.430
stack it's possible for us to do arbitrary[br]address free. We can pad a fake
0:16:42.430,0:16:47.989
PhysMemoryPage structure on the stack and[br]then make the check fail in the function
0:16:47.989,0:16:53.759
DMA memory create and finally when it[br]comes to the PhysMemoryRelease it will
0:16:53.759,0:17:01.669
free a pointer of our PhysMemoryPage[br]structure. So we just try to find a
0:17:01.669,0:17:09.710
function to pad the data on the stack.[br]There is a design pattern in software
0:17:09.710,0:17:18.031
development, where we store the data into[br]the stack, if the size is small, when we
0:17:18.031,0:17:25.541
allocate some memory. And otherwise we[br]will output it to the heap. And we found a
0:17:25.541,0:17:33.720
function that fits this pattern. This[br]function will be used when our guest OS
0:17:33.720,0:17:40.660
executes the instruction outsb. It will[br]check the size, if the size is smaller
0:17:40.660,0:17:48.411
than 0x8000 it will use the stack to store[br]the data. And finally it will copy the
0:17:48.411,0:17:55.640
data we send from the guest into the[br]stack. So we can use this function to pad
0:17:55.640,0:18:02.800
the data on the stack. Then how do we[br]combine this to do arbitrary address free?
0:18:02.800,0:18:10.973
We can use outsb instruction in guest OS[br]first to pad the data on the stack. This
0:18:10.973,0:18:19.260
data should contain fake PhysMemoryPage[br]structure and the page count of this fake
0:18:19.260,0:18:25.800
structure should be zero. The page array[br]of this fake PhysMemoryPage structure
0:18:25.800,0:18:34.170
should be the address we want to free.[br]Then we set some registers of the vmxnet3
0:18:34.170,0:18:41.170
to make the check fail in the function DMA[br]memory create. And finally, we order the
0:18:41.170,0:18:50.320
vmxnet3 netcard, to execute the command to[br]update MAC filters and then in the VMX it
0:18:50.320,0:18:57.230
will use the PhysMemRelease to destroy the[br]structure we pad before. This structure is
0:18:57.230,0:19:04.900
a fixed structure with pad in the first[br]step and it will check the page count if it's 0. If
0:19:04.900,0:19:12.110
it's 0, it will free the page[br]array of this fake PhysMemPage structure.
0:19:12.110,0:19:17.860
So we can do arbitrary address free now by[br]using the first uninitialized stack usage
0:19:17.860,0:19:25.990
vulnerability. Here come the next one, the[br]second vulnerability also exists in the
0:19:25.990,0:19:34.050
vmxnet3 net card. The vmxnet3 net card[br]tries to execute command get_coalesce. It
0:19:34.050,0:19:43.428
will first get a length from the guest,[br]and the length must be 16. Then it
0:19:43.428,0:19:51.500
initializes the first eight byte of a[br]structure on the stack. But it's just for
0:19:51.500,0:19:57.890
guest to initialize the next 8 byte of[br]this structure and just write this
0:19:57.890,0:20:07.080
structure back to our guest OS. So we can[br]link 8 byte uninitialized data on the
0:20:07.080,0:20:14.190
stack from the host to our guest. And[br]after debugging the guest VMX process, we
0:20:14.190,0:20:20.310
realized that there are fixed offsets[br]between the images, so it's possible for
0:20:20.310,0:20:31.200
us to get all the information about the[br]address space by using this vulnerability.
0:20:31.200,0:20:38.320
Now, what do we have now? We can do[br]arbitrary address free by using the first
0:20:38.320,0:20:45.220
one. And we can get all information about[br]the address space by using the second one.
0:20:45.220,0:20:50.970
What do we want to do? We want to do[br]arbitrary shell code execution in the
0:20:50.970,0:20:58.330
VMX. So how do we combine these two[br]vulnerabilities to achieve our target?
0:20:58.330,0:21:03.490
It's hard for us to do arbitrary shell[br]code execution by using arbitrary address
0:21:03.490,0:21:09.320
free. But it's easy for us to do arbitrary[br]shell code execution by using an arbitrary
0:21:09.320,0:21:16.600
address write. So our target changes into[br]how to do arbitrary address write by using
0:21:16.600,0:21:25.650
arbitrary address free. Then we realized[br]that we need a structure and this
0:21:25.650,0:21:33.620
structure should include pointers we can[br]write and the size. So last we can
0:21:33.620,0:21:40.440
overwrite this structure. We can do[br]arbitrary address writes usually. When we
0:21:40.440,0:21:48.510
first tried to exploit this vulnerability,[br]we used some structures in the heap, but
0:21:48.510,0:21:56.860
we've found that we can not manipulate the[br]heap's layout stably because VMX
0:21:56.860,0:22:03.500
frequently allocates and releases[br]memory. So we cannot use the structures in
0:22:03.500,0:22:11.870
the heap. And after reversing some code of[br]VMX, we have found a structure. The
0:22:11.870,0:22:20.210
structure's name is channel and it's used [br]in VMWare RPCI. What's VMWare RPCI?
0:22:20.210,0:22:26.850
VMWare has a series of RPC mechanisms to[br]support communication between the guest
0:22:26.850,0:22:33.000
and the host. And here it has an[br]interesting name: backdoor. RPCI is one of
0:22:33.000,0:22:40.230
them. And the other one we may be familiar[br]with is VMWare tools. I'd like to ask
0:22:40.230,0:22:47.200
again if anyone has installed VMWare tools[br]in your guest OS, please raise your hands
0:22:47.200,0:22:58.230
again. Oh, not as much as before. So if[br]you use VMWare workstation, you'll
0:22:58.230,0:23:04.850
probably have installed VMWare tools in[br]your guest because once you installed it,
0:23:04.850,0:23:12.790
you can use some convenient functions such[br]as copy and the paste text fields between
0:23:12.790,0:23:20.940
the guest and the host, drag and drop[br]files, create shared folder and so on.
0:23:20.940,0:23:29.610
VMWare tools are implemented by using some[br]RPCI commands. And here are some examples
0:23:29.610,0:23:37.760
about about some RPCI commands. For[br]example, we can use info-set guestinfo to
0:23:37.760,0:23:44.350
set some information about our guest and[br]we can use info-get to retrieve this
0:23:44.350,0:23:54.790
information back. Then what happens when[br]we execute this RPCI command in our guest?
0:23:54.790,0:24:03.230
For example, if we execute this RPCI[br]command 'info-set guestinfo.a' 123 in our
0:24:03.230,0:24:12.940
guest OS. What happens in VMX? It will[br]call VM Exit first and finally it will return
0:24:12.940,0:24:22.690
to the RPCI handler of VMX. Then the RPCI[br]handler will choose a subcommand to use by
0:24:22.690,0:24:31.500
checking the value of the registers of our[br]guest OS. The RPC tool in our guest OS
0:24:31.500,0:24:39.650
will use the subcommand, 'Open' first to[br]open a channel and initialize it. Then it
0:24:39.650,0:24:49.880
will use a subcommand, 'SendLen' to set[br]the size of our channel and allocate heap
0:24:49.880,0:24:56.111
memory to install the data of our RPC[br]command and suddenly it will use the
0:24:56.111,0:25:07.780
'SendData' subcommand to pad the data of[br]the memory we allocated before. And once
0:25:07.780,0:25:15.750
the length of the data we sent from the[br]guest re-calls to the sizeof from the
0:25:15.750,0:25:23.220
'SendLen' subcommand the VMX will use a[br]corresponding RPCI command handler
0:25:23.220,0:25:31.410
function after a string combination. And[br]finally, it will use a 'Close' subcommand
0:25:31.410,0:25:37.980
to destroy the channel structure including[br]setting the size to zero and freeing the
0:25:37.980,0:25:46.720
data pointer. That's what happens when we[br]execute this RPCI commend in our guest.
0:25:46.720,0:25:54.847
Furthermore, there is a channel structure[br]area in the data segment we can use. So
0:25:54.847,0:26:03.740
this is a perfect structure for our[br]exploit. Now, you got all the things we
0:26:03.740,0:26:09.720
want. We've got two vulnerabilities and[br]we've got the structure we want. How do we
0:26:09.720,0:26:20.280
combine this? We notice that the VMX uses[br]ptmalloc of Glibc to manage its heap. So
0:26:20.280,0:26:26.227
we just choose to use a fast-bin attack.[br]What's the fast-bin attack? Fast-bin
0:26:26.227,0:26:32.110
attack is a method to exploit heap[br]vulnerabilities of ptmalloc by using the
0:26:32.110,0:26:41.252
singly-linked list. And it's the easiest[br]exploit method to exploit ptmalloc, I
0:26:41.252,0:26:48.640
think. It's also the first method to[br]exploit ptmalloc that I learned when I
0:26:48.640,0:26:56.840
just started to learn how to how to[br]exploit. Then after considering the check
0:26:56.840,0:27:05.590
existing in the Glibc, we decided to free[br]the address at the Reply Index of channel.
0:27:05.590,0:27:15.240
Because by doing that, the Glibc will treat[br]this address as a fake chunk and the Glibc
0:27:15.240,0:27:23.310
will check the current chunk's size. And[br]after doing that, the size of the fake
0:27:23.310,0:27:30.360
chunk is also the size of the[br]'channel[N]', so we can set a valid value
0:27:30.360,0:27:38.690
to the size of the 'channel[N]' to bypass[br]the check. So we can bypass the check.
0:27:38.690,0:27:47.015
Once we've freed this address this fake[br]chunk will be put into the fast-bin linked
0:27:47.015,0:27:59.120
list first. Then we can reallocate this[br]fake chunk by using another channel, N+2.
0:27:59.120,0:28:08.001
Now we have a data pointer pointed at the[br]reply index of channel[N] and we can
0:28:08.001,0:28:16.040
easily overwrite the channel[N+1] by using[br]channel[N+2]. We can send a data to
0:28:16.040,0:28:23.710
channel[N+2] and finally it will overwrite[br]some parts of the channel[N+1]. So it's
0:28:23.710,0:28:29.490
easy now for us to do arbitrary address[br]write by faking some parts of the channel
0:28:29.490,0:28:39.330
structure. Do remember our target? Our[br]target is to do arbitrary shell code
0:28:39.330,0:28:46.960
execution in VMX and we can do arbitrary[br]address write now. There are many ways to
0:28:46.960,0:28:52.370
do arbitrary shell code execution by using[br]arbitrary address write. We choose to use
0:28:52.370,0:29:02.850
a ROP. We can override the '.got.plt'[br]segment. We can fake the channel[N+1],
0:29:02.850,0:29:10.620
structure first, overwrite the data[br]pointer at channel[N+1] to the address of
0:29:10.620,0:29:21.940
.got.plt segment. Then we can overwrite[br]the function pointer on the .got.plt
0:29:21.940,0:29:30.940
segment. So once the VMX uses this[br]function we overwrite, it will jump to our
0:29:30.940,0:29:40.780
ROP gadget. So it's also easy for us to do[br]arbitrary shell code execution by using
0:29:40.780,0:29:50.280
ROP. So now we can do arbitrary shell code[br]execution in the VMX process. We're seeing
0:29:50.280,0:29:56.820
that we have escaped from the virtual[br]machine of the ESXi fully, we tried to
0:29:56.820,0:30:06.350
execute some command by using a system[br]call execve, but it fails. We tried to
0:30:06.350,0:30:13.550
open and read some sensitive files just[br]like password, it fails again. Then we
0:30:13.550,0:30:22.750
realize that there is a sandbox. We cannot[br]execute any commands unless we escape the
0:30:22.750,0:30:31.650
sandbox either. The next part come to[br]comes to the how we analyze and the
0:30:31.650,0:30:41.540
escape the sandbox. After realizing that[br]there is a sandbox in the ESXi, we reverse
0:30:41.540,0:30:47.620
some code of the VMkernel and we find the[br]kernel module named as VM Kernel SAS
0:30:47.620,0:30:54.540
control system. And this system, this[br]module, implements the fine grained checks
0:30:54.540,0:31:04.010
for the system call. And it seems that[br]this sandbox is a rule-based sandbox. So
0:31:04.010,0:31:09.520
we just tried to find the configuration[br]file of this sandbox. We finally found it
0:31:09.520,0:31:15.929
at this directory,[br]/etc/vmware/secpolicy/domains, and it
0:31:15.929,0:31:24.560
seems that there are many different[br]sandboxes offered by VMWare to the
0:31:24.560,0:31:33.740
different processes in the userworld. Like[br]app, plugin and the globalVMDom is a file
0:31:33.740,0:31:43.820
for our VMX process and for our VM. After[br]reading that, it's obvious for us that the
0:31:43.820,0:31:51.310
/var/run directory is the only directory[br]where we have read and write permissions.
0:31:51.310,0:31:58.710
Then we look at the files existing in this[br]directory. We got a lot of pid filess just
0:31:58.710,0:32:07.611
like crond, dcui, inetd and so on. And[br]it's also obvious that inetd.conf
0:32:07.611,0:32:19.350
configure file is only configure file we[br]can write. What's inetd? inetd is open
0:32:19.350,0:32:27.630
source software and it's a super-server[br]domain that provides internet services.
0:32:27.630,0:32:34.930
Then we just analyze the contents of the[br]inetd.conf. The content of the inetd.conf
0:32:34.930,0:32:44.230
is here on the ESXi. We can find that it a[br]defines two services, ssh and the authd.
0:32:44.230,0:32:50.300
And some of it defines which binary will[br]be used by different services. For
0:32:50.300,0:33:02.750
example, the authd will be used by the[br]authd services. Also after some testing,
0:33:02.750,0:33:08.903
we realize that the authd service is[br]always enabled, while the sshd service is
0:33:08.903,0:33:16.650
not. So this is the only configure file we[br]can write. So we got an idea. How about
0:33:16.650,0:33:24.140
overwriting this configure file? Or we can[br]overwrite the binary part for authd like
0:33:24.140,0:33:31.810
that, we can override the /sbin/authd to[br]/bin/sh. So once can restart the inetd
0:33:31.810,0:33:41.360
process we can bind the shell to the port[br]authd is using. Then we just find a way to
0:33:41.360,0:33:48.510
restart the inetd process. We analyzed the[br]configure file of the sandbox again, and
0:33:48.510,0:33:55.130
we found out the queue system call we can[br]use in the VMX process. Then we just use
0:33:55.130,0:34:03.520
the queue HUP to restart the inetd[br]process. Once the inetd process restarts,
0:34:03.520,0:34:11.730
we can execute any commands by sending[br]them to the port the authd is using. So
0:34:11.730,0:34:23.889
that's the method we use to escape from[br]the sandbox. And here's a demo.
0:34:23.889,0:34:43.259
Oh, sorry.
0:34:43.259,0:34:49.500
Oh, it seems not, I cannot play this[br]video, but it's OK. You can find it on
0:34:49.500,0:34:58.529
YouTube and we created this demo after[br]the GeekPwn 2018, we get a reverse shell
0:34:58.529,0:35:10.730
after excuting the exploit in our guest[br]OS. That's all. And if you want to get
0:35:10.730,0:35:17.410
more details about our exploit chain,[br]please check our paper here and that's
0:35:17.410,0:35:19.079
all. Thanks.
0:35:19.079,0:35:30.009
applause
0:35:30.009,0:35:33.630
Herald: So I don't think I'm actually[br]worthy to share the stage with
0:35:33.630,0:35:39.869
f1yyy, that was awesome. If you have[br]questions, we have microphones, you need
0:35:39.869,0:35:45.999
to come up to the microphone, line up[br]behind them and we'll take your question.
0:35:45.999,0:35:53.193
Meanwhile, does the signal angel have[br]anything? No questions yet. Do we not have
0:35:53.193,0:35:57.710
questions from the audience? There is one.[br]Can I have number six, please?
0:35:57.710,0:36:04.279
Mic 6: Do you talk to VMWare for this[br]little hack?
0:36:04.279,0:36:11.330
f1yyy: We have reported all these[br]vulnerabilities to VMWare after the
0:36:11.330,0:36:18.630
GeekPwn 2018, and it has been one year[br]since after they repair it.
0:36:18.630,0:36:24.578
Mic 6: OK, Thanks.[br]Herald: That's definitely a relief. Number
0:36:24.578,0:36:28.640
one, please.[br]Mic 1: First of all, thanks for the great
0:36:28.640,0:36:33.859
talk. I just want to know if there is any[br]meaningful thing a system administrator
0:36:33.859,0:36:41.750
can do to lock down the sandbox further so[br]that we can have some preventative,
0:36:41.750,0:36:48.329
basically tasks, for our ESXi setups. Or[br]if there is nothing we can do except
0:36:48.329,0:36:55.158
patching, of course.[br]f1yyy: Could you repeat your question?
0:36:55.158,0:37:01.980
It's so fast for me. Sorry about that.[br]Mic 1: Basically, is there anything you
0:37:01.980,0:37:08.720
can do as an administrator to lock down[br]the sandbox even more so that this is
0:37:08.720,0:37:11.950
impossible or that it is harder than what[br]you showed?
0:37:11.950,0:37:19.130
f1yyy: OK. This is the first question.[br]Your can set the sandbox down by executing
0:37:19.130,0:37:30.150
a command on the ESXi shell. I didn't put[br]the command here. I found the command to
0:37:30.150,0:37:38.559
set the sandbox down. You can find it by[br]searching the documents about the ESXi.
0:37:38.559,0:37:48.860
Wait, wait, wait, wait. I found it, just[br]by myself by using the command offered on
0:37:48.860,0:38:00.430
the ESXi shell. It's not documented by the[br]VMWare. OK, I will share this command on
0:38:00.430,0:38:05.880
my Twitter later. Sorry about that. I[br]didn't put this command into my slides.
0:38:05.880,0:38:09.960
Mic 1: But would this have prevented the[br]attack?
0:38:09.960,0:38:16.769
f1yyy: Prevented it?[br]Herald: By doing that change, by doing
0:38:16.769,0:38:22.520
that command, would be possible to prevent[br]the attack that you just showed?
0:38:22.520,0:38:33.589
f1yyy: The sandbox is used to protect the[br]VMX process. So if you update your ESXi, I
0:38:33.589,0:38:40.670
think that it will be safe.[br]Herald: Okay, great. We have a we have a
0:38:40.670,0:38:44.710
question from the Internet.[br]Signal Angel: Yes. Does this exploit also
0:38:44.710,0:38:51.819
work on non-AMD VTx enabled VMs using binary[br]translation?
0:38:51.819,0:38:57.609
Herald: Is it is it more universal than[br]just the AMD-VX?
0:38:57.609,0:39:03.420
f1yyy: Yeah, can you repeat that again?[br]I just hear the, okay.
0:39:03.420,0:39:13.300
Signal Angel: Does it also work on non-AMD[br]V or VTX-enabled VMs using binary
0:39:13.300,0:39:19.980
translation?[br]f1yyyy: Yes, because all these
0:39:19.980,0:39:26.529
vulnerabilities exist in the virtual[br]hardware. You will need to use virtual
0:39:26.529,0:39:35.289
hardware in your virtual machine.[br]Herald: So any further questions? I'm not
0:39:35.289,0:39:40.440
seeing anybody on the microphones. Any[br]further questions from the internet?
0:39:40.440,0:39:48.230
That's it then. Good. Please, everybody help [br]me in thanking f1yyyy for this fantastic talk.
0:39:48.230,0:39:51.140
applause
0:39:51.140,0:39:55.990
36c3 postroll music
0:39:55.990,0:40:18.000
Subtitles created by c3subtitles.de[br]in the year 2020. Join, and help us!