WEBVTT

00:00:00.000 --> 00:00:18.746
<i>36c3 preroll</i>

00:00:18.746 --> 00:00:25.030
Herald: So like many operators, in my
group, we actually use a lot of ESXi

00:00:25.030 --> 00:00:27.870
servers. You would think that after using
these things for 10 years, I would know

00:00:27.870 --> 00:00:35.050
how to speak, but I do not. We use these
for virtualizing machines. Some of... some of

00:00:35.050 --> 00:00:39.920
these actually runs on sandboxes or, you
know, run kind of dubious software on it.

00:00:39.920 --> 00:00:45.530
So we really do want to prevent these
processes from jumping from the virtual

00:00:45.530 --> 00:00:54.489
environment to the hypervisor environment.
We have today - we have - f1yyy, he wants

00:00:54.489 --> 00:01:02.620
to be known by f1yyy, so I'm respecting
that; and he's from Triton Security Labs,

00:01:02.620 --> 00:01:09.670
and he's going to show us how the exploits
that he discovered in the, I think it was

00:01:09.670 --> 00:01:15.490
the last Chinese GeekPwn capture the flag.
He's gonna show us how these things work,

00:01:15.490 --> 00:01:21.970
and was that I would like to help. I would
like to ask you, to help me, welcome f1yyy

00:01:21.970 --> 00:01:23.645
onto the stage.

00:01:23.645 --> 00:01:28.630
<i>applause</i>

00:01:28.630 --> 00:01:41.671
f1yyy: Hello. Thanks for the introduction.
Good evening, everybody. I'm f1yyy a

00:01:41.671 --> 00:01:49.130
Senior Security Researcher at Chaitin
Technology. I'm going to present The Great

00:01:49.130 --> 00:01:56.880
Escape of ESXi; Breaking Out of a
Sandboxed Virtual Machine. We have

00:01:56.880 --> 00:02:05.460
demonstrated this exploit chain before at
GeekPwn 2018. I will introduce our

00:02:05.460 --> 00:02:12.060
experience of escaping the sandbox on the
ESXi. I will also introduce the work we

00:02:12.060 --> 00:02:23.020
have done about the sandbox on the ESXi.
Now let's start it. We come from the

00:02:23.020 --> 00:02:28.690
Chaitin Security Research Lab. We have
researched many practical targets in

00:02:28.690 --> 00:02:35.750
recent years, including PS4 jailbreak,
Android rooting, IoT offensive research,

00:02:35.750 --> 00:02:43.740
and so on. Some of us also play CTF with
Team b1o0p and Tea Deliverers. We recently

00:02:43.740 --> 00:02:51.720
own the championship at HITCON final. We
are also the organizer of the Real World

00:02:51.720 --> 00:02:58.680
CTF. We've created some very hard
challenges this year. So if you are

00:02:58.680 --> 00:03:09.400
interested in it, we welcome you to
participate in our CTF game. Now, before

00:03:09.400 --> 00:03:16.150
we start our journey to escaping the
virtual machine, we need to figure out

00:03:16.150 --> 00:03:24.930
what is virtual machine escape? I like to
ask some of you that, did anyone use the

00:03:24.930 --> 00:03:32.130
virtualization software? If you have used
the virtualization software, like VMware

00:03:32.130 --> 00:03:41.200
Workstation, Hyper-V, VirtualBox and so
on, please raise your hand. Okay, okay,

00:03:41.200 --> 00:03:50.250
okay. Thanks, thanks, thanks. Many. So if
you are a Software Engineer or a Security

00:03:50.250 --> 00:03:58.930
Researcher, you'll probably have used
virtualisation software, but if anyone has

00:03:58.930 --> 00:04:03.730
heard of the word virtual machine escape,
if you have heard of that, please raise

00:04:03.730 --> 00:04:12.870
your hand again. Oh, oh, surprised.
Thanks, thanks, thanks. It surprises me

00:04:12.870 --> 00:04:20.560
that all you know about that, but I have
to introduce that again. What's virtual

00:04:20.560 --> 00:04:25.240
machine escape? You know, in most
circumstances the host OS runs on the

00:04:25.240 --> 00:04:32.690
hypervisor and the hypervisor will handle
some sensitive instructions executed by

00:04:32.690 --> 00:04:40.090
the guest OS. Host OS emulates virtual
hardware and handles RPC requests from the

00:04:40.090 --> 00:04:49.500
guest OS. That's the architecture of
normal virtualization software. And the

