 So thank you. So I'm trouble Hudson and I'm going to be talking about Thunderstrike 2 which is a firmware vulnerability Or a set of firmware vulnerabilities on Macbooks You might have seen it in the press as you know the first firmware worm that affects Macs that it's you know super stealthy and backdoors them That it remains after reformatting and it can be remotely installed and it is undetectable and it can't be removed There's a lot of hyperbole in these sort of press reports But it is true that firmware malware once it's installed is very hard to detect very hard to remove And that's because it installs in the SPI flash on the motherboard also called the boot ROM and on most systems the SPI flash is really the root of trust. This is where all of Everything in the security of the boot process depends on the sanctity of the boot flash and Because this boot flash contains literally the first instruction the CPU executes when it starts up It's possible to circumvent any other software mechanism that attempts to ensure security So one other really important part about this talk is that Thunderstrike 2 is not a new vulnerability It's actually built on five previously disclosed multi-year-old UEFI firmware vulnerabilities that along with collaborators Corey Kallenberg and Zino Kova, we are able to port from commodity PCs to Mac systems And that is the real key point of this talk is that UEFI firmware vulnerabilities are Shared between these different systems because they share so much in common You might think that your shiny Macbook has nothing in common with some run-in-the-mill commodity desktop PC It has a different motherboard. It has different OS. It runs You know pretty much everything is different But under the covers they look very very similar that when you disassemble it We see the same sort of code paths. We see the same functions being called We seem the same vulnerability is appearing even though they're built with different compilers different optimization and frequently very different versions there's still a lot of commonality and The commonality goes back to the earliest days of the PC IBM's 16-bit real-mode BIOS in the early 80s was cloned by Phoenix and then everyone else Reverse engineered and cloned that one in 95 Intel started the extensible firmware interface project to try to support new CPUs bigger memory fancier hard drives and things and In the early 2000s when Apple switched over to the the Intel CPUs they Forked Intel's EFI standard and use that for their systems few years later Intel Transferred all ownership of EFI to the unified EFI forum and that's why it's called you EFI now and The forum has continued development adding a lot of features secure boot and other things and They continue development on this We can see that on Christmas Day there were commits being made to their code tree Some of these are security related you know a suspicious null pointer D reference Could be a security vulnerability So even after Ten years or so of divergence There's still millions of lines of code shared between Apple's EFI and the more recent UEFI firmware What most firmware vendors do is very similar to what Apple has done They fork the open-source tree at whatever version it is they kind of freeze at that head They port it to hardware platforms and they sell these packaged firmwares so when Intel fixes or excuse me when when the The EFI forum fixes bugs in the edk2 tree That doesn't mean that all the vendors have actually done a git pull and and and patched And even if they have fixed it on their new motherboards They haven't necessarily fixed it on their decades of legacy systems and even if they've Shipped a firmware update. There's no guarantee that users install it. Most people don't install firmware And this is an area where Apple has actually really excelled that they are actively pushing firmware updates for systems going back almost ten years When firmware security vulnerabilities are disclosed to them So that's enough of the history lesson Let's talk a little more about Thunderstrike 2 as I mentioned It's built on five previously disclosed multi-year old firmware vulnerabilities. These have been All the details have been published going back 2014 2013 some of them as late as I mean as early as 2007 This first one the speed racer was presented last year here at 31c3 by Cori Kallenberg and It is a hardware race condition that allows in a multi-threaded or Multi-core CPU Allows a second core to get right access to the BIOS And the reason for this goes back to again, you know legacy hardware The Intel Interface control hub was designed for a single threaded system. There is the BIOS write-enable bit that Prevents accidental rights to the firmware unless you're in ring zero There's the BIOS lock-enable bit that allows SMM to arbitrate writes The to arbitrate the BIOS write-enable bit when the bit is when the write-enable bit is set to one and SMI is generated SMM gets a chance to decide whether to allow it and if it doesn't want to allow it. It sets the bit back to zero But that leaves a race condition where the second thread Has BIOS write enabled enabled turned on for a few cycles and they can keep trying and trying to write to it Intel actually realized this was a problem in 2004 when they migrated to the platform controller hub and they added a third protection bit the SMM BIOS write protect disable in which all threads have to be in SMM in order to be able to write to the firmware So on a correctly configured system the write access to the firmware is controlled First by the protected range registers and then by the SMM BWP bit and then by the BIOS lock-enable bit Corey and his collaborators went through responsible disclosure and Disclosed all the details to cert and most of the firmware vendors were affected because they had not updated To use all of these hardware protection measures that the that Intel was providing Apple specifically said however that they were not affected So we wanted to find out if that was actually the case Going back to the data sheet we can read the BIOS control register, which is at offset DC in the In the hub and we can use a tool like a read memory, which is a open-source tool that lets you Read arbitrary physical memory on OS 10 and what we find is that it has the value of 8 and that means that Neither the BIOS write protect bit nor the BIOS lock-enable bit are set This is you know is not the recommended configuration and it turns out that a OS resident attacker is able to write a One to the BIOS write enable bit and now they can write to the BIOS They can't write to the entire BIOS because of the protected range registers But it does mean that they can write in Arbitrarily into the NV RAM variables. They can also write to any region. That's not protected by the protected range registers and If you corrupt with the that portion of the of the firmware it actually bricks the machine so that it is unable to boot We went through again disclosure with Apple and they rolled out a fix and it goes all the way back to 10 6 8 Which was released in? 2008 so that's almost eight years of Systems that are that are now protected and because Apple does the automatic rollout they these systems For the most part have been updated and are now protected One problem is that the fix was was just by changing the protected range register Which means that the SMM BIOS write protect is still not set And the BIOS write enable bit is still vulnerable to an OS resident attacker So only the protected range registers are preventing rights Which brings us to our second vulnerability the Darth Phenomus or dark Jedi coma attack also presented publicly for the first time last year at CCC by Rufal and some collaborators What they realized is that when the system goes into a S3 suspend to ram sleep All of the flash protection bits get unlocked and when the system comes out of sleep There's a brief race window that allows an attacker to have right access to the firmware As always they went through responsible disclosure and It turns out that Apple had was not contacted by cert regarding this, but they were informed through us RT to understand how to take advantage of this vulnerability we have to go back to the the boot script specification which Describes how the system How EFI goes through a normal boot and then when it resumes during a normal boot the system probes for connected devices looks to see what's out there and it writes a sort of a cheat sheet of memory addresses and and configuration registers into this this boot script and Then on a resume it just runs through the script right into those same addresses Not everything can be expressed in just a simple right So there's a dispatch opcode that gives you the ability to put in a function pointer So again, we can use the the read memory tool to read out the boot script which is actually the pointer to it is stored in a invi-ram variable and When we parse it we see a bunch of those memory writes and this right down here is the one that writes into the protected range registers and the flock down bit to to lock them, but that occurs too late in the boot script We've already had a dispatch to a function and because the boot script lives in unprotected memory we can Use the right mem tool to poke our own function pointer in there And then when the system goes into sleep, which is a user a user command The system wakes back up and those protected range registers are no longer protected which allows the OS resident attacker to write pretty much anywhere in the firmware for the the CPU which again It allows it to take control of the machine from that first instruction and circumvent any other chain of trust We again went through responsible disclosure with Apple and they In their notes said that a insufficient locking issue existed and it was addressed through improved locking So very brief commit log there There's an additional Sleep vulnerability that we didn't see but was also fixed in that patch OS X reverser also watched the CCC talk last year and Experimented on recreated it on his Mac book what he found was actually much worse that the the s3 implementation Left the flash protection completely unlocked after a suspend resume cycle As you might imagine, that's a bad thing And it turns out this is a rediscovery of a 2013 vulnerability called Snorlax In which Dell systems failed to properly set write protection after resuming from sleep And that was a team at MITRE that found that the reason that That we didn't see it in our tests is that Our slightly newer Mac books had a different Intel chip set and at some point there had been a silent fix that the either Intel rolled out a Improved reference implementation for that hardware or Apple fixed it But it meant that new machines were not vulnerable to this this issue but older machines were and No one publicly knew which were which There's a similar silent fix that happened with the the brand new Mac books the ones with the USB C Only that it appears to be using something like SMM lockbox, so they're not vulnerable to To the boot script hijacking So as I mentioned Apple addressed the both the Darth of Anonymous and the Snorlax or Prince Harming vulnerabilities through improved locking what they did is moved the The code that sets the the lock bits and the protective range registers to before the S3 script is executed But the S3 script is still in unprotected memory and available for an OS resident attacker to hijack They can't use it to Directly turn off the flash protection But there are other interesting interesting things that this lets you do prior to the OS kernel starting up Possibly get into SMM. I'm still looking into that So One you know with with the easy routes to get in the flash unlocked sort of taken care of There's one time when the flash is deliberately unlocked and that's during a firmware update so Corey Kallenberg Found a class of integer overflow bugs that he was able to write a scanner for that searched through lots of different firmwares and he found a That a lot of these vulnerabilities occurred When the flash was in a entirely unlocked state meaning during a firmware update one of the machines that he showed this on was a HP laptop and What's happening is that the The link there in the descriptor buffer is user controlled So it's possible to generate an integer overflow in that length, which then gives him good execution While it is parsing a firmware update so this is this is being run with the flash unlocked and Gives him full write access This affected so many systems that he won the pony award for best privilege at escalation at black hat earlier this year I As always Responsible disclosures really important and as you see almost everyone's affected except Apple Apple Claimed that because they don't use the standard UEFI firmware update routine They're not vulnerable to this to this attack Because they have their own firmware update routine if you're interested in that The Thunder strike one talk that I gave last year at CCC goes into Extensive detail about how how Apple does their firmware updates The problem comes that everything in UEFI is done via function pointers and these 128 bit GUIDs So when you want to call a function You pass in this GUID and it looks it up on a table and then returns a function pointer to you Which means that the linker can't Remove a lot of dead code because there's a reference to it in this in this dispatch table so the the vulnerable Firmware capsule update routine Turns out is present in Apple's ROM so even though Apple doesn't use this for for their firmware updates the code is still there and Through what what Cori and Zeno called BIOS necromancy They were able to generate a set of inputs that caused that code to get executed So, you know again two very different laptops But they share very similar code in that in that vulnerable routine Obviously they've been built with different compilers and different optimization levels, but you can see that the That integer overflow is still there as the result of Our work improving that and exclusion to Apple they have updated their status with cert and now a year after it was publicly announced they've they've admitted that they are affected and they have rolled out a fix The particular vulnerabilities actually kind of a very neat Wanted to look into that You know unused functions Can contain these vulnerabilities Legacy functions can contain these vulnerabilities and it becomes really important that when Code is being audited that both the new code and this legacy code Gets reviewed and gets updated So going back to another legacy feature one That goes back again to the 1980s so with the original IBM PC the BIOS at that time would Look on the motherboard to these expansion ROM sockets to see if any optional features were installed Things like the basic interpreter a hard drive controller It would also look on the expansion bus to see if any cards were installed like a video card so that it's able to Display the the boot messages as the BIOS starts up Unfortunately, this code is run in the BIOS in ring zero before the kernel and that's really a bad idea for security John Heisman in 2007 showed how this could be used to get persistence on On servers with certain network cards snare in 2012 showed how Thunderbolt is actually PCIE and it loads option ROMs off PCIE My talk at last year at CCC showed how you could use an option ROM to During a firmware update to get code execution with the unlocked ROM and then earlier this year as you know, and I presented a class of vulnerabilities at defcon Related to all these five that have been fixed Following CC's the disclosure at CCC Apple rolled out a fix that Partially addressed the Thunderstrike one issue what they changed is that the system no longer loads option ROMs during firmware updates, which Prevents Thunderstrike from getting code execution During during a firmware update, but it still gives you a way to get persistence and code running on the system There was a follow-on update a little bit later due to a rollback vulnerability And even with this patch applied as I mentioned you get code execution during the boot So if you have a Thunderbolt adapter, these Thunderbolt Ethernet adapters are super popular for this sort of research It runs before the kernel starts and it's able to log keystrokes such as the firmware and Fileval password there It also gives you a way to get persistence. So if you get a remote shell on a system You can map all of our physical memory look for PCIe devices Write your code into the option ROM on it and the next time the system boots that code is going to run This is almost as good persistence as the SPI flash It doesn't necessarily give you The ability to circumvent all of the root of trust because option ROMs are loaded much later in the boot process But it still is a very dangerous thing to to let happen Earlier today Johanna Votosko presented Something showing how much writable state there is in the system and it's really scary. How many things have writable firmware blobs You know your fancy Thunderbolt monitor has an option ROM in it Your SSD might have an option ROM in it So Intel realized this was a huge problem and For the secure boot process they required that option ROMs be signed Unfortunately, Apple has not updated to a version of the system Updated to a version of UEFI that supports secure boot. So this is not an option on on Apple systems It's also not an option if your system doesn't support secure boot and If someone gets the ability to write to the firmware flash on the motherboard secure boot won't do anything for you So But the key point is these are all cross-platform Vulnerabilities that were found on commodity PCs and we were able to port over to the To the Mac platform You know, most of them are patched at this point by Apple I've heard that the new iMacs and some of the newer systems are no longer loading option ROMs, which I think is great and Usb-c doesn't have option ROMs yet, but maybe Thunderbolt 3 will bring option ROMs to usb-c. We'll see so You know all these vulnerabilities are They're interesting. I'm glad we've got them fixed But it was really fun to package them together into a proof of concept demo. So let's let's see How could this all come together? So unlike last year It actually can start with a Just a like a software exploit. Maybe a software download or a Adobe flash Sandbox escape or something that then can escalate to root with whatever the root exploit of the day is And once it has root it can install a kernel module to let it go walk through physical memory if the system is subject to Prince Harman, it's able to immediately write malware into the motherboard boot flash It can also then search the PCIe Space for devices with option ROMs and write itself into them and in this case the you know It found a thunderbolt ethernet adapter. So I go ahead and flag that that one's infected and Now the next time the system reboots the Thunderstrike 2 proof of concept is going to be run from the motherboard boot flash It's not trying to be stealthy or anything like that. So it displays big splash screen and logo and Because this runs before the OS 10 kernel has started it can do pretty much arbitrary things It can get into SMM. It can hide in virtualization. It has you know total control of the system at this point if you Reinstall OS 10 it's still there you swap out the hard drive. It's still there Because it's you know, it's literally in the motherboard so you know if we put the infected system aside and But we and plug that infected adapter into a clean system When this one boots It loads the option ROM off the off the Thunderbolt adapter This is a newer laptop that is not subject to Prince Harman So it can't directly write to the flash, but it can use Darth Phenomus to hook the s3 boot script And I don't if you can see it also reports my firmware password on there And then the system continues to boot normally When the system goes into an s3 sleep such as when the lid is closed the CPUs are going to shut down and You don't have to open the machine I've just done that to show that the the fans have turned off the CPUs are completely powered down when the system wakes back up the The s3 script is executed prior to the boot flash being locked So it's able to write itself into The boot flash on the motherboard and again, I just flag it so I know which ones I've infected for cleanup afterwards So from the perspective of the the user of the system it took just a couple extra seconds for it to come out of that sleep mode But you're nothing out of the ordinary So in the next time this system reboots. It's going to also display the the boot screen Logo, so we've now you possibly You know infected another machine via this sort of viral transmission And what's interesting is this didn't touch the the OS at all. This was completely At a level below the operating system One of the other things that Thunderstrike 2 proof of concept does is it watches for the PCIe hot plug event? So when a when a clean adapter is plugged in it detects that The interrupt handler writes the option ROM to the device so this allows it to potentially spread and potentially cross air gap security measures and so if you have a Uranium centrifuge plant that you're trying to get into this might be one of those ways to do it so The proof of concept is showing a really neat sort of lifecycle for this kind of malware going from You know software exploit that's able to escalate into the bootflash or the option ROM Hook s3 get into SMM and then go on and infect other machines in the bootflash And once it's in that sort of bootflash option ROM kind of space It's completely underneath the OS so most by virus scanners aren't even looking for it And probably couldn't even see it because they have the ability to trap all of those memory references and hide from Normal scanning techniques Pretty much the only way you could see if it's in the bootflash would be to put a chip clip on the on the All in the SPI flash there and read it out and hope that nothing's interfering with that Any attempt to do in software is going to be masked by the by them the proof of concept so Johanna presented a lot of ideas about things we could do to Deal with the inevitably inevitability of root kits and firmware issues You know attempts to try to move it outside the system, but there are a lot of smaller steps We can take as well Things like checking the signatures on the option ROMs or not even loading option ROMs is a really big first step Using all of the locks that the platform provides You know is really key Making sure that the BIOS is not writable to OS residents attackers making sure that they can't hook the S3 boot script to get into SMM You know Intel has added features to UEFI like the SMM lockbox that allow the S3 boot script to be protected from attackers and there are tools like chip sec and Copernicus that can help validate these configurations to make sure that the systems are being booted and run in a safe manner Intel is also continuing some hardware attempts some of their newer CPUs have a feature called boot guard and This adds actual ROM for the first instructions the CPU executes Which is sufficient to do a cryptographic Verification of the boot flash before executing any code out of it This is great for security, but unfortunately this locks out free software developers. So systems with boot guard are not are fundamentally incompatible with with core boot and There's that's a really difficult move for for software freedom even if it does provide a good level of protection and my plea to system vendors is that when new vulnerabilities are disclosed that To really work with researchers to try to figure out if they're vulnerable I write a lot of proof of concepts and they're really difficult to get working on one machine much less a range of machines So sometimes vendors take the proof concept. They run it on their system. It doesn't work and they say oh, we're not vulnerable and there's really not any Risk to them for doing that So, you know, it would be great if vendors were more proactive and working with researchers on Helping to port these things and find that out The legacy code, you know as Corey found there's a lot of code dead code in EFI that may have vulnerabilities and even if You think that your system is not running it. It might be possible with a set of inputs to to get the code to jump into it It's super important to test the full cross cross product of old vulnerabilities and Systems that things like Snorlax being an old vulnerability that reappeared a few years later It's actually really kind of scary. You know that there was we learned about a really serious bug and Systems got fixed and then new systems got produced that were still vulnerable to that old to that old bug that that's a problem likewise new vulnerabilities Might a lot of times they don't necessarily get tested against order systems. So we don't know what Machines are actually vulnerable other than the current generation of machines and You know, please if you are in an opportunity to to fix security vulnerabilities Don't just do it silently make sure that people know, you know, these are the CVEs that are being patched against these are the things that that are being changed and what Systems will actually be secure against because when we're in the dark with this. It's really dangerous. We don't know if we're going to You know just because my machine is two years old and you've got a newer machine. It's dangerous for for For us to not have that certainty so On that I love to open up for some questions There's a lot more details about the vulnerabilities on my website. I'm also happy to take a GPG emails and You know continue the discussion on these firmware topics Thank you Not for you guys, but for the people out there in the stream So we're gonna do a little question talk And we'll do one question from the room one question From the web and then again a question from the room. So are there any questions out there? Yep Mike three, please Yes Have you seen actual? SPI flash erase commands going to your flash chips or how how is it actually managed on the background? with different SPI flash chips Are you asking Does the OS periodically do erases of some sort? Well, how the because to write to flash You also have to erase flash first before you can write to it, right? That's right So for things like the the in VRAM variables and this There's a related question of why does Apple leave the flash writeable and they store in view the non-volatile variables in in the flash So things like what is your screen brightness? What it was the last Wi-Fi network and credentials that you logged into are stored in the in the in VRAM and It's stored in a In a log a pin structure So you can add items to it and then they can set individual bits to mark To tombstone old values and once they fill up a block then they They will do a full erase rewrite cycle, but typically they just do A pinned and then a tombstone marking Okay, and do we have a question from the internet? Is there anybody out there? Yeah. Yeah, go ahead How is boot guard related or different to the trusted platform module? So the trusted platform module is unfortunately not It assumes that the SPI flash is protected that the trust in platform module is outside the CPU so and it only Signs or it only generates hashes based on what the CPU has asked it to do so if you have malware that has taken over the SPI flash it is able to Send whatever values it wants to the TPM that the TPM can't look at memory The TPM can't look at the state of the CPU the TPM only hashes. What's given to it? So boot guard moves the trust inside the CPU so it's no longer having to go to this outside device and Because boot guard doesn't even start executing code from the flash until it verifies it. This means that A malicious attempt to modify the flash will be detected or will be Detected on the next boot You know for sure I don't remember if they have the sort of soft fail versus hard fail in the boot guard implementation but yet the TPM unfortunately was a An interesting idea, but there's probably a dozen or two dozen papers on how to defeat it and get around it in different ways Okay, the next question from Mike three I I Have had my own share was Reporting bucks to Apple and getting some feedback and making sure that they actually fixed it the way that I thought it should be fixed or but I see that You seem to have that in a repetitive pattern that they thought they fixed it. They didn't Consult with you and they released the fix and then you found out. Oh, no, it didn't work. Is that kind of I mean Is I would expect that this is such a sensitive area where what where Apple would really want to have a dialogue with you Did that never happen or was it miscommunication? On some of the bugs they there has been a good dialogue and we've had they have sent me betas to test And we've had back and forth occasionally things have been put out before we've had a chance to do that and sometimes Yes, sometimes the dialogue takes takes longer than they want to To wait for the fix although I do have really good hopes They've just Acquired as you know and Corey's company like the core So I'm really hoping that this means that Apple's former security is going to go even better than Then it's been in the past few years One more question from the net No, do you have a tool to check the current state of the MacBook like is if it's vulnerable or not the difficulty the difficulty with ascertaining if the system is currently vulnerable or currently infected is that a A Sufficiently stealthy malware can trap all attempts to read the ROM and read the state of things So if it's been able to infect the system, it's very very difficult to even tell if that's happened tools like chip sec will attempt to tell you if the system is in a vulnerable state and That's one way to say if you with a clean system, you know, you can check to see if it's It whether or not it looks like it's good, but if you've had a system that you think has been infected It's very difficult to say Okay, is there one more question from the net? Otherwise we're gonna call this a baby Okay, there's one more question from the net What platform would you would you recommend to avoid? You if EFI boot systems and which are nearly as compatible to our normal computers Well, you EFI is making its way into the arm world now So I'm not sure if it's possible to avoid UEFI in its entirety The you by itself it that's somewhat of a good thing. It is extensible. It is nice to have a lot of that functionality But it is a huge amount of code in the trusted compute base and you know as Missecurity researchers will tell you that that is problematic But at this point it looks like all the hardware is going to be UEFI in the foreseeable future I do have good hopes for things like bunny's laptop Open-source hardware laptop with entirely open-source firmware Because that at least means that we're not running a bunch of Proprietary binary blobs things like the Intel management engine are you know, certainly You know it's we just don't know anything about what's going on inside of it and what it might be doing so Even if you have secure firmware You've got a binary blob running that might be doing something that you don't want and that's a somewhat of a difficult situation to be in Okay, let's have a final hand for tremel