 So this is Agenda. We'll talk briefly about hypervisor based isolation, what protections those provide against malicious software, malicious devices and so on or compromised devices. We'll talk about this nasty thing that we call firmware rootkit and how hypervisors are good at protecting gays from rootkit. We'll also talk about how that rootkit could be installed as well as the vulnerabilities that we use to install the firmware rootkit or to compromise hypervisor from within the virtual machines. And we'll conclude with some of the mitigations available there, tools that we'll be releasing soon, open source. So with that, you know, hypervisor based isolation, it's good when it's done, when it's complete. And with that I'm switching to Alex, he'll actually explain what it is. So usually hypervisor isolation working with some, if we have malicious virtual machine, it's infected by some malware or compromised by some exploit. Closer or take it. Okay. So, okay. So, good. If we have some compromised virtual machine and by some malicious software or some exploit, it's usually protected by hypervisor to not affect the other virtual machines into cloud or some machine. And also hypervisor protect from attacks from the malicious hardware. It's been some VTD attacks based on DMA or something like option ROM, something like that. So. And usually hypervisor developers not directly thinking about firmware isolation. And we will show in our representation how system firmware can affect a lot of different hypervisors. So. And it's some description of different technologies based on hypervisor isolation. So usually the memory protects and hypervisors dispatch BMA access and isolated direct hardware access for read emissars, IO permissions, by beat maps. And also memory protected by EPT and controlling from hypervisor level. And it's software, usually it's software based isolation. And also a lot of hypervisors have device level isolation which based on some interuptive mapping or IO MMU for which protected by VTD also for DMA attacks. But so we will look in how from firmware it's looks in different vision. So it's a little bit description about how this technology of isolation work. So usually all configuration about hypervisor, about virtual machine start in VM control structure in Intel, it's VM CS. And it's control all interrupt execution or instruction exceptions. And also the we have MSR beat maps which isolate direct access to read write MSRs from guests or EPT pages which usually software based isolation. And IO bit maps which controlling direct IO access to the devices. And here is the B2, it's software SMI interrupt. And we will show on the next slides how we can apply SMI handlers attack against hypervisors for compromise this protection. And we will show how we can compromise EPT pages protection by script attack vector. It's not new exploit but it's already show on his communication con address in the last year, on the end of the last year by Corey and Drafal from Bromium and Lekbukor. Corey from Lekbukor. So but we found some interesting way to compromise hypervisors by this vector. It's not showing before just on glass black hat this week. And system firmware level isolation it's really important. And if you control the system firmware you can access to direct to the physical memory and control everything on the system. It's not mean if you control the firmware on some device, it's mean if you control the bios you control the system. And we will show how it's possible to attack VMM with some specific root kit for ECMM. And Yuri we will continue with root kit. Yeah if I'm not tripping over this cable. So okay. So one of the first thing before we actually go into trying to attack hypervisor from within the virtual machines using firmware. Why would anyone do that? Well one of the impact is install a root kit into the firmware and get persistence, get full stealth, get what we think or what you might think after the presentation full control over the hypervisor and all the virtual machines. But before we started that we kind of found that picture. And what do you think where the kit is? And who is the kit and who is the lion? No guess? Okay. Our guess was the kit is the root kit and the hypervisor. So those kind of things that you know monstrous completely you know protecting everything from including those kind of things like root kit. So we'll see how that goes. So what is firmware root kit? In a really kind of a very high level picture it's just something infecting the system firmware. Either bios or U5 firmware or an SMI handler which is a runtime portion of the bios executing in parallel with the hypervisor OS. Or it could be something else like I don't know Corbut or some other kind of software architecture of the firmware. So you can see the arrow on the left of the slide. The privileges of the exploit compromising each portion on that picture increases with going down the stack. And it's pretty kind of a familiar concept. If you compromise something within the VM you cannot compromise other VMs or hypervisor. If you compromise hypervisor you can control the VMs but you cannot really compromise firmware and so on. But if you can compromise firmware you control hypervisor and everything on top of it. So that's kind of the idea of the slide. However this is not how we've actually implemented that because the root kit, one of the goals of the root kit is to stay stealthy and persistent so nobody gets out of the firmware and nobody can detect it. So we took a different strategy rather than root kit compromising hypervisor over writing its code and so on. It might be detectable. And it's not that it's more difficult because we don't know hypervisors. We don't know how to modify them. So what we did instead, I assume there's an attacker VM. The VM that is controlled by the attacker completely and somehow on that system, and we'll explain how, but somehow on that system root kit got installed into the firmware. So instead of actually kind of over writing hypervisor or installing your own hypervisor or anything like that, so we implemented a back door. We did a very small modification to the data structures. No modification to the code. I'll explain how we modified data structures, but the ultimate is ultimately we can implement multiple kind of strategies for the root kit. And in fact, one of the strategies is one bit modification. And that one bit modification basically gives the attacker VM full control over everything going on in the system, including the hypervisor. So we'll have a demo. The demo uses a slightly different approach. So I'll explain it on the next slide. So through that back door, we don't modify anything, any code. We install that back door through a data structure, and then that back door provides full access to one specific particular VM to all other VMs, including to the hypervisor itself. So how that particular, our particular back door worked. So when root kit is on the system, every time the system boots, it starts as part of the firmware. In fact, we've been using kind of runtime part of the firmware, which periodically scans the memory. So the root kit scans memory, finds virtual kind of a virtual control blocks or virtual control structures for the virtual machines, finds the one that belongs to our attacker VM, and then from that point on, it finds the kind of the pointer to the hardware assisted page tables that Alex talked about, the page tables that actually translate the guest physical addresses to the host physical addresses, and modifies those page tables by just adding a few entries. And those entries, you can see them over there. So they basically map on, you know, they map all of the DRAM starting from zero to the physical addresses starting from 256 gigabytes. So at 256 gigabytes boundary, our attacker VM will have full access to the DRAM, to all of the other VMs, to the VMM itself, and everything else. And basically that's, you know, I had actually balloons describing what I just described, right? So the root kit added a page table, page table entries to the page table, and now attacker VM has full access to all of the memory. So before we show you the demo, how would one install the root kit in the firmware? First, method is what Dino calls a border guard attack. It's basically when somebody sticks something to your laptop when you, you know, leave it. Like for example, this, you know, spy flash programmer, and physically overrides the firmware on the spy flash. That's kind of a nice, you know, sometimes you can see that somebody, you know, broke your laptop apart. Sometimes you cannot. But, you know, the easier mechanism would be if the firmware is not properly protected, it's protecting itself on the spy flash, on the ROM, then, you know, putting into a malicious USB and basically running a code that will reflash your firmware, that's an easier mechanism. Kind of like better USB or something. You can use other ways with the physical access to infect the system. In fact, Traml and Zeno showed yesterday how to use, you know, the add on, add on adapters to infect the firmware. So there are other mechanisms with the physical access. But firmware root kit could be installed using software mechanism, right? For example, if the firmware is not adequately protected itself in the flash memory, you don't need physical access at all. You need to have a kind of an attack, a software attack that can flash whatever it wants on the spy flash memory. It could be done from privileged guests. For example, Dom Zero or Root Petition. Because all of them, you know, provide some direct access to the system firmware. You know, for that, you would need either a direct exploit to the privileged guest or you need privileged escalation from normal guest to the privileged guest. It could be done from the host of us in the hosted virtualization scenario. You could, you know, one could install a root kit before even the hypervisor is there or in parallel with the hypervisor. Or, you know, hypothetically it could be done from a normal guest if the VMM provides direct access to one of the system firmware interfaces to the normal guest. So there are software mechanisms to install a root kit. So, and now let me just show you the demo of the root kit before we go into the exploitation part. So we will, we will use hypervib. Can you see that? Okay. So we'll use hypervib, but this root kit is VMM agnostic. It will work against any VMM. So it's broken in two parts. The demo is broken in two parts. This is the first part where we install the root kit. And we're using the fact that this system particularly doesn't properly protect its own firmware. So we're just bypassing the firmware protection and installing something on the flash. And this could be done like months before this, you know, rebooting the server. It could be done like I showed with a physical access with a USB stick or with a spy program or something like that. So it's, it was the first part. Now we rebooted that server. So we have, we have three virtual machines here. Two of these are victim machines. One of them runs Ubuntu, the other one runs Windows. And we have a third machine which is a attacker virtual machine. It runs Windows. So first we will open a Ubuntu virtual machine. It has an Apache installed in it. And so what we'll, what we'll do is we'll actually generate a public private key pair, including the public certificate for Apache for HTTPS. And that's what I will do in a second and bear with me because I was made to type this whole open SSL command line, you know, not from history, but like literally type it, three lines. Okay. So we're generating, we're generating X509 certificates and private key, RSA private key for our Apache. So the private part, you can see RSA 2048 bits that about right. So the private, the private key will be dumped into that SSL certsnakecoil.key file. And the public part will get written to SSL certsnakecoil.pm. So we're issuing a certificate, we're requesting to issue a certificate for victim corp registered in Las Vegas, Nevada with no emails. Now I'll just bring up the config file. And you can see that those private and public keys are, you know, used in Apache. Now let's restart Apache. So the server is up. It's using those keys. HTTPS is enabled to the server, to the web server. Now I'll just bring it, bring the private portion of the RSA key on the display. So this is all that the victim corp did on that virtual machine. Now we'll open a virtual machine with windows. And the only thing we'll do there, we have kind of a, you know, confidential documents over there on that virtual machine. Two confidential documents. One of them is annual earnings of some corporation which is, apparently confidential for, I don't know what reason. The second document is product schedule of the same corporation. And it's super top secret. A little bit more confidential. So the only thing we did is just view those documents. And now we'll go to the attacker's VM running windows. Remember, this system just got, you know, a couple minutes ago that system got RootKit installed in the firmware. So RootKit is now, you know, working, running, doing its thing, opening it back door to the attacker VM. So in attacker VM, I'll tell you a secret. Now it has full access to all the memory. So what we do is we just run a script that dumps and searches for, you know, some secret artifacts in that memory. And we're searching for private keys. We're searching for kind of the documents, RTF documents, docs, and so on. So give it a minute. It found RTF documents in memory somewhere. Saved it to file. Found a few of those. Found RSA private key, SSH key, key blob, by the way, not ours. Some encrypted private keys and so on. It actually finds a whole bunch of stuff, not even the ones that we generated. So the script is done. It dumps all those found artifacts into folder. Now let's search for confidential, files that have confidential. And here we go. So we found blank document. Okay. We found annual earnings confidential documents that somebody opened in a completely different VM. You have to say at least until top, super top secret. So we're now looking for super top secret. And we found that super top secret document as well. And so finally, we're looking for private key blob. There are quite a few private key blobs extracted from memory. And one of them is basically our RSA private key. And just to compare those, you can compare those offline. The video will be available offline. So those will be two keys. So bottom line, we had a completed persistent rootkit, completely stealthy. Nobody from within the VM virtual machines including the administrative virtual machines like root partition in this Hyper-V is able to find it there. And the rootkit is VMM agnostic. So you install any VMM and it will get the same results. It won't even notice which VMM is installed because we're not even using any of the artifacts of any specific VMM. So now we're switching. I'm switching to full screen. Bear with me. Second. Yeah. Okay. So yeah. So we flashed the rootkit directly into the firmware image from within the root partition. And this is because the system didn't properly protect the firmware. But more systems started protecting those, doing those basic protections like enabling right protection of the firmware in the spy flash. You can test with that specific module common dot bias underscore WP. By the way, you have Chipsack on all the DevCon CDs, thanks to DevCon team and lost especially for that. So you can grab Chipsack out of there and test if your system is recuitable like that. But what would the attacker do if the system's properly protect their biases in UFI firmware? Well, we've explained a whole bunch of attacks that, you know, a whole bunch of vulnerabilities in the previous presentation and recon that could be used for those purposes. So you could install a rootkit using those vulnerabilities as well. And we'll discuss two of those. But before we go, we'll go to discuss two of those vulnerabilities. So a couple of words about what this rootkit could do. In fact, it's, you know, the rootkit has access to provides access to the attacker VM to all the memory. And from that memory, that attacker VM can extract VMC structures or VMCV structures, extended page tables or an asset page table. So hardware assisted page tables can extract host page tables for for the hypervisor guest page tables for each of the guests can extract all of the page tables for IOMMU units for all of the units for all the hardware. It could extract the memory map including a VM exit handler, as well as it can extract full configuration of all of the real hardware devices, including PCI configuration register, some way of register since on. So this is one example. So we're, we're basically extracting from just memory, we're extracting all the extended page tables with which gives us all of the kind of a memory map, the translation from the guest physical addresses to the host physical addresses. Now with that, let's go to the section that explains how we would, how the attacker would exploit hypervisors from within the virtual machines. And all of those attacks that we'll describe here, they are done from the privileged administrative position. So specifically a root position or DOM zero. So, you know, but we kind of the full version of the slides that are published right now, it has a little bit more details, including, you know, including vulnerabilities from within the normal guests and so on. So with that, transitioning to Andrew, he'll, he'll walk you through the attacks. Okay. So, what the, turn it on. Okay. All right, so, yeah. Okay. Oh, that's better. So, what poor attacker can do if he finds that spy flash is properly protected. So, he can try another thing. There is a small piece of code that handles the system management interrupts. It's SMI handlers and SMI handlers accept parameters in general purpose registers. The parameters can be pointers and SMI handlers reads and writes data using these pointers. So, and if the pointer is not checked, it can write or read from SMRAM itself. So, if that attacker can generate SMI and supply the pointer into SMRAM, SMI handler will do write for the attacker. So, the attacker is a privileged, isn't privileged with partition. So, and if he can generate SMI from the kernel from RIN0, it will go to SMI handler and SMI handler will write to hypervisor memory. Like this. It can modify the code data. Like you mentioned, it can modify page table structures, open a back door or drop a piece of code that will override the spy flash for us. We have a demo. Second demo. It's a hyper e as well. This way we run the exploit from the partition. So, right now the exploit is compromising SMI handler from within the partition. We're launching the second part of the exploit. Now we're trying to find controlled structures in hypervisor memory. So, we're in a virtual machine analyzer that will find this for us and show this on the screen. So, as you can see, it found 3 virtual machine including a partition itself. So, we have complete access to the hypervisor memory. So, we can do whatever we want with it. So, how is this possible? The problem is that the memory configures IO bitmap. So, it allows a privilege guest to generate access to several ports. One of the open port is B2 port which we can use to generate system management and interrupt. You can see the IO map ports that cause the exit circuit with red. So, the access only to this port will be caught by VMM or other accesses to other ports. They will not be seen by VMM. So, this way we can generate the system management interrupt and hypervisor will not see it. So, this is a firm ratio, right? So, the problem is that hypervisor doesn't check the pointers that supply to, oh, the SMI handler doesn't check the pointers that supply to it. But what is the SMI handler is implemented correctly and it checks that the pointer is not in SM RAM? Because it's the only thing it can do. Because he knows where the SM RAM is but he has no idea of the virtual, of the hypervisor memory partition and where is the hypervisor memory and where is virtual machine memory. So, the attacker can still supply pointer pointing somewhere in physical memory and this memory can be hypervisor memory. And SMI will still write data to this memory because it's outside of SM RAM. So, from the point of view of SMI handler, it's completely legal operation. So, in this case, the attack will look like this. So, the attacker generate SMI and SMI handler will compromise the hypervisor memory. So, SMI handler writes data, writes data code in VMM and opens the back door. So, you want to... Yep, so, thanks, Andrew. So, basically, that was one of the attacks applicable to Hyper-V because of the fact that, route partition has access to all the IOPORs including the SMI IOPOR which is B2. So, it can trigger vulnerability in the SMI handler and this way, you know, propagate the attack on to the hypervisor. Next, we'll show a completely different issue which was discovered by multiple folks and multiple teams including our team as well as Rafaal from Bromium and researchers from Legbacore. This vulnerability is known as S3 Resimbot Script Vulnerability and Tremel and Zeno used it in Thunderstrike 2 attack as well on Max yesterday. So, we'll use that attack. So, the first, I need to explain a little bit of the kind of background of what S3 is. You know, most of the systems especially, laptops, desktops and so on, they support the sleep state or suspender RAM where you put the system into sleep and it's resumed and that happens much faster than you put the system and that's the purpose, right? The contents in the memory are preserved when you're resuming the system from sleep. And so, what happens with a firmware? When firmware normally boots, it executes a whole bunch of code. If it's a UFI specific firmware or base firmware, then it's executing hundreds of so-called firmware Dixit drivers. Each of them configures something within the hardware, some device or so, like writing certain registers. So, it's a lot of time and we need to, you know, conserve that time. Thank you. So, the way it's done, those drivers record their actions in addition to configuring hardware, they record their actions into a structure called Resume Boot Script Table. And this structure is just in the memory, well, on many systems. So, when you put the system into sleep and resume from sleep, the firmware doesn't execute all of that, you know, code all of those drivers. In fact, what it does, it loads a kind of the executable module, firmware module that interprets the Boot Script Table. So, which reads those actions that have been previously recorded on a normal boot, interprets them, and this way restores all of the hardware configuration on the system. That saves you a whole bunch of time. That is why we can resume like in seconds and so on. So, a little bit, a few words about what this Boot Script Table is. It's just a sequence of upcodes. Each upcode can write specific hardware register, either PCI Config register or memory map IO register or memory location or IO port. So, this particular screenshot, it shows you that the upcode is writing to memory. In fact, judging based on the address, that's a kind of a memory map IO or memory map configuration register. But there are other upcodes because, you know, sometimes it's not sufficient to just write to the register. Sometimes firmware needs to do a little bit more complex action. And for those kind of types of things, there is a dispatch upcode that basically just invokes arbitrary code. So, what can you go wrong? First of all, the vulnerability is described in great details by, in the white paper we've referenced as well as in the publications by Corey and Rafal. So, first, how that applies to attacking hypervisor. So, we will attack Xen from DOM zero. Because Xen does not prevent DOM zero access to the S3 boot script table. Well, apparently because just, you know, VMM's don't know about that boot script table. That's a firmware thing, right? So, they assume there is an exploit within the DOM zero. This exploit just goes and modifies the contents of memory. It modifies that S3 boot script table, installs additional upcodes, modifies existing upcodes or something like that. And, you know, then puts system into sleep. And when system resumes from sleep, the firmware, you know, interprets the completely bogus attacker boot script table. And, you know, including, you know, executing a richer code. This is done on, with the firmware privileges. There are four, therefore that code can modify hypervisor at will. So, basically, you've got Xen compromised here. So, well, I'll show you the demo on exploiting Xen from DOM zero using this vulnerability. Just, let's just see that we're in DOM zero using Xen. And we have Ubuntu Guest, Ubuntu virtual machine. So, I'm launching a command that just, you know, searches memory for hypervisor structures. Structures, you saw the structures, VMCAS, extended page tables and so on. Basically, structures hypervisor wants to protect. They guarantee hypervisor protection. And the script couldn't find anything. Because, you know, you generally, not other guests have access to those critical structures, including the privileged guests like DOM zero or root partition. They cannot. Now, so, to kind of solve that problem, we're launching an exploit. We're launching an exploit by modifying S3 boot script table in memory, which we have access to. We installed some upcodes into that boot script table. Then we're putting system into sleep with RTC wake. And it will take us a couple of seconds to wake from sleep. So, now we're awake. System is up and running again. And we're launching the same script that, you know, looks for those critical structures of the hypervisor. VMCAS structures and APT page tables. And we found one. So, basically, we have full access to the structures controlling virtual machine for that Ubuntu guest. So, okay. That does look a little bit familiar for those of you who followed ITL research for a few years ago. They did, you know, they did explain that, hey, it's possible to bloop the hypervisor through the BIOS or through the MBR. And pretty much those attacks, you know, kind of get to the point that, yes, you can compromise hypervisors completely using those vulnerabilities in the BIOS or in the firmware. So, but those vulnerabilities were from privileged guests, like route partition and DOM zero, which sort of limits the impact in the minds of a lot of people, right? Minus the privilege escalations from the normal guest to the privileged guest, right? Or directly, you know, exploit into the route partition. So, what about the cases that strictly want to separate guests from route partition? And we heard a presentation by folks from Microsoft on the new virtualization based security modal in Windows 10, which is basically that modal. So, right now we are working with Microsoft to make sure that those are not kind of applicable to the Windows 10. So, tools and mitigations that we have. First of all, first thing, things first. If you have vulnerabilities in the firmware, you're in trouble. You can have thunder strike, you know, infection, you can have a completely persistent and stealthy route kit. You can compromise, you know, you can attack full-disk encryption based on TPM. You can attack secure boot. You can, as we saw, you can completely control the hypervisors and everything, every secrets within every VM. So, we need to fix those vulnerabilities, of course. And there are tests in the open source chip stack framework that you can run and test for both issues that we've explained. If your systems are vulnerable as well as you can test if the firmware is right protected on the spy flash. But you can, we also need to test hypervisors and especially all of those hardware and firmware interfaces that the hypervisor is exposed to the VMs. And we'll be releasing open source modules to the chip stack that tests pretty much every hardware interface. Like MSR emulation, IO port emulation, CPID emulation, MMIO emulation and so on. As well as we'll release some of the additional functionality in the chip stack that just allows you to see how VMMs are built and debug them and so on. But how do we deal with the firmware attacks and the hypervisors? First, a number of interfaces exist that could be used to attack firmware. Variables, SMI handlers, S3 bits, direct spy flash writes and so on. And unfortunately, firmware doesn't know what hypervisor wants to protect. It doesn't know all those pages that the hypervisor is protecting. So the firmware cannot validate that the pointer I just got is really pointing to some obscure hypervisor memory. I cannot validate that. The firmware cannot validate that. So both, firmware, it's, so that just demonstrates the point that it's not just the firmware problem. It is both firmware and hypervisor problem. Both VMM and the firmware have to be designed such that they are aware of each other, of each, you know, its own interfaces and so on. So, you know, sometimes some of those interfaces should not be even exposed. Like for example, Xen doesn't expose directly SMI handlers to even DOM zero, right? So some of those interfaces have to, should not be even exposed. But some interfaces, you know, may need to be trapped and emulated by the hypervisor. So the conclusions, because we have a couple of minutes. First, compromised firmware is definitely bad news for VMM. And that lion and the kitty picture, it pretty much, you know, we now know that the lion is the firmware root kit. It's not the hypervisor. So the firmware needs to be tested for issues. With Windows 10 there is a path to a direct update of the firmware through the Windows update, which will, which should streamline updates of the firmware with vulnerabilities and so on. With fixes for the vulnerabilities. With new vulnerabilities as well, of course. So make sure that your privilege guests are really secure and really hardened. Because privilege guests, as we saw, because of those, you know, exposed interfaces to the firmware, they pretty much control the hypervisor on, you know, majority of the systems. They've, your domes here is pretty much the hypervisor. Root partition is pretty much the hypervisor. Because of those vulnerabilities. So the vulnerabilities in the device and CPU emulation are very common. So we need to pause the interfaces for those. And, you know, we've seen high-profile vulnerabilities recently, like that, and so on. And our team found quite a few of those in the, you know, in the, in the device emulation. So those are pretty common and pretty well understood. But, you know, they need to, you know, the hypervisors needs to be fast for those vulnerabilities. Now the firmware interfaces and features may affect hypervisors if they are exposed to the guests. So both BMMs and firmware need to be designed such that they are aware of each other. And, you know, you, you, you saw Andrew describing SMI handler attacks. The, the demo that we did, it actually compromises SMI handler first. Basically it overwrites SMM firmware and then that malicious payload within the SMM compromises hypervisor. So this is a firmware problem. But, even if the firmware SMI handler validates that the pointer supplied to it doesn't point to its own memory. So you cannot really get SMM code execution through that vulnerability. You can still tell the SMI handler hey here's a pointer points inside a VMM page writes to it something. And it will write on your behalf. So basically you are using firmware as a confused deputy or as a proxy to proxy the attack onto the hypervisor. And it's a big, and it's a, it's, it's a significant point because it, you know, it proves that this is not just the firmware problem. It's also a hypervisor and, you know, both hypervisor and firmware problem. So with that we're basically concluding. There are some references including, you know, details to the white papers explaining all of the technical information about all, you know, vulnerabilities that we've, we've used. And again, I appreciate very much you staying until Sunday and until our talk. Thank you.