 Next we have Gene Eric telling us how scary our UEFI is. Please welcome Gene. Hey guys, I'm Gene and this is, as he said, a talk about why you should be terrified of UEFI but also a little bit about why it's cool. So who am I? Why do you care? I'm a hacker. If you haven't seen this card before today, here it is. I'm also an accidental enthusiast over UEFI. I didn't mean to do any of this research. It just kind of happened while I was looking at something else. So what is UEFI? You guys probably heard of it by now. It's a replacement firmware thing that basically replaces the old idea of BIOS. So when your computer is trying to start up everything and you need some kind of a really basic control system, BIOS was it. It's been replaced by UEFI, which is good and bad. It does a whole lot more stuff. So it's basically a pre-OS OS. It has its own drivers. It has its own, more or less, kernels that they call a bootloader, pre-bootloader, but it's capable of running programs. It's capable of doing lots of stuff. You can have network access from your pre-OS, pre-bootloader, loader. And it's also open source. So where can you find it? It's kind of on everything these days. Any new device that you're going to buy that's like a PC or a laptop or a server, it's going to have UEFI on it, or at least some kind of UEFI, depending on how weird they gotten. So you can find it kind of everywhere. It's also starting to get into the virtual machine space. The virtual box for a long time has had the ability to do UEFI-based stuff. It's kind of a pain in the butt to use, but it's on there. And you can also do a lot of UEFI stuff from embedded platforms now. We're getting kind of more of that, formerly U-boot, which was kind of like a predecessor almost. But we're getting a little more stuff. Me personally, I like to use UEFI on my Raspberry Pi because I'd like to actually be able to update things, but that's just me. So there's a link to how to do that. Why is it so awesome? Well, it's capable of doing a lot of stuff that the BIOS couldn't do back in the day. One of those is loading from GPT instead of MBR-based storage devices, which means you can have a lot more partitions and crazy stuff going on. There's a whole host of things that GPT can do that MBR couldn't, and usually when you find a system that can support booting from GPT, it's also UEFI. You can support secure boot. So it's really easy to do booting known signed binaries from a UEFI firmware as long as you've told it how to do that and what your key material is, et cetera. So that's something you can do from UEFI. Huge file systems. So you can boot from a two terabyte device. That's not something you used to be able to do with BIOS because, you know, bit length. Oh, thank you. So you can also build all kinds of weird drivers for it to boot different file systems. You're not limited to something that necessarily the manufacturer or newer understood when they shipped the device because you can load drivers after the fact. You can do scripting stuff with it. So you can actually load scripts from the UEFI. Most manufacturers include a shell application with their UEFI firmware that's actually installed on your device. So that's meant to actually run scripts to do things like update your UEFI or do diagnostics. So that's the thing that you can use, too, to do some weird research type things. But it's kind of a weird system scripting. Both awesome and terrifying is the fact that ACPI stuff has been lumped into the UEFI now. So previously, all the descriptions on how different bits of hardware in your system talked to the other bits of hardware in your system were defined in like a permanent state in an ACPI thing. You could update it, but it was really hard. In UEFI, that's just like a thing that it does. So you can replace functions for talking between devices in the ACPI and like you don't have to recompile anything. That's just the thing that you can do with it, which is awesome and insane at the same time. You're not stuck using x86. So BIOS was very, very custom to whatever hardware you were using. In the UEFI world, because it's been unified, we have a similar code base that works on tons of different architectures. So you can get those embedded platforms. You can even get some old stuff or some new weird stuff like PowerPC64, maybe. All right. So with all these things, what's wrong? Why are we afraid of this really cool new thing? Well, one of them is the ACPI thing that I mentioned. If you can change how the hardware is talking to other pieces of hardware in non-compiled code from something you're loaded from an untrusted source that's not actually burned in the firmware, you've got all kinds of access to do weird things. And there are projects that make great use of this for good and also evil. I'm not going to mention what they are, because some of them are violating copyright to do that. So also with UEFI, a lot of things are based on common code bases. They all kind of open source their spec. And the EDK, which is part of a project called Tiana Core, is actually something that manufacturers use to build their firmware. And they actually burn that into the ROM that's on your machine. Which is awesome because it's open source, but it's scary because everybody's using the same thing. So we're all kind of screwed in the same places. And you can't really tell, you can kind of tell what version it is. Some manufacturers actually tell you what version it is. But it's really hard to tell what has been patched and what hasn't. So boot loader signing. So frequently when these things come out of the factory, they're not using any kind of signing for the boot loader. It's basically counting on you to provide some files on your file system to then load the OS. The problem is that actually loads into the UEFI space, which means you have the ability to do some crazy crap that maybe you shouldn't do with untrusted code. Back in the days, maybe the boot loader got some access to things with BIOS. You can make direct calls and things like that to memory addresses. In UEFI, it's less obscure. So you can actually make more attack surface of more equipment without knowing a specific memory address. You can just ask for a particular piece of hardware and it'll respond like, oh, I don't know. You're secure enclave. So that's interesting. There's not a lot of research going on in UEFI. It's kind of like the Wild West. People don't look at it all that often. That's changing a little bit. There are people that are actually looking at it now and trying to raise those red flags, which is cool. It's good for everybody, and I do support that. As I mentioned, things do kind of live on the file system for some of this. So half of it's actually burned into the ROM on your machine, and then the other half for three quarters, that's a lot of math with 125%, is actually on your desk in a file system that could be mounted within an operating system, which then you're at the mercy of whatever that is. And it's still kind of bleeding edge for the concept that it is replacing. UEFI is still really young. We've had BIOS for many decades, and we've replaced the entire concept with something else, and it's still a little new. Here's some example of things going horribly wrong with UEFI. So Microsoft had an accidental leak of access to UEFI for basically anything. That's not great. If you have one exploit to rule them all and you are suddenly in the firmware on somebody's machine, now they're owned forever. There's been a group of people doing some cool talks about how to attack and defend UEFI, and they go into some of the nitty-gritty details, which is really cool. I recommend you guys look it up. This is an example of them talking about it at DEF CON Asia last year. You should go look into it. They give some information about how to actually debug real systems with real UEFI, not just something that you compiled, and what they found when they started doing that. And it's not good. So you should take a look at that. My favorite one is actually the Vault 7 leaks. I didn't hear about this very much until I went hunting for it. So there is a UEFI set of attacks in the Vault 7 drop that actually tells you how to stay resident after you've loaded the bootloader and the operating system. So you can have a program running in the background at ring zero that your operating system does not know is there because it's running in the UEFI. That's awesome. You want to call home? That's how you call home. So I included this because I love this picture. This is an example from the same people that did the DEF CON Asia 2017 talk. They actually wrote a proof of concept malware that changed all the way through an active Windows installation into the UEFI using some of the exploits and using some of the stuff they learned from the Vault 7 drop. And that's pretty badass. They managed to ransomware the system in UEFI. So you can reformat. It's just going to lock you again. So some of the notes on research stuff that you might be interested if you want to go play with things. TienaCore's EDK slash UDK is out there. It's free. It's on GitHub. It gives you some pretty cool tools to get started with messing with things. It gives you code for all kinds of drivers and the ones that they don't include you can get from the Grubb project. They actually have drivers for tons and tons and tons of file systems that you might not even remember exist that you can boot from using UEFI using the TienaCore project. You can actually take those same drivers and put them on a real system. It's kind of fun to do. So being able to have a debugger in your pre-boot firmware is kind of a cool thing too. So that's something that's included with TienaCore that you can actually do. So it'll fire up a libvert from QEMU to actually give you a UEFI system in a virtualized space that you can mess with. That's pretty cool. Like from a research perspective, being able to actually mess with something in a controlled way like a virtual machine is really cool. Refined. So it's cool. It does some of that crazy ACPI stuff that I mentioned. But it's primarily used for, I'm not going to mention, because that's a copyright thing and you shouldn't do that, that's bad. But if you've heard of the project, you know what I'm talking about. It is cool, however, all on its own. You don't have to use it for the bad purpose. You can just use it for cool stuff. Like I use it for my machine every day because it's really useful. Like keeping on a USB stick, you never know. All right. So what do we do about all this crazy, terrible stuff? I say we go attack it. So just keep doing attack research. New bugs and new holes. That may be from an operating system vector. It may be from the bottom up when you're talking about defeating signed code. Just go do the research. Find public stuff. It's open source. They'll probably fix it. Make sure you're actually using it. So a lot of systems that are capable of doing UEFI for support reasons have actually fallen back to a legacy slash hybrid system where it's emulating BIOS within UEFI so you don't get some of the good features that you should be using with UEFI even though your system is somewhere under the hood actually using it. So I would say make sure that you're using it. Keep everything up to date. The fact that Tiena Core, EDK, blah, blah, blah is open source means that they do actually change it fairly frequently. And because they don't have to do so much work, the manufacturers, as far as I've been observing it, have actually been releasing firmware for their platforms more frequently than they used to with BIOS because it's no longer custom. They can just suck in the new code and compile it. So what else is helping? There are some defensive ideas that have been drafted. They're still not real clear. So you guys can take a look at that spot on GitHub. They talk about what attack and defense you might be able to do. That's a good thing to know, especially when you're a blue teamer. It's good to know what you can do to defend the platform. The Embeddy guys, as I said, they provide a bunch of information on how to do debugging and are talking about what's bad. That's active research that's still being done. And they're antivirus systems. They're actually starting to do scanning of UEFI. How much that's going to actually find for you? It's hard to say. Your UEFI is owned. It's at ring zero, so I don't know how much a scanner is actually going to find. But it can't hurt. And they can at least look at the files that are in your file system that are being loaded into EFI. So what do I think is going to happen next? I think things are going to get a lot worse before they get better. Something big is going to happen and we're going to have a problem, I think, like crypto-lockering or like the big embedded device attacks that we've seen lately. I feel like that's going to happen with UEFI at some point. Everything's kind of in place to actually allow that, I think. I do also think we're going to hear about somebody doing an attack on UEFI where they're actually sucking out secrets from one of these systems with a secure enclave, like a Mac laptop that's supposed to have your fingerprint in a secure place that you can never get a copy. If they can get into the EFI, that rule might just go out the window because somebody's got to be able to talk to it. We're going to see more of the EFI stuff being done by the operating system manufacturers instead of the actual hardware manufacturers because it's more universal that way. We're going to kind of dumb down what's actually living on the hardware, at least that's what I think the trends are saying a little bit. We're going to see more secure boot stuff. It's actually how we solve some of these problems. It's not hard to do. It's really not like everything's pretty much already in place. You just have to start signing your bootloaders, which you can do with Grubb and it's already sometimes done depending on your distribution of Windows. I think we're going to see more of that and embedded stuff using the Ufie. Again, I think that it's important to note that UEFI can get you ring zero and beyond. It's just an important thing to keep in mind when you're talking about the security of that kind of firmware. Users are looking at this, how can they not? This is a big juicy area to play in and the wins are big. You own and you stay owned. When you make stuff with the EDK, it might actually end up in what's on the firmware on some of these devices. That's kind of a good payout. I would encourage some development in the open source space against the EDK. There's a little note here on how you actually do secure boot with Linux and open source environment. Yeah. That's it. Yeah. What facilities does UEFI furnish that make a boot kit or something that modifies the kernel's memory prior to boot? More dangerous than just like an old school MBR style boot kit. Right. The question is why is an attack in UEFI, which happens before a kernel boot, more dangerous than something that maybe exists in the MBR? I think the answer to that is when you own the MBR, you can run an application that modifies how the loaded operating system is going to run, but you can kind of tell that that's happened in memory. With UEFI, you can't actually tell because it's living in a part that's not reported to the operating system. Anybody else? Do you try to do online for more updates through the UEFI? Yes, I have. And it's kind of silly. So yeah, motherboard vendors are doing online updates of UEFI and yeah, that doesn't sound like the greatest idea in the world. There are just too many things that can go wrong. Yes, you in the back. Yeah. So on my personal computers, I do have custom EFI stuff. So I've went out and done some of what I recommend here, which is compiling, making some of my own apps. I have a USB stick of Doom that does all kinds of crazy crap, including loading some weird UEFI. One of the things I didn't mention is the bootloader, or not bootloader, but like one of the chain EFI files programs to actually start the bootloader can be defaulted on any device that it's supposed to try to boot from. And I actually take advantage of that on my USB stick and use the default location. So just about anything will boot from it. All right. Anyone else? All right. Thank you.