So this is agenda we'll talk about- briefly about hypervisors (Inaudible) with protections against malicious software, malicious devices and so on or compromised devices. We'll talk about kind of this nasty thing that we call from (Inaudible) how hypervisors are good at protecting gates from (Inaudible). We'll also talk about how that we could convince (Inaudible) as well as the vulnerabilities that we use to install the firmware, cable ware to compromised hypervisor firmware within the virtual machines and we'll conclude with some of the mitigations available there; the tools that we'll be releasing soon, open source. So with that you know hypervisor based (Inaudible) 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 (Inaudible ) working with some- if we have malicious virtual machine it's infected by malware or compromised by something. Okay so good. If we have some compromised virtual machine by some malicious software or some exploit it's usually protected by hypervisor to (Inaudible) others virtual machines into cloud or some machine and also hypervisor protect from attacks from the malicious hardware. It's mean some (Inaudible) or something like option run something like that so... And usually hypervisor developers not directly thinking about firmware installation and we will show in our presentation how system firmware can effect a lot of different hypervisors. So-- and it's some description of different technologies based on hypervisor installation so usually the memory protects and the hypervisors dispatch access and is related direct hardware access for (Inaudible) audio permissions, bit maps and also memory protected by controllers from hypervisor level and it's software usually it's software based virtualization and also a lot of hypervisors have device level virtualization based on some interruption I think or IMMU for which are protected by G also for G- attacks but- so we will looking how from firmware it's looks indifferent-- different region. So it's a little bit description about how this technology for virtualization works. So usually all configuration about hypervisor, about virtual machine start in VM- control structure and VMCS and it's control all interrupt execution or instruction exceptions and also we have MSR bit maps which is a way to direct access to read write MSR's from guests or (Inaudible) which usually software based virtualization and IO bit maps which controlling direct IO access to the devices and the software is interact and we will show on the next slides how we can apply SMI handlers attack against hypervisors or compromises this protection and we will show how we can compromise (Inaudible) protection by script attack director. It's not new exploit but it's already show on communication in the last year-- in the last year by Corey and Jeff from (Inaudible) So- but we found some interesting way to compromise hypervisors by (Inaudible) it's not showing before just on last like that and system level virtualization is really important and if you control the system firmware you can access to direct to the physical memory and control everything in 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 possibly to attack the mem with some specific root kit. You will continue with root kit.
>> Yeah if I won't trip over this cable. So okay one of the first things before we go in to try to attack hypervisor from within the virtual machines using firmware, why would anyone do that? Again well one of the impacts is will it will slowly creep into the firmware and get persistence get, well what we think or what you might think after the presentation full control over the hypervisors and all the virtual machines but you know before we started that we kind of found that picture and what do you think were the kitties? Who's the kitty and who's the lion? No guess? Okay our guess was the kitty is the root kit and the hypervisor. So those kind of things that monstrous complicity and protecting everything from- including those kind of things like root kits. So let's hear how that goes. So what is firmware root kit? And really kind of a high level picture is just something effecting the system firmware either bios or you apply firmware and as my 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 core boot or some other kind of a software extension of the firmware. So when -- and you can see the error on the left of the slide via the privileges of the exploit compromising each portion on the picture increases with going down the stack and it's pretty kind of a familiarly concept if you compromise something within the VM- you cannot compromise all the VM- short hypervising. If you compromise hypervising you can control the VM- but you cannot really compromise firmware and so on. But if you can compromise firmware you control hypervisor and everything in the software. So that's kind of a neat idea, this slide. However this is not how we've actually implemented that because the root kit here, one of the goals of the root kit is to stop the persistence that no body gets the -- out of the firmware and no body can detect it so we took a different strategy rather than you know root kit compromising hypervisor you know writing as code and so on and say it might be detectable and it's not that kind of a - it's more difficult because we don't know hypervisors, we don't know how to modify them right? So what we did instead assume there's an attacker VM-. They VM- the control 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 overwriting hypervisor or installing your own hypervisor or anything like that we implemented the back door. We did a very small modification to the data structures. No modifications to the code. I'll explain how when modified data structures but kind of the ultimate is ultimately with-- 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 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 in the next slide. So through the 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 backdoor works, 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 a kind of a runtime part of the firmware which periodic with kinds of memory so the root kit scans memory, finds virtual kind of a virtual control blocks or virtual control structures for the virtual machines you know finds the one that belongs to your attacker VM- and then from that point on it finds the kind of the pointer to the hardware system cables that Alex talked about, the base tables that actually translate the guests physical addresses, the host physical addresses and modifies those base tables by just adding a few entries and those entries you can see them out over there. So they basically map out you know-- they map all of the DRM- starting from the arrow to the physical address, starting from 256 gigabytes. So at 256 gigabytes boundary our attacker VM- will have full access to the DRM- to all of the other VMs, to the VMM himself, and everything else and basically that's- 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 the attacker VM- has 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 calls word guard attack is basically when someone sticks something to your laptop when you leave it. Like for example this spy flash firmware and physically overrides the firmware on the spy flash. That's kind of nice but you know you can sometimes see that somebody broke your laptop apart. Sometimes you cannot. But you know the easiest mechanism would be if the firmware is not properly protected-- protecting itself on the spy flash on the RAM then you know booting into a malicious USB and basically running a code that will reflash your firmware that's an easier mechanism. You can use other ways with a physical access to infect the system in fact Tramle and Zena showed yesterday how to use you know the add on adapters to infect the firmware. So there are other mechanisms with the physical but firmware could be installed using software mechanisms right? If for example if the firmware is not added and protecting itself in flash memory you don't need physical at all you have to have kind of an attack, a software attack that can flash whatever it wants on the spyflash memory. It could be done from privileged guests for example ground zero or a root petition because all of them you know provide some direct access to the system firmware. And you know for that you would need either a direct to the privileged guest or you need privileged escalation from a normal guest to the privileged guest. It could from the host OS- and the hosted virtualization scenario you could you know--- one could install a root kit before the hypervisor is there or in parallel with a hypervisor or you know hypothetically could be done from a normal guest if the VMM provides direct access to one of the system firmware cases to the normal guest. Right? 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 explanation part. So we will -- we will use hyper-v. Can you see that? Okay. We will use hyper-v but this root kit is the diagnostic. It won't work against any VMI. 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 it's own firmware so we're just bypassing the firmware protection and installing something on a flash. And this could be done like months before the rebooting the server can be done like I showed with the physical access or with a spot program or something like that. So it was the first part. Now we've rebooted that server. So we have three virtual machines here. Two of these are victim machines. One runs (Inaudible) the other one runs Windows and we have a third machine which is a tagger virtual machine, it runs Windows. So first we will open a virtual machine. It has a patch installed in it and so what we'll do is we'll actually generate a probably private keeper including the public surrogate for patching and that's what I will do in a second and bare with me because I was made to type this whole open in SSL command line you know not from history but like literally type it, three lines. Okay so we're generating X509 certificates and private key; I say private key for our patching. So the private part you can say ours say 2,048 bits. So the private will be dumped into the SSL coil.p file and the public part will get written to an SSL server.Pdm. So we're issuing a certificate. We're requesting to issue a certificate for victim core 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 are used. Now let's restart. So the server is up, it's using those keys and its enabled to the web server. Now I'll just bring the private portion of the R-state key on the display. So this is all that the victim core 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 confidential documents over there on that virtual machine; two confidential documents. One 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 attackers VM running windows. Remember this is to just couple minutes ago that system got root kit installed in the firmware. So root kit is now working, running, doing its thing, opening the backdoor to the attacker VM. So an 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, kind of documents, rtf documents and so on. So give it a minute. It found rtf documents in memory somewhere save it to your file. Found a very safe private key, ssh key, not ours. Some encrypted private keys and so on. It actually finds a whole bunch of stuff not even the ones that we just generated. So the script is done. It dumped the artifacts into folder now let's search for confidential. Files that have confidential. And here we go. So we've found blank document? We've found annual earnings confidential documents that somebody opened in a completely different VM-. [Applause] Thank you. You have to see at least until 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 a private key log. There's quite a few private key blogs extracted from memory and one of them is basically our c-private key. And just to compare those you could compare those offline and the video will be available offline. So those will be two keys. So bottom line we had a completely persistent root kit completely stealthy and no one within the virtual machines including the administrative on the virtual machines is able to find it there. And the root kit is VM- diagnostics so if you install any VM- it will get the same results like even- 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 a second. Yeah okay. So yeah, so we flash the root kit directly into the firmware image from within the position and this is because the system didn't properly protect the firmware. Before the system started protected-- doing those basic protections like when you enable the protection in the firmware or the spyflash. You can tell with that specific module common.Bias. (Inaudible) by the way you have chip sets on all the defcon cds thanks to the defcon team especially for that. So you can you know grab chipsack out of there and tell us if your system is refutable like that but what would the attacker do if the systems didn't properly protect their biases and you applied firmware? We'll we've explained a bunch of vulnerabilities in the previous presentation and recon that could be used for these purposes. So you could install a root kit using either those vulnerabilities as well and we'll discuss two of those but before we'll go to discuss two of those vulnerabilities, so a couple of words about what this root kit could do. In fact, it's you know the root kit has access to, it provides access to the attacker VM- tool to the memory and from that memory that attacker VM- can extract the structure pinch tables or page tables can instruct host page tables for the hypervisor. Guest page tables for each of the guests. It can extract all of the page tables for the units, for all the units for all the hardware. It can extract the memory map including VM- exit handler as well as it can extract full configuration of all the real hardware devices including PCI configurations. So this is one example. So we're basically extracting from just memory. We're extracting all the extended page tables which gives us all the memory map, the translation from the guest physical address 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 you know-- the kind of full version of the slides that are published right now it has a little bit more details including vulnerabilities from within the normal guest and so on. We've got to transition to Andrew, he'll walk you through the text.
>>Okay that's better. So what you can do if you find that spyware is properly protected. So he can try-- there is a small piece of (Inaudible) that handles system management interrupts and so is a micaliber and so that sets the parameters in general purpose registers. They can be-- my handler reads and writes data uses pointers. So-- and if the pointer is not checked it can write or read from the server itself. So I think I can generate a summarized pointer into (Inaudible) so my handler will do write read. So that is privileged so if he or she can intercept from the zero it will go to a semi-handler which will rewrite to hypervisor memory like this. It can modify the codes, data like we mentioned. It can modify page table structures, open a back door or drop a piece of codes to override the spy flash for us. We have a demo. Its a hyper read as well. This we run the exploit from the repetition.
>>Right now the exploit is compromising as my handler promo than the partition.
>> Yup.
>>We'll launch the second part of the exploit...
>> I'm trying to find the compromised structures in hypervised memory. So we'll run the virtual analyzer and we'll find this-- control the three. So you can see it found three virtual machine to 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 remember figures-- IO bit map, it allows a privileged guest to generate-- to access several ports and one of the open port is the port which we can use to generate the system management interrupt as you can see the IO map ports is the VM exit is red. So they exist only to this port. You would code by VMM or the access to other ports will not be seen by VMM. So the three can generate the management interrupt the hypervisor will not see it. So this firmware right, so the problem is that hypervisor doesn't change the point of the supply to-- oh, that doesn't change the point but what is semi-handler is implement correctly and check that the pointer is not in SMM because it can guess. It can -- he has no idea of the virtual-- of the hypervisor memory partition. There's hypervisor memory and there's virtual machine memory so that I can steal supply pointer in physical memory and this memory can be hypervisor memory. And SMI will steal-- will write data to this memory because it's outside of SMM so from the point of view from the handler its a completely legal operation. So this will be the view like this. SMI color view will compromise the hypervisor. SMI writes data or coding VMM and opens a back door.
>> So this is Andrew. So basically that was the -- one of the attacks applicable to hyper-v because of the fact that root partition has access to the whole ports including the SMI port which is V2, so it could trigger vulnerability in the SMI handler and this way you know propagate the attack onto the hypervisor. Next we'll show a completely different issue which was discovered by multiple folks, teams including our team as well as (Inaudible) from Bromium and researchers from Legmacorp. This vulnerability is known as encryptical vulnerability and Treml and Zeno used it in thunder strike two attack as well on maximum yesterday. So we'll use that attack. So the first idea to explain a little bit of the background about what s3 is, you know most of the systems especially they support the sleep state or suspended realm 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. The contents in the memory are preserved when you're resuming the system from sleep and so what happens with the firmware? When firmware normally boots it executes a whole bunch of code if it's a unified specific firmware or base firmware. Then it's executing hundreds of so called firmware 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, these drivers record their actions in addition to now configuring hardware they record their actions into a structure called resumable 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 code, all of those drivers. In fact what it does, it loads a kind of the executable module, the firmware module that interprets the script table which reads those actions that have been previously recorded on a normal and interprets them and this way restores all of the hardware configuration on the system. That saves you a whole bunch of time. Now that is why we can resume like (Inaudible) and so on but a few words about what table is. It's just a sequence of drop codes. Each code can write specific register either PCI configuration or memory map, bio-register or memory location or IO port. So this particular screen shot it shows you that the up code is writing to memory. In fact judging this I'd say that's a kind of a memory mapped IO or memory mapped configuration register but there are other up codes because sometimes you get-- it's not sufficient to just write to the register. Sometimes firmware needs to do a little bit more, you know more complex action and for those who can attach the things there is a dispatch code that basically just invokes our code. So what could go wrong? First of all the vulnerabilities you know described in great details by -- in the white paper we referenced as well in the publications by Corey and Refall. So first how that applies to attacking hypervisors. So we will attack them from ground zero because then does not prevent ground zero access to the previous root table because VMM is not on the crypt table that's a firmware thing right? So the- assume there's an exploit within it. This exploit just goes and modifies the contents of memory. It modifies that previous crypt table, installs additional log codes, modifies existing up codes or something like that and you know then puts system into sleep and when system resumes from sleep, the firmware interprets the completely bogus attacker this crypt table including you know executing your code. This is done with a firmware cryptologist. There are four that the code can modify hypervisor as well. So basically you got them compromised here. So I'll show you the demo on exploiting them from ground zero using this vulnerability. You can see we're in ground zero using them. And we're going to guest, to virtual machine. So I'm launching a command that just you know searches memory for hypervisor structures. Structures, you saw the NCS, 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 as a guest have access to those critical structures including privileged guests like ground zero root petition. They cannot. So to kind of a solve that problem we're launching an exploit. We're launching an exploit by modifying the previous script table in memory which we have access to. We installed some up codes into that previous 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 looks for those critical structures of the hypervisor; the NCS structures and the page tables. And we found one. So basically we have full access to the structures controlling virtual machine for that guest. So okay that does look a little bit familiar for those of you who followed ITL- research a few years ago. They did explain that hey it's possible to pull the hypervisor through the bios right? Or through the MVR and pretty much those attacks give up to the point that yes you can compromise hypervisors completely using those vulnerabilities in the bios or in the firmware. But those vulnerabilities were from privileged guests like root partition and (Inaudible) which sort of limits the impacts in the minds of a lot of people and minus the privilege escalations from the normal guest to the privileged guest or directly exploiting into the root partition. So what about -- it keeps us that strictly want to separate guests from root partition and we heard a presentation by folks from Microsoft on the new virtualization security based model and the system which is basically that model. So right now we are working with Microsoft to make sure that those are not applicable to the Windows 10. So tools and mitigations that we have. First of all the first things first-- if you have vulnerabilities in the firmware you are in trouble. You can have thunder strike, you can have completely persistent stuff and it can compromise, it can attack full encryption based CPM. It can attack seeker boot. As we saw you can completely control the hypervisors and every secret. So we need to fix those vulnerabilities of course and there are tests in the open source. It can run and test for both issues we've explained. If your systems are vulnerable as well as you can test if the firmware is what protected on the spy flash but you can-- we will also need to test hypervisors and especially all of those hardware and firmware pieces that the hypervisor is exposed to the VMs. We'll be releasing the open source modules to the chipset that pretty much tells every hardware interface, I'm sorry emulation, I'm poor at emulation CPID emulation, MMOI emulation, and so on as well as we'll provide, we'll release some of the additional functionality that just allows you to see how VMMs are built and debugged and so on. So-- but how do we deal with you know the firmware attacks and the hypervisors? First a number of interfaces exist that could be used to attack firmware. Variable my handler says direct the spyflash raids and so on. 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 you know 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-- so that just you know 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 which-- on a (Inaudible) and so on. So you know sometimes some of those are phases should not even be exposed like for example Zem doesn't expose directly SMI handlers to even ground zero. So some of those interfaces 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 pretty much you -- 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 should streamline updates of the firmware with vulnerabilities with fixes for vulnerabilities. With new vulnerabilities as well of course. So make sure that your privileged guests are really secure and really hardened because privileges guests as we saw because of the exposed interfaces to the firmware they pretty much control the hypervisor on you know the majority of the systems. It's pretty much the hypervisor-- the root partition is pretty much the hypervisor because of those vulnerabilities. So the vulnerabilities in the device and CPM emulation are very common so we need to pause the interfaces for those and you know we've seen high profile vulnerabilities recently like earlier and our team found quite a few of those in the device emulation. So those are pretty common and pretty well understood but you know they -- the hypervisors need to be false for those vulnerabilities. Now the firmware interface may effect hypervisors if they are exposed to the guests. So both VMMs and firmware need to be designed such that they are aware of each other and you know you saw Andrew describing SMI handler attacks. The demo that we did it actually compromises SMI handler first. Basically it writes SMM firmware and then that malicious within the SMS compromises hypervisor. So this is a firmware problem but even if the firmware SMI handler validates that the pointer supplied to it doesn't apply to it's own memory, so you cannot really get SMI code execution through that vulnerability you can still tell the SMI handler, hey there's a pointer, it points inside a VMM page, writes to it something and it will write on your behalf. So basically you are using firmware as the computers deputy where as the proxy, you proxy the attack onto the hypervisor and it's a significant point because it proves that this is not just a firmware problem. It's also a hypervisor and both you know hypervisor and firmware problem. So with that we're basically concluding there are some references including details to white papers explaining all the technical information and the vulnerabilities that we've used and again I appreciate very much you staying until Sunday and until our talk. Thank you. [Applause]