Get Off the Kernel if You Can't Drive
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Michael, Jesse
Shkatov, Mickey
For software to communicate with hardware, it needs to talk to a kernel-mode driver that serves as a middle-man between the two, helping to make sure everything operates as it should. In Windows that is done using the Kernel-Mode Driver Framework (KMDF). These drivers are used to control everything in your computer, from small things like CPU fan speed, color of your motherboard LED lights, up to flashing a new BIOS. However, as the code in these drivers runs with the same privileges as the rest of the kernel, malicious drivers can be used to compromise the security of the platform. To that end, Microsoft relies on WHQL, code signing, and EV Signing to prevent drivers which have not been approved by Microsoft from being loaded into the kernel. Unfortunately, security vulnerabilities in signed drivers can be used to as a proxy to read and write hardware resources such as kernel memory, internal CPU configuration registers, PCI devices, and more. These helpful driver capabilities can even be misused to bypass and disable Windows protection mechanisms. Let us teach you how these drivers work, show you the unbelievable risk they pose, and enjoy our walk of shame as we parade all the silly and irresponsible things we discovered in our research. Jesse Michael Jesse Michael is an experienced security researcher focused on vulnerability detection and mitigation who has worked at all layers of modern computing environments from exploiting worldwide corporate network infrastructure down to hunting vulnerabilities inside processors at the hardware design level. His primary areas of expertise include reverse engineering embedded firmware and exploit development. He has also presented research at DEF CON, Black Hat, PacSec, Hackito Ergo Sum, Ekoparty, and BSides Portland. Mickey Shkatov Mickey Shkatov, a principal researcher at Eclypsium, has been performing security research and product security validation since 2010, He has also presented multiple times at DEF CON, Black Hat, PacSec, CanSecWest, BruCon, Hackito Ergo Sum, and BSides Portland.
 So I am Mickey, that's Jesse, um that's our Twitter handles. If you want to ask us questions about anything we give at the stock just feel free to reach out and ask us even next week or whatever, we're happy to help. About the agenda of the stock, well we're going to start with a little bit of high level introduction into what is a driver in Windows. We're going to keep it high level and then we're going to go get more and more technical as we go along. Part of the things we're going to discuss is what the problem is, uh give you some funny examples of it, the tools that you need to explore for yourselves and a couple of funny stories about disclosures. This topic is not new so bad drivers have been known to be found in um the past decade. They pop up one here, one there, three here and you get a little blood post and description and excuse me how to use them and it just goes away after a while. The vendor patches it and fixes it or not and it stays there and then just continues on. So here are some of the examples we use in our talk and based on um some of our code on so we thought it would be best to give credit. Um more information can be found in these links. We'll have the slides available on the GitHub uh soon after the talk or next early next week and we'll explain for that later. Um let's start with the biggest uh the smallest uh the simplest explanation. I'm sorry English is not my first language. Um why are we talking about Windows and not Linux or or Apple? Uh Linux drivers are basically all in the tree so except for specific examples that are proprietary code, most of the Linux drivers are available in GitHub or open source and you can find them and look at them. Apple is a closed garden so whatever Apple does Apple knows and Apple sees so we don't really care. There is a caveat um Apple does have uh their Windows drivers for their hardware. We did skim those but we didn't find anything substantial there. What is a driver and how it's used? So basically in in in the in the computer and operating system you have a user space, you have kernel space and then you have the hardware. For applications in user space to talk to the hardware you're gonna need some sort of way to do this securely. Otherwise you violate every known concept of a security boundary ever. You don't want a bring three or user space application to be able to read and write spy flash. It's just wrong. So we have this concept called drivers. These drivers are running within kernel space. They communicate with the kernel. The kernel gets requests from the application, passes it on to the driver, the driver does its magic, communicates with the hardware and goes back and forth. It's pretty straightforward. These drivers in Windows are signed. Now um for a driver to run and be executing kernel space in these days it needs to be signed and uh it needs to be certified by Microsoft. We're not going to go into the entire process of how drivers are certified by Windows. It's not it's not easy to explain. There's a back and forth. I know some of you are are spurking right now. Yeah, because you probably try to sign drivers with Windows. There is a reason for that process. Um but it's it's not quite straightforward to get out from reading blog posts on the internet. Um the point that the key point in this slide is Windows 10 signing process right. So Microsoft introduced this new process called EV. EV stands for extended validation. Um if you want to EV sign a certificate uh uh driver you need to have this EV certificate which um allows basically Microsoft to co-sign the driver with you and give that Wickel certification side by side so you have a driver that's certified by Microsoft and operates and everything's great. Um EV these are slides we found from Microsoft presentation given in Shanghai 2015 uh when they introduced this. Uh funny funny thing about this is that the the bad guys the bad guys reference here and that EV certificates are better because it means less malware but not for legacy. So if you have an old driver that's already signed do whatever you want with it. Ever Microsoft is a good guy that will let you load the driver even if the certificate's expired. Um we do have one of these drivers that for some reason loaded and we kept double checking the properties and it's just expired the certificate what the hell's going on so we're in sign tool. Sign tool said it's uh it's not within the required period of verifying. No idea why it loaded it's still loaded I don't complain. So at this point we were like maybe we'll get our own EV certificate we'll try to make our own example driver and you know have some fun with it. We saw this list of things to do of getting it and you know you have to have the legal agreements to sign in behalf of your organization. I don't think so. It's just too much of a hassle. We work for a company that company has their own driver they develop they sign it with Microsoft. I don't want to risk anything potentially with Microsoft so highest of notes. So uh let's take a look at some of the uh the issues that we've seen in the past with sign drivers and uh one example that we uh that a lot of people know about is uh read write everything and uh there's also uh Lojax is one of the more interesting uh malware that we saw that was using sign drivers. Slingshot was another APT that was using uh this class of driver specifically to bypass Windows protections. Uh we've also seen this type of uh driver being used by game cheating engines or uh anti-cheat software. Uh there was an interesting case uh CAPCOM driver where this driver was signed by CAPCOM for a video game that it would turn off uh SMEP protection, execute code that you pass in from user space and then uh continue on and that was found pretty quickly and people were able to uh know to block that but the these issues keep popping up individually so we were trying wanted to look uh across the spectrum a little bit more. There's some uh nice examples right up so if there's a vulnerability in a MSI driver and here's how to use it to escalate from uh user space non-elevated to uh NT authority system by using one of these sign drivers. So to take a little bit of a closer look uh read write everything it's essentially it was designed to give you the ability to look at these hardware interfaces in your system basically explore the system see what the state of the machine is and it basically has a user space app and then a signed driver which is intended for this purpose but uh the problem is that it it allows access to components that have really important security properties and they need confidentiality in some of these uh resources and uh integrity in other resources so you're basically given free reign to arbitrarily read write modify some of the device some of the interfaces that Windows depends on Windows security depends on these not being tampered with so this this was an interesting app um but then uh Lojax was a malware that was found in the wild it was an APT that they actually brought a copy of that ring write write anywhere driver along with them as part of their infection uh their implant tool used read write everything in order to uh gain direct access to the spy controller and then they were able to use that in order to write their own malicious module into the into the system flash and uh persist in that UEFI firmware that would uh survive reboots operating system reinstalls because they have the ability to directly talk to the hardware through this mechanism and even if your system did not have this read write everything driver on it they just brought it with them they were able to load it and use that capability in a really interesting uh attack uh there was another APT command uh campaign that also basically it also brought their own driver their driver was not signed but they exploited uh four different drivers that had uh read write MSR capability in order to get arbitrary code execution in the kernel and bypass driver signing enforcement so they could install their own uh kernel root kit so this is out there actually being used in the wild by real attackers so there's a few different reasons why you might want to use one of these drivers basic one is just privilege escalation from user space get either escalate a user from a normal unelevated user to admin user there's also just getting code execution running within uh within the kernel itself uh another uh possibility is you can use some of these uh drivers to disable bypass uh window security mechanisms and sometimes that can be used in order to uh escalate privilege within the kernel or just get access to resources that you shouldn't get access to uh there's another uh motivation where essentially getting access to the hardware itself is is really useful you can modify system firmware you can modify device firmware there are a lot of devices that still have unsigned firmware and you can go basically write your malicious modification to either the system firmware get code execution before the operating system loads or modify a device and uh have a persistent implant in a particular device and there's some other things you can do with direct hardware access but those are some key ones that we wanted to specifically call out so there's a few different uh attack scenarios uh if the driver is already on the system and loaded the driver itself controls the policy for who can talk to this device so many drivers you don't have to be admin you can be a normal non-elevated user in order to talk to this particular device there's another scenario where the the driver is on the system but it's not loaded yet and in that case you do need admin privileges to load the driver uh we have found signed applications that you can use to load drivers uh that are signed by well-known trusted vendors that you could potentially use one of these applications there'd be a little uac pop up that says would you like some trusted vendor to modify your computer and that might be a good thing to uh load the driver if you don't have uh admin privileges but you can also just wait so the if you if it's already loaded you don't need to be admin if it's not yet loaded you do need admin essentially and there's also the scenario where the driver isn't on the system all of your all of your drivers are fully up to date uh malware can bring a driver with it and load that in this case they do you do need to have escalated to uh an admin in order to load the driver but there have been a lot of pre-legislations uh you can bring an older version of the driver so uh even if the newest version has been fixed in many cases the old vulnerable driver will still be loaded into windows or loadable into windows and you can just bring the old version load that and use this kind of capability and lowjax did this for their in the wild APD campaign where they brought an older driver they were able to load it and get direct set direct access hardware and implant the UEFI firmware so we've we've seen this pop up every now and then just one at a time there isn't really uh industry wide fix for this problem or industry wide effort to go fix this so we wanted to uh take a look and see see how hard it is to find these drivers and how widespread it is so we uh focused on because we're interested in signed drivers so that we're loaded into windows we we threw out any that we found that weren't signed because we're looking for drivers that talk to hardware interfaces or have that kind of capability we look for drivers specifically from uh firmware and hardware vendors and then just to make it a little easier we uh went with the smaller drivers that would probably be more uh simple so also looking for things like uh read write MSR opcode uh move to control register in and out opcodes those are specific x86 instructions that are uh talking to drivers or talking to devices or hardware in a way that we're interested in uh one other thing to keep in mind is that uh there's two different uh driver there's two different mechanisms or frameworks that you could write your driver there's the uh older uh windows driver model and uh the the newer windows driver framework uh with the uh the older version you basically your driver would just call IO create device and then write a address of a handler for uh all of the requests that uh user space is going to make to your driver to a specific address within uh a structure that it passes to this IO create device uh function uh the windows driver framework has changed a little bit but it's a a similar kind of concept where you uh you have a couple functions that are set up and uh eventually you do have a a main dispatch or uh i octal handling function that will handle all of the requests from user space uh uh uh I I don't know if we mentioned it but uh I octal is basically IO control so there's a specific number that you could say I want I octal 1 2 3 4 and uh the the dispatch will call your your kernel handler and say here's your IO request packet with request 1 2 3 4 and the data that was passed from uh user space um so there is a a little bit of a difference where uh in IO create device versus this uh create device secure function if you if the driver is calling a create device secure it can actually specify a uh a security descriptor which is a a policy that says who can talk to this driver and what type of access they have uh this is a an example of one of these uh uh SDDL strings uh in this case it's a discretionary access control list that allows generic all to local system and generic all to built in administrators most of the drivers that we looked at don't bother to set any kind of policy so a normal elevate a normal non elevated user can talk to these drivers so we essentially spent two weeks looking for drivers we uh skim through hundreds of of uh driver files just doing uh manual disassembly analysis looking for this type of uh behavior uh we found 42 uh different vulnerable signed drivers uh we found 42 vulnerable signed x8664 drivers uh we did find uh a lot that had a 32 bit version so it was around uh 80 something total files but we did find one itanium driver that I don't know if anybody still has an itanium machine out there but uh we've we've also found more drivers since but there were uh 42 drivers 42 x8664 drivers that we were looking at but uh the types of things that we found were things like basically you could ask from user space for the kernel to go read and write virtual memory in the kernel or to read and write to uh physical memory addresses uh you could go talk to uh MIO devices uh model specific register, arbitrary read write, uh control register access, talking to PCI devices, some SM bus access, just basic uh in and out so uh here's an example of uh uh mem copy that we found in the kernel where they literally are taking the the source destination and size for this copy operation from user space there's no checks of any any uh pointers uh no pointer checks, no length checks, no length checks, you can literally just ask the driver to go copy memory around for you. Um this this can be used to mod to modify uh kernel code and data structures um patch guard will detect some modifications it doesn't detect them all though so it's if you have a primitive that's this flexible you can do a lot of interesting things with it. You can copy from user space into kernel memory the other way around it's it's really useful. Uh another thing that we found is just basic arbitrary physical memory write uh read and write uh in in this it's intended so that you can use it to go talk to device drivers and do MMO access uh in this case there's also no uh sanity checks you could basically have any any address any size and go try to call this function uh MMMM map IO space um there has been a change in how windows deals with this function as of uh uh 1803 where they've tried to limit the scope of what you can do with this physical memory write only to those uh MMMM IO addresses so uh older systems before 1803 you could just map map any kernel address and do read and write there also um but even after 1803 you can still go uh get direct access to the hardware and do some pretty interesting things there. Uh there there's also drivers that just expose the the physical to virtual mapping so you can look up addresses in virtual space and find their corresponding page in uh the physical address layout which is is it's useful for for dealing with actles that give that kind of uh physical address but it's also useful for uh things like row hammer where it's like knowing where things are mapped physically into into the address space this type of functionality can be really useful. So another thing that we uh looked at was just arbitrary uh model specific register uh read and write uh here's an example where they're taking the address of the model specific register to read no filtering directly give you the data back. So if you're not familiar with model specific registers uh these are uh internal registers within the the CPU that like you have your general purpose registers for normal executing code but these special purpose model specific registers are uh in addition to that and they were originally used for experimental features that Intel wanted to try out and some of those uh experimental features they decided these are really useful so we're going to turn them into architectural uh model specific registers or MSRs such that from a certain point going forward they're committing to support this particular usage model for the the value that you put into into the MSR will be used in a architecturally defined way and uh they do have uh special op codes special X86 op codes uh read MSR and write MSR in order to uh access these uh registers. Uh one interesting point is that you can only access them from ring zero so ring three if you try to read a MSR uh you'll get a uh fault and it won't allow you to uh get that data but we we have a primitive here where you can read MSRs and there's some pretty useful things that you can get just by reading the MSR uh we also found uh model specific write primitives and there are some really really critical model specific uh registers that uh are especially interesting like uh star C star L star and C star where in order to even transition from user space into kernel space or ring three into ring zero when you call a when you execute a sys call instruction it will as part of that transition going from use from ring three into ring zero it will take the address that's stored in this L star register and use that as the address that it starts re executing in ring zero so if you if you have the ability to write to this register from user space that's pretty dangerous. So there's also uh control registers and there's a lot less control registers but they store some key uh control bits for the processor um CR three is the base of the virtual memory uh paging tables so knowing where that is could potentially be useful uh CR four has uh uh some other security controls CR zero has some security controls so in this case we have a arbitrary ability to read any of these control registers uh including the base of the page table structure in kernel space not the user space copy of the page tables and there's also a control register write uh functions where you could take an arbitrary value and arbitrary control register that's taken directly from your user space uh input buffer and write the value to the control register and some pretty uh key ones that are that some of the security controls in Windows depend on is uh supervisor mode execution protection that basically is uh one of the features that helps protect against a number of different attacks that have been very successful against Windows in the past uh there's also this uh write protect bit in CR zero where if if the write protect bit is not set in CR zero and uh the the kernel or ring zero code tries to write to a page that is marked as read only it will completely ignore the permissions in the page table and let you do the right anyway so it's a it's an interesting control so it's kind of per security hardening but it's useful to know about if we can write to that that can help us other things are just arbitrary uh IO port right you can write arbitrary values arbitrary IO ports it's what you can do with that is platform dependent you could possibly use that to modify system and device firmware uh we we saw a really cool uh vulnerability last year involving a speed BMC configuration where there were debug features that were accessible from the host and you could through IO reads and writes arbitrarily read and write into the BMC address space uh laptops have look likely have an embedded controller that you can talk to over IO access and then there's also legacy PCI access over IO port CF8 CF8 CFC there's also just functions to literally do that legacy PCI right so there have been issues with uh security of PCI devices and that comes up a lot so to kind of look at the MSR case a little bit more essentially the LS L star MSR is pointing to an address into kernel memory where we don't know exactly where the kernel has been loaded there's address randomization is happening so when when this transition happens when you go from user space to kernel space it starts executing at the at the address that L star points to so if you can write to L star we can basically allocate a buffer in user memory and then when that transition happens the very next next call that happens it'll start executing from your pointer instead but there's some complications to that so one of the features that I mentioned uh supervisor mode execution prevention is intended to uh stop this feature there have been a lot of bugs where you could get the kernel to uh jump to your your pointer and they added this feature to the CPU uh I think in uh Sandy bridge where maybe IV bridge but it's essentially a feature where if the CPU is executing in uh in a ring zero and it does a code fetch to a page that's in a user user mapping it'll cause a fault and this is controlled by a bit in the CR4 register so if we have a read write primitive for uh control registers we can just read this bit from or we can read the CR4 value clear the bit and write it back to CR4 and in order to uh get around supervisor mode execution prevention um there's another uh complication that uh uh there needs to be a little bit of state change when you're transitioning into the kernel space so although it starts executing in ring zero it hasn't fully switched into kernel space so you need to do a little bit of extra work entering and executing your your payload there and then there's also uh uh kernel page table isolation so as part of the meltdown mitigation for uh one of the Intel uh CPU issues uh they basically isolated the kernel pages so they have two different sets of pages one for user space and one for kernel space so uh we do need to know the address for those kernel page tables in order to fully be able to switch into kernel space uh but if we have an I octal that we can arbitrarily read CR3 then we can then we can get the address of that kernel uh page table base so that when we build our payload we could just swap in the kernel page table pointer and do what we want to do so we have a couple little demos of uh switching uh of uh some of these uh features. Quick note all these demos are in PowerShell. So we have a basic uh uh so this this one is not PowerShell but this this is just a simple uh yeah. So we in order to in order to do our research we basically uh made a simple tool to uh load any arbitrary driver for us so instead of needing to uh instead of needing to write a helper to load it and deal with it we can use a simple tool to uh load any arbitrary driver for us so instead of needing to uh instead of needing to write a helper to load it and deal with it it's just a simple tool to load a driver, create the service, start the service for us so we could try things out. So in order to do this we were running as administrator um the other demo that I'm about to show uh is not running as administrator. Uh yeah. So in in in this case we basically are reading some uh state from basically uh the the kernel is being loaded at a random address so from user space not elevated at all we can uh read the uh the address of that uh entry point into the kernel and uh uh understand where the kernel is loaded so this can help us with uh with further attacks that depend on where where the kernel is loaded into uh into the address space. We also know the the base of the the page tables is this uh second value so when we're building a payload we can use this this value to uh make that easier. Uh yeah. So there's also uh the SMEP bit in uh in CR4 where we can also like in this case we we read CR4 we saw that it was enabled. We cleared the value, we wrote it back, we see that it's still it's it's disabled now uh and there there is a uh a feature in windows called uh patch guard that will go and look for uh configuration of the system look for dangerous things and uh we found a write up that meant that said that they were able to measure that they were reading these MSRs every 30 minutes so that's a lot of time to uh get your malicious code to uh run and so we we were testing it didn't crash even after like 45 seconds. We did see some cases where it would crash after you wrote to the MSR but it's uh it seems like plenty of time in order to uh get your your payload working if you want to use this for. And if you can calculate it's a lot of time. What's that? Uh it's uh 1903. Oh yeah. And this is on a uh 1903 system so it's latest has the latest version of uh of uh patch guard. Okay. So some of the problems is like we we took all of these drivers we uploaded them to virus total none of the drivers came back as malicious they're loaded by windows but AV isn't really helping us with this issue because you can you can use a lot of these drivers to attack AV and bypass some of those. Some of the those uh protections. So we're we're hoping that we could actually fix this. So Microsoft does have a virtualization based security and uh hypervisor enforced code integrity. Um those uh those are only present from uh 7th generation CPU and newer. Uh also there are compatibility issues that prevent you from turning this on and HVCI will help against some of these issues but uh not all. And I have a a Kaby Lake laptop that is pretty new and should support it but I have compatibility issues and I haven't been able to actually turn on this feature. Um there there's also some uh enterprise uh device guard policy that you can configure to block known drivers once they're known to be vulnerable but there hasn't been any really industry wide fix for this yet. So we're hoping to uh fix that. So all of these all of these drivers that we found originally were just through manual analysis so we were looking how can we actually automate this and started looking at the uh anger framework for uh symbolic execution. And if you're not familiar with anger or symbolic execution uh it essentially allows you to dynamically execute the parts of a program and every time you get to a conditional branch it will try to execute both paths and see what happens. So it's really useful but it's easy to uh run into issues but. So I got an initial script just to try out the idea working in about a day and it works really well in some cases. In other cases the code is complex enough that you run out of memory and you have a a state explosion because there are so many conditional branches that it had issues but for for what that actually looked like for trying it out we uh we had a specific driver that we know is vulnerable and we know the the address of the handler that that main actual dispatch is at a particular address and we know the address of a right MSR opcode that we want to uh search for and see if this is actually taking data that's passed from from user space. So essentially you just need to load the driver into anger in this case we don't care about uh libraries so we'll not load libraries and then uh create a uh an anger uh execution state object that uh starts execution at the I octahandler the dispatch function and we can take that uh uh I-O request packet that structure and uh basically create symbolic regions for those parts and set pointers so that when we're starting execution at the uh I octahandler it will have these uh these uh symbolic regions as the the input data that we're passing into this function. Then you can uh create a sim- simulation manager and just let it start executing code from the uh from the uh I octahandler point with a target address of the uh right MSR address so we're trying to reach that address. If it's found we just print that we've we've print that a path was found and whether the uh the input data to this right MSR is taken from the input buffer if it's symbolic data and it it worked it completed in less than five seconds and we proved that when we reach this uh MSR at right MSR opcode uh that the address and uh data that will be written to the the CPU register is uh included in the input buffer it even tells you the specific dword offset into the input buffer for where you need to structure your your data to to talk to this driver and it it completed in uh five seconds literally the the last three slides that I showed you that's the entire script to uh to do this improve that that this is actually taking input from the user. Uh another issue is that we want to automatically find that I octahandler ourselves so we don't have to manually open every driver do some disassembly find that prime that initial dispatch function so for a WDM Windows driver model uh drivers it's a lot easier we can easily just set a a memory right breakpoint on that structure structure element in the driver object and uh this this script right here that's all you need to find the I octahandler for these WDM drivers. We can also uh automatically find the I octal number so you have a driver there's a right MSR it'll tell you that there's a right control register or an MSR it'll tell you the number you need to pass for the I octal it can tell you what values you also need to put into the into the input buffer so in this case uh this list of constraints down at the bottom were automatically detected and uh anger can actually simplify those for you so these three constraints at the bottom basically are simplified to the value at the first D word in uh the input buffer needs to be four and then the second uh there are the the third and fourth D words are the value that's written to this uh CR4 register so we can actually find a lot of information automatically um there are some problems with with this uh anger is based on a VEX which was part of Valgrind so it was all user space applications and as far as we can tell it was never used to analyze privilege code because it literally has decode errors when it runs into some of these privilege opcode so the the decompiler and instruction lifter it so it lifts into an immediate intermediate representation and that part of the code it runs into decode error and it doesn't know what to do so there is some functionality that was added in the Python framework on top of that where you can write a Python module to kind of emulate or implement what this opcode should have done so we were we were able to take advantage of that and have it work more reliably on on more uh on more uh drivers so one other problem is that it currently only supports at least the tool that we wrote only supports uh WDM drivers we do detect if it's a WDF driver and have some ideas on how to make it work with uh WDF drivers also it's just a little bit more in direction and hooking but it should be fairly straightforward um and then there's the issue that some drivers are a little bit more complex and cause it to run out of memory I've had it run out of 64 gigs around so we uh we we need to fix a few things so I'll let let Mickey do it. So um now for a little bit of uh naming, shaming and faming uh we talked about 20 total vendors these are the ones that we can uh disclose right now some are not um ready to release updates some did not respond some said acknowledged but we haven't heard back from um and some are really working on a fix but because they're in regulated environments they require more time to go through certification so we're not gonna disclose them we're gonna go through um everything we've been through talking to these to these guys and and these uh companies since uh late April early May uh we're gonna start from the best example to the worst um the best example we had is with Phoenix Phoenix is one of the big three IBVs I have never heard or experienced a better response than Phoenix we we started with with the first disclosure batch to send out to vendors um I think Monday that week and we said yeah we'll finish it up we'll send it on Tuesday obviously it ended up Friday 5 p.m. and we sent it out to emails and we went home Saturday morning we got an email back saying we acknowledged the issue we're working on a fix within six weeks they already had a fix ready to deploy to customers this is textbook like I've never ever experienced anything like this especially with a driver uh we also sent an email to cert and uh cert cc we for some reason it got lost in communication with us cert uh I didn't up calling them a couple days ago and they did receive it so I don't know what's going on from that perspective we did get a receipt but um no actions were were prescribed for us from from certs Microsoft uh now that's a story so Microsoft's model of of the operating system is basically give third parties the option to write their driver right it's like I have a company I have a product here write code to interface with our product um the problem with this class of issues is a lot of drivers fall into that caveat where some someone might write bad code so what can Microsoft do about it they can't just say hey okay people uh write some code but don't make it bad it's a bit problematic so we had a an initial discussion with them and and send them a note say hey what's your what's your view about this and we got a response from MSRC tier one that said not a problem uh talk to you later we sent another email later on asking if they're really sure it was a back and forth and the end of the day after uh quite a few rants on twitter we ended up getting to communicate and ended up doing a couple of face to faces here in Vegas uh it changed the complex the entire conversation uh I'd like to say thank you to Krista Anderson and Nate Warfield for being very good at communicating and forthcoming and trying to help also to Kimberly Marissa Mary Eustace and Gaurav I hope I'm not butchering that name for helping from MSRC site to clear everything up and and um help sort things out. Now the worst driver award goes to as rock um because this is one of four I think one of four signed drivers that does all of this so it's quite impressive the you try to award goes to Nvidia for telling us that the driver that we found is internal so it doesn't merit a CVE because it's it requires a security hardening effort internally although it is distributed by MSI on their website as a tool for updates for their graphics cards so it's internal tool but it's distributed by an OEM on the internet. Okay the worst ones are these four that did not respond so out of these four there is one um that completely doesn't respond so at least some of them sometimes respond but real tech I've had um researchers during this time in Vegas we talk to each other and we we share notes and we discuss uh you know experiences like oh this vendor sucks this vendor is great and no one in real tech is answering any emails so if anyone from real tech sees this please check your inbox and reply to something. Um a few advisories are coming out so Phoenix did June 21st within amazingly quickly time uh already sent to OEMs so uh the fixes that Phoenix inside an AMI will release the three big BIOS vendors are gonna go get distributed to OEMs and um OEMs will then distribute it to customers uh Intel had a fix in July 9th Huawei in July 10th uh let's see inside is today it's the next slide and a couple more coming out next week we can't talk about it and a few more during the until the end of the year um inside was kind of enough to send us this uh statement I'm not gonna go through it but the gist is they're fixing it Microsoft send us this statement I'm not gonna go through this because we've been through enough uh and now I'm going to the conclusion so basically bad drivers are bad um people that write ring zero code and write it badly are a danger to society um these some of these drivers like the easiest way to fix this is okay I'm a vendor I wrote a driver I own up to it I revoked the certificate done can't load it anymore in Windows 10 at least um so getting vendors to to remove to revoke the certificates is is not as easy as sometimes like we had with Phoenix but um it will be a great help to do this like the biggest majority of the the majority of drivers that we've seen are old they're not new brand new 2018 2017 some of these go back to 2008 so just revoke the certificates this is like a big problem it's not just specifically it's just a class again um multiple researchers have disclosed these drivers separately at a time but the problem is systemic and we want to we want to hope that we're hoping that at some point this can be fixed in a larger scale Windows 10 is is moving towards this there's mitigations in place there's HVCI um virtual based security but you know you have to have a 7th gen CPU and above for HVCI to work and even then not always does it work um we are going to release all all our code C sharp C plus plus and PowerShell examples on GitHub with the latest slides and the videos and um our tracking for all the drivers and where you can find them please check this GitHub on August 13th um we did have this internal debate of whether to release it today or in three days but because it was so close we just decided to sort everything out get through Vegas and up loaded on the 13th and I think we're done.
 So I am Mickey, that's Jesse, um that's our Twitter handles. If you want to ask us questions  about anything we give at the stock just feel free to reach out and ask us even next week or  whatever, we're happy to help. About the agenda of the stock, well we're going to start with a  little bit of high level introduction into what is a driver in Windows. We're going to keep it  high level and then we're going to go get more and more technical as we go along. Part of the  things we're going to discuss is what the problem is, uh give you some funny examples of it, the  tools that you need to explore for yourselves and a couple of funny stories about  disclosures. This topic is not new so bad drivers have been known to be found in um the past decade.  They pop up one here, one there, three here and you get a little blood post and description and  excuse me how to use them and it just goes away after a while. The vendor patches it and  fixes it or not and it stays there and then just continues on. So here are some of the examples  we use in our talk and based on um some of our code on so we thought it would be best to give  credit. Um more information can be found in these links. We'll have the slides available on the  GitHub uh soon after the talk or next early next week and we'll explain for that later. Um  let's start with the biggest uh the smallest uh the simplest explanation. I'm sorry English is not  my first language. Um why are we talking about Windows and not Linux or or Apple? Uh Linux  drivers are basically all in the tree so except for specific examples that are proprietary code,  most of the Linux drivers are available in GitHub or open source and you can find them and  look at them. Apple is a closed garden so whatever Apple does Apple knows and Apple sees so we  don't really care. There is a caveat um Apple does have uh their Windows drivers for their  hardware. We did skim those but we didn't find anything substantial there. What is a driver and  how it's used? So basically in in in the in the computer and operating system you have a  user space, you have kernel space and then you have the hardware. For applications in user  space to talk to the hardware you're gonna need some sort of way to do this securely. Otherwise  you violate every known concept of a security boundary ever. You don't want a bring three or  user space application to be able to read and write spy flash. It's just wrong. So we have  this concept called drivers. These drivers are running within kernel space. They communicate  with the kernel. The kernel gets requests from the application, passes it on to the driver, the  driver does its magic, communicates with the hardware and goes back and forth. It's pretty  straightforward. These drivers in Windows are signed. Now um for a driver to run and be  executing kernel space in these days it needs to be signed and uh it needs to be certified by  Microsoft. We're not going to go into the entire process of how drivers are certified by  Windows. It's not it's not easy to explain. There's a back and forth. I know some of you are  are spurking right now. Yeah, because you probably try to sign drivers with Windows. There is a  reason for that process. Um but it's it's not quite straightforward to get out from reading  blog posts on the internet. Um the point that the key point in this slide is Windows 10  signing process right. So Microsoft introduced this new process called EV. EV stands for  extended validation. Um if you want to EV sign a certificate uh uh driver you need to have this  EV certificate which um allows basically Microsoft to co-sign the driver with you and give  that Wickel certification side by side so you have a driver that's certified by Microsoft and  operates and everything's great. Um EV these are slides we found from Microsoft presentation  given in Shanghai 2015 uh when they introduced this. Uh funny funny thing about this is that the the bad  guys the bad guys reference here and that EV certificates are better because it means less  malware but not for legacy. So if you have an old driver that's already signed do whatever you  want with it. Ever Microsoft is a good guy that will let you load the driver even if the  certificate's expired. Um we do have one of these drivers that for some reason loaded and we  kept double checking the properties and it's just expired the certificate what the hell's  going on so we're in sign tool. Sign tool said it's uh it's not within the required period of  verifying. No idea why it loaded it's still loaded I don't complain. So at this point we were  like maybe we'll get our own EV certificate we'll try to make our own example driver and you  know have some fun with it. We saw this list of things to do of getting it and you know you have  to have the legal agreements to sign in behalf of your organization. I don't think so. It's just  too much of a hassle. We work for a company that company has their own driver they develop they  sign it with Microsoft. I don't want to risk anything potentially with Microsoft so highest of  notes. So uh let's take a look at some of the uh the issues that we've seen in the past with  sign drivers and uh one example that we uh that a lot of people know about is uh read write  everything and uh there's also uh Lojax is one of the more interesting uh malware that we saw  that was using sign drivers. Slingshot was another APT that was using uh this class of driver  specifically to bypass Windows protections. Uh we've also seen this type of uh driver being used  by game cheating engines or uh anti-cheat software. Uh there was an interesting case uh CAPCOM  driver where this driver was signed by CAPCOM for a video game that it would turn off uh SMEP  protection, execute code that you pass in from user space and then uh continue on and that was  found pretty quickly and people were able to uh know to block that but the these issues keep  popping up individually so we were trying wanted to look uh across the spectrum a little bit more.  There's some uh nice examples right up so if there's a vulnerability in a MSI driver and here's  how to use it to escalate from uh user space non-elevated to uh NT authority system by using  one of these sign drivers. So to take a little bit of a closer look uh read write everything it's  essentially it was designed to give you the ability to look at these hardware interfaces in your  system basically explore the system see what the state of the machine is and it basically has a  user space app and then a signed driver which is intended for this purpose but uh the problem is  that it it allows access to components that have really important security properties and they  need confidentiality in some of these uh resources and uh integrity in other resources so you're  basically given free reign to arbitrarily read write modify some of the device some of the  interfaces that Windows depends on Windows security depends on these not being tampered with so  this this was an interesting app um but then uh Lojax was a malware that was found in the  wild it was an APT that they actually brought a copy of that ring write write anywhere driver  along with them as part of their infection uh their implant tool used read write everything in  order to uh gain direct access to the spy controller and then they were able to use that in  order to write their own malicious module into the into the system flash and uh persist in that  UEFI firmware that would uh survive reboots operating system reinstalls because they have the  ability to directly talk to the hardware through this mechanism and even if your system did not  have this read write everything driver on it they just brought it with them they were able to  load it and use that capability in a really interesting uh attack uh there was another  APT command uh campaign that also basically it also brought their own driver their driver was  not signed but they exploited uh four different drivers that had uh read write MSR capability in  order to get arbitrary code execution in the kernel and bypass driver signing enforcement so  they could install their own uh kernel root kit so this is out there actually being used in  the wild by real attackers so there's a few different reasons why you might want to use one of  these drivers basic one is just privilege escalation from user space get either escalate a  user from a normal unelevated user to admin user there's also just getting code execution  running within uh within the kernel itself uh another uh possibility is you can use some of  these uh drivers to disable bypass uh window security mechanisms and sometimes that can be  used in order to uh escalate privilege within the kernel or just get access to resources that  you shouldn't get access to uh there's another uh motivation where essentially getting  access to the hardware itself is is really useful you can modify system firmware you can  modify device firmware there are a lot of devices that still have unsigned firmware and you  can go basically write your malicious modification to either the system firmware get code  execution before the operating system loads or modify a device and uh have a persistent  implant in a particular device and there's some other things you can do with direct hardware  access but those are some key ones that we wanted to specifically call out so there's a  few different uh attack scenarios uh if the driver is already on the system and loaded the  driver itself controls the policy for who can talk to this device so many drivers you don't  have to be admin you can be a normal non-elevated user in order to talk to this particular  device there's another scenario where the the driver is on the system but it's not loaded  yet and in that case you do need admin privileges to load the driver uh we have found signed  applications that you can use to load drivers uh that are signed by well-known trusted vendors  that you could potentially use one of these applications there'd be a little uac pop up  that says would you like some trusted vendor to modify your computer and that might be a  good thing to uh load the driver if you don't have uh admin privileges but you can also just  wait so the if you if it's already loaded you don't need to be admin if it's not yet loaded  you do need admin essentially and there's also the scenario where the driver isn't on the  system all of your all of your drivers are fully up to date uh malware can bring a driver with it  and load that in this case they do you do need to have escalated to uh an admin in order to  load the driver but there have been a lot of pre-legislations uh you can bring an older  version of the driver so uh even if the newest version has been fixed in many cases the old  vulnerable driver will still be loaded into windows or loadable into windows and you can  just bring the old version load that and use this kind of capability and lowjax did this  for their in the wild APD campaign where they brought an older driver they were able to load  it and get direct set direct access hardware and implant the UEFI firmware so we've we've seen  this pop up every now and then just one at a time there isn't really uh industry wide fix for  this problem or industry wide effort to go fix this so we wanted to uh take a look and see  see how hard it is to find these drivers and how widespread it is so we uh focused on because  we're interested in signed drivers so that we're loaded into windows we we threw out any that we  found that weren't signed because we're looking for drivers that talk to hardware interfaces or  have that kind of capability we look for drivers specifically from uh firmware and hardware  vendors and then just to make it a little easier we uh went with the smaller drivers that would  probably be more uh simple so also looking for things like uh read write MSR opcode uh move to  control register in and out opcodes those are specific x86 instructions that are uh talking to  drivers or talking to devices or hardware in a way that we're interested in uh one other thing  to keep in mind is that uh there's two different uh driver there's two different mechanisms or  frameworks that you could write your driver there's the uh older uh windows driver model and uh  the the newer windows driver framework uh with the uh the older version you basically your  driver would just call IO create device and then write a address of a handler for uh all of the  requests that uh user space is going to make to your driver to a specific address within uh a  structure that it passes to this IO create device uh function uh the windows driver framework has  changed a little bit but it's a a similar kind of concept where you uh you have a couple  functions that are set up and uh eventually you do have a a main dispatch or uh i octal handling  function that will handle all of the requests from user space uh uh uh I I don't know if we  mentioned it but uh I octal is basically IO control so there's a specific number that you  could say I want I octal 1 2 3 4 and uh the the dispatch will call your your kernel handler and  say here's your IO request packet with request 1 2 3 4 and the data that was passed from uh user  space um so there is a a little bit of a difference where uh in IO create device versus this uh  create device secure function if you if the driver is calling a create device secure it can  actually specify a uh a security descriptor which is a a policy that says who can talk to this  driver and what type of access they have uh this is a an example of one of these uh uh SDDL  strings uh in this case it's a discretionary access control list that allows generic all to  local system and generic all to built in administrators most of the drivers that we looked  at don't bother to set any kind of policy so a normal elevate a normal non elevated user can  talk to these drivers so we essentially spent two weeks looking for drivers we uh skim through  hundreds of of uh driver files just doing uh manual disassembly analysis looking for this  type of uh behavior uh we found 42 uh different vulnerable signed drivers uh we found 42  vulnerable signed x8664 drivers uh we did find uh a lot that had a 32 bit version so it was  around uh 80 something total files but we did find one itanium driver that I don't know if  anybody still has an itanium machine out there but uh we've we've also found more drivers since  but there were uh 42 drivers 42 x8664 drivers that we were looking at but uh the types of things  that we found were things like basically you could ask from user space for the kernel to go  read and write virtual memory in the kernel or to read and write to uh physical memory  addresses uh you could go talk to uh MIO devices uh model specific register, arbitrary read  write, uh control register access, talking to PCI devices, some SM bus access, just basic uh  in and out so uh here's an example of uh uh mem copy that we found in the kernel where they  literally are taking the the source destination and size for this copy operation from user  space there's no checks of any any uh pointers uh no pointer checks, no length checks, no  length checks, you can literally just ask the driver to go copy memory around for you. Um  this this can be used to mod to modify uh kernel code and data structures um patch guard will  detect some modifications it doesn't detect them all though so it's if you have a primitive  that's this flexible you can do a lot of interesting things with it. You can copy from user  space into kernel memory the other way around it's it's really useful. Uh another thing that  we found is just basic arbitrary physical memory write uh read and write uh in in this it's  intended so that you can use it to go talk to device drivers and do MMO access uh in this  case there's also no uh sanity checks you could basically have any any address any size and  go try to call this function uh MMMM map IO space um there has been a change in how windows  deals with this function as of uh uh 1803 where they've tried to limit the scope of what you  can do with this physical memory write only to those uh MMMM IO addresses so uh older systems  before 1803 you could just map map any kernel address and do read and write there also um  but even after 1803 you can still go uh get direct access to the hardware and do some pretty  interesting things there. Uh there there's also drivers that just expose the the physical to  virtual mapping so you can look up addresses in virtual space and find their corresponding  page in uh the physical address layout which is is it's useful for for dealing with actles that  give that kind of uh physical address but it's also useful for uh things like row hammer where  it's like knowing where things are mapped physically into into the address space this type  of functionality can be really useful. So another thing that we uh looked at was just arbitrary  uh model specific register uh read and write uh here's an example where they're taking the  address of the model specific register to read no filtering directly give you the data back. So  if you're not familiar with model specific registers uh these are uh internal registers  within the the CPU that like you have your general purpose registers for normal executing code but  these special purpose model specific registers are uh in addition to that and they were  originally used for experimental features that Intel wanted to try out and some of those uh  experimental features they decided these are really useful so we're going to turn them into  architectural uh model specific registers or MSRs such that from a certain point going forward  they're committing to support this particular usage model for the the value that you put into  into the MSR will be used in a architecturally defined way and uh they do have uh special op  codes special X86 op codes uh read MSR and write MSR in order to uh access these uh registers.  Uh one interesting point is that you can only access them from ring zero so ring three if you  try to read a MSR uh you'll get a uh fault and it won't allow you to uh get that data but we we  have a primitive here where you can read MSRs and there's some pretty useful things that you  can get just by reading the MSR uh we also found uh model specific write primitives and there are  some really really critical model specific uh registers that uh are especially interesting  like uh star C star L star and C star where in order to even transition from user space into  kernel space or ring three into ring zero when you call a when you execute a sys call  instruction it will as part of that transition going from use from ring three into ring zero it  will take the address that's stored in this L star register and use that as the address that it  starts re executing in ring zero so if you if you have the ability to write to this register from  user space that's pretty dangerous. So there's also uh control registers and there's a lot less  control registers but they store some key uh control bits for the processor um CR three is the  base of the virtual memory uh paging tables so knowing where that is could potentially be  useful uh CR four has uh uh some other security controls CR zero has some security controls so in  this case we have a arbitrary ability to read any of these control registers uh including the base  of the page table structure in kernel space not the user space copy of the page tables and  there's also a control register write uh functions where you could take an arbitrary value and  arbitrary control register that's taken directly from your user space uh input buffer and write  the value to the control register and some pretty uh key ones that are that some of the security  controls in Windows depend on is uh supervisor mode execution protection that basically is uh one  of the features that helps protect against a number of different attacks that have been very  successful against Windows in the past uh there's also this uh write protect bit in CR zero where  if if the write protect bit is not set in CR zero and uh the the kernel or ring zero code tries to  write to a page that is marked as read only it will completely ignore the permissions in the  page table and let you do the right anyway so it's a it's an interesting control so it's kind of  per security hardening but it's useful to know about if we can write to that that can help us  other things are just arbitrary uh IO port right you can write arbitrary values arbitrary IO  ports it's what you can do with that is platform dependent you could possibly use that to modify  system and device firmware uh we we saw a really cool uh vulnerability last year involving a  speed BMC configuration where there were debug features that were accessible from the host and  you could through IO reads and writes arbitrarily read and write into the BMC address space uh  laptops have look likely have an embedded controller that you can talk to over IO access and  then there's also legacy PCI access over IO port CF8 CF8 CFC there's also just functions to  literally do that legacy PCI right so there have been issues with uh security of PCI devices and  that comes up a lot so to kind of look at the MSR case a little bit more essentially the LS L  star MSR is pointing to an address into kernel memory where we don't know exactly where the  kernel has been loaded there's address randomization is happening so when when this transition  happens when you go from user space to kernel space it starts executing at the at the address  that L star points to so if you can write to L star we can basically allocate a buffer in  user memory and then when that transition happens the very next next call that happens it'll  start executing from your pointer instead but there's some complications to that so one of the  features that I mentioned uh supervisor mode execution prevention is intended to uh stop this  feature there have been a lot of bugs where you could get the kernel to uh jump to your your  pointer and they added this feature to the CPU uh I think in uh Sandy bridge where maybe IV bridge  but it's essentially a feature where if the CPU is executing in uh in a ring zero and it does a  code fetch to a page that's in a user user mapping it'll cause a fault and this is controlled by a  bit in the CR4 register so if we have a read write primitive for uh control registers we can  just read this bit from or we can read the CR4 value clear the bit and write it back to CR4 and  in order to uh get around supervisor mode execution prevention um there's another uh  complication that uh uh there needs to be a little bit of state change when you're transitioning  into the kernel space so although it starts executing in ring zero it hasn't fully switched  into kernel space so you need to do a little bit of extra work entering and executing your  your payload there and then there's also uh uh kernel page table isolation so as part of the  meltdown mitigation for uh one of the Intel uh CPU issues uh they basically isolated the  kernel pages so they have two different sets of pages one for user space and one for kernel  space so uh we do need to know the address for those kernel page tables in order to fully be able  to switch into kernel space uh but if we have an I octal that we can arbitrarily read CR3 then  we can then we can get the address of that kernel uh page table base so that when we build our  payload we could just swap in the kernel page table pointer and do what we want to do so we have a  couple little demos of uh switching uh of uh some of these uh features.  Quick note all these demos are in PowerShell. So we have a basic uh uh so this this one is not  PowerShell but this this is just a simple uh yeah. So we in order to in order to do our research  we basically uh made a simple tool to uh load any arbitrary driver for us so instead of needing to uh  instead of needing to write a helper to load it and deal with it we can use a simple  tool to uh load any arbitrary driver for us so instead of needing to uh instead of needing to  write a helper to load it and deal with it it's just a simple tool to load a driver, create the  service, start the service for us so we could try things out. So in order to do this we were  running as administrator um the other demo that I'm about to show uh is not running as  administrator. Uh yeah. So in in in this case we basically are reading some uh state from  basically uh the the kernel is being loaded at a random address so from user space not  elevated at all we can uh read the uh the address of that uh entry point into the kernel and uh  uh understand where the kernel is loaded so this can help us with uh with further attacks that  depend on where where the kernel is loaded into uh into the address space. We also know the the  base of the the page tables is this uh second value so when we're building a payload we can use  this this value to uh make that easier. Uh yeah. So there's also uh the SMEP bit in uh in CR4 where  we can also like in this case we we read CR4 we saw that it was enabled. We cleared the value, we  wrote it back, we see that it's still it's it's disabled now uh and there there is a uh a feature in  windows called uh patch guard that will go and look for uh configuration of the system look for  dangerous things and uh we found a write up that meant that said that they were able to measure  that they were reading these MSRs every 30 minutes so that's a lot of time to uh get your  malicious code to uh run and so we we were testing it didn't crash even after like 45 seconds. We  did see some cases where it would crash after you wrote to the MSR but it's uh it seems like  plenty of time in order to uh get your your payload working if you want to use this for.  And if you can calculate it's a lot of time. What's that? Uh it's uh 1903. Oh yeah. And this is on a uh  1903 system so it's latest has the latest version of uh of uh patch guard. Okay. So some of the  problems is like we we took all of these drivers we uploaded them to virus total none of the  drivers came back as malicious they're loaded by windows but AV isn't really helping us with this  issue because you can you can use a lot of these drivers to attack AV and bypass some of those.  Some of the those uh protections. So we're we're hoping that we could actually fix this. So  Microsoft does have a virtualization based security and uh hypervisor enforced code  integrity. Um those uh those are only present from uh 7th generation CPU and newer. Uh also  there are compatibility issues that prevent you from turning this on and HVCI will help against  some of these issues but uh not all. And I have a a Kaby Lake laptop that is pretty new and  should support it but I have compatibility issues and I haven't been able to actually turn on  this feature. Um there there's also some uh enterprise uh device guard policy that you can  configure to block known drivers once they're known to be vulnerable but there hasn't been any  really industry wide fix for this yet. So we're hoping to uh fix that. So all of these all of  these drivers that we found originally were just through manual analysis so we were looking  how can we actually automate this and started looking at the uh anger framework for uh symbolic  execution. And if you're not familiar with anger or symbolic execution uh it essentially  allows you to dynamically execute the parts of a program and every time you get to a  conditional branch it will try to execute both paths and see what happens. So it's really  useful but it's easy to uh run into issues but. So I got an initial script just to try out the  idea working in about a day and it works really well in some cases. In other cases the code is  complex enough that you run out of memory and you have a a state explosion because there are so  many conditional branches that it had issues but for for what that actually looked like for  trying it out we uh we had a specific driver that we know is vulnerable and we know the the  address of the handler that that main actual dispatch is at a particular address and we know  the address of a right MSR opcode that we want to uh search for and see if this is actually  taking data that's passed from from user space. So essentially you just need to load the  driver into anger in this case we don't care about uh libraries so we'll not load libraries and  then uh create a uh an anger uh execution state object that uh starts execution at the I  octahandler the dispatch function and we can take that uh uh I-O request packet that structure and  uh basically create symbolic regions for those parts and set pointers so that when we're starting  execution at the uh I octahandler it will have these uh these uh symbolic regions as the the  input data that we're passing into this function. Then you can uh create a sim- simulation manager  and just let it start executing code from the uh from the uh I octahandler point with a target  address of the uh right MSR address so we're trying to reach that address. If it's found we just  print that we've we've print that a path was found and whether the uh the input data to this  right MSR is taken from the input buffer if it's symbolic data and it it worked it completed in  less than five seconds and we proved that when we reach this uh MSR at right MSR opcode uh that  the address and uh data that will be written to the the CPU register is uh included in the input  buffer it even tells you the specific dword offset into the input buffer for where you need to  structure your your data to to talk to this driver and it it completed in uh five seconds  literally the the last three slides that I showed you that's the entire script to uh to do this  improve that that this is actually taking input from the user. Uh another issue is that we want to  automatically find that I octahandler ourselves so we don't have to manually open every driver do  some disassembly find that prime that initial dispatch function so for a WDM Windows driver  model uh drivers it's a lot easier we can easily just set a a memory right breakpoint on that  structure structure element in the driver object and uh this this script right here that's all you  need to find the I octahandler for these WDM drivers. We can also uh automatically find the  I octal number so you have a driver there's a right MSR it'll tell you that there's a right  control register or an MSR it'll tell you the number you need to pass for the I octal it can  tell you what values you also need to put into the into the input buffer so in this case uh this  list of constraints down at the bottom were automatically detected and uh anger can actually  simplify those for you so these three constraints at the bottom basically are simplified to the  value at the first D word in uh the input buffer needs to be four and then the second uh there  are the the third and fourth D words are the value that's written to this uh CR4 register so we  can actually find a lot of information automatically um there are some problems with with this uh  anger is based on a VEX which was part of Valgrind so it was all user space applications and as  far as we can tell it was never used to analyze privilege code because it literally has decode  errors when it runs into some of these privilege opcode so the the decompiler and instruction  lifter it so it lifts into an immediate intermediate representation and that part of the code it  runs into decode error and it doesn't know what to do so there is some functionality that was  added in the Python framework on top of that where you can write a Python module to kind of  emulate or implement what this opcode should have done so we were we were able to take advantage  of that and have it work more reliably on on more uh on more uh drivers so one other  problem is that it currently only supports at least the tool that we wrote only supports uh  WDM drivers we do detect if it's a WDF driver and have some ideas on how to make it work with uh  WDF drivers also it's just a little bit more in direction and hooking but it should be fairly  straightforward um and then there's the issue that some drivers are a little bit more complex and  cause it to run out of memory I've had it run out of 64 gigs around so we uh we we need to fix a  few things so I'll let let Mickey do it. So um now for a little bit of uh naming, shaming and  faming uh we talked about 20 total vendors these are the ones that we can uh disclose right now  some are not um ready to release updates some did not respond some said acknowledged but we  haven't heard back from um and some are really working on a fix but because they're in regulated  environments they require more time to go through certification so we're not gonna disclose them  we're gonna go through um everything we've been through talking to these to these guys and and  these uh companies since uh late April early May uh we're gonna start from the best example to  the worst um the best example we had is with Phoenix Phoenix is one of the big three IBVs I  have never heard or experienced a better response than Phoenix we we started with with the  first disclosure batch to send out to vendors um I think Monday that week and we said yeah  we'll finish it up we'll send it on Tuesday obviously it ended up Friday 5 p.m. and we  sent it out to emails and we went home Saturday morning we got an email back saying we  acknowledged the issue we're working on a fix within six weeks they already had a fix ready to  deploy to customers this is textbook like I've never ever experienced anything like this  especially with a driver uh we also sent an email to cert and uh cert cc we for some reason it  got lost in communication with us cert uh I didn't up calling them a couple days ago and they  did receive it so I don't know what's going on from that perspective we did get a receipt but um  no actions were were prescribed for us from from certs Microsoft uh now that's a story so  Microsoft's model of of the operating system is basically give third parties the option to  write their driver right it's like I have a company I have a product here write code to  interface with our product um the problem with this class of issues is a lot of drivers fall  into that caveat where some someone might write bad code so what can Microsoft do about it they  can't just say hey okay people uh write some code but don't make it bad it's a bit problematic so  we had a an initial discussion with them and and send them a note say hey what's your what's  your view about this and we got a response from MSRC tier one that said not a problem uh talk to  you later we sent another email later on asking if they're really sure it was a back and forth and  the end of the day after uh quite a few rants on twitter we ended up getting to communicate and  ended up doing a couple of face to faces here in Vegas uh it changed the complex the entire  conversation uh I'd like to say thank you to Krista Anderson and Nate Warfield for being very  good at communicating and forthcoming and trying to help also to Kimberly Marissa Mary  Eustace and Gaurav I hope I'm not butchering that name for helping from MSRC site to clear  everything up and and um help sort things out. Now the worst driver award goes to as  rock um because this is one of four I think one of four signed drivers that does all of this  so it's quite impressive the you try to award goes to Nvidia for telling us that the driver  that we found is internal so it doesn't merit a CVE because it's it requires a security hardening  effort internally although it is distributed by MSI on their website as a tool for updates for  their graphics cards so it's internal tool but it's distributed by an OEM on the internet.  Okay the worst ones are these four that did not respond so out of these four there is one um  that completely doesn't respond so at least some of them sometimes respond but real tech I've  had um researchers during this time in Vegas we talk to each other and we we share notes and  we discuss uh you know experiences like oh this vendor sucks this vendor is great and no  one in real tech is answering any emails so if anyone from real tech sees this please check  your inbox and reply to something. Um a few advisories are coming out so Phoenix did June 21st  within amazingly quickly time uh already sent to OEMs so uh the fixes that Phoenix inside an  AMI will release the three big BIOS vendors are gonna go get distributed to OEMs and um OEMs  will then distribute it to customers uh Intel had a fix in July 9th Huawei in July 10th uh  let's see inside is today it's the next slide and a couple more coming out next week we can't  talk about it and a few more during the until the end of the year um inside was kind of  enough to send us this uh statement I'm not gonna go through it but the gist is they're  fixing it Microsoft send us this statement I'm not gonna go through this because we've been  through enough uh and now I'm going to the conclusion so basically bad drivers are bad um  people that write ring zero code and write it badly are a danger to society um these some of  these drivers like the easiest way to fix this is okay I'm a vendor I wrote a driver I own up to  it I revoked the certificate done can't load it anymore in Windows 10 at least um so getting  vendors to to remove to revoke the certificates is is not as easy as sometimes like we had with  Phoenix but um it will be a great help to do this like the biggest majority of the the majority of  drivers that we've seen are old they're not new brand new 2018 2017 some of these go back to  2008 so just revoke the certificates this is like a big problem it's not just specifically it's  just a class again um multiple researchers have disclosed these drivers separately at a time but  the problem is systemic and we want to we want to hope that we're hoping that at some point this  can be fixed in a larger scale Windows 10 is is moving towards this there's mitigations in  place there's HVCI um virtual based security but you know you have to have a 7th gen CPU and  above for HVCI to work and even then not always does it work um we are going to release all  all our code C sharp C plus plus and PowerShell examples on GitHub with the latest slides and  the videos and um our tracking for all the drivers and where you can find them please check  this GitHub on August 13th um we did have this internal debate of whether to release it today  or in three days but because it was so close we just decided to sort everything out get  through Vegas and up loaded on the 13th and I think we're done.