00:04:49.500 --> 00:04:59.340
guest OS is isolated from each other and
cannot affect the host OS. However, if

00:04:59.340 --> 00:05:04.660
there are some bugs, or if there are some
vulnerabilities existing in the host OS,

00:05:04.660 --> 00:05:13.150
it's possible for the guest OS to escape
from the virtualization environment. They

00:05:13.150 --> 00:05:21.139
can exploit these vulnerabilities. And
finally, they can execute arbitrary code

00:05:21.139 --> 00:05:30.880
on the host. So this is the Virtual
Machine Escape. Then why we chose ESXi as

00:05:30.880 --> 00:05:39.220
our target? The first reason is we know
that more and more companies are using or

00:05:39.220 --> 00:05:48.552
plan to use private cloud to store its
private data, including these companies

00:05:48.552 --> 00:05:56.670
and the vSphere is an enterprise solution
offered by VMware. It's popular between

00:05:56.670 --> 00:06:02.600
companies. If you are a Net-Manager of a
company, you may know about VMware

00:06:02.600 --> 00:06:11.810
vSphere. And the ESXi is the hypervisor
for VMware vSphere, so it's widely used in

00:06:11.810 --> 00:06:17.810
private cloud. That's the first reason.
The second one is that it's a challenging

00:06:17.810 --> 00:06:24.740
target for us. There are several
exploitations of VMware Workstation in

00:06:24.740 --> 00:06:30.790
recent years. Hackers escape from the
VMware Workstation by exploiting some

00:06:30.790 --> 00:06:38.520
vulnerabilities. These vulnerabilties
exist in graphic cards, network cards and

00:06:38.520 --> 00:06:48.820
USB devices and so on. But, there has been
no public escape of ESXi before, so it's a

00:06:48.820 --> 00:06:58.311
challenging target for us and we love
challenge. Then why is the ESXi so

00:06:58.311 --> 00:07:04.930
challenging? The first reason I think is
that there are little documents about its

00:07:04.930 --> 00:07:13.640
architecture. The only thing we have found
is a white paper offered by VMware. The

00:07:13.640 --> 00:07:20.490
white paper only includes some definitions
and pictures without details. So let's

00:07:20.490 --> 00:07:29.460
take a brief look at the architecture of
ESXi first. ESXi is an Enterprise bare-

00:07:29.460 --> 00:07:35.800
metal hypervisor and it includes two
parts. The kernel, it uses VMKernel

00:07:35.800 --> 00:07:42.069
developed by VMware and the User Worlds
and the other part, the User Worlds. The

00:07:42.069 --> 00:07:51.476
VMKernel is a POSIX-like operating system.
And it is uses an in-memory filesystem. It

00:07:51.476 --> 00:07:59.291
means that all files stored in this system
are not persistent. And the VMKernel also

00:07:59.291 --> 00:08:08.470
manages hardware and schedules resource
for ESXi. VMKernel also includes VMWare

00:08:08.470 --> 00:08:15.335
drivers, I/O Stacks and some User World
APIs offered to the User Worlds. And the

00:08:15.335 --> 00:08:25.560
word "User World" is used by VMWare to
refer the processes running in VMKernel

00:08:25.560 --> 00:08:31.770
operating system and the word "User World"
means that a group of these processes.

00:08:31.770 --> 00:08:38.300
This process can only use a limited /proc
directory and limited signals and it can

00:08:38.300 --> 00:08:45.070
just use some of the POSIX API. For
example, there are some User Worlds

00:08:45.070 --> 00:08:55.880
processes like hosted, ssh, vmx and so on.
Then this is the architecture of ESXi. I

00:08:55.880 --> 00:09:02.814
would like to give you an example to show
how a virtual machine works on ESXi. The

00:09:02.814 --> 00:09:09.249
VMX process in the User World can
communicate with the VMM by using some

00:09:09.249 --> 00:09:18.829
undocumented customized system call. And
the VMM will initialize the environment

00:09:18.829 --> 00:09:27.420
for the guest OS. When guest OS executes
some sensitive instructions, it will cause

00:09:27.420 --> 00:09:35.490
a VMExit and return to VMM. The VMX
process also emulates virtual hardware and

00:09:35.490 --> 00:09:41.449
handles RPC requests from the guest.
That's how a virtual machine works on

00:09:41.449 --> 00:09:49.336
ESXi. Then, how can we escape from the
virtual machine on ESXi? If there is a

