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!