1
00:00:00,000 --> 00:00:18,746
36c3 preroll
2
00:00:18,746 --> 00:00:25,030
Herald: So like many operators, in my
group, we actually use a lot of ESXi
3
00:00:25,030 --> 00:00:27,870
servers. You would think that after using
these things for 10 years, I would know
4
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
5
00:00:35,050 --> 00:00:39,920
these actually runs on sandboxes or, you
know, run kind of dubious software on it.
6
00:00:39,920 --> 00:00:45,530
So we really do want to prevent these
processes from jumping from the virtual
7
00:00:45,530 --> 00:00:54,489
environment to the hypervisor environment.
We have today - we have - f1yyy, he wants
8
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,
9
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
10
00:01:09,670 --> 00:01:15,490
the last Chinese GeekPwn capture the flag.
He's gonna show us how these things work,
11
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
12
00:01:21,970 --> 00:01:23,645
onto the stage.
13
00:01:23,645 --> 00:01:28,630
applause
14
00:01:28,630 --> 00:01:41,671
f1yyy: Hello. Thanks for the introduction.
Good evening, everybody. I'm f1yyy a
15
00:01:41,671 --> 00:01:49,130
Senior Security Researcher at Chaitin
Technology. I'm going to present The Great
16
00:01:49,130 --> 00:01:56,880
Escape of ESXi; Breaking Out of a
Sandboxed Virtual Machine. We have
17
00:01:56,880 --> 00:02:05,460
demonstrated this exploit chain before at
GeekPwn 2018. I will introduce our
18
00:02:05,460 --> 00:02:12,060
experience of escaping the sandbox on the
ESXi. I will also introduce the work we
19
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
20
00:02:23,020 --> 00:02:28,690
Chaitin Security Research Lab. We have
researched many practical targets in
21
00:02:28,690 --> 00:02:35,750
recent years, including PS4 jailbreak,
Android rooting, IoT offensive research,
22
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
23
00:02:43,740 --> 00:02:51,720
own the championship at HITCON final. We
are also the organizer of the Real World
24
00:02:51,720 --> 00:02:58,680
CTF. We've created some very hard
challenges this year. So if you are
25
00:02:58,680 --> 00:03:09,400
interested in it, we welcome you to
participate in our CTF game. Now, before
26
00:03:09,400 --> 00:03:16,150
we start our journey to escaping the
virtual machine, we need to figure out
27
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
28
00:03:24,930 --> 00:03:32,130
virtualization software? If you have used
the virtualization software, like VMware
29
00:03:32,130 --> 00:03:41,200
Workstation, Hyper-V, VirtualBox and so
on, please raise your hand. Okay, okay,
30
00:03:41,200 --> 00:03:50,250
okay. Thanks, thanks, thanks. Many. So if
you are a Software Engineer or a Security
31
00:03:50,250 --> 00:03:58,930
Researcher, you'll probably have used
virtualisation software, but if anyone has
32
00:03:58,930 --> 00:04:03,730
heard of the word virtual machine escape,
if you have heard of that, please raise
33
00:04:03,730 --> 00:04:12,870
your hand again. Oh, oh, surprised.
Thanks, thanks, thanks. It surprises me
34
00:04:12,870 --> 00:04:20,560
that all you know about that, but I have
to introduce that again. What's virtual
35
00:04:20,560 --> 00:04:25,240
machine escape? You know, in most
circumstances the host OS runs on the
36
00:04:25,240 --> 00:04:32,690
hypervisor and the hypervisor will handle
some sensitive instructions executed by
37
00:04:32,690 --> 00:04:40,090
the guest OS. Host OS emulates virtual
hardware and handles RPC requests from the
38
00:04:40,090 --> 00:04:49,500
guest OS. That's the architecture of
normal virtualization software. And the
39
00:04:49,500 --> 00:04:59,340
guest OS is isolated from each other and
cannot affect the host OS. However, if
40
00:04:59,340 --> 00:05:04,660
there are some bugs, or if there are some
vulnerabilities existing in the host OS,
41
00:05:04,660 --> 00:05:13,150
it's possible for the guest OS to escape
from the virtualization environment. They
42
00:05:13,150 --> 00:05:21,139
can exploit these vulnerabilities. And
finally, they can execute arbitrary code
43
00:05:21,139 --> 00:05:30,880
on the host. So this is the Virtual
Machine Escape. Then why we chose ESXi as
44
00:05:30,880 --> 00:05:39,220
our target? The first reason is we know
that more and more companies are using or
45
00:05:39,220 --> 00:05:48,552
plan to use private cloud to store its
private data, including these companies
46
00:05:48,552 --> 00:05:56,670
and the vSphere is an enterprise solution
offered by VMware. It's popular between
47
00:05:56,670 --> 00:06:02,600
companies. If you are a Net-Manager of a
company, you may know about VMware
48
00:06:02,600 --> 00:06:11,810
vSphere. And the ESXi is the hypervisor
for VMware vSphere, so it's widely used in
49
00:06:11,810 --> 00:06:17,810
private cloud. That's the first reason.
The second one is that it's a challenging
50
00:06:17,810 --> 00:06:24,740
target for us. There are several
exploitations of VMware Workstation in
51
00:06:24,740 --> 00:06:30,790
recent years. Hackers escape from the
VMware Workstation by exploiting some
52
00:06:30,790 --> 00:06:38,520
vulnerabilities. These vulnerabilties
exist in graphic cards, network cards and
53
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
54
00:06:48,820 --> 00:06:58,311
challenging target for us and we love
challenge. Then why is the ESXi so
55
00:06:58,311 --> 00:07:04,930
challenging? The first reason I think is
that there are little documents about its
56
00:07:04,930 --> 00:07:13,640
architecture. The only thing we have found
is a white paper offered by VMware. The
57
00:07:13,640 --> 00:07:20,490
white paper only includes some definitions
and pictures without details. So let's
58
00:07:20,490 --> 00:07:29,460
take a brief look at the architecture of
ESXi first. ESXi is an Enterprise bare-
59
00:07:29,460 --> 00:07:35,800
metal hypervisor and it includes two
parts. The kernel, it uses VMKernel
60
00:07:35,800 --> 00:07:42,069
developed by VMware and the User Worlds
and the other part, the User Worlds. The
61
00:07:42,069 --> 00:07:51,476
VMKernel is a POSIX-like operating system.
And it is uses an in-memory filesystem. It
62
00:07:51,476 --> 00:07:59,291
means that all files stored in this system
are not persistent. And the VMKernel also
63
00:07:59,291 --> 00:08:08,470
manages hardware and schedules resource
for ESXi. VMKernel also includes VMWare
64
00:08:08,470 --> 00:08:15,335
drivers, I/O Stacks and some User World
APIs offered to the User Worlds. And the
65
00:08:15,335 --> 00:08:25,560
word "User World" is used by VMWare to
refer the processes running in VMKernel
66
00:08:25,560 --> 00:08:31,770
operating system and the word "User World"
means that a group of these processes.
67
00:08:31,770 --> 00:08:38,300
This process can only use a limited /proc
directory and limited signals and it can
68
00:08:38,300 --> 00:08:45,070
just use some of the POSIX API. For
example, there are some User Worlds
69
00:08:45,070 --> 00:08:55,880
processes like hosted, ssh, vmx and so on.
Then this is the architecture of ESXi. I
70
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
71
00:09:02,814 --> 00:09:09,249
VMX process in the User World can
communicate with the VMM by using some
72
00:09:09,249 --> 00:09:18,829
undocumented customized system call. And
the VMM will initialize the environment
73
00:09:18,829 --> 00:09:27,420
for the guest OS. When guest OS executes
some sensitive instructions, it will cause
74
00:09:27,420 --> 00:09:35,490
a VMExit and return to VMM. The VMX
process also emulates virtual hardware and
75
00:09:35,490 --> 00:09:41,449
handles RPC requests from the guest.
That's how a virtual machine works on
76
00:09:41,449 --> 00:09:49,336
ESXi. Then, how can we escape from the
virtual machine on ESXi? If there is a
77
00:09:49,336 --> 00:09:57,779
vulnerability in the virtual hardware of
the VMX, we can write a driver, or write
78
00:09:57,779 --> 00:10:07,410
an exploit, to escape from it. The driver
will communicate with the virtual hardware
79
00:10:07,410 --> 00:10:14,480
and it can exploit the vulnerability. And
finally we can execute shellcode in the
80
00:10:14,480 --> 00:10:19,850
VMX process. So it means that we have
successfully escaped from the virtual
81
00:10:19,850 --> 00:10:28,269
machine on the ESXi. So the second reason
about why ESXi is so challenging, is that
82
00:10:28,269 --> 00:10:40,279
User World API. The VMX uses many
undocumented and customized system calls
83
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
84
00:10:46,519 --> 00:10:55,629
API the VMX is using. But luckily we found
two system call tables after compromising
85
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
86
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
87
00:11:11,740 --> 00:11:20,870
reason. Thirdly, there are some security
mitigations here, including ASLR and NX.
88
00:11:20,870 --> 00:11:27,410
It means that we need to link some address
information before we start our exploit
89
00:11:27,410 --> 00:11:34,670
to break the randomness of the address
space. Furthermore after testing we found
90
00:11:34,670 --> 00:11:43,970
that there is another mitigation on the
ESXi. There is a sandbox that isolates the
91
00:11:43,970 --> 00:11:50,720
VMX process. So even if you can execute
some shellcode in the VMX process you can
92
00:11:50,720 --> 00:11:57,949
not execute any commands, you can not read
any sensitive fields, unless you escape
93
00:11:57,949 --> 00:12:06,720
from the sandbox either. And finally, we
think that the VMX of ESXi has a smaller
94
00:12:06,720 --> 00:12:13,651
attack surface. After comparison of the
VMX binary between the Workstation and the
95
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
96
00:12:20,920 --> 00:12:28,079
World to the VMKernel. For example the
packet transmission function in the e1000
97
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
98
00:12:37,679 --> 00:12:44,569
security advisories published by VMware
recently, you can notice that there are
99
00:12:44,569 --> 00:12:52,850
many vulnerabilites existing in the packet
transmission part of the e1000 net card.
100
00:12:52,850 --> 00:13:00,689
And all these vulnerabilites only affect
Workstation. So we think that the VMX of
101
00:13:00,689 --> 00:13:09,540
ESXi has a smaller attack surface. Now
let's start the journey of escaping from
102
00:13:09,540 --> 00:13:17,600
the ESXi. Let's overview the entire
exploit chain first. We use 2 memory
103
00:13:17,600 --> 00:13:23,709
corruption vulnerabilites in our exploit.
The first one is an uninitialized stack
104
00:13:23,709 --> 00:13:31,529
usage vulnerability which CVE Number is
CVE-2018-6981. And the second is an
105
00:13:31,529 --> 00:13:40,825
unitialized stack read vulnerability and
the CVE number is CVE-2018-6982. And we
106
00:13:40,825 --> 00:13:46,799
can do arbitrary address free by using the
first vulnerability, and we can get
107
00:13:46,799 --> 00:13:52,906
information leakage from the second one.
After combining of these two
108
00:13:52,906 --> 00:14:00,059
vulnerabilites we can do arbitrary
shellcode execution in VMX process. And
109
00:14:00,059 --> 00:14:09,589
finally we use a logic vulnerability to
escape the sandbox of VMX and reverse a
110
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
111
00:14:16,959 --> 00:14:24,329
start the first one. The first
vulnerability is an uninitialized stack
112
00:14:24,329 --> 00:14:32,749
usage vulnerability. It exists in VMXNET3
netcard. When the VMX VMXNET3 netcard
113
00:14:32,749 --> 00:14:39,939
tries to execute command
UPDATE_MAC_FILTERS it will us a structure
114
00:14:39,939 --> 00:14:47,749
on the stack, the PhysMemPage structure.
This structure is used to represent the
115
00:14:47,749 --> 00:14:54,410
memory mapping between the guest and the
host. And it's also been used to transport
116
00:14:54,410 --> 00:15:01,809
data between the guest and the host. Then
the VMXNET will call function
117
00:15:01,809 --> 00:15:07,799
DMA_MEM_CREATE to initialize the structure
on the stack first, then it will use this
118
00:15:07,799 --> 00:15:16,379
structure to execute this command. And
finally it uses PhysMemRelease to destroy
119
00:15:16,379 --> 00:15:23,410
the structure, the physical memory page
structure. So it seems that there are no
120
00:15:23,410 --> 00:15:30,829
problems here. But if we look at the
function DMA memory create, we can notice
121
00:15:30,829 --> 00:15:39,609
that there is a check before the
initialization of the PhysMemoryPage
122
00:15:39,609 --> 00:15:47,399
structure. It will check the argument
address and the argument size and if the
123
00:15:47,399 --> 00:15:54,410
check passes then it will initialize the
structure. But if the check fails, it will
124
00:15:54,410 --> 00:16:02,350
never initialize the structure on the
stack. And finally we found that we can
125
00:16:02,350 --> 00:16:13,269
control the address argument by writing a
value to one of the registers of VMXNET3.
126
00:16:13,269 --> 00:16:18,389
What is worse is that in function
PhysMemoryRelease there are no checks
127
00:16:18,389 --> 00:16:24,819
about if the PhysMemoryPage structure had
been initialized and it just frees a
128
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
129
00:16:34,189 --> 00:16:42,430
stack it's possible for us to do arbitrary
address free. We can pad a fake
130
00:16:42,430 --> 00:16:47,989
PhysMemoryPage structure on the stack and
then make the check fail in the function
131
00:16:47,989 --> 00:16:53,759
DMA memory create and finally when it
comes to the PhysMemoryRelease it will
132
00:16:53,759 --> 00:17:01,669
free a pointer of our PhysMemoryPage
structure. So we just try to find a
133
00:17:01,669 --> 00:17:09,710
function to pad the data on the stack.
There is a design pattern in software
134
00:17:09,710 --> 00:17:18,031
development, where we store the data into
the stack, if the size is small, when we
135
00:17:18,031 --> 00:17:25,541
allocate some memory. And otherwise we
will output it to the heap. And we found a
136
00:17:25,541 --> 00:17:33,720
function that fits this pattern. This
function will be used when our guest OS
137
00:17:33,720 --> 00:17:40,660
executes the instruction outsb. It will
check the size, if the size is smaller
138
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
139
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
140
00:17:55,640 --> 00:18:02,800
the data on the stack. Then how do we
combine this to do arbitrary address free?
141
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
142
00:18:10,973 --> 00:18:19,260
data should contain fake PhysMemoryPage
structure and the page count of this fake
143
00:18:19,260 --> 00:18:25,800
structure should be zero. The page array
of this fake PhysMemoryPage structure
144
00:18:25,800 --> 00:18:34,170
should be the address we want to free.
Then we set some registers of the vmxnet3
145
00:18:34,170 --> 00:18:41,170
to make the check fail in the function DMA
memory create. And finally, we order the
146
00:18:41,170 --> 00:18:50,320
vmxnet3 netcard, to execute the command to
update MAC filters and then in the VMX it
147
00:18:50,320 --> 00:18:57,230
will use the PhysMemRelease to destroy the
structure we pad before. This structure is
148
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
149
00:19:04,900 --> 00:19:12,110
it's 0, it will free the page
array of this fake PhysMemPage structure.
150
00:19:12,110 --> 00:19:17,860
So we can do arbitrary address free now by
using the first uninitialized stack usage
151
00:19:17,860 --> 00:19:25,990
vulnerability. Here come the next one, the
second vulnerability also exists in the
152
00:19:25,990 --> 00:19:34,050
vmxnet3 net card. The vmxnet3 net card
tries to execute command get_coalesce. It
153
00:19:34,050 --> 00:19:43,428
will first get a length from the guest,
and the length must be 16. Then it
154
00:19:43,428 --> 00:19:51,500
initializes the first eight byte of a
structure on the stack. But it's just for
155
00:19:51,500 --> 00:19:57,890
guest to initialize the next 8 byte of
this structure and just write this
156
00:19:57,890 --> 00:20:07,080
structure back to our guest OS. So we can
link 8 byte uninitialized data on the
157
00:20:07,080 --> 00:20:14,190
stack from the host to our guest. And
after debugging the guest VMX process, we
158
00:20:14,190 --> 00:20:20,310
realized that there are fixed offsets
between the images, so it's possible for
159
00:20:20,310 --> 00:20:31,200
us to get all the information about the
address space by using this vulnerability.
160
00:20:31,200 --> 00:20:38,320
Now, what do we have now? We can do
arbitrary address free by using the first
161
00:20:38,320 --> 00:20:45,220
one. And we can get all information about
the address space by using the second one.
162
00:20:45,220 --> 00:20:50,970
What do we want to do? We want to do
arbitrary shell code execution in the
163
00:20:50,970 --> 00:20:58,330
VMX. So how do we combine these two
vulnerabilities to achieve our target?
164
00:20:58,330 --> 00:21:03,490
It's hard for us to do arbitrary shell
code execution by using arbitrary address
165
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
166
00:21:09,320 --> 00:21:16,600
address write. So our target changes into
how to do arbitrary address write by using
167
00:21:16,600 --> 00:21:25,650
arbitrary address free. Then we realized
that we need a structure and this
168
00:21:25,650 --> 00:21:33,620
structure should include pointers we can
write and the size. So last we can
169
00:21:33,620 --> 00:21:40,440
overwrite this structure. We can do
arbitrary address writes usually. When we
170
00:21:40,440 --> 00:21:48,510
first tried to exploit this vulnerability,
we used some structures in the heap, but
171
00:21:48,510 --> 00:21:56,860
we've found that we can not manipulate the
heap's layout stably because VMX
172
00:21:56,860 --> 00:22:03,500
frequently allocates and releases
memory. So we cannot use the structures in
173
00:22:03,500 --> 00:22:11,870
the heap. And after reversing some code of
VMX, we have found a structure. The
174
00:22:11,870 --> 00:22:20,210
structure's name is channel and it's used
in VMWare RPCI. What's VMWare RPCI?
175
00:22:20,210 --> 00:22:26,850
VMWare has a series of RPC mechanisms to
support communication between the guest
176
00:22:26,850 --> 00:22:33,000
and the host. And here it has an
interesting name: backdoor. RPCI is one of
177
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
178
00:22:40,230 --> 00:22:47,200
again if anyone has installed VMWare tools
in your guest OS, please raise your hands
179
00:22:47,200 --> 00:22:58,230
again. Oh, not as much as before. So if
you use VMWare workstation, you'll
180
00:22:58,230 --> 00:23:04,850
probably have installed VMWare tools in
your guest because once you installed it,
181
00:23:04,850 --> 00:23:12,790
you can use some convenient functions such
as copy and the paste text fields between
182
00:23:12,790 --> 00:23:20,940
the guest and the host, drag and drop
files, create shared folder and so on.
183
00:23:20,940 --> 00:23:29,610
VMWare tools are implemented by using some
RPCI commands. And here are some examples
184
00:23:29,610 --> 00:23:37,760
about about some RPCI commands. For
example, we can use info-set guestinfo to
185
00:23:37,760 --> 00:23:44,350
set some information about our guest and
we can use info-get to retrieve this
186
00:23:44,350 --> 00:23:54,790
information back. Then what happens when
we execute this RPCI command in our guest?
187
00:23:54,790 --> 00:24:03,230
For example, if we execute this RPCI
command 'info-set guestinfo.a' 123 in our
188
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
189
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
190
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
191
00:24:31,500 --> 00:24:39,650
will use the subcommand, 'Open' first to
open a channel and initialize it. Then it
192
00:24:39,650 --> 00:24:49,880
will use a subcommand, 'SendLen' to set
the size of our channel and allocate heap
193
00:24:49,880 --> 00:24:56,111
memory to install the data of our RPC
command and suddenly it will use the
194
00:24:56,111 --> 00:25:07,780
'SendData' subcommand to pad the data of
the memory we allocated before. And once
195
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
196
00:25:15,750 --> 00:25:23,220
'SendLen' subcommand the VMX will use a
corresponding RPCI command handler
197
00:25:23,220 --> 00:25:31,410
function after a string combination. And
finally, it will use a 'Close' subcommand
198
00:25:31,410 --> 00:25:37,980
to destroy the channel structure including
setting the size to zero and freeing the
199
00:25:37,980 --> 00:25:46,720
data pointer. That's what happens when we
execute this RPCI commend in our guest.
200
00:25:46,720 --> 00:25:54,847
Furthermore, there is a channel structure
area in the data segment we can use. So
201
00:25:54,847 --> 00:26:03,740
this is a perfect structure for our
exploit. Now, you got all the things we
202
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
203
00:26:09,720 --> 00:26:20,280
combine this? We notice that the VMX uses
ptmalloc of Glibc to manage its heap. So
204
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
205
00:26:26,227 --> 00:26:32,110
attack is a method to exploit heap
vulnerabilities of ptmalloc by using the
206
00:26:32,110 --> 00:26:41,252
singly-linked list. And it's the easiest
exploit method to exploit ptmalloc, I
207
00:26:41,252 --> 00:26:48,640
think. It's also the first method to
exploit ptmalloc that I learned when I
208
00:26:48,640 --> 00:26:56,840
just started to learn how to how to
exploit. Then after considering the check
209
00:26:56,840 --> 00:27:05,590
existing in the Glibc, we decided to free
the address at the Reply Index of channel.
210
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
211
00:27:15,240 --> 00:27:23,310
will check the current chunk's size. And
after doing that, the size of the fake
212
00:27:23,310 --> 00:27:30,360
chunk is also the size of the
'channel[N]', so we can set a valid value
213
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.
214
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
215
00:27:47,015 --> 00:27:59,120
list first. Then we can reallocate this
fake chunk by using another channel, N+2.
216
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
217
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
218
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
219
00:28:23,710 --> 00:28:29,490
easy now for us to do arbitrary address
write by faking some parts of the channel
220
00:28:29,490 --> 00:28:39,330
structure. Do remember our target? Our
target is to do arbitrary shell code
221
00:28:39,330 --> 00:28:46,960
execution in VMX and we can do arbitrary
address write now. There are many ways to
222
00:28:46,960 --> 00:28:52,370
do arbitrary shell code execution by using
arbitrary address write. We choose to use
223
00:28:52,370 --> 00:29:02,850
a ROP. We can override the '.got.plt'
segment. We can fake the channel[N+1],
224
00:29:02,850 --> 00:29:10,620
structure first, overwrite the data
pointer at channel[N+1] to the address of
225
00:29:10,620 --> 00:29:21,940
.got.plt segment. Then we can overwrite
the function pointer on the .got.plt
226
00:29:21,940 --> 00:29:30,940
segment. So once the VMX uses this
function we overwrite, it will jump to our
227
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
228
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
229
00:29:50,280 --> 00:29:56,820
that we have escaped from the virtual
machine of the ESXi fully, we tried to
230
00:29:56,820 --> 00:30:06,350
execute some command by using a system
call execve, but it fails. We tried to
231
00:30:06,350 --> 00:30:13,550
open and read some sensitive files just
like password, it fails again. Then we
232
00:30:13,550 --> 00:30:22,750
realize that there is a sandbox. We cannot
execute any commands unless we escape the
233
00:30:22,750 --> 00:30:31,650
sandbox either. The next part come to
comes to the how we analyze and the
234
00:30:31,650 --> 00:30:41,540
escape the sandbox. After realizing that
there is a sandbox in the ESXi, we reverse
235
00:30:41,540 --> 00:30:47,620
some code of the VMkernel and we find the
kernel module named as VM Kernel SAS
236
00:30:47,620 --> 00:30:54,540
control system. And this system, this
module, implements the fine grained checks
237
00:30:54,540 --> 00:31:04,010
for the system call. And it seems that
this sandbox is a rule-based sandbox. So
238
00:31:04,010 --> 00:31:09,520
we just tried to find the configuration
file of this sandbox. We finally found it
239
00:31:09,520 --> 00:31:15,929
at this directory,
/etc/vmware/secpolicy/domains, and it
240
00:31:15,929 --> 00:31:24,560
seems that there are many different
sandboxes offered by VMWare to the
241
00:31:24,560 --> 00:31:33,740
different processes in the userworld. Like
app, plugin and the globalVMDom is a file
242
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
243
00:31:43,820 --> 00:31:51,310
/var/run directory is the only directory
where we have read and write permissions.
244
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
245
00:31:58,710 --> 00:32:07,611
like crond, dcui, inetd and so on. And
it's also obvious that inetd.conf
246
00:32:07,611 --> 00:32:19,350
configure file is only configure file we
can write. What's inetd? inetd is open
247
00:32:19,350 --> 00:32:27,630
source software and it's a super-server
domain that provides internet services.
248
00:32:27,630 --> 00:32:34,930
Then we just analyze the contents of the
inetd.conf. The content of the inetd.conf
249
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.
250
00:32:44,230 --> 00:32:50,300
And some of it defines which binary will
be used by different services. For
251
00:32:50,300 --> 00:33:02,750
example, the authd will be used by the
authd services. Also after some testing,
252
00:33:02,750 --> 00:33:08,903
we realize that the authd service is
always enabled, while the sshd service is
253
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
254
00:33:16,650 --> 00:33:24,140
overwriting this configure file? Or we can
overwrite the binary part for authd like
255
00:33:24,140 --> 00:33:31,810
that, we can override the /sbin/authd to
/bin/sh. So once can restart the inetd
256
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
257
00:33:41,360 --> 00:33:48,510
restart the inetd process. We analyzed the
configure file of the sandbox again, and
258
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
259
00:33:55,130 --> 00:34:03,520
the queue HUP to restart the inetd
process. Once the inetd process restarts,
260
00:34:03,520 --> 00:34:11,730
we can execute any commands by sending
them to the port the authd is using. So
261
00:34:11,730 --> 00:34:23,889
that's the method we use to escape from
the sandbox. And here's a demo.
262
00:34:23,889 --> 00:34:43,259
Oh, sorry.
263
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
264
00:34:49,500 --> 00:34:58,529
YouTube and we created this demo after
the GeekPwn 2018, we get a reverse shell
265
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
266
00:35:10,730 --> 00:35:17,410
more details about our exploit chain,
please check our paper here and that's
267
00:35:17,410 --> 00:35:19,079
all. Thanks.
268
00:35:19,079 --> 00:35:30,009
applause
269
00:35:30,009 --> 00:35:33,630
Herald: So I don't think I'm actually
worthy to share the stage with
270
00:35:33,630 --> 00:35:39,869
f1yyy, that was awesome. If you have
questions, we have microphones, you need
271
00:35:39,869 --> 00:35:45,999
to come up to the microphone, line up
behind them and we'll take your question.
272
00:35:45,999 --> 00:35:53,193
Meanwhile, does the signal angel have
anything? No questions yet. Do we not have
273
00:35:53,193 --> 00:35:57,710
questions from the audience? There is one.
Can I have number six, please?
274
00:35:57,710 --> 00:36:04,279
Mic 6: Do you talk to VMWare for this
little hack?
275
00:36:04,279 --> 00:36:11,330
f1yyy: We have reported all these
vulnerabilities to VMWare after the
276
00:36:11,330 --> 00:36:18,630
GeekPwn 2018, and it has been one year
since after they repair it.
277
00:36:18,630 --> 00:36:24,578
Mic 6: OK, Thanks.
Herald: That's definitely a relief. Number
278
00:36:24,578 --> 00:36:28,640
one, please.
Mic 1: First of all, thanks for the great
279
00:36:28,640 --> 00:36:33,859
talk. I just want to know if there is any
meaningful thing a system administrator
280
00:36:33,859 --> 00:36:41,750
can do to lock down the sandbox further so
that we can have some preventative,
281
00:36:41,750 --> 00:36:48,329
basically tasks, for our ESXi setups. Or
if there is nothing we can do except
282
00:36:48,329 --> 00:36:55,158
patching, of course.
f1yyy: Could you repeat your question?
283
00:36:55,158 --> 00:37:01,980
It's so fast for me. Sorry about that.
Mic 1: Basically, is there anything you
284
00:37:01,980 --> 00:37:08,720
can do as an administrator to lock down
the sandbox even more so that this is
285
00:37:08,720 --> 00:37:11,950
impossible or that it is harder than what
you showed?
286
00:37:11,950 --> 00:37:19,130
f1yyy: OK. This is the first question.
Your can set the sandbox down by executing
287
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
288
00:37:30,150 --> 00:37:38,559
set the sandbox down. You can find it by
searching the documents about the ESXi.
289
00:37:38,559 --> 00:37:48,860
Wait, wait, wait, wait. I found it, just
by myself by using the command offered on
290
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
291
00:38:00,430 --> 00:38:05,880
my Twitter later. Sorry about that. I
didn't put this command into my slides.
292
00:38:05,880 --> 00:38:09,960
Mic 1: But would this have prevented the
attack?
293
00:38:09,960 --> 00:38:16,769
f1yyy: Prevented it?
Herald: By doing that change, by doing
294
00:38:16,769 --> 00:38:22,520
that command, would be possible to prevent
the attack that you just showed?
295
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
296
00:38:33,589 --> 00:38:40,670
think that it will be safe.
Herald: Okay, great. We have a we have a
297
00:38:40,670 --> 00:38:44,710
question from the Internet.
Signal Angel: Yes. Does this exploit also
298
00:38:44,710 --> 00:38:51,819
work on non-AMD VTx enabled VMs using binary
translation?
299
00:38:51,819 --> 00:38:57,609
Herald: Is it is it more universal than
just the AMD-VX?
300
00:38:57,609 --> 00:39:03,420
f1yyy: Yeah, can you repeat that again?
I just hear the, okay.
301
00:39:03,420 --> 00:39:13,300
Signal Angel: Does it also work on non-AMD
V or VTX-enabled VMs using binary
302
00:39:13,300 --> 00:39:19,980
translation?
f1yyyy: Yes, because all these
303
00:39:19,980 --> 00:39:26,529
vulnerabilities exist in the virtual
hardware. You will need to use virtual
304
00:39:26,529 --> 00:39:35,289
hardware in your virtual machine.
Herald: So any further questions? I'm not
305
00:39:35,289 --> 00:39:40,440
seeing anybody on the microphones. Any
further questions from the internet?
306
00:39:40,440 --> 00:39:48,230
That's it then. Good. Please, everybody help
me in thanking f1yyyy for this fantastic talk.
307
00:39:48,230 --> 00:39:51,140
applause
308
00:39:51,140 --> 00:39:55,990
36c3 postroll music
309
00:39:55,990 --> 00:40:18,000
Subtitles created by c3subtitles.de
in the year 2020. Join, and help us!