 Dobre evening, everyone. I hope because you picked this talk that all of you know what UEFI stands for. Just in case stands for unified extensible farmer interface and roughly speaking it's a replacement for or the successor for legacy bias. Just more features, more secure. The objective of our research was get access to this tiny chip that's normally stored solder to your motherboard and it's named SPI flash chip and it holds the contents of the UEFI farmer. So it holds the code of UEFI. The rules of the play is with physical access it's straightforward. All you need is to connect proper gear, the flash programmer to this chip and then you can play with it at will. So we consider only software attacks during this talk, particularly the ones that can be conducted remote, which is much more scary. Why bother? Bios or UEFI is quite special piece of code because that's the code that gets executed first by the CPU after the machine is powered up. So it means if you have control at this very early state of execution you control what's executed here, you also control what's executed later. You can trojan it at your will, so you can trojan the kernel that's loaded later or the applications. And this method of trojanning has a nice advantage that it can survive OS installation, right? Because the code for the trojan does not reside on the hard drive along with the operating system, but in the bios body on the SPI flash. So that's pretty unique. Also if you're not that sophisticated, you can do much more simpler trick, just overwrite the bios area with garbage. And then what happens is that machine will not boot, because bios will not start. And the only way to revive this machine is just again connect the flash programmer. There is no other way. So that's pretty nasty attack. If you consider what happened to Saudi Aramco a couple of years ago, that kind of attack would be much more nasty. So all these three reasons why it is interesting to get access to the flash chip. It's again ideal place for rootkit. You probably don't hear a lot about these rootkits being deployed in the wild, because it's a little bit advanced, but they do happen. And if you Google for the project data bounds by NSA, you can see that really that kind of rootkits happen in the wild. So regarding all this issue, how security is implemented. Well, first of all, the chipset itself provides the means, the features to actually program the flash device. It's necessary if you want to support, for instance, biosubdates. But it also... It's possible to configure the chipset in a way that prevents right access to the chip. And then it's up to the firmware, BIOS, UEFI, whatever, to utilize the feature properly, so that, for instance, before an update to the BIOS is applied, UEFI must have a chance to, for instance, check the signature to verify that it's a legitimate update. And of course, any random attempts to write the SPI flash should be denied. Well, out this method of protection solid. There were vulnerabilities in the past that allowed us to get past this right protection. So probably the first one was in 2009, so a long time ago, by Aleks Tereszkin and me from ITL. And this gentleman much more recently presented at least two different ways of getting right access to the SPI flash. But in fact these attacks were a bit theoretical. Certainly suboptima from an explication point of view. The reason was these attacks were based on complex memory corruption vulnerabilities. And even developing exploits for WAN is very tedious because it's very difficult to debug the early BIOS code. So in reality to have reasonable chances to develop such an exploit, equipment like JTAG based debugger flash programmer and it gets complicated. Also the exploits were quite unstable. So they were dependent on particular version of the chipset etc. etc. and porting them to a different platform was not trivial. So for that reasons, although definitely real and possible to exploit, these vulnerabilities are not expected to be really exploiting in a wide. But today we'll present something better. Namely we'll present two vulnerabilities which are prevalent among UEFI and legacy biosystem. Essentially all five or six systems that we tested from different OEMs were vulnerable. So it means your laptop is vulnerable too. The consequences are again ability to get right access to the SPI flash and also as a nice bonus ability to get into SMM. SMM being system management mode. It's a very powerful mode of execution of CPU. That's again usually insulated from the rest of the operating system. And finally they are quite straightforward reliable, simple should be able to reproduce it at home. Okay. Okay. Before I begin, let me make sure my demo is still up and ready to go. So, as Rafał was saying protecting the contents of the SPI flash is of paramount importance for all those properties he was listing. And due to this security critical nature of the bios there's a number of protections that surround making arbitrary programs or any programs to the SPI flash. So it's not sufficient to just break down one of these. You have to really have to break through many layers if you actually want to insert an implant onto the bios. The general flow of the presentation from here will just be to describe each of these layers of security. Describe the attack surface against them and then break through them and hopefully show some live demonstrations of us doing it on these systems up here but we'll see if the demo gods are nice to us today. So, layer number one as you can see on this one is the bios control register and this is a memory mapped register that you can access in memory map.io or port.io and it takes the form of many of the security critical registers on the X86 architecture where you have some bits that control features and then you have maybe one locking bit so that once it's set the feature bits can't be maliciously modified by a compromised operating system or a compromised driver or something like that. So in this case this is responsible for at least something that's partly responsible for protecting the bios and you can see bit number zero is the bios try to enable bit and this is quite simple. When this is one you can make rights to the bios, when it's not you can. Simple. Bit number one is a bit more interesting so as I was saying, normally with these locking bits you have it where you set it to a one and then you can't change the feature bits anymore until the platform resets, they're just locked. But this one is different, if you read the in-print text it says ok if bios lock enable set to one, enable setting the bios try to enable bit to cause SMIs once set this bit can only be cleared by a platform reset so kind of interesting it's not saying that it just straight up blocks access to the bios try to enable bit it just enables essentially SMM to act as an arbitrator and decide whether or not bios try to enable should be set to a one or to a zero and so this puts system management mode in a position to decide who gets access to the flash chip so that was a bit abstract it's probably helps to clarify with some diagrams so if a let's say this is a malicious kernel driver wants to put an implant onto the flash chip the first thing it has to do is right enable the bios because it has to be one to make programming operations but in this case the bios lock enable bit is also set so the bios is being protected so because bios lock enable is set SMI system management interrupt is immediately generated SMM kicks in and SMM in this case is going to determine that hey this is an illegitimate attempt to right enable the bios so we need to come in here and set bios try to enable back to zero and then eventually the system the SMM handler will eventually return context back to the original kernel driver that started this whole attempt to reprogram the flash chip and at the end of the day the attempt to flash write the bios fails because this kernel driver this thread is never able to actually execute instructions in the context of the chipset when bios try to enable a set equal to one so what do we have here is the description of the bios control register from the old days and from the new days so the process of looking at this was kind of like a bendiffing for vulnerabilities but in this case we're diffing the documentation and you'll see some interesting changes happen so back in the old days the x86 architecture you had the north bridge south bridge style the memory controller hub and the CPU so this is what's up top the old ICH what I'm calling ICH style architecture but on newer systems most of them they've gravitated away from this north bridge south bridge style architecture now there's a lot of that north bridge functionality has been migrated into the CPU and other functionality has been pushed to the platform controller hub which has kind of assumed the role of many of the north bridge south bridge functions so now you just have CPU platform controller hub and I think this happened around 2010 or so but I can't say for sure but on the old one you see that bits 7 through 5 are disreserved they don't provide any additional features but on the new platform controller hub chip sets bit number 5 is for the smm bios write protect bit which has some pretty interesting language in particular it says that when it's set bios region smm protection is enabled the bios region is not writable unless all processors are an smm so when we looked at that it kind of gave pause to what does that actually mean all processors have to be an smm for rights to occur well it turns out that intel was patching a latent race condition in the spy flash protections provided by bios control and actually the way this cooperation between Rafał and I came about is I sent Rafał a paper of mines describing some attacks against legacy bios and it described this bios control functionality and Rafał said that seems a bit maybe we should try to look at that closer and some of my colleagues also suggested this might be a problem but as it turns out that this bios lock enable mechanism is subject to a race condition on multi core systems so the way this generally works it's really simple to exploit you just need two threads so two cores so essentially two kernel drivers and one will be attempting to write enable the bios in a tight loop and then the other core what I'm presenting here is thread number two is just going to be attempting flash programming operations in a tight loop so this when we succeed in the race condition bios try to enable okay we're doing this a million times an SMI occurs and the smm handler is going to come in and try to save the day and set bios try to enable equal to zero but it doesn't happen in time because thread two here just keeps on keeps on trying and eventually they're able to make that flash programming operation happen and this works pretty easily because there's no penalty for failure you can just attempt this flash programming operation in a tight loop millions and millions of times and if it fails because bios try to enable a zero then it just basically silently fails nothing catastrophic happens like hanging the system or whatever so you can really be take quite a brute force approach and it will work just fine and then yeah eventually smm will come in and set bios try to enable to zero but too late the the implants already been installed and the game is already lost so we're about to attempt live demo number one so I'm going to try to show you this race condition just to make it more real what's going on so let's give that a try everyone so what I have here is I'm currently rdp'd in one of these systems and we're just going to use this race condition to corrupt the firmware on this HP Elite Book and just render it non bootable that's the goal anyway but before we begin I want to show you just to make it even more clear what's going on at this bios try to enable bit so this right here on the LPC device is you can see right here it offset DC this is the bios control register right now only bit one is set which the bios lock enable bit and you can try all you want to set this thing to one and yeah it appears maybe to stick for a second you see a three there but that only appears to because the refresh rate of this is like one time a second so we can attempt to set bios try to enable but it's not working because smm is coming in and setting bios try to enable equal to zero but what happens if we just try this millions of millions of times simultaneously eventually we'll succeed hopefully okay before I begin I just want to show you the region of the flash that we're going to change if I can remember so in here it's just essentially unused space so it's just make a change here because it'll be obvious and what we have to do when doing these flash programming operations is actually from 4k block and doing so will corrupt the firmware to the point where it's not going to boot anymore so this is what will be changing, this is our target okay so what I've already done previously is I've installed two kernel drivers into this 108 systems and kernel driver number one is going to do bios try to enable in a tight loop when it receives an IO control code and kernel driver number two is going to attempt a flash programming operation in a tight loop upon receiving an IO control code and what we have to do is use these two user land agents to start sending the IO control codes to try to win this race condition okay so this one on the right set bios try to enable agent that's going to do the one that invokes the bios try to enable tight loop code and this one will do the flash programming now with flash programming it's a bit odd or I guess not odd but you have to do an erase operation before you do a programming operation so I'm actually going to have to win this race two separate times to actually accomplish this attack so let's see if I can be quick about this oops I didn't install the drivers here we go okay so right now I'm racing both those threads are occurring it's happening millions of times that was attempting the flash erase operation and now I'm going to attempt the programming operation so let's just try that one more time let it go for a little bit okay that should have been sufficient but we can actually check so what I have right now is a kernel driver where it's just dumping the contents of the spy flash so I can just verify that I've actually won the race and been able to make these changes yeah and you can see here these were originally F's and I just wrote some junk here and as I was mentioning programming only happened 64 bytes at a time so I've only changed 64 bytes here I could just continue this and write even more but the erase happens in a full 4k block so I actually annihilated a whole lot of other stuff including important UEFI data structures which is basically on a brick this system when I tried to reboot it so let's see what happens when I try to do that so I'm just going to reboot and the real race will be can I unbrick this system with the flash program I bought with me before fall finishes his portion and we can continue okay so I just rebooted that system probably it will do something horrible yeah so right now it's just stuck in this diagnostic boot loop it'll never boot again the firmware has been completely hosed because I've overridden critical parts of it and you're basically dead in the water you can't attempt to reinstall the operating system that's not going to fix it because the firmware is just completely blasted at this point it'll never turn on so this kind of attack was to happen you know your IT department would be pretty ill prepared to recover from this luckily so luckily I've had the foresight to make a backup of the firmware with my flash programer that I brought here so I can try to recover the contents of this while our fall is continuing which I'll do after I finish up here okay so one sort of important question is who is affected now as I mentioned ICH and earlier systems didn't even have this SMM bioshrite protect newer platform controller hub based systems it's like doing this CPU loop of doom right now so I'll turn that off if newer platform controller hub based systems if they set SMM bioshrite protect race condition defeated doesn't happen good to go older systems they can possibly protect these cells themselves this other layer of protection called protected range registers but even if they use them we'll talk more about how these work but it might not be sufficient and we'll talk about why later so if you don't set SMM bioshrite protect you're probably vulnerable and the bad news is most systems that I've looked at even systems that support SMM bioshrite protect don't set it so I did another paper with some colleagues earlier this year that I talked about hacking the box to Amsterdam and we surveyed about 8000 systems and granted the systems were probably about 2 years old on average I would say but less than 10% were actually making use of SMM bioshrite protect so there's this fix available for a lot of systems but for whatever reason systems don't seem to be using it like this elite book supports it but doesn't set it and many systems looked at it just don't bother to use it for whatever reason and yeah just to reiterate very easy to exploit nothing magical going on just need one thread setting bioshrite enable a bunch another thread attempting to flash programming and then wait a second and then you've probably won no penalty for brute force and in work you get to the promised land of the flash chip of the UEFI firmware so next up is if the OEM if the BIOS makes use of SMM bioshrite protect we are essentially forced to break into system management mode to continue our assault on the firmware and Rafał is going to talk about how we can attack SMM on most UEFI systems with this portion of next hmm ok, so attacking SMM bioshrite protect so have you ever heard the story of Darth Plaguez the wise no I thought so, that's not the story that the Jedi would tell you so for our purposes the important thing is that Darth Plaguez kept Darth Venami's Kamathos for many years in fact he killed him and revived a couple of times the reasoning behind it was research he just wanted to figure out how midichlorians work and how they are connected to life and death so how it's relevant for our business the relevant part is that you have already seen namely the chipset registers are lockable and some of the lock bits are cleared only during the whole reset so the idea is to force this reset so the death of the platform and then still gain control over it while it's being resurrected and that that idea means that we still have control why the registers are not locked and some of you might already have guessed that we will use ACP S3 sleep because it involves both death so sleep and then resurrection so resume so we will see that S3 sleep equals dark Jedi coma so what's the difference between normal boot and resume from S3 sleep in context of UE5 so UE5 execution is divided into a couple of phase you have sec phase PI phase DXE then boot device selection and operating system load and the interesting part happens in the XE phase so at this point most of the registers are actually locked interestingly each time the platform is being configured by the means of PCI, config space write memory write, IO write the information about information about what's being configured as recorded in the data structure named boot script and boot script is just again data structure stored in normal RAM typically it is in ACP NVS area of RAM reserved for the purposes of UE5 and why it is so it will be useful on S3 resume so as S3 resume we start in a very similar way so CPU is powered up, jumps to the reset vector then the sec phase executes PI phase executes but then something else happens namely instead of just loading all the DXE drivers from the flash and just running all of them we just replay the configuration actions from the boot script so that's the difference so at this point it's not the contents of the flash that dictates what's being executed in fact it's just the contents of this memory of the boot script that shows what configuration actions will be applied and then afterwards as usual the operating system is woken up and given control so again the important part is that at the moment when the boot script is interpreted most of the platform registers are not locked yet okay so obvious thing ACP NVS memory is just normal RAM it's not protected against the operating system in any way so it means attacker with at least ability to access all physical memory can mess with the contents of the boot script and that's what we're going to do one more thing this whole boot script concept is quite a core feature of UEFI so all the UEFI implementations are used so how a boot script look like so again maybe just for completeness i will quote some documentation the chipset configuration can be viewed as a series of memory, ION and PCI configuration operations which DXC drive is recording the framework boot script during as few years yom the boot script engine executes the boot script to restore the chipset settings so the boot script consists of the series of opcodes like IO write, memory write PCI config write and parameters to them there is a very interesting opcode for our purposes it's named dispatch and the semantics of it is essentially execute arbitrary code it's very useful as you can see in the specification all the consequences are obvious so if we can achieve any of the following either alter the contents of the boot script so insert a malicious dispatch opcode into it or alter the target or add a misting AEFI boot script dispatch opcode so that's different we do not mess with the boot script itself but we hook or overwrite the code that's legally called from it and finally we can alter the data structure used by the firmware to locate where the boot script is if we can achieve any of the following then we can force S3 suspend region cycle and run arbitrary code in the context of the boot script interpreter so how exploitation would look like that's the normal layout of relevant data structure on most of the machines that we have a look at so at the top of it there is UEFI environment variable named AGP global variable and it stores a value that's interpreted as a pointer this pointer points into RAM into AGP and VS and there is structure named AGP global variable at certain offset in it there is a pointer to the boot script so that's how it legally looks so the most straightforward way that works most of the time is first we will prepare our evil boot script we copy the original boot script here we prepend evil dispatch opcode that just calls our shellcode and then we change this pointer to point to our new shiny boot script the reason why we copied the original boot script is obvious we want to maintain the stability of the system during resume and that's pretty much it so the question is can it be done in the right way so is it possible to implement the boot script concept in a secure way and the answer is yes and actually the key introduces the concept of the lockbox so the method to store certain crucial data structures in a secure way and the way how it's achieved is that these data structure must be stored in SMM memory not in normal unprotected RAM but in the region of memory assigned for system management mode that's protected against operating system and then these will not work but it's possible to screw things in a number of ways so we have seen only a single system that actually used SMM lockbox to store the boot script and relevant data structure and it was actually a UEFI development motherboard the problem is that the implementation contained a legal opcode dispatch opcode with the arguments being again in unprotected memory so this time instead of messing with the boot script or the pointer to the boot script we can just overwrite or hook the code that's normally called during suizume again the effect would be quite the same so again why we're doing that platform is largely unlocked at this point particularly on all the systems that we have seen from various OEMs BIOS CNTL is unlocked so it means even if BIOS if CNTL BIOS write protect the bits that we talked previously even if it is set it can be fully unset nothing prevents that and at this point BIOS CNTL does not prevent write access to the chip it means that we don't even necessarily have to actually get code execution in the SMM context because we simply can unset BIOS write protect bit but getting control over SMM is quite nice because again of all the power that this model execution has so how it looks so generally SMM memory is protected by two set of registers first of all you have to protect against access from the CPU so for that purpose modern CPUs have dedicated MSR registers named SMM range registers and essentially this registers define region of memory that cannot be accessed by the CPU unless it is in system management mode interestingly at least again on the platforms that we have seen these MSRs are already configured prior to execution of boot script so this time no luck at least no free lunch even in the context of boot script interpreter we cannot access SMM from the CPU but there is another way how memory can be accessed by DMA direct memory access triggered by PCI devices all PCI devices that are master bus capable can trigger access to the memory and there is a separate register named TSEG this time it's a chipset register that again defines a region of memory that cannot be accessed by DMA interestingly TSEG is configured before the boot script is interpreted but it's not locked interestingly which is good news for us what we can do is change the value of the TSEG register to something totally bogus value and then any PCI device can execute DMA cycles and get read and write access to the SMM the only traveller's approach is that actually configuring PCI device to do arbitrary DMA or arbitrary address is tricky because essentially you must know full semantics of the device and just implementing it in the shellcode itself would be quite non trivial so we can do something better so in the shellcode itself we just move TSEG out of the way essentially also lock it and then after the operating system is woken up it's much easier to do arbitrary DMA because at that time you can use all the drivers that have been loaded by the operating system particularly the most straightforward way is to use the hard disk driver ok so that's again consequences really ability to get access to SMM memory so this vulnerability has been reported to cert and has been assigned this tracking number again all of the unified system that we surveyed were vulnerable or another it allows a kernel level attacker right essentially to bypass restriction employed by bioscntl and also escalate to SMM in runtime which is also interesting and finally it is more or less easy to exploit the only potential difficulty is that the boot script format varies from vendor to vendor slightly but significantly so if you want to inject your custom dispatch opcode you need to know the format so some reverse engineering might be quiet if you mean to port it to another system another interesting bit this very same vulnerability was discovered totally independently and mostly at the same time by guys from intel advanced threat research team so congratulations to them it happens really but it does happen ok so now let's try to do some demonstration i have set up a Linux system it's here so you should see the wide rectangle so the machine is powered up so assume you have some access to this machine it doesn't need to be SSH you could just exploit a browser and then get connect back share and all these attacks again to require administrator privileges so lucky there are a couple of ways to do that it's irrelevant and now we can essentially get busy so first of all let's see what's the location of the t-sec so t-sec is register in the host bridge interface at offset BA BA so normally it's at cc and zeros so now let's this demo is mostly about getting access to smm so now how we can try what happens when we do dma to this address to do that we need to insmote this helper module and then the tool we will read to the file name t-sec at this address this address and read one page so if you do it what do you get just try to figure out when I type the commands nothing is kind of expected and if you look at the kernel logs well something horrible has happened essentially the kernel had to totally reset the settling because it complained the hardware complained that the dma transaction has failed you can see that write spdma failed again it means how the protection offered by the t-sec works so now we run the exploit again it's just a matter of running another tool so what it does it writes shellcodes to subdefault location determines what's the acp variable hold and then switches the location of the actual what script what it does it again loads shellcode and actually this shellcode is just an else binary and once it is run it will log some information to it's body so if we dump content of the memory at this location to some log file offset lens and you do strings log file ok this is just the contents of the shellcode so nothing has been logged yet so what remains we can now use the normal utility bundle with linux that will arm realtime clock and wake the platform will suspend it to memory and will tell it to wake after 20 seconds again it's utility that's bundled with most distributions ok so now you can have a look at this machine now it's running run this command you should see it went blank so it's suspended now and you can see that the shell is hung i cannot of course interact with it because the machine is active so now we can either wait for it to reboot or use the force like banamis i command you rise and let's see let's see yeah it's complied and now let's redo all the things that you have done previously so now what's the value of tseg? it's some ff it won't help much let's read let's read the log of the shellcode and and now you see something more so the shellcode says that initial value of tseg was cc not locked it was possible to overwrite with ff and most importantly that value of bios cntl was 8 so the bit number 1 is not set so again we have bypassed the protection offered by bios cntl and finally let's try to do dma at this point ok and now let's see if anything interesting is in there now it looks much better not only zeros right so let's try to disassemble does it look like like 886 code ok, we have a jump jump 54 and then we have something very unusual we have memory access with cs prefix so the selektor for the code is used as a prefix of memory access and coupled with that weird prefix and the fact that you load global descriptor table it tells you that it's really smm proof can be found below unfortunately if you disassemble further you see bad instructions the reason is that smm entry point enters long mode quickly so we need to disassemble in the long mode i always mix it and now no more bad instructions and most interestingly after a couple of them yes, this is the smoking gun return from system management mode this instruction can be possibly only used in a single place so that really shows that we can get access to smm by dma after tsec has been moved consequently we can overwrite the body of smm and get code execution in smm context ok, so we've broken past bias control we've broken into system management mode on most systems that we've evaluated one last hurdle remains before we get to the sacred land the protected range register is protecting the firmware so what are these guys well, it is possible to use protected range registers such that you mask off parts of the flash so it's not even writable even to system management mode this ultra privileged mode of execution so you have several regions that you can declare and smm can't even write to them what's interesting about UEFI is that the protected range registers can't cover the entire spy flash chip because UEFI has these things called non-volatile variables which are kind of like linux, unix, environment variables describing things like the boot order, platform language etc etc and these have to be these live on the flash chip so coexist near the UEFI code and all that but they have to be updatable by the run time of the system which essentially means the operating system the US has to be able to communicate information about the firmware and change these variables or change the boot order etc etc so these essentially cannot be masked by the protected range registers if we can get into smm we can always clobber whatever is in this region so the question we asked is if we can clobber anything in here can we find some trusted integer value and corrupt it and induce a buffer overflow or something like that in general can we find memory corruption vulnerabilities by doing crazy things this region of the flash chip and smm has right access to well obviously we're up here today and the UEFI code there's a reference implementation that's open source you can just go and SV and check out or whatever and go to work you don't have to do any crazy reverse engineering so Rafał and I went to work on auditing the UEFI code and we found many of these vulnerabilities that if you assume an smm attacker can induce some type of memory corruption vulnerability to maybe do bad things like get past protected range registers now early we can induce these vulnerabilities in the boot up of the system if we can make this vulnerable line of code run in the platform boot up before the protected range registers are set and locked then we can bypass them so in this case pretty simple buffer overflow data size is controlled by smm attacker because it comes to that variable region and that in public key store is a fixed size data area we can clobber it and get control of the instruction pointer in the early boot environment blah blah blah not very exciting plus bypass protected range registers and we found another instance of this not very surprising this data a lot of times just in general treated as trusted if it originates if it originates from smm you don't have to validate it too much because smm is like a privileged type of entity which should have been instantiated by the BIOS anyway so in this case we can make next variable point somewhere crazy which leads to a buffer overflow on the EFI copy mem so another buffer overflow that we can possibly use to pivot past these protected range registers but the point in this presentation is that we don't want to give you complex memory corruption vulnerabilities because they're hard to do it yourself, they're hard to reproduce they're implementation dependent etc etc they're just hard to deal with so we want to give you some other ideas for how you can bypass these protected range registers without doing these complicated tricks so what's interesting is I checked out the protected the UEFI reference code further and it turned out that data that was within these authenticated variables these non-volatile variables that smm can control was used to authenticate flash updates so there is a mechanism for doing firmware updates updating your BIOS and back in the old days of legacy BIOS it was like the wild wild west HP would do something different Dell would do something different American megatrends would do something different and everyone was just doing their own thing without updating their BIOS but the UEFI reference implementation code provides a clear way called capsule update this is how you should do firmware updates on your UEFI based system all the code is in there and that code path the UEFI capsule update just straight up uses the smm control data to authenticate whether or not these updates are valid so an attacker can just use the legitimate BIOS update path and add their malicious root kit update as a legitimate update by manipulating this data by sending a key to one of these authenticated variables etc so this is what I thought when reading the UEFI code and I was like this can't be right there's like a security barrier here that's just been completely demolished by this assumption so what's the deal so we talked to some UEFI a core UEFI developer and you basically confirmed our suspicions that smm is just in the trusted code base for UEFI if you can break into smm then it's pretty much game over right now now UEFI is going to be depending on a new hardware feature in the future called platform platform firmware armoring technology or bioscar or I afraid exactly what they're calling it these days that I think uses the management engine in some clever way to protect the the firmware even from an smm present attacker I'm not sure how much data about this is publicly available I'm mostly just found marketing documents and patent filings when I was looking at it so not really clear how it works but definitely the point is to protect UEFI from a smm present attacker and right now older systems you can get smm, the rest of the platform is probably going to fall so the cake is a lie, there is no protected range registers on these UEFI based systems and it turns out that you probably don't have to bypass them anyway because many systems way more than 50% I would say don't even use protected range registers Rafal's Dell right here doesn't use them I doubt this Lenovo does Miss Lenovo's I haven't some, a lot of the HPs I've seen do use protected range registers but even on the systems that do use them they often fail to cover all the important data so for instance the protected range registers should have in theory protected this HP Elite Book which I bricked with a race condition from becoming bricked but they didn't because they usually don't cover all the important data areas even if they're used I've another survey paper we did that heck in the box, Amsterdam one I think the number we're looking at was only like 30% or something systems using protected range registers out of a mix of like Lenovo, Dell and HP so they're not using a lot of systems so you probably don't have to worry about them so point is if you can get to SMM firmware is going to be toast so the summary is that we wanted to talk about vulnerabilities that you could take and do it yourself, you could re-create these and because they are relatively easy to exploit and you can do cool things with them the first one is the race condition the bias control register very easy to exploit, all you need is two kernel drivers one attempting to set bias tried to enable in a tight loop one attempting to do flash programming in a tight loop and then it will probably win and that affects a great number of systems because some systems don't even support the fix and of the ones that do support the fix many of them don't bother to use it the boot script vulnerability literally affected every UEFI system that we looked at which granted was only like 8 or 9 systems but it included systems from HP Dell, Lenovo, the big 3 we suspect that it affects pretty much all the UEFI systems so your system if it was bought within the last 4 or 5 years or whatever probably is vulnerable to the UEFI boot script attack and pretty easy to exploit it you just need physical memory access and you just need to do a tiny bit of reverse engineering to figure out what the boot script looked like exactly so just to give you an idea when Rafal and Alexander Treskin did the first BIOS memory corruption vulnerability when they were part of the visible things labs they said it took them like a month to do the exploit and it probably only worked on one BIOS revision for one board etc etc so not very portable when I did the BIOS exploits recently it took me about 6 weeks to do one and it only worked for one BIOS revision on one system etc etc it was very tedious to do exploiting these took Rafal and I just a few days and we were able to exploit basically all the systems we had access to in a few days because they were simple to exploit and so go and play them pretty easy to reproduce and the last point is system management mode it's just been a problem invisible things labs talked about this at length back in the day SMM can do really bad things it's kind of just free to do whatever and that's still the case in UEFI if you get to SMM you can wreak havoc on the rest of the firmware end of story new hardware feature will address us in the future but the feature is not now so now we are vulnerable now one thing I'd like to point out these UEFI and BIOS vulnerabilities in general are pretty complex to disclose because they affect a wide number of people they affect HP, Dell, Lenovo, American megatrends Phoenix etc etc there's a lot of affected parties and coordinating these vulnerabilities is real pain so big thanks to the guys at Intel and the UEFI security response team insert for helping reach out all the affected parties and help fix these issues now it says I have 10 minutes left so I'm going to try one last demo for our viewer audience out there because the point is Rafal exploited his Dell laptop which is running Linux with the boot script but the point is Rafal uses Linux, I use Windows he uses AT&T style, X86 syntax I use Intel syntax he uses VI, I use Emacs but we can find a vulnerability that works for both of us and that's exactly what we're going to do I'm just going to ok so the goal is to break into system management mode by altering the boot script this right here is system management mode you can't see it, it's all less because the memory controller hub is blocking access to it from the CPU and we couldn't get into a DMA anyway because this right here is the TSEG it offset AC which basically means the SMM region is protected from DMA access try to access it, it's just going to fail horribly in fact I can show you that so I'm attempting a DMA read on that region and it's not going to work if you get this real nasty weird error I'm not really sure what's going on but essentially this DMA attempt is just failing, so whatever but what we're going to do now is alter the boot script to move TSEG like we did on the Linux system to FF000000 so that DMA protection basically won't exist anymore in the system and we just have to go to sleep now I didn't do some fancy re-wake-up thing like Rafal did because I don't have the same dark Jedi powers apparently, but you could easily do that by programming an event to just re-wake the system immediately using Windows but I didn't do that so I'm just going to press the power button again basically to make it come back to life yeah yeah yeah thank you so the system didn't die, that's good all of our demos have worked and you can see right here TSEG is set to FF000000 and I'm about to be punished by the gods because I haven't finished this one so let's try the DMA again see him to work and yeah here so this is the SMI handler which previously quit and read if you were to disassemble this you would see all the same stuff that you saw on our fall system so at this point we can use DMA to blow past the system management protections and then get into SMM and corrupt the firmware so pretty much all your systems are runnable to this attack sorry about that I don't need them, think patches have been released yet sorry ok, so I think references if you want to check some of those things any questions at this point please line up in front of a mic if you have a question mic one and so I agree with that I think and I stopped using it for a long time I think I began reusing it I think when nothing changed and in fact I think I was one of those people who thought things would change under Obama and there would be some accountability like if you torture people you're held accountable for torturing people and then that didn't so I agree we need a new term for that wait for the next one excellent this is awful does work? speaking of protection obviously Intel TXT is supposed to theoretically protect against these because to put trust into bios whatever but of course TXT is vulnerable to SMM attack so because you mentioned you spoke to lots of you speak to Intel and bios developers and other folks what's the state of the STM? your guess is pretty much as good as mine I've never seen one in the wild in fact I believe the specification is not even public yet right but I have heard that it's been at version 0.99 it can't go further so it's just like provision B, C, D, E and further so I don't really know what's up with the STM vaporware right now my understanding can you put mic 2 back on? 2? we ruled out TXT any other alternative protection you suggest? what do you use for your laptops? faith in god cubes mic 1 does this attack work regardless if you're using a modern system in legacy mode or ufi mode? so the race condition works no matter legacy or uefi because it's a problem with the underlying hardware itself but the boot script I'm pretty sure it didn't exist in legacy bios days but I can't speak to that mic 4 so the attacks that you demonstrated were using you needed to be able to either execute arbitrary codes in current context or you needed raw access to memory so in a situation where you have a requirement to sign current drivers or no ability to perform arbitrary DMA from user space do you have an attack that would still work in that situation? on one of the slides you mentioned get firmware variable is there any way to manipulate data via the uefi set variable interface that can still trigger these issues? so I'll answer that two ways one is that I did give a presentation a black hat that was only using the set variable API to get access to the firmware but it was doing a very complicated memory corruption vulnerability that honestly would be very hard to do in practice in the wild second answer to your question is you say that it's a requirement to have a release sign driver for Windows 8 for instance and that's true but as Joanna Rukalska pointed out back in 2007 if you're administrator in a Windows system there really is no barrier to getting into the kernel you just have to load a signed but vulnerable driver and then exploit it or you're seeing I was using read write everything on this system that's a signed utility that reads and writes everything so I mean do you have administrator access on a Windows system getting a physical memory access I don't think it's really a barrier do you want to have anything? Mike 3? Is it possible for the bias or uefi vendors to fix this vulnerability by applying an update? yeah, sure so the boot script vulnerability can be solved in two ways either using the logbox that we talked about and not screwing up things or you can just move the locking code before interpreting the boot script so both of these is fixable and we contacted the vendors about in August so at least some of them responded that they have purchased ready I can say too that we did receive some patches for evaluations from vendors that did fix the issue correctly but I'm not sure if they're publicly available yet so if you're like an IT manager for a large organization my recommendation is to contact your guy there and see what the deal is and see if you can lean on them to get those patches all faster last question Mike 4 assuming there's an uefi malware on the system can it self cloak against those attacks can it make itself invisible from those accesses say it again assume you have a malware on uefi mode very low can it hide itself from those probings from those reading those memory is the way it can make the system look normal and clean so you're saying once I have all this access in the bios can I load a trojan in a way that's not visible it can be done in millions of ways that's really not the subject of this way but you know generic responses use something like a blue pill you can load hypervisor very early and then wrap the whole system in the blue pill and then it's very difficult to detect that you're running in a hypervisor and again once you have this level of access it's at least cat and mouse game because there are millions way of hide your presence on the system there are millions ways of detecting them so that's difficult but the point is that you need at least to be aware that such a possibility exist that way of persistence is possible but that's topic for a totally different talk there's another some colleagues of mine did a presentation at Cansec West this past year that was basically using a bios implant and you can attempt to detect it by reading the spy flash but there's actually a hardware mechanism such that SMM can interpose on attempted reads of the flash and you can use this to fake out the attempt to read it you could try to detect that with timing stuff but then it gets kind of and finally I mentioned operation DET bounds so what they did was Trojan Biosys and gain presence in SMM so then operating system load but SMM also runs concurrent to it and it's still under attacker control and once you are in SMM you control all the operating system in a pretty stealthy way there was a presentation in Black Hat 2008 about SMM rootkits as well so it's fully applicable here again topic for a different talk well that was a deep dive and last round of applause for Rathong Corey