00:09:49.336 --> 00:09:57.779
vulnerability in the virtual hardware of
the VMX, we can write a driver, or write

00:09:57.779 --> 00:10:07.410
an exploit, to escape from it. The driver
will communicate with the virtual hardware

00:10:07.410 --> 00:10:14.480
and it can exploit the vulnerability. And
finally we can execute shellcode in the

00:10:14.480 --> 00:10:19.850
VMX process. So it means that we have
successfully escaped from the virtual

00:10:19.850 --> 00:10:28.269
machine on the ESXi. So the second reason
about why ESXi is so challenging, is that

00:10:28.269 --> 00:10:40.279
User World API. The VMX uses many
undocumented and customized system calls

00:10:40.279 --> 00:10:46.519
and if you want to reverse some code of
VMX it is hard for you to understand which

00:10:46.519 --> 00:10:55.629
API the VMX is using. But luckily we found
two system call tables after compromising

00:10:55.629 --> 00:11:04.660
the k.b00 field. There are 2 system call
tables we found with symbols so this field

00:11:04.660 --> 00:11:11.740
will be useful if we want to reverse some
code of the VMX. This is the second

00:11:11.740 --> 00:11:20.870
reason. Thirdly, there are some security
mitigations here, including ASLR and NX.

00:11:20.870 --> 00:11:27.410
It means that we need to link some address
information before we start our exploit

00:11:27.410 --> 00:11:34.670
to break the randomness of the address
space. Furthermore after testing we found

00:11:34.670 --> 00:11:43.970
that there is another mitigation on the
ESXi. There is a sandbox that isolates the

00:11:43.970 --> 00:11:50.720
VMX process. So even if you can execute
some shellcode in the VMX process you can

00:11:50.720 --> 00:11:57.949
not execute any commands, you can not read
any sensitive fields, unless you escape

00:11:57.949 --> 00:12:06.720
from the sandbox either. And finally, we
think that the VMX of ESXi has a smaller

00:12:06.720 --> 00:12:13.651
attack surface. After comparison of the
VMX binary between the Workstation and the

00:12:13.651 --> 00:12:20.920
ESXi we found that there are some function
that have been moved from the VMX in User

00:12:20.920 --> 00:12:28.079
World to the VMKernel. For example the
packet transmission function in the e1000

00:12:28.079 --> 00:12:37.679
net card has been moved from the VMX to
the VMKernel. And if you have read some

00:12:37.679 --> 00:12:44.569
security advisories published by VMware
recently, you can notice that there are

00:12:44.569 --> 00:12:52.850
many vulnerabilites existing in the packet
transmission part of the e1000 net card.

00:12:52.850 --> 00:13:00.689
And all these vulnerabilites only affect
Workstation. So we think that the VMX of

00:13:00.689 --> 00:13:09.540
ESXi has a smaller attack surface. Now
let's start the journey of escaping from

00:13:09.540 --> 00:13:17.600
the ESXi. Let's overview the entire
exploit chain first. We use 2 memory

00:13:17.600 --> 00:13:23.709
corruption vulnerabilites in our exploit.
The first one is an uninitialized stack

00:13:23.709 --> 00:13:31.529
usage vulnerability which CVE Number is
CVE-2018-6981. And the second is an

00:13:31.529 --> 00:13:40.825
unitialized stack read vulnerability and
the CVE number is CVE-2018-6982. And we

00:13:40.825 --> 00:13:46.799
can do arbitrary address free by using the
first vulnerability, and we can get

00:13:46.799 --> 00:13:52.906
information leakage from the second one.
After combining of these two

00:13:52.906 --> 00:14:00.059
vulnerabilites we can do arbitrary
shellcode execution in VMX process. And

00:14:00.059 --> 00:14:09.589
finally we use a logic vulnerability to
escape the sandbox of VMX and reverse a

00:14:09.589 --> 00:14:16.959
root shell from the ESXi. So that's the
entire exploit chain we use. Now let's

00:14:16.959 --> 00:14:24.329
start the first one. The first
vulnerability is an uninitialized stack

00:14:24.329 --> 00:14:32.749
usage vulnerability. It exists in VMXNET3
netcard. When the VMX VMXNET3 netcard

00:14:32.749 --> 00:14:39.939
tries to execute command
UPDATE_MAC_FILTERS it will us a structure

00:14:39.939 --> 00:14:47.749
on the stack, the PhysMemPage structure.
This structure is used to represent the

00:14:47.749 --> 00:14:54.410
memory mapping between the guest and the
host. And it's also been used to transport

00:14:54.410 --> 00:15:01.809
data between the guest and the host. Then
the VMXNET will call function

00:15:01.809 --> 00:15:07.799
DMA_MEM_CREATE to initialize the structure
on the stack first, then it will use this

00:15:07.799 --> 00:15:16.379
structure to execute this command. And
finally it uses PhysMemRelease to destroy

00:15:16.379 --> 00:15:23.410
the structure, the physical memory page
structure. So it seems that there are no

00:15:23.410 --> 00:15:30.829
problems here. But if we look at the
function DMA memory create, we can notice

00:15:30.829 --> 00:15:39.609
that there is a check before the
initialization of the PhysMemoryPage

00:15:39.609 --> 00:15:47.399
structure. It will check the argument
address and the argument size and if the

00:15:47.399 --> 00:15:54.410
check passes then it will initialize the
structure. But if the check fails, it will

00:15:54.410 --> 00:16:02.350
never initialize the structure on the
stack. And finally we found that we can

00:16:02.350 --> 00:16:13.269
control the address argument by writing a
value to one of the registers of VMXNET3.

00:16:13.269 --> 00:16:18.389
What is worse is that in function
PhysMemoryRelease there are no checks

00:16:18.389 --> 00:16:24.819
about if the PhysMemoryPage structure had
been initialized and it just frees a

00:16:24.819 --> 00:16:34.189
pointer of this structure. So that's it
about it. If we can pad the data on the

00:16:34.189 --> 00:16:42.430
stack it's possible for us to do arbitrary
address free. We can pad a fake

00:16:42.430 --> 00:16:47.989
PhysMemoryPage structure on the stack and
then make the check fail in the function

00:16:47.989 --> 00:16:53.759
DMA memory create and finally when it
comes to the PhysMemoryRelease it will

00:16:53.759 --> 00:17:01.669
free a pointer of our PhysMemoryPage
structure. So we just try to find a

00:17:01.669 --> 00:17:09.710
function to pad the data on the stack.
There is a design pattern in software

00:17:09.710 --> 00:17:18.031
development, where we store the data into
the stack, if the size is small, when we

00:17:18.031 --> 00:17:25.541
allocate some memory. And otherwise we
will output it to the heap. And we found a

00:17:25.541 --> 00:17:33.720
function that fits this pattern. This
function will be used when our guest OS

00:17:33.720 --> 00:17:40.660
executes the instruction outsb. It will
check the size, if the size is smaller

00:17:40.660 --> 00:17:48.411
than 0x8000 it will use the stack to store
the data. And finally it will copy the

00:17:48.411 --> 00:17:55.640
data we send from the guest into the
stack. So we can use this function to pad

00:17:55.640 --> 00:18:02.800
the data on the stack. Then how do we
combine this to do arbitrary address free?

00:18:02.800 --> 00:18:10.973
We can use outsb instruction in guest OS
first to pad the data on the stack. This

00:18:10.973 --> 00:18:19.260
data should contain fake PhysMemoryPage
structure and the page count of this fake

00:18:19.260 --> 00:18:25.800
structure should be zero. The page array
of this fake PhysMemoryPage structure

00:18:25.800 --> 00:18:34.170
should be the address we want to free.
Then we set some registers of the vmxnet3

00:18:34.170 --> 00:18:41.170
to make the check fail in the function DMA
memory create. And finally, we order the

00:18:41.170 --> 00:18:50.320
vmxnet3 netcard, to execute the command to
update MAC filters and then in the VMX it

00:18:50.320 --> 00:18:57.230
will use the PhysMemRelease to destroy the
structure we pad before. This structure is

00:18:57.230 --> 00:19:04.900
a fixed structure with pad in the first
step and it will check the page count if it's 0. If

00:19:04.900 --> 00:19:12.110
it's 0, it will free the page
array of this fake PhysMemPage structure.

00:19:12.110 --> 00:19:17.860
So we can do arbitrary address free now by
using the first uninitialized stack usage

00:19:17.860 --> 00:19:25.990
vulnerability. Here come the next one, the
second vulnerability also exists in the

00:19:25.990 --> 00:19:34.050
vmxnet3 net card. The vmxnet3 net card
tries to execute command get_coalesce. It

00:19:34.050 --> 00:19:43.428
will first get a length from the guest,
and the length must be 16. Then it

