 good morning everybody. How are we feeling? Good? Yeah. Nice. Nice. If you think you feel like crap now, wait until tomorrow. So a quick programming note. We know, we absolutely heard about all the problems in the hallways yesterday and you notice we made a couple small changes yesterday that I think seem to improve some things. We made another kind of substantial change today. So what we did was Defcon 101 that has moved to Bali's gold. So over at the other part of the hotel. Track 4 moved to where 101 was and then if we do need to corral all of you fine folks, we will probably be doing it in the area where track 4 used to be. Make sense? Cool? So hopefully that will make the congestion problems a lot better today. But that said, hey, keep cooperating. You guys were great yesterday especially for some of the big talks like the Tesla talk and I'm sure we're going to have some talks that are just jammed in here. So keep playing along and we'll all have a good time. Right? But hey, let's talk about Mac. How many people in here are up Macintoshes? It's nice hardware. It's nice hardware. And depending on who you ask, some people may have a nice sense of oh, I'm so safe because I have a Macintosh. That kind of thing. Well, we're going to learn once again why that kind of idea is false. And we're also going to reinforce the rule of and say this one with me, physical access is total access. No? All right. It's early still I guess. All right. Let's give our guys a big hand. So good morning. As Argyon alluded to, we're going to be talking about MacBook physical security, but also some software security. So I'm Tremel Hudson and I really like to take things apart. I've been doing a lot of work in reverse engineering, things like the camera firmware for Canon SLRs. I've produced a GPL runtime to let folks write their own programs to run on it. I also really enjoy digging through old ROMs, looking for Easter eggs such as the Apple team that built the Mac SE that they hid in their ROMs back in the 1980s. And this project got to start a couple years ago when my employer, Two Sigma Investments, a high tech hedge fund in New York City, wanted to deploy MacBooks. And there had been some reports about root kits and I was asked to use my reverse engineering skills to look into if it's possible to defend against them. Because we have a lot of concern about security both physical and software. Hi, and I'm Zino Kovac, Corey Kellenberg couldn't be with us this year at the cons. But this past January, Corey and I started Legwood Core and we're basically the only company that's focused specifically on PC firmware security. So firmware for X86 PCs, Macs, and then all the peripherals as well, all the hard drive firmware, NIC card firmware, GPU firmware, all that other stuff that people talk about at conferences, but nobody ever seems to get around to actually checking. That's what we do. So this talking sort of got its start last year at CCC in Hamburg. I presented Thunderstrike, which I suppose we can now call Thunderstrike 1, which was the first firmware root kit for MacBooks that we learned how to, what protections Apple had on their firmware and how we could generate files to write into the ROM. The day before my talk, Rafale and Corey presented some really amazing attacks on UEFI security, including one called Darth Phenomus that I found very interesting and really wanted to see if it was possible to port it to the Mac. So we teamed up and what we found is that yes, it is possible to port vulnerabilities from Windows systems to Macintosh and other systems. And that's the key message of this talk is that these most EFI vulnerabilities, many EFI vulnerabilities are OS independent. They're in a lot of cases hardware agnostic and that vendors and everyone needs to be aware of that. So that's enough talk. Let's jump straight to the demo. So Thunderstrike 2 is an improvement over the original Thunderstrike in that now physical access is no longer required to initiate the infection. It's possible to, with a remote code execution that can then use whatever root exploited the day to escalate to root. Once root, it can install the white listed direct hardware kernel extension, which allows it to map all of the physical memory, including the memory mapped SPI flash registers. On some machines, on some Mac books it's able to immediately unlock the flash and start writing into it. And this is using the information again from the Thunderstrike 1 talk about how are the firmware volumes organized? How are they integrity checked? So in this case we've added a, we've appended a payload into the free space and we've updated the CRC. While we are scanning memory, we also go ahead and walk the PCIe bus looking for devices with option ROMs. And we're able to write the payload into those as well. In this case, much like Thunderstrike 1, we're using the Gigabit Ethernet adapter as a payload transmission vector. So the option ROM now contains the payload and the Mac book also has written the payload to the motherboard boot flash. When we reboot the machine, we will see the Thunderstrike logo come up. We are deliberately not trying to be stealthy with the proof of concept. So there's our awesome ASCII art logo hidden in the boot ROM. And this is controlling the system from the very first instruction that it executes. The viral transmission means that we can put that laptop aside and share the adapter with another one, which is pretty common in a lot of corporate environments. So now the EFI firmware loads the exploit from the option ROM. And it's not able, in this Mac book, it's not able to unlock the flash immediately. But what it can do is use the Darth Phenomys attack that was presented at TCCC by Cori and Rafal to hook the S3 resume boot script. So then when the kernel boots normally, and then at some point later, the system goes to sleep either via software or just the user closes it. And the vulnerability is that when the CPU enters the low power state, all of the flash protection bits get reset. So when the system wakes back up, the S3 script, which is executed on resume that we have injected code into, writes thunderstrike into the motherboard boot ROM. And this is not in, this is not on the hard drive. So you reinstall OS 10 and it doesn't fix it. You swap out the hard drive, it doesn't fix it. And possibly when you swap to a new computer, you could re-infect through the peripherals that you retain. So at this point, as I mentioned, we're not stealthy. So when the system reboots, we'll see the logo. A weaponized version could use SMM or virtualization, similar to the blue pill attack from a few years ago, to really do a good job of hiding from attempts to detect it. So this laptop's now infected. And the other part of the infection that's new is that it's watching for clean Thunderbolt adapters to be plugged in. And then it writes the exploit into those adapters so that they can then continue to spread to other machines, possibly crossing air gap security printers. So what we've demonstrated with this proof of concept is a somewhat unique life cycle for a firmware worm that starts with a software exploit, is able to write itself into the boot flash on the motherboard. They can then infect Thunderbolt and other removal option ROMs, which are able to hook the S3 Resume script and then write themselves into the boot flash of other machines and continue the infection. Right? So that's the black magic attack here, but now let's get into understanding how it works, right? So the key point, again, is that firmware vulnerability is found across many systems. When we disclose things in the past, they would affect many different PCs. And here we're showing the effect max as well. A little quick background on the transition of firmware on modern systems, right? So you'll hear about, you'll hear us often use the term BIOS interchangeably with EFI or UEFI. When we say BIOS, we just mean generically firmware. But firmware for X86 PC is typically. So Intel started the EFI extensible firmware interface project back in the late 90s to replace BIOS. So they were trying to create a non-backwards compatible IA64 architecture. They said we want to get rid of all this legacy croft you don't want to keep working on this, you know, thing from the 80s. And so they said, okay, for our new architecture, we're going to have a new modular, well-designed version of the firmware. So they did that. They did that on their itanium systems. And then when Apple first moved from PowerPC chips over to Intel chips back in the early 2000s, they said, okay, we'll go ahead and use this new type of firmware that Intel recommends. That was the Intel EFI one point, you know, whatever version. So in 2005, Intel was trying to bring more people in the fold, get wider industry adoption. So they created the UEFI forum as a sort of industry consortium to collect up many more players, get all of their buy-in, get all of their contributions, and get them to actually start using this. So the original EFI one point one was deprecated and now everybody was talking about UEFI and the EDK development kit, the EFI development kit. So of course, when they got more industry buy-in, they didn't just go ahead and rewrite everything from scratch, right? It just meant they continued to evolve with more people's input. So Apple forked it back at the one point one and you would expect Apple's implementation to generally diverge from the rest of the world and the rest of the UEFI implementations. But still, there's of course going to be millions of lines of code that are similar from the old stuff and the new stuff. The way that the whole UEFI ecosystem typically works is that there's a single open source reference implementation. That's the EDK 2, the EFI developers kit 2. Single reference implementation which is then modified by the independent BIOS vendors like AMI, Phoenix and Inside. They go ahead and add value to the systems, right? They have to compete amongst each other in order to say what new features they've added that the other guys haven't added and that's how they're going to get OEMs to buy theirs. And then the OEMs buy and maybe manipulate if they've got enough BIOS engineers themselves. The OEMs will do further customizations on this and then that's what we ultimately see. But because of this hierarchical nature, you know, that means fixes that happen, the open source reference implementation take a long time to trickle down, right? Months and potentially years. So a big point of this talk is to be, look, no one's a unique and beautiful snowflake. Everybody looks the same. So we took a, you know, ASUS machine that we did with our CanSec West talk, we did an analysis we showed, you know, here's all of these places where an attacker could hook all of, all of the systems that are out there today. And we took that, we analyzed it and so its control flow graph picture is a little bigger because it's got comments in it. But then you take a ASUS desktop and you take a MacBook Air, Ultrabook if you will. And the thing is they look all the same, right? Their control flow graphs look the same. They call the same functions in the same order. There has to be some level of similarity in order for EFI or UEFI systems to implement that extensible firmware interface, right? There's a spec out there that says how the firmware interface works and to conform to that you have to look the same. So, you know, call the same functions in the same order, have the same assembly in the same order. No one's system firmware if their EFI derived is unique and beautiful snowflake. So that means that there's going to be shared vulnerabilities, all of the stuff that we've been disclosing over the past couple of years for PCs, you know, does it affect Macs? Well, spoiler alert, yes. Right? So, this means that there's all these vulnerabilities which are out there and a lot of vendors don't necessarily pull in the code and the fixes from upstream and they don't necessarily they hear, oh there's this PC attack, maybe it doesn't affect me, right? I'm a Mac. So, beyond this there's problems such as Intel has recommendations about protection mechanisms that vendors should use and not all the vendors use those. Beyond that there's still these decades of legacy decisions and things like option ROMs which we'll talk about later which lead to sort of inherent built-in vulnerabilities. So, we considered a bunch of different vulnerabilities, you know, we took a bunch of old work and we said, you know, do these apply to Mac? And so all of these should be old news at this point, right? These are all things which were responsibly disclosed over the last couple of years, publicly disclosed at conferences and yet when we came along and we said, let's take a look at the Mac, are they still there? Yes they are, right? That's not cool. So the first thing to think about is the speed racer vulnerability. This is actually vulnerability in Intel hardware. So this is not the kind of thing which we would expect any given vendor to say I'm not vulnerable to because if you're running chips the core vulnerability is in Intel hardware and the core fix is to use some Intel protection bits. But speed racer is going to be a race condition, a hardware race condition and that will see, you know, why exactly that happens. So if you look at the BIOS control register on Intel hardware, this is sort of the oldest protection mechanism for the firmware. It says, okay, am I allowed to write to the BIOS? There's a BIOS write enable bit that must be set before you're allowed to write to the BIOS. Now, if a vendor wants to stop any malicious OS attacker from writing into the BIOS, they need to set the BIOS lock enable bit. BIOS lock enable bit says, if someone sets the BIOS write enable bit, I want to cause a system management interrupt. I want this code that I've put into SMM, system management mode. I want to catch anyone trying to set the BIOS write enable and I want to probably stop them from writing into the BIOS. So that's the oldest most common functionality. But what the speed racer vulnerability disclosed is there's this hardware race condition where once we have multi-threaded hardware, right, so back in the day, that was just single threaded hardware, single core hardware and so that protection mechanism worked great. Once you have multi-threaded, multi-core hyper-threaded type hardware, you can have an attacker who just continuously hammers on the write enable bit. They say set it writeable, set it writeable, set it writeable. And then in a separate thread, in a separate core, they continuously say write this value to the BIOS, write this value to the BIOS, write this value to the BIOS. And so the core race condition is those two threads continuously are just hammering on trying to write to the BIOS and eventually we found that they're always able to succeed. This is the kind of race condition which an attacker likes, right? There's no penalty for failure and beyond that you just keep doing it long enough and you're always guaranteed to win. So Corey talked about this back at CCC in December 2014. This was disclosed privately to Intel and CERT in May of 2014 and so this has been out there for quite a while. So Intel's sort of response to this was okay, well we recognize that that could potentially be a problem but we had already added this new protection bit back in 2004 to our newer platform controller hubs and this new bit says even if the BIOS write enable is equal to one somehow, I still want to stop an attacker from writing into the BIOS unless they've broken their way into system management mode. So this bit says you must be in SMM before I allow you to write to the BIOS. So that requires an extra exploit, an extra bit of effort on behalf of the attacker. They can't just race from kernel space and set and write to the BIOS. So this is basically the way that Intel says it should be. This is the way Intel recommends that BIOS vendors actually set their protection bits. So you've got layers of protection each of which provides some architectural value. So BIOS lock enable says system management mode they get to man the middle every attempt to write to the BIOS and that will be stopped and checked. Well that's the problem with that is speed racer bypasses that. But if a vendor sets SMM BWP then that will also say you must currently be in SMM before I'm going to let you write to the BIOS. And beyond that there's further protection mechanism called protected range registers. And these allow the BIOS maker to set non-contiguous slaces of the firmware as non-writeable. And typically a firmware maker would set the code as non-writeable even from SMM. They basically say lock it down and this is the kind of thing where it would be locked down and you want that to be stopping an attacker in SMM from writing into the flash chip. So when we go back and we said okay let's consider this let's see whether or not this is Apple's vulnerable. First thing is we check the cert vulnerability disclosures. So the nice thing, the really nice thing that we like about cert vulnerability disclosures, the reason why we used cert for our coordination even when we were at MITRE and even when you know we had CVs available to us is that CV just tells you these vendors are vulnerable and they've you know set their vulnerable. The cert ones are nice because cert handles the coordination for you and then they go around and ask the different vendors are you vulnerable and they get back responses. So there's going to be some vendors that say they're vulnerable and then usually they'll be a fix to their a link to their fix on the cert disclosure. And then there's some vendors that say we're not vulnerable and then there's vendors that don't say anything at all and you can probably guess that they're going to be vulnerable. If they don't even care enough about firmware security to respond to vulnerability disclosures they're probably going to be vulnerable. So we looked at Apple. Apple said it's not affected. Okay well this is a fundamental hardware race condition. All the Intel CPUs have this so that bears investigation. And like I said you know if vendors don't actually respond to these and if you don't hold them accountable if you don't say hey I saw this talk about whatever are you actually vulnerable they just aren't even going to say anything. So we need to check Apple. We need to say is Apple vulnerable to this problem? So you go in you look at the BIOS control register. The BIOS control register is set to 8. I won't make you do the bit math in your head for that. But the basic result is BIOS lock enabled not set. SMMBWP not set. Right so they're basically not using those first two layers of protections. So in a very technically accurate you know pedantic sense of the word Apple is not vulnerable to speed racer because you don't need to use an exploit to get around protections that just aren't there. So this is what protection looks like on a new Mac system. I bought I went out bought the absolute newest Mac mini and this is the protections I saw. So you see they're not even using the first two protection mechanisms so that means they've got a single point of failure. Right and beyond that there are gaps. There are gaps in this region. The first gap points at the EFI variables. If you use the command line tool NVRAM you can twiddle NV variable bits. But even some variables are prevented from being accessed by NVRAM. But if an attacker knows how to write to the flash chip they can just bypass whatever Apple's API is to writing to the variables. Write directly to the flash chip and modify any variables that they want. Beyond that there's an additional sort of gap in this protection which we don't even know what that does. But as you know testing this sort of attack we go ahead and we say all right corrupt that. Write all X's into that and let's see what happens. Well what happens is the system is bricked it will never ever boot again. Right and that's undesirable behavior. So there's a video for that online which you can watch but it's kind of hard to show a cool demo video. Look the system does not boot it's just a picture of the system. So we decided to skip that and you can watch that video online if you'd like. So second thing we need to look at. Darthonomus vulnerability. Got a goon crawling up here. I don't know what he's doing but okay. So Darthonomus vulnerability right. So we saw that the protection mechanism still have the protected range registers. Attacker would like to get around that modify the code and stuff. And so that's exactly what the Darthonomus vulnerability allows an attacker to do. Sometimes called the dark Jedi attack. This was named by Rafaal Wojcik because basically Darth Plagueis defeated Darthonomus, killed him, put him into this and then continued to resurrect him and then kill him and resurrect him and kill him and resurrect him. I'm not you know I don't know the exact story and consequently it's been said that this is just like you know putting maybe he didn't kill him he put him into coma that sort of thing but the analogy here is that we want to continuously kill and resurrect the system and use it to study the system find vulnerabilities for science. So the Darthonomus vulnerability is the situation that when you put your system to sleep just normal sleep not a hibernate not a what does apple call it deep sleep. If you just put the system to sleep close the lid. You're going into what's called ACPI S3 sleep this is a low power mode where the hardware tries to power off as much of the motherboard as it can. Well some of the stuff that it powers off is parts of the chipset which allow these protected bits to become unset right you're going into low power you lose all of your you lose all of your electricity and the bits get unset right and so this can be manipulated by an attacker. So this vulnerability was disclosed to CERT and the newly formed UEFI security response team back in September of 2014 and then this was publicly disclosed in December of 2014 as Trammel said day before his talk and you know wanted to find out whether this applies to apple. So very very quick you know I recommend you go watch the actual talk if you want to know the details but at the highest level the details of Darthonomus or this. A normal system when it's booting is going to take that top path there. The normal boot path you're going to execute each of your UEFI or UEFI phases. As the systems booting it's going to save information about which hardware configuration bits it set to this little cheat sheet this is boot script this S3 boot script which is going to be stored in RAM somewhere. Well unfortunately it's stored in unprotected RAM that's the core of the vulnerability but when you go into sleep and you wake back up the resume execution path is going to say instead of executing all of my normal boot code which would make my resume from sleep as slow as a normal boot. I just want to consult the cheat sheet and it will say you know it has these type of operations you can write to IO you can write to memory and so you basically just go down the line and interpret this boot script and that will make it so that the hardware will be reconfigured the same way it would be with a full boot but much much faster right that's why you have the nice quick wake from sleep. But there's a core problem with this boot script core vulnerability the vulnerabilities are two fold one the script gets stored in nonprotected RAM and why does it get stored nonprotected RAM well because you look at the spec document from 2004 and you can see right there they're recommending storing it into this ACPI nonvolatile memory well the thing is that memory is just memory like any other memory an attacker can manipulate it compromise it. When they go to manipulate it there's this one sort of catch all opcode there's this dispatch opcode the dispatch opcode says whatever I need to do to configure hardware it's too complicated for just you know combination of reads and writes things like that so instead I'm going to jump off and I'm going to jump to some arbitrary code that's pointed to by the dispatch opcode. So a script that has jumps to arbitrary code plus an unprotected script somewhere in RAM means that attacker can compromise the script get rid of the protected range registers and have access to everything you know get access to the code modify the code so that right from the very beginning all of the code is compromised by the attacker. So that's the net result of the Darth Phenomus attack. So when we go back and we say you know did Apple say they were vulnerable or not vulnerable look at the cert disclosure this case this particular disclosure unlike all of our past ones was a little weird in that we saw cert had been listing only the affected vendors only those vendors that replied and said they were affected so at first we didn't know you know did Apple say they were not vulnerable did cert not actually contact them but by running it to ground we found out that cert hadn't actually contacted them and told them about it. Well that's fine but it was still also coordinated through the newly formed UEFI security response team and since Apple is a UEFI board member you would expect them to listen to the UEFI security response team right. So again the big finding from Darth Phenomus is the fact that previously Trammel's attack was the first thing that showed and proved that you could write Apple firmware there had been you know snares earlier 2012 attack there had been some thought that maybe Apple firmware was somehow protected by extra hardware something like that. Trammel showed no that's not the case you just need to know how to fix up CRCs and things like that and once you do that you can write to it but again Thunderstrike 1 required physical access with the Thunderstrike the Thunderbolt device itself. So Darth Phenomus says you know no more physical access is required anyone who can get remote access to the system can manipulate that script in memory and then make it so that when you go to sleep and wake it back up you can compromise it. Now sorry that this is so small that no one who didn't sit right up next to the projectors is going to be able to see that but the basic this is showing you know just a plain Jane software attack version of this. So once you've used a root privilege exploit you can look and inspect the system right. Inspect the system it does have protected range registers they are protecting the code but then you find the boot script in memory you find one of these dispatch op codes and you point it at some other address where you're going to put code. So point it at a different address insert code into that address and so the specific code we did here was to set a lock early so basically the boot script is going down down down and it's interpreting stuff. The protected range registers get set somewhere lower in the boot script somewhere higher there's going to be this dispatch op code and so all we do is we just lock down the registers and say no one is allowed to modify these protected range registers in so doing they get locked into a default zero value that they had when they got cleared because you lost power. Right so when we do that then you set it to sleep then you wake it back up there you go after wake now the protected range registers all zero locked in can't be changed until the next you know sleep resume cycle. So after that right we've just taken out protected range registers Apple doesn't use bios lock enable or SMMBWP that means you know go to win the attacker can write anything into the firmware here we just showed writing hello world into the firmware some place we knew wouldn't actually brick the system. So another vulnerability very similar to this that you may have heard of a couple months ago is called Prince Harming. So we'd actually seen this vulnerability in the past in other vendors called it Snorlax and told CERT about it back in 2013. Unfortunately the vendors fixed it before we told CERT you know you can make this live now it's been you know fixed and then CERT said well it's been fixed we don't need coordinate this anymore. So they kind of wouldn't post our thing for a long time until Pedro Velaca came along this past May and he found the exact same sort of vulnerability on apples. Right so Pedro came found the same vulnerability we said dear CERT you can you can start coordinating this now it's open zero day again. So Pedro didn't give it a name but you know he didn't want to go the hype route but Katie Mo suggested Prince Harming because this poisoned kiss wakes you from sleep so we're going to go with that. So his blog post said basically he had seen literally he had seen the title for this talk he saw Thunder Strike 2 Scythe Strike right and he correctly caught you know the implication of that Scythe Strike probably has something to do with Darth Venomous right we're probably saying Thunder Strike, Max Stuff, Darth Venomous, Scythe, Darth Venomous right. So he said he had been looking into the Darth Venomous attack on Max and he had been you know using some other proof of concept code that was put out there by another researcher to look into it. When he looked into it what he found was this Prince Harming vulnerability which at the end of the day was actually a little more severe than Darth Venomous because you didn't have to do anything special as an attacker you just put the system to sleep you woke it back up and everything was unprotected they were just not even setting any of the protection bits that matter on resume. So this you know he was a little concerned about this as a Mac user I was a little concerned about that as a Mac user it leaves something to be desired when an attacker can just sleep your machine wake it back up and right into your firmware that's not good right. So we had not actually reported the Prince Harming vulnerability to Apple why not because we were testing on our MacBook Pro 11 2's which turned out to not actually have the vulnerability so Darth Venomous Prince Harming was actually fixed at some point. His 10-1 had it our 11-2 didn't have it so Apple basically silently fixed this at some point and they didn't back port it to older machines. So consequently what that meant was accidentally this blog post went live he thought that we had told Apple about it he thought that Apple would already know about it because of disclosure of Darth Venomous but no Apple didn't know about it so oops Apple zero day now anyone can break into the firmware right the core question is why are there zero days just laying around to be found like this on Apple that doesn't make me happy as a Mac user sure that doesn't make you happy. So now that there was a full disclosure vulnerability out there in the wild right Apple turned around a patch relatively quickly. So basically they put out this EFI security update 2015-01 it affected they patched 24 different models and the models which they patched were basically everything from 2011 and newer so if you have a system from 2011 or newer right hopefully you're just applying Apple's updates as you go. But how did they actually fix this right? So they fixed this with improved locking and so the question is you know what is that exactly mean? So I was very curious you know what is this improved locking so I did a binary diff and dug into their update and what I found is that they've moved the protected range register and flash lock down configuration register setting out of the boot script and they lock it in PEI before they begin executing it and this is this is the right place to do it because you don't want the protected range register to ever unset. So this does prevent the demo that we showed from being able to write directly to the boot flash. However they're still not using the BIOS control bits so it's still possible to break the system. The S3 boot script is still unprotected so you can do all kinds of interesting stuff in PEI long before lots of other protection is enabled. There's also some obscure features like TSAG MB that were discussed in the original Darth Phenomus attack that are left unlocked which means that it's possible to DMA into SM RAM which can then get code execution in system management mode. And something that I find very worrying is that the brand new MacBook the USB-C only one is protecting the boot script in some way. So this means that there are now two classes of machines some which are vulnerable to Darth Phenomus and some which are not. So the fourth vulnerability that we take advantage of is a really legacy feature of option ROMs. And this goes back to the original IBM PC with the 8080. The BIOS's in that era were typically socketed ROM chips and there's also empty sockets on the motherboard for optional expansion features. This is where you can put your basic interpreter or your hard drive controller. The ISA expansion bus also allowed cards to contain option ROMs. So this allows you to drop a new video card into your system and have the BIOS be able to display onto it. Unfortunately because this gives you code execution early in the boot process it's a great place to put malicious code. And this is not a new idea. John Heisman presented it at Black Hat in 2007 with a modified PCI at that time PCI card. And in 2012 Snarer gave a amazing talk at Black Hat showing how to build EFI root kits that ran out of the Thunderbolt Ethernet option ROMs. And his talk is what actually started my research into MacBook security. Intel realized that this was a problem for any sort of trustworthy boot. So as part of secure boot they required that all expansion card ROMs be signed, cryptographically signed with a key stored, with a public key stored in the boot flash on the motherboard. And they required this for secure boot in UEFI 2.3. As we've mentioned Apple has sort of frozen on EFI 1.10 which doesn't support the secure boot concepts. And they still unconditionally load and execute option ROMs from both internal and external devices like the Thunderbolt. This is despite Heisman's talk in 2007 this despite Snarer's demo in 2012 and despite my Thunderstrike demo in 2014. And what it really needs is an architectural fix. Either security conscious users need to be able to disable loading of option ROMs or whitelist hashes of option ROMs or signatures on option ROMs. There are quite a few steps that could be done here. In the Thunderstrike talk I hypothesized that the option ROMs can also be used to spread malware by early. And this is an improvement over John Heisman's talk that had the option ROMs on PCIe cards fixed in systems. But now with Thunderbolt devices can be shared between machines. At the time of my talk it was mostly a hypothetical because to rewrite the option ROMs required booting to DOS and plugging in the adapter. But what we've realized is that the Linux kernel Broadcom 57 device driver had all of the hooks for writing and writing the option ROMs. So we were able to port that over to OS 10. And now it's possible to install new option ROMs into these removable devices with just root access. We also ported it to run in the in the DXE environment so that it's possible for Thunderstrike to rewrite from the option from the boot ROM. So the way that this could be used maliciously is that you get a remote shell somehow. Use whatever exploit of the week. You install this whitelist to driver and then you're able to flash code into the Thunderbolt device. And we use the Thunderbolt device because they're very easy and very small and cheap. But lots of other devices have option ROMs. A lot of Wi-Fi cards do. A lot of GPUs do. A lot of SATA controllers built into SSDs have them as well. So again back to the main point of the talk. UEFI vulnerabilities shared across many systems. It's highly likely that any given vulnerability that's found is going to report to everywhere. So ultimately in this work we considered six vulnerabilities that were all old, all publicly disclosed, all privately disclosed. We said, you know, which of these affect the max, right? So there was Prince Harming which was patched in the June 2013, June 2015 patched by Apple. Completely gone now. That's not an issue. As we said, Darth Phenomus is only partially patched. You can still use it to break into SMM which is not good. Got Speed Racer which, you know, we're still vulnerable because Apple doesn't use SMM BWP so we don't have to get around that vulnerability. But then the really interesting thing is Queen's Gambit. So Queen's Gambit we presented here one year ago at DEF CON. Corey just won a pony for it the other day because it affected hundreds of models of PCs. But a vulnerability that had been disclosed privately one and a half years ago. Publicly one year ago is still actually affecting Apple systems. They're not patched yet. Apple is working on a patch for them. But so although they patched the basic thing that would allow our current proof of concept Thunderstrike 2, this vulnerability could do exactly the same thing. So that's still out there and open. And then the Sicilian is a much lesser known vulnerability. This just had to do with us trying to make a point that previously invisible things labs had said if you break into BIOS, if you break into SMM that does not imply you can break into BIOS but if you break into BIOS you can always break into SMM. We wanted to show that you can break into BIOS from SMM on some systems just by way of saying this is a possibility. The sixth thing that we considered was the set up vulnerabilities that are very common amongst UEFI systems. The set up variable will have configuration bits which will affect secure boot. Well again Apple doesn't have secure boot so even if they had this variable it wouldn't matter. But the set up vulnerability can be used to bypass secure boot on a lot of PCs and if you just corrupt the variable you can break the system. This vulnerability though does not affect Apple's whatsoever because they don't use this variable, they don't have an equivalent sort of variable. So five out of six old public vulnerabilities all affected Apple systems right? That's not what we wanted to find but that's what we found. So what can vendors do right? We always go around and we help vendors understand you know Intel's recommendations should really be thought of as requirements. They're not really recommendations. There's a reason why Intel said that you should set all of these protection bits. You don't want to have a single point of failure when you're only using one of them right? So obviously vendors have to test all of these old vulnerabilities against their systems. All of those vendors on you know go look at the cert disclosures see whether you're currently running a machine that your vendor doesn't even respond to vulnerability disclosures right? They're probably vulnerable. Obviously setting all the protection bits. Chipsack is Intel's tool that they had been privately disclosed they had been privately passing around to bios makers in order to have them fix vulnerabilities before they ship right? And then they eventually made it public for researchers to play around with right? If you run Chipsack on an Apple system well it doesn't support Mac unfortunately so you have to either run it from EFI or install Windows but if you run it Chipsack would say this system is vulnerable right? If Apple were using Chipsack they would understand the system is vulnerable. And then there's other things like the SMM lock box which can protect make it so that the S3 resume script is not just sitting around in RAM where anyone can manipulate it you lock it back in system management mode where an attacker would have to have an extra exploit to break into SMM before they could manipulate it right? That's not a panacea though because even at the original Darth Phenomus attack they showed that you know some Intel systems were using SMM lock box but just because you hide your stuff away in RAM if it still jumps out and reads from other unprotected memory well that's a bug as well right? Intel boot guard is a great technology that allows a system to actually have a much stronger root of trust so that instead of the very first instruction coming from your potentially manipulatable firmware instead it comes from signed code where literally the CPU verifies the digital signature on that code so that's a much stronger upfront guarantees and then of course option ROMs there's many things that need to happen for improving option ROM security. Digital signatures are a good first step but that's not an end step and certainly it would be nice to have the ability that if you're security conscious you're setting a firmware password something like that maybe you wouldn't like all of these untrusted unsigned code to just be sucked in and executed in the BIOS. Alright for all of you who are not BIOS engineers who don't spend your day making BIOS's all the time what can you do? Well you have to start doing firmware forensics right? It's not just about hard drives anymore it's not just about RAM memory forensics right? You have to do firmware forensics and as I said people have been running around giving these sort of talks for years now but no one ever seemed to do anything about it no one ever seemed to actually you know provide ability to check the firmware and so that's sort of why we started like before but in order to not leave you empty handed here we put out an option ROM checker right? So you go you take you plug in your Thunderbolt Ethernet adapter into your machine plug it into your machine and then run the script that we provided it will dump out the option ROM using the stuff that's been ported over from Linux dump the option ROM and then integrity check it because it turns out everybody's option ROMs that we've seen they all look the same and they're very easy to integrity check and so this gives you a first order you know is there some manipulation of my option ROMs. So we've only checked it on our own and you know a few devices beyond that so if you go check yours and it says there's an error either A our tools are broken highly highly possible or B you actually have some attacks so in either case whether it's a false positive or true positive we'd like to hear about it. The other thing you can do I always have to put my plug in here the other thing you could do is go get smart on firmware right go learn x86 assembly go learn about root kits go to open security training take some free classes get smart on things and then go off and do your own firmware security research. Alright thanks so much for attending our talk this early Saturday morning.