Jesse_Michael_-_Get_Off_the_Kernel_if_You_Can_t_Dr_tzWq5iUiKKg_0_107.png Jesse_Michael_-_Get_Off_the_Kernel_if_You_Can_t_Dr_tzWq5iUiKKg_108_1163.png Jesse_Michael_-_Get_Off_the_Kernel_if_You_Can_t_Dr_tzWq5iUiKKg_1164_2111.png Jesse_Michael_-_Get_Off_the_Kernel_if_You_Can_t_Dr_tzWq5iUiKKg_2112_2567.png Jesse_Michael_-_Get_Off_the_Kernel_if_You_Can_t_Dr_tzWq5iUiKKg_2568_4835.png Jesse_Michael_-_Get_Off_the_Kernel_if_You_Can_t_Dr_tzWq5iUiKKg_4836_6479.png Jesse_Michael_-_Get_Off_the_Kernel_if_You_Can_t_Dr_tzWq5iUiKKg_6480_7079.png Jesse_Michael_-_Get_Off_the_Kernel_if_You_Can_t_Dr_tzWq5iUiKKg_7080_7511.png Jesse_Michael_-_Get_Off_the_Kernel_if_You_Can_t_Dr_tzWq5iUiKKg_7512_7739.png Jesse_Michael_-_Get_Off_the_Kernel_if_You_Can_t_Dr_tzWq5iUiKKg_7740_7835.png Jesse_Michael_-_Get_Off_the_Kernel_if_You_Can_t_Dr_tzWq5iUiKKg_7836_7883.png Jesse_Michael_-_Get_Off_the_Kernel_if_You_Can_t_Dr_tzWq5iUiKKg_7884_7979.png Jesse_Michael_-_Get_Off_the_Kernel_if_You_Can_t_Dr_tzWq5iUiKKg_7980_8039.png Jesse_Michael_-_Get_Off_the_Kernel_if_You_Can_t_Dr_tzWq5iUiKKg_8040_8555.png Jesse_Michael_-_Get_Off_the_Kernel_if_You_Can_t_Dr_tzWq5iUiKKg_8556_9407.png Jesse_Michael_-_Get_Off_the_Kernel_if_You_Can_t_Dr_tzWq5iUiKKg_9408_9875.png Jesse_Michael_-_Get_Off_the_Kernel_if_You_Can_t_Dr_tzWq5iUiKKg_9876_11447.png Jesse_Michael_-_Get_Off_the_Kernel_if_You_Can_t_Dr_tzWq5iUiKKg_11448_11963.png Jesse_Michael_-_Get_Off_the_Kernel_if_You_Can_t_Dr_tzWq5iUiKKg_11964_13043.png Jesse_Michael_-_Get_Off_the_Kernel_if_You_Can_t_Dr_tzWq5iUiKKg_13044_13499.png Jesse_Michael_-_Get_Off_the_Kernel_if_You_Can_t_Dr_tzWq5iUiKKg_13500_17507.png Jesse_Michael_-_Get_Off_the_Kernel_if_You_Can_t_Dr_tzWq5iUiKKg_17508_19247.png Jesse_Michael_-_Get_Off_the_Kernel_if_You_Can_t_Dr_tzWq5iUiKKg_19248_20759.png Jesse_Michael_-_Get_Off_the_Kernel_if_You_Can_t_Dr_tzWq5iUiKKg_20760_22679.png Jesse_Michael_-_Get_Off_the_Kernel_if_You_Can_t_Dr_tzWq5iUiKKg_22680_23975.png Jesse_Michael_-_Get_Off_the_Kernel_if_You_Can_t_Dr_tzWq5iUiKKg_23976_24707.png Jesse_Michael_-_Get_Off_the_Kernel_if_You_Can_t_Dr_tzWq5iUiKKg_24708_24971.png Jesse_Michael_-_Get_Off_the_Kernel_if_You_Can_t_Dr_tzWq5iUiKKg_24972_25079.png Jesse_Michael_-_Get_Off_the_Kernel_if_You_Can_t_Dr_tzWq5iUiKKg_25080_25595.png Jesse_Michael_-_Get_Off_the_Kernel_if_You_Can_t_Dr_tzWq5iUiKKg_25596_27167.png Jesse_Michael_-_Get_Off_the_Kernel_if_You_Can_t_Dr_tzWq5iUiKKg_27168_27815.png Jesse_Michael_-_Get_Off_the_Kernel_if_You_Can_t_Dr_tzWq5iUiKKg_27816_29027.png Jesse_Michael_-_Get_Off_the_Kernel_if_You_Can_t_Dr_tzWq5iUiKKg_29028_37883.png Jesse_Michael_-_Get_Off_the_Kernel_if_You_Can_t_Dr_tzWq5iUiKKg_37884_39239.png Jesse_Michael_-_Get_Off_the_Kernel_if_You_Can_t_Dr_tzWq5iUiKKg_39240_40367.png Jesse_Michael_-_Get_Off_the_Kernel_if_You_Can_t_Dr_tzWq5iUiKKg_40368_41795.png Jesse_Michael_-_Get_Off_the_Kernel_if_You_Can_t_Dr_tzWq5iUiKKg_41796_44171.png Jesse_Michael_-_Get_Off_the_Kernel_if_You_Can_t_Dr_tzWq5iUiKKg_44172_44339.png Jesse_Michael_-_Get_Off_the_Kernel_if_You_Can_t_Dr_tzWq5iUiKKg_44340_44423.png Jesse_Michael_-_Get_Off_the_Kernel_if_You_Can_t_Dr_tzWq5iUiKKg_44424_44567.png Jesse_Michael_-_Get_Off_the_Kernel_if_You_Can_t_Dr_tzWq5iUiKKg_44568_45131.png Jesse_Michael_-_Get_Off_the_Kernel_if_You_Can_t_Dr_tzWq5iUiKKg_45132_45347.png Jesse_Michael_-_Get_Off_the_Kernel_if_You_Can_t_Dr_tzWq5iUiKKg_45348_45563.png Jesse_Michael_-_Get_Off_the_Kernel_if_You_Can_t_Dr_tzWq5iUiKKg_45564_46559.png Jesse_Michael_-_Get_Off_the_Kernel_if_You_Can_t_Dr_tzWq5iUiKKg_46560_47339.png Jesse_Michael_-_Get_Off_the_Kernel_if_You_Can_t_Dr_tzWq5iUiKKg_47340_47867.png Jesse_Michael_-_Get_Off_the_Kernel_if_You_Can_t_Dr_tzWq5iUiKKg_47868_48263.png Jesse_Michael_-_Get_Off_the_Kernel_if_You_Can_t_Dr_tzWq5iUiKKg_48264_48335.png Jesse_Michael_-_Get_Off_the_Kernel_if_You_Can_t_Dr_tzWq5iUiKKg_48336_48407.png Jesse_Michael_-_Get_Off_the_Kernel_if_You_Can_t_Dr_tzWq5iUiKKg_48408_48491.png Jesse_Michael_-_Get_Off_the_Kernel_if_You_Can_t_Dr_tzWq5iUiKKg_48492_48803.png Jesse_Michael_-_Get_Off_the_Kernel_if_You_Can_t_Dr_tzWq5iUiKKg_48804_52019.png Jesse_Michael_-_Get_Off_the_Kernel_if_You_Can_t_Dr_tzWq5iUiKKg_52020_57971.png Jesse_Michael_-_Get_Off_the_Kernel_if_You_Can_t_Dr_tzWq5iUiKKg_57972_60899.png Jesse_Michael_-_Get_Off_the_Kernel_if_You_Can_t_Dr_tzWq5iUiKKg_60900_62339.png Jesse_Michael_-_Get_Off_the_Kernel_if_You_Can_t_Dr_tzWq5iUiKKg_62340_62915.png Jesse_Michael_-_Get_Off_the_Kernel_if_You_Can_t_Dr_tzWq5iUiKKg_62916_63239.png Jesse_Michael_-_Get_Off_the_Kernel_if_You_Can_t_Dr_tzWq5iUiKKg_63240_66347.png Jesse_Michael_-_Get_Off_the_Kernel_if_You_Can_t_Dr_tzWq5iUiKKg_66348_69155.png Jesse_Michael_-_Get_Off_the_Kernel_if_You_Can_t_Dr_tzWq5iUiKKg_69156_69419.png Jesse_Michael_-_Get_Off_the_Kernel_if_You_Can_t_Dr_tzWq5iUiKKg_69420_69683.png Jesse_Michael_-_Get_Off_the_Kernel_if_You_Can_t_Dr_tzWq5iUiKKg_69684_71255.png Jesse_Michael_-_Get_Off_the_Kernel_if_You_Can_t_Dr_tzWq5iUiKKg_71256_72059.png Jesse_Michael_-_Get_Off_the_Kernel_if_You_Can_t_Dr_tzWq5iUiKKg_72060_72659.png Jesse_Michael_-_Get_Off_the_Kernel_if_You_Can_t_Dr_tzWq5iUiKKg_72660_73214.png