00:19:43.428 --> 00:19:51.500
initializes the first eight byte of a
structure on the stack. But it's just for

00:19:51.500 --> 00:19:57.890
guest to initialize the next 8 byte of
this structure and just write this

00:19:57.890 --> 00:20:07.080
structure back to our guest OS. So we can
link 8 byte uninitialized data on the

00:20:07.080 --> 00:20:14.190
stack from the host to our guest. And
after debugging the guest VMX process, we

00:20:14.190 --> 00:20:20.310
realized that there are fixed offsets
between the images, so it's possible for

00:20:20.310 --> 00:20:31.200
us to get all the information about the
address space by using this vulnerability.

00:20:31.200 --> 00:20:38.320
Now, what do we have now? We can do
arbitrary address free by using the first

00:20:38.320 --> 00:20:45.220
one. And we can get all information about
the address space by using the second one.

00:20:45.220 --> 00:20:50.970
What do we want to do? We want to do
arbitrary shell code execution in the

00:20:50.970 --> 00:20:58.330
VMX. So how do we combine these two
vulnerabilities to achieve our target?

00:20:58.330 --> 00:21:03.490
It's hard for us to do arbitrary shell
code execution by using arbitrary address

00:21:03.490 --> 00:21:09.320
free. But it's easy for us to do arbitrary
shell code execution by using an arbitrary

00:21:09.320 --> 00:21:16.600
address write. So our target changes into
how to do arbitrary address write by using

00:21:16.600 --> 00:21:25.650
arbitrary address free. Then we realized
that we need a structure and this

00:21:25.650 --> 00:21:33.620
structure should include pointers we can
write and the size. So last we can

00:21:33.620 --> 00:21:40.440
overwrite this structure. We can do
arbitrary address writes usually. When we

00:21:40.440 --> 00:21:48.510
first tried to exploit this vulnerability,
we used some structures in the heap, but

00:21:48.510 --> 00:21:56.860
we've found that we can not manipulate the
heap's layout stably because VMX

00:21:56.860 --> 00:22:03.500
frequently allocates and releases
memory. So we cannot use the structures in

00:22:03.500 --> 00:22:11.870
the heap. And after reversing some code of
VMX, we have found a structure. The

00:22:11.870 --> 00:22:20.210
structure's name is channel and it's used 
in VMWare RPCI. What's VMWare RPCI?

00:22:20.210 --> 00:22:26.850
VMWare has a series of RPC mechanisms to
support communication between the guest

00:22:26.850 --> 00:22:33.000
and the host. And here it has an
interesting name: backdoor. RPCI is one of

00:22:33.000 --> 00:22:40.230
them. And the other one we may be familiar
with is VMWare tools. I'd like to ask

00:22:40.230 --> 00:22:47.200
again if anyone has installed VMWare tools
in your guest OS, please raise your hands

00:22:47.200 --> 00:22:58.230
again. Oh, not as much as before. So if
you use VMWare workstation, you'll

00:22:58.230 --> 00:23:04.850
probably have installed VMWare tools in
your guest because once you installed it,

00:23:04.850 --> 00:23:12.790
you can use some convenient functions such
as copy and the paste text fields between

00:23:12.790 --> 00:23:20.940
the guest and the host, drag and drop
files, create shared folder and so on.

00:23:20.940 --> 00:23:29.610
VMWare tools are implemented by using some
RPCI commands. And here are some examples

00:23:29.610 --> 00:23:37.760
about about some RPCI commands. For
example, we can use info-set guestinfo to

00:23:37.760 --> 00:23:44.350
set some information about our guest and
we can use info-get to retrieve this

00:23:44.350 --> 00:23:54.790
information back. Then what happens when
we execute this RPCI command in our guest?

00:23:54.790 --> 00:24:03.230
For example, if we execute this RPCI
command 'info-set guestinfo.a' 123 in our

00:24:03.230 --> 00:24:12.940
guest OS. What happens in VMX? It will
call VM Exit first and finally it will return

00:24:12.940 --> 00:24:22.690
to the RPCI handler of VMX. Then the RPCI
handler will choose a subcommand to use by

00:24:22.690 --> 00:24:31.500
checking the value of the registers of our
guest OS. The RPC tool in our guest OS

00:24:31.500 --> 00:24:39.650
will use the subcommand, 'Open' first to
open a channel and initialize it. Then it

00:24:39.650 --> 00:24:49.880
will use a subcommand, 'SendLen' to set
the size of our channel and allocate heap

00:24:49.880 --> 00:24:56.111
memory to install the data of our RPC
command and suddenly it will use the

00:24:56.111 --> 00:25:07.780
'SendData' subcommand to pad the data of
the memory we allocated before. And once

00:25:07.780 --> 00:25:15.750
the length of the data we sent from the
guest re-calls to the sizeof from the

00:25:15.750 --> 00:25:23.220
'SendLen' subcommand the VMX will use a
corresponding RPCI command handler

00:25:23.220 --> 00:25:31.410
function after a string combination. And
finally, it will use a 'Close' subcommand

00:25:31.410 --> 00:25:37.980
to destroy the channel structure including
setting the size to zero and freeing the

00:25:37.980 --> 00:25:46.720
data pointer. That's what happens when we
execute this RPCI commend in our guest.

00:25:46.720 --> 00:25:54.847
Furthermore, there is a channel structure
area in the data segment we can use. So

00:25:54.847 --> 00:26:03.740
this is a perfect structure for our
exploit. Now, you got all the things we

00:26:03.740 --> 00:26:09.720
want. We've got two vulnerabilities and
we've got the structure we want. How do we

00:26:09.720 --> 00:26:20.280
combine this? We notice that the VMX uses
ptmalloc of Glibc to manage its heap. So

00:26:20.280 --> 00:26:26.227
we just choose to use a fast-bin attack.
What's the fast-bin attack? Fast-bin

00:26:26.227 --> 00:26:32.110
attack is a method to exploit heap
vulnerabilities of ptmalloc by using the

00:26:32.110 --> 00:26:41.252
singly-linked list. And it's the easiest
exploit method to exploit ptmalloc, I

00:26:41.252 --> 00:26:48.640
think. It's also the first method to
exploit ptmalloc that I learned when I

00:26:48.640 --> 00:26:56.840
just started to learn how to how to
exploit. Then after considering the check

00:26:56.840 --> 00:27:05.590
existing in the Glibc, we decided to free
the address at the Reply Index of channel.

00:27:05.590 --> 00:27:15.240
Because by doing that, the Glibc will treat
this address as a fake chunk and the Glibc

00:27:15.240 --> 00:27:23.310
will check the current chunk's size. And
after doing that, the size of the fake

00:27:23.310 --> 00:27:30.360
chunk is also the size of the
'channel[N]', so we can set a valid value

00:27:30.360 --> 00:27:38.690
to the size of the 'channel[N]' to bypass
the check. So we can bypass the check.

00:27:38.690 --> 00:27:47.015
Once we've freed this address this fake
chunk will be put into the fast-bin linked

00:27:47.015 --> 00:27:59.120
list first. Then we can reallocate this
fake chunk by using another channel, N+2.

00:27:59.120 --> 00:28:08.001
Now we have a data pointer pointed at the
reply index of channel[N] and we can

00:28:08.001 --> 00:28:16.040
easily overwrite the channel[N+1] by using
channel[N+2]. We can send a data to

00:28:16.040 --> 00:28:23.710
channel[N+2] and finally it will overwrite
some parts of the channel[N+1]. So it's

00:28:23.710 --> 00:28:29.490
easy now for us to do arbitrary address
write by faking some parts of the channel

00:28:29.490 --> 00:28:39.330
structure. Do remember our target? Our
target is to do arbitrary shell code

00:28:39.330 --> 00:28:46.960
execution in VMX and we can do arbitrary
address write now. There are many ways to

00:28:46.960 --> 00:28:52.370
do arbitrary shell code execution by using
arbitrary address write. We choose to use

00:28:52.370 --> 00:29:02.850
a ROP. We can override the '.got.plt'
segment. We can fake the channel[N+1],

00:29:02.850 --> 00:29:10.620
structure first, overwrite the data
pointer at channel[N+1] to the address of

00:29:10.620 --> 00:29:21.940
.got.plt segment. Then we can overwrite
the function pointer on the .got.plt

00:29:21.940 --> 00:29:30.940
segment. So once the VMX uses this
function we overwrite, it will jump to our

00:29:30.940 --> 00:29:40.780
ROP gadget. So it's also easy for us to do
arbitrary shell code execution by using

00:29:40.780 --> 00:29:50.280
ROP. So now we can do arbitrary shell code
execution in the VMX process. We're seeing

00:29:50.280 --> 00:29:56.820
that we have escaped from the virtual
machine of the ESXi fully, we tried to

00:29:56.820 --> 00:30:06.350
execute some command by using a system
call execve, but it fails. We tried to

00:30:06.350 --> 00:30:13.550
open and read some sensitive files just
like password, it fails again. Then we

00:30:13.550 --> 00:30:22.750
realize that there is a sandbox. We cannot
execute any commands unless we escape the

00:30:22.750 --> 00:30:31.650
sandbox either. The next part come to
comes to the how we analyze and the

00:30:31.650 --> 00:30:41.540
escape the sandbox. After realizing that
there is a sandbox in the ESXi, we reverse

00:30:41.540 --> 00:30:47.620
some code of the VMkernel and we find the
kernel module named as VM Kernel SAS

00:30:47.620 --> 00:30:54.540
control system. And this system, this
module, implements the fine grained checks

00:30:54.540 --> 00:31:04.010
for the system call. And it seems that
this sandbox is a rule-based sandbox. So

00:31:04.010 --> 00:31:09.520
we just tried to find the configuration
file of this sandbox. We finally found it

00:31:09.520 --> 00:31:15.929
at this directory,
/etc/vmware/secpolicy/domains, and it

00:31:15.929 --> 00:31:24.560
seems that there are many different
sandboxes offered by VMWare to the

00:31:24.560 --> 00:31:33.740
different processes in the userworld. Like
app, plugin and the globalVMDom is a file

00:31:33.740 --> 00:31:43.820
for our VMX process and for our VM. After
reading that, it's obvious for us that the

00:31:43.820 --> 00:31:51.310
/var/run directory is the only directory
where we have read and write permissions.

00:31:51.310 --> 00:31:58.710
Then we look at the files existing in this
directory. We got a lot of pid filess just

00:31:58.710 --> 00:32:07.611
like crond, dcui, inetd and so on. And
it's also obvious that inetd.conf

00:32:07.611 --> 00:32:19.350
configure file is only configure file we
can write. What's inetd? inetd is open

00:32:19.350 --> 00:32:27.630
source software and it's a super-server
domain that provides internet services.

00:32:27.630 --> 00:32:34.930
Then we just analyze the contents of the
inetd.conf. The content of the inetd.conf

00:32:34.930 --> 00:32:44.230
is here on the ESXi. We can find that it a
defines two services, ssh and the authd.

00:32:44.230 --> 00:32:50.300
And some of it defines which binary will
be used by different services. For

00:32:50.300 --> 00:33:02.750
example, the authd will be used by the
authd services. Also after some testing,

00:33:02.750 --> 00:33:08.903
we realize that the authd service is
always enabled, while the sshd service is

00:33:08.903 --> 00:33:16.650
not. So this is the only configure file we
can write. So we got an idea. How about

00:33:16.650 --> 00:33:24.140
overwriting this configure file? Or we can
overwrite the binary part for authd like

00:33:24.140 --> 00:33:31.810
that, we can override the /sbin/authd to
/bin/sh. So once can restart the inetd

00:33:31.810 --> 00:33:41.360
process we can bind the shell to the port
authd is using. Then we just find a way to

00:33:41.360 --> 00:33:48.510
restart the inetd process. We analyzed the
configure file of the sandbox again, and

00:33:48.510 --> 00:33:55.130
we found out the queue system call we can
use in the VMX process. Then we just use

00:33:55.130 --> 00:34:03.520
the queue HUP to restart the inetd
process. Once the inetd process restarts,

00:34:03.520 --> 00:34:11.730
we can execute any commands by sending
them to the port the authd is using. So

00:34:11.730 --> 00:34:23.889
that's the method we use to escape from
the sandbox. And here's a demo.

00:34:23.889 --> 00:34:43.259
Oh, sorry.

00:34:43.259 --> 00:34:49.500
Oh, it seems not, I cannot play this
video, but it's OK. You can find it on

00:34:49.500 --> 00:34:58.529
YouTube and we created this demo after
the GeekPwn 2018, we get a reverse shell

00:34:58.529 --> 00:35:10.730
after excuting the exploit in our guest
OS. That's all. And if you want to get

00:35:10.730 --> 00:35:17.410
more details about our exploit chain,
please check our paper here and that's

00:35:17.410 --> 00:35:19.079
all. Thanks.

00:35:19.079 --> 00:35:30.009
<i>applause</i>

00:35:30.009 --> 00:35:33.630
Herald: So I don't think I'm actually
worthy to share the stage with

00:35:33.630 --> 00:35:39.869
f1yyy, that was awesome. If you have
questions, we have microphones, you need

00:35:39.869 --> 00:35:45.999
to come up to the microphone, line up
behind them and we'll take your question.

00:35:45.999 --> 00:35:53.193
Meanwhile, does the signal angel have
anything? No questions yet. Do we not have

00:35:53.193 --> 00:35:57.710
questions from the audience? There is one.
Can I have number six, please?

00:35:57.710 --> 00:36:04.279
Mic 6: Do you talk to VMWare for this
little hack?

00:36:04.279 --> 00:36:11.330
f1yyy: We have reported all these
vulnerabilities to VMWare after the

00:36:11.330 --> 00:36:18.630
GeekPwn 2018, and it has been one year
since after they repair it.

00:36:18.630 --> 00:36:24.578
Mic 6: OK, Thanks.
Herald: That's definitely a relief. Number

00:36:24.578 --> 00:36:28.640
one, please.
Mic 1: First of all, thanks for the great

00:36:28.640 --> 00:36:33.859
talk. I just want to know if there is any
meaningful thing a system administrator

00:36:33.859 --> 00:36:41.750
can do to lock down the sandbox further so
that we can have some preventative,

00:36:41.750 --> 00:36:48.329
basically tasks, for our ESXi setups. Or
if there is nothing we can do except

00:36:48.329 --> 00:36:55.158
patching, of course.
f1yyy: Could you repeat your question?

00:36:55.158 --> 00:37:01.980
It's so fast for me. Sorry about that.
Mic 1: Basically, is there anything you

00:37:01.980 --> 00:37:08.720
can do as an administrator to lock down
the sandbox even more so that this is

00:37:08.720 --> 00:37:11.950
impossible or that it is harder than what
you showed?

00:37:11.950 --> 00:37:19.130
f1yyy: OK. This is the first question.
Your can set the sandbox down by executing

00:37:19.130 --> 00:37:30.150
a command on the ESXi shell. I didn't put
the command here. I found the command to

00:37:30.150 --> 00:37:38.559
set the sandbox down. You can find it by
searching the documents about the ESXi.

00:37:38.559 --> 00:37:48.860
Wait, wait, wait, wait. I found it, just
by myself by using the command offered on

00:37:48.860 --> 00:38:00.430
the ESXi shell. It's not documented by the
VMWare. OK, I will share this command on

00:38:00.430 --> 00:38:05.880
my Twitter later. Sorry about that. I
didn't put this command into my slides.

00:38:05.880 --> 00:38:09.960
Mic 1: But would this have prevented the
attack?

00:38:09.960 --> 00:38:16.769
f1yyy: Prevented it?
Herald: By doing that change, by doing

00:38:16.769 --> 00:38:22.520
that command, would be possible to prevent
the attack that you just showed?

00:38:22.520 --> 00:38:33.589
f1yyy: The sandbox is used to protect the
VMX process. So if you update your ESXi, I

00:38:33.589 --> 00:38:40.670
think that it will be safe.
Herald: Okay, great. We have a we have a

00:38:40.670 --> 00:38:44.710
question from the Internet.
Signal Angel: Yes. Does this exploit also

00:38:44.710 --> 00:38:51.819
work on non-AMD VTx enabled VMs using binary
translation?

00:38:51.819 --> 00:38:57.609
Herald: Is it is it more universal than
just the AMD-VX?

00:38:57.609 --> 00:39:03.420
f1yyy: Yeah, can you repeat that again?
I just hear the, okay.

00:39:03.420 --> 00:39:13.300
Signal Angel: Does it also work on non-AMD
V or VTX-enabled VMs using binary

00:39:13.300 --> 00:39:19.980
translation?
f1yyyy: Yes, because all these

00:39:19.980 --> 00:39:26.529
vulnerabilities exist in the virtual
hardware. You will need to use virtual

00:39:26.529 --> 00:39:35.289
hardware in your virtual machine.
Herald: So any further questions? I'm not

00:39:35.289 --> 00:39:40.440
seeing anybody on the microphones. Any
further questions from the internet?

00:39:40.440 --> 00:39:48.230
That's it then. Good. Please, everybody help 
me in thanking f1yyyy for this fantastic talk.

00:39:48.230 --> 00:39:51.140
<i>applause</i>

00:39:51.140 --> 00:39:55.990
<i>36c3 postroll music</i>

00:39:55.990 --> 00:40:18.000
Subtitles created by c3subtitles.de
in the year 2020. Join, and help us!