 These speakers really need no introduction, but they will introduce themselves and let's give them a big defcon welcome. Come on. Thank you, everyone, for coming. All 12 of you. Before we begin, here you go. So before we begin, thank you for coming to our talk. We're going to try to be quick because we have a lot of slides and a lot of content. And a couple of trigger warnings before we begin, there's a lot of load of the ring content in the slide deck. If you have a problem with it, it's your problem, go see a therapist. There might be a few animations that have flickering lights if anyone has sensitivity for that. And I might, I probably will curse a lot. And we're going to mention a lot of Microsoft. If anyone is sensitive to that, please let us know. If you work at Microsoft, if you want to raise your hand, so I know who to aim this at. No one. Anyone at Dell? Okay, so there's a lot of Dell and Microsoft in the deck. And we're going to try to make it fun and entertaining for you guys. Quick introductions. I'm Mickey, that's Jesse, that's our Twitter. We work at a company called EclipseM. Moving on. The agenda, we're going to be boring for the first 10, 15 minutes. I do apologize. Some of this information is not very exciting. It's not very wow. But we're going to try to keep it as simple as possible. So even if you don't know anything about BIOS or security or anything in the secure boot flow or whatever, you still can get an understanding or a basic understanding of it. I promise it will pick up towards the end. He's smiling because he knows why. We're going to talk about the vulnerabilities we found and all the demos and everything that we have to do about it. And in the summary, we're going to discuss the experience of how everything went through with the disclosure, the patching, the fixing everything. So what secure boot, secure boot is the thing that secures a boot. Everyone needs it. It's awesome. Use it. How it works. When you power on your computer, usually in the normal boot, boot sequence, you power on your computer. There's some magic happening. Then the firmware starts running. The firmware then finishes its run, hands it off to the assigned boot loader that is assigned in the firmware. Then the boot loader goes and starts loading the chain for starting the OS, whatever OS it is. So for Windows, you have a boot manager. For Windows.efi, that's usually the boot loader that I use. And then there's other winload.efi and all kinds of other files that go in the path in the sequence. It changes with grub, for example. There's a different sequence for grub and so on. Where the secure part comes in, you have the firmware itself that can get verified before. So there's all kinds of technologies that do all that. I'm not going to bore you with the details. But once a dedicated secure firmware is booted and loaded, it goes and checks, passes the checks along and checks that the boot loader is signed and it's verified and everything's okay. And the boot loader continues the checks with whatever enforcement mechanism it has. And then the Windows says, yay, I'm good. I'm authenticated. In this slide deck, we're going to focus on this part. So I want to say, I'm sorry, I kind of ran through this. So let's talk about it at a high level. Let's look at some architecture and implementation details for a second. UEFI firmware is very modular. It's designed to run on a bunch of systems. When your laptop boots up, there may be 500 different executables in the spy flash on your motherboard that could potentially run before the operating system even loads. And in order to provide all this modularity and functionality, one of the key mechanisms is the concept of protocols and protocol interfaces. It's essentially if a module or executable wants to provide a service or some kind of capability that is then going to be used later, it will register a protocol interface that's identified by a GUID. So there's a well-defined set of GUIDs in the specification. OEMs will have their own additional GUIDs. But essentially code will register a protocol and then later code will then look up or locate protocol. And then that protocol interface is essentially just a structure that has function pointers in it. And it can have private data. But that's a key thing to understand about how all this is tied together. So for the secure boot checks, it's also built in kind of a modular fashion where there's different pieces of code that will do different types of checks. And those will register with a single point of where the check is going to be performed. It's essentially it will go through all these callbacks. But the mechanism for executing those security policies is registered in a protocol. There's a security arc protocol and security arc 2 protocol where if you look up that protocol by a well-known GUID, you'll basically get a structure that has a function pointer to the function that will be called in order to go do all these checks during the boot process. Some of these things that are going to be called during the boot process are things like doing measurements into the TPM or cryptographic signature verification. And there are some other things that can be registered as part of these checks, but those are the key ones that we're most interested in. So there's measured boot versus verified boot or secure boot, which is doing the cryptographic verification. Another thing is that we're primarily focusing on Dixie here for this use, but there is pre-EFI initialization that happens before and there can be some measurements during that phase as well. Here's kind of a high-level view of the UEFI boot process where you have different phases like the initial power on starts at the beginning, at the left there with a security phase, then PEI, and then Dixie or driver execution environment is the biggest phase and it has the most functionality. It's also the thing that runs and does a boot device selection and loads your boot loader and passes off execution to the boot loader. So focusing on that area a little bit, PEI core does things and then it passes off execution to Dixie core. Dixie core will then set up things like runtime services table, boot services table, and then it acts as a dispatcher where it will then go and load different executables and run those. And as part of that loading operation, it will call this function in the security architecture protocol in order to trigger these checks that have been registered. And that's also used for boot device selection and loading the boot loader in order to continue that chain of trust. Most of the boring sleepy stuff is done. So bear with us if you're sleeping, if you're falling asleep, just wake up. Now the interesting part, some of the cool things that we know of that happened in the past few years were known secure boot bypasses. One of them, which is funny, is the golden key, which was released a few years back. I don't remember exactly when by long heard and slipstream. I'm going to butcher names. So I just put Twitter handles and screenshots in the deck. If I mispronounce the names, apologies. Sid Biscuit is the one who did the screenshot of how it looks when he used the golden key. What it is, basically, is it's a debug feature that allows you to install a secure boot debug policy from Windows. But the funny thing was that binary was signed by Microsoft. So that was essentially a Microsoft handed bypass to secure boot. The source for this, the zip is in the GitHub for this talk. One of the other researchers, one of the researchers that did the golden key slipstream, they gave a talk two months ago in CCC EMP camp. I highly recommend you go watch it. It contains a class of issues. A lot of information is contained there. I'm not going to go into deeper details because it's a lot. I highly recommend you go see it. There's also the repo that he released, the slides, and the talk is not available yet, but it will be because they're still editing that video. One of the other, in my eyes, it was the most famous secure boot bypass that I've seen so far was the Kaspersky bypass. So we all know of Kaspersky antivirus. They had a rescue disk for those of you who are Gen Z, that's the round thing. It's what you use to boot off here, put your computer off if something happens or whatever. So Kaspersky said, you know what, we want to be good. We're going to do this secure boot right way. So if our customer is using secure boot, you can use this disk without having the user go into BIOS because in consumer software or programming products for consumers, you really don't want the users to go into BIOS because it's really hard to explain to someone, it's hard enough to explain to someone click here, click that, then go into BIOS and select that feature. Anyway, so they had this disk, the disk was using a shim. So that shim is basically a binary that is signed by Microsoft and that binary contains a CA and a certificate verification mechanism to check subsequent files that it loads. So the shim is signed by Microsoft, the shim then loads another binary that was signed by Kaspersky. In this entire process, it was discovered that Grub was loading unsigned modules and there was a module loaded that changed the file policy that allowed you to load unsigned binaries. So you could bypass a secure boot, you just take the whole file system, the whole file structure for Grub, copy it over to the EFI system partition and change the boot order to that and you're golden. Another one that we discovered a while back was, we called it boot home. Basically, we found a bug in Grub that allows you to do code execution. That is a short history of things. Basically, you can see by the years there was one bug in 2015, there was, we added in 2020, we added some and others added on top of us. 2021, there were eight more. In 2022, there's just one for now as far as I can tell. But you can definitely see that there is more attention put on to that area. If you want to read more on that, I highly recommend go to the Grub, what's it called, the mailing list. There are links posted also. One last thing, not directly secure boot bypasses but can be used to bypass secure boot. There are vulnerabilities that are being discovered on a regular basis, so to speak, in firmware, where if you can code execution in SMM, you can do horrible things, but it can also affect secure boot. Some of these examples are the binary vulnerabilities, Sentinel 1, ESET, Lenovo, ESET, and BSSA1 is a good example for debugging production. There tends to be a lot of that happening in firmware, where you have code that is not necessarily coded off. It's still there, but it's not dead code. You can still reach it in certain ways, but the vendors don't really tend to remove it. In general, getting firmware versions, a lot of firmware versions is a big pain. Deploying a firmware version to your fleet of devices, if you're Dell or HP or Lenovo, you risk a lot. If you mess up one thing and you end up breaking 100,000 computers, you end up paying for those. It's a lot of money for a software bug. Why care? Why do we need to even bypass secure boot? We're all hackers and we do security and stuff, so we want to have our boots and roots embedded in the computer and have all our stuff. It's like, oh, the old, everybody knows, yeah, rootkits, bootkits, security, what's the APT or adversaries, malicious actors, what's the word for today? There is an even a minor attack category for pre-OS boots. Stealth and persistence, that's all you want. But I want to talk a little bit more about the other side of things, the normal people. If you take a side security for a second, how dare we? Let's put aside that for a second and think, where else do we have a use for a secure boot bypass? So, surprisingly, or unsurprisingly, if you're a gamer and you're cheating, anyone here cheats or has their hand? I hate you. Hand you. If you're cheating in multiplayer games, I especially hate you. So that's a big motivator. Turns out, the cybersecurity industry in 2021 made about $130 billion in market share. The gaming esports was 155 or something like that, $160 billion. Anyway, it's a lot of aliens. It's huge. They're kind of similar in amount, but there is a lot of money in gaming. And surprisingly, you can see these pop-ups and notifications coming in regarding this specific thing from the game. So this screenshot right there on the right, I took it from Twitter where a user was complaining like, I can't play my game now. They demand TPM2 and that secure boot is on. Like, where have we ever heard like TPM and secure boot enforcement outside of an enterprise? It's like unheard of. But now anti-cheat. Anyone here from the gaming industry, anti-cheats, keep doing the good work. Anti-cheats, I swear to you, they are like, in some cases, they're insanely clever. So listen up. So in the open source community, there are, there's Maddie and there's Samuel Toulac. Samuel has, I don't know how, I'll just say Samuel. Those two GitHub repos are very, very good if you're interested into doing the PRS research and secure boot and all that stuff. The Samuel Toulac example here is a driver that loads during boot that allows you to communicate with the runtime environment from the OS. So basically you bypass the, the, you don't really need ring zero. You can get direct memory access and do all kinds of things using hooks. Anyway, I'm not only getting to that too much, because that's not the point of the talk, but highly recommend you go look at it. He has also YouTube videos and it's, it's extensively used in, in the cheating forums. The other one, the Maddie one, the, the EFI Guard Dixie, it's a very robust repository that has a lot of features, including driver signature enforcement bypasses and, and it is maintained, it is actively maintained. So highly recommend using that for, for development, for learning, for trying to do new things and so on and so forth. Now that's the open source, the good guys, the ones that want to, hey, look, you can do this. Everyone here, let's learn something together. And then there's those who want to make money off of it. There are cheats like this one. It's called W3 cheats. It's a website. If you go W3cheats.com or work or net, whatever XYZ it's called today, I forgot. And they, they sell you a file scheme. Basically, it's a file structure of a bootloader that you put on a USB and you boot off the USB, you select what kind of cheat you want, Apex Legends, Apex Legends, whatever other, I don't play Apex. So I don't know what the versions is. And the CS Go. If you play CS Go, my heart goes out to you. That's like the most abused platform ever for cheaters. From what we've seen, like at least. So there, there's a video there that their support published about how you do this, how you, how do you get us to give you a license, right? You pay 30 or 40 euros. And you have to tell them who you are, so they can assign a license key to you. They do it by getting a hardware ID. To do that, you have to plug in this USB. Is it playing? Yeah. If like this USB, you have to say, go, go to the boot order, go boot from this UEFI USB partition. And then it goes, it loads their bootloader and then gives you a menu. Which one do you want to cheat? Oh, I want the W3 hardware ID. They write it to a text file. Then you get the USB stick out. You send that hardware ID to their, well, in their website, there's a text box. You put it there. And then you get a user. They know who you are. It's a unique ID. And then you can pay and cheat to your heart's content. That was the most simplistic cheating website. About 300, 400 users. This one, holy crap. You go to their website, the Face IT cheats. It's like a full on normal product. There's like a portfolio of things you can buy. You can get a spoofer. You can get a premium cheat, a cheat plus spoofer. But the one I want to focus on is the URAN. I don't know why it's called URAN. Not IRAN, whatever. But that one popped up into our radar because it uses a bootloader. And it has capability of adding code execution before the boot. Highly recommend looking into that. A few other small examples. The other games that I didn't mention are listed here. So ZW hacks is a cheating website that's no longer available. Exodus production. And what's it called? Celex. Also, the ZW product had a leak. So their source code leaked for their Valorant ESB aimbot. Go have fun. And I'm going to wrap up this gaming part with one of the most important things I can tell you if you're in a security community. If you have a question about some Windows kernel data structure, there's a 50% chance that the best person to talk to is a 16-year-old in a game hacking forum. Unknown cheats is one of those game hacking forums? Holy crap. Like, I've seen more technical discussions in the forum there than I've seen anywhere else for like deep kernel structures and pointers. And they analyze the games intensely. Okay, now, switching gears a little bit. We know that secure boot is a problem. If we find an issue, how do we usually deal with this? So the simplest way is by design, there is something called DBX, which is the revocation database for whatever hashes you don't want the system to load for the binaries. The best example for how this can go wrong was when the Kaspersky rescue disk bootloader issue came up, Microsoft issued an update that lasted about a week before they pulled it. And they pulled it because a lot of systems were not booting and there were problems with it and there were issues with it. Anyway, I'm going to let you guess what happened this time around. But yeah, I don't see where they patched it with Windows or something. Anyway, so there's by design, there's DBX, you update it, that's how it's supposed to work. That's from the UEFI specifications. That's how it was designed. So how you want to do this? Let's say you had a fix deployed but you don't want to and you're a cheater and they hate you and you want to play this game and you want to use this bootloader or whatever. This is an example of how it works on a Dell laptop. So what you do is you go into BIOS, this should work on most systems. You go into BIOS, you go like, I'm going to go into the secure boot menu. And in the secure boot menu, I'm going to tell it, I want to load my custom keys. So you go when you say enable custom mode and then you go and you say like DBX and then you say delete DBX, I don't want it. And then you go like, you know what? I changed my mind. Disable the custom mode. What happened there was you basically told the BIOS to go with its BIOS level permissions to exchange the current value of DBX with a default value that came with the firmware. Right? So now if your DBX was updated and it was included with hashes that were like the grub, for example, had the bootloader hash was included in there and now you can't boot it. You go, you tell the BIOS like delete it. And then it deletes it. So the action is done at that point. When you go and you revert back to normal mode, it doesn't bring back the updated DBX. It just stays the default. So things can be undone. Okay. Fun parts. Vulnerabilities. Lord of the ring cosplay of how vulnerability is exploited. If you know the movie, you know what it means. We have three vulnerabilities that we categorize in two separate classes. One class that we're going to start with is the signed UEFI shell. A UEFI shell is basically like a DOS shell or a command prompt shell that the UEFI framework gives you to use. In this case, we found two products that have their own bootloader signed, their own shim that loads among other files that are signed by the company. One of them is a UEFI shell. So if the boot is on, it gets a bootloader that's trusted. The bootloader goes like, oh, fine. What do you want me to load now? And we tell them, go load that file. Or it's a hard-coded path in that shim that goes, ah, next file to load is this. And you just rename the shell to whatever next file it's expecting and it will just load it. So what can you do with it? So the UEFI shell inherently comes with a lot of tools in it. Obviously, DIR list files, change directories, you know, the usual stuff, but it also has cool things like write to memory, you can talk to PCI devices, IO ports. What else am I missing? All kinds of stuff. Yeah, there's a bunch of, it's more of a debug tool that doesn't usually ship with most systems, but you can find on some, but it's not usually signed, but it has things like read write physical memory, list handles, find the addresses that things are loaded at, other things like that. And it's a really useful tool to have. Not good if you want security. The beautiful part of it is in by default in the UEFI shell, it looks for a start-ups.nsh script. So if you do want to have a backdoor or something automated on a system, you can put a script in and it will just execute it every time it boots. So it usually waits five seconds, executes the script, and then it runs. In the GitHub, there's an example of a script in the demos that searches all the drives for the Windows boot manager and loads it if you want to use your own boot sequence and then just pop the Windows. A couple demos. So this one is available in the GitHub. So all you need is QMU. Download, this is like 10 megs or 8 megs. It's a QMU image, OVMF image or BIOS that has the secure boot enabled. So if you want to play with it in a controlled environment and debug with it and play with it, the script, everything you're going to see is in there. So please feel free to just download and play with it. You boot the system, it boots into UEFI shell, that's how it looks. I go into the drive, I try to run the UEFI, it says no access denied, I run the patch, and I try to run it again and it runs it. We're going to talk further, later on we're going to talk exactly what the patch is and how it's done. In a more of a real world environment, this is how it's done if you have, this is a Dell 5520, Dell 5520. So you have a computer, you go into it, okay. We check, we're not lying, this is secure boot enabled. Right. One time boot menu, we select the USB to boot from. Don't be scared with all the drives, Dell has a lot of partitions. We try to run the file, it says does not recognize, we patch it and run the file again, it says hello world and we're hackers, we have to put in a SKALL, ASCII SKALL, ASCII SKALL. And now we just continue to boot into Windows. We slowly type boot manager for Windows and we're back in business. And we need to show you that secure boot is still on. We obviously show that secure boot is off. Wait, wait, don't clap yet. And secure boot is on. Thank you. I don't know exactly why it stays on. But now to the best one, right? That's the last. So we said two categories, right? One was the UEFI sign shells. The other one, I don't know how to call it. It's basically do whatever you want. This boot loader, this shim is signed by Microsoft. And in it, we're going to show you in a second, when we looked at it, it was like, what the hell is going on? It basically looks for that filename, the shdmgr.ef underscore and loads it and runs it. But it does it manually to bypass the security checks. We're just like, what the hell? So we looked at it, 73 kilobytes, right? Tiny file, throw it into BINJA. Look at it and it was like start image. And in UEFI, there's load image and start image. There's no underscores. Load image, start image. And even if we ran the UEFI plug-in to parse everything to make it look nice, you would still see it like load image, start image. But when we saw this, it was like, okay, what? Why is there a custom start image program? And in there, you'd see that it looks to follow up and jumps to the start of the code in it. This is a much better bypass from an adversarial perspective or a game cheat perspective. Because you don't have to have the full grub and all the files and everything to copy a bajillion files over. You just need the one file. That's it. And caveat here, 73 kilobytes is the sample that we have. We don't know how many samples there are of this bootloader. Because Microsoft doesn't tell you. We'll get into that in a second. There are samples of this that are even smaller than that, like 36 or 40 something kilobytes. But we haven't gotten a chance to use them. We got this. It works. Even if it is patched, you can revert it and have fun. Oh, so part of the release in GitHub is that we have a, we wrote a tool that we're going to describe in a second that does, we call it unsecureboot or unSB. Basically what it does, it looks for the security to architecture protocol and the security arch protocol and finds those handlers, find the pointers to the handles. And it's the next slide. You want to talk about this? So one of the reasons that we wanted to have this tool that what we're going to talk about right here is that that bootloader that we just talked about, just the next single file that you load will be unsigned code. I don't want to write my own loader to load other stuff if I want to run a bunch of other things. If I want to use the standard UEFI load image and start image, it'll go through the security checks and disable me from loading or prevent me from loading additional unsigned code. So although we have unsigned code running initially, we want to make it easy for us to just go ahead and run whatever we want without writing our own loader like these guys did. So I mentioned the protocols before, that security architecture protocol and security two protocol. You can literally just call locate protocol and give it the good and it'll give you a pointer to the structure that has a function that will be called when it's doing the security check. So you literally can just write like patch it directly. There's no memory protection at this point. UEFI is essentially running single threaded and doing callbacks instead of having any kind of isolation between processes and things like that. So we can literally just dereference the pointer to this function, patch whatever we want. In this case, we just wrote two instructions to do move zero Rax and return. And that zero is essentially the EFI success value. And because the security check that something else is going to call is going to just get EFI success, it'll go ahead and run whatever you want, no matter if the signature is broken, if the signature doesn't exist, or whatever. So it's really easy fix. This also prevents further measurements into the TPM at this from this point forward, until the bootloader or something else starts taking over that process. So any measurements and anything that you run in the UEFI environment from the point that you overwrite this function is not going to be measured in the TPM anymore. So at that point, we can just call the boot services functions to load image and start image and run whatever we want. So you don't need to write any fancy shell code to like search through structures or do egg hunting or anything like that. You can just patch the pointer because you get a pointer. You can basically look up a pointer to the function that you want to patch overwrite that and then just run whatever you want. So if you look at the code running through this example, the first part is you patch the handlers and from that point on you can run whatever you want. This is also in the GitHub. We load a shell binary, but the shell that we load is one that we patched off all the console out. So it's like a silent shell which allows you to script whatever you want without anything showing on the screen. It's handy if you want to use it. And you can do whatever calls you want. You can even be done, patch it back and then can resume operations if you'd like. And now we're going to switch a little bit to software. But before that, if you're in Windows and you want to mount the EFI system partition and change files, change a boot loader, you need to be admin, right? But what's this? It's called service. Look, Microsoft. Microsoft has a Windows servicing criteria where they decide these are the types of vulnerabilities that they will fix. They do not consider a UAC bypass to be a serviceable vulnerability. They might fix it at some point in the future, but they might not. So going from user to admin is not exactly difficult. Yeah. And there's a lot of examples for this online. There's UACMe on GitHub. There's a set of 60 or 90 examples of how to bypass UAC. But in our case, we found something that we're going to call low installers. Anyone here familiar with low binaries? Raise your hand. Low bins. Have you heard that term? Okay, cool. There's a lot of people. So for those who did not, low bins are basically binaries that are already exist in a system that are trusted, but you can use them to sideload something that's not. But in this case, what I call low installer has to match a criteria. Now it's not the lame DLL load and the DLL sideload shit. No, this has to be to be considered a low installer has to be a sign installer from a major brand, major OEM, that blindlessly loads an unsigned executable. If you match that, that's a low installer. This example, we started with a real tech on the left. We found one of those. It's a setup for a driver that's from real tech. It looks nice. You send a fish email. Look, you're going to install this real tech driver. But it looks lame because the icon is crappy. So we found a Microsoft one. So super legit. By the way, both of these are in the GitHub. If you want to play with a UAC, arbitrary UAC bin, low, whatever. There's a Microsoft example in the GitHub. What it does, it's setup.exe. You run, pops up that logo, which you're going to see in a second in a demo and runs stuff in as admin. So again, how did this work? How do we infect a system using this? So this is the same Dell 5520. We boot it up. Normal. You see, there's nothing on the screen. There's no Reds call. We log in. We check email. Oh, look, we have an email from Microsoft at update.management. We must install this attachment. Oh, what is this? Click on it. It's too old. I must enable content to view what's in it. Okay. I click on it. What happens? Oh, look at that. Very suspicious. I must not trust this. What is this? Is this signed? Yeah, looks legit. I'm not sure what I'm looking for. And the certificate's okay, right? I'm a dumb user. What do I know? Click yes. Oh, this must be related to this update that they gave me. I don't know. It's installing something. Driver update set up installing. Okay, I'll wait. Oh, crap. It's going to sign me out. Done. It's IT's will, you know. So we have a Reds call. The boot loader has been swapped. And also did the usual WPBT, Microsoft backdoor where you drop a file. You can check out WPBT content later online. So now we booted with the implant infected. So we checked the device security. Secure boot is still on. Everything's fine. Looking good. It's not over yet. Wait. There's no detections, no infections. The virus is good. Right. I can keep working. I just got to scare. I'm just paranoid. But there's an executable in startup. So we switch to the attacker perspective. Of course, all hackers run Windows even if they're running malware. And then they run this DC rat tool that we found on GitHub. Anyway, there's a connect back to that machine. We look at it and we can do a remote screen. And there you have a remote rat implanted from a boot loader on a system from an email. And secure boot is still on. Yeah. So we do, we give this example, but there's also things like BitLocker. BitLocker is doing measurements at the TPM. It'll decrypt the drive when it has the right measurements into the system. So BitLocker is also only available in Windows Pro. It isn't in Windows Home. Not everybody even turns on BitLocker in the first place. So we have some protections here, but it is not universal throughout the system. Also, like we said, once we patch the system, it's no longer doing those measurements, at least until Windows picks up and takes it over. But there's some other things we can do related to suspending BitLocker. And there's a kind of a fun demo that we'll show in a second that there have been some changes recently in the latest Windows that prevent the thing we're about to show, but I think it's still pretty interesting. Yeah, so we're going to, I think we have one last video, but by the way, if anyone has any questions that want to interrupt, feel free to interrupt. So how would we do this if we want to do the TPM avoidance? So let's assume you already have infected the system prior to BitLocker. You have a bootloader persistence and you patch the handlers, but after you patch them, TPM doesn't measure. So you can change that binary afterwards. You can switch it off to when you payload, keep your rat, maintain or whatever, if you're a nation state, plug your ears. So how does this really, how does it translate to real life? You know, it's fancy in a graph. In an example, it kind of looks like this. You boot, there's a smiling, right? This is a symbolic, this is the version one of the bootloader payload that's currently on the system. You boot into Windows, BitLocker's on, SQBoot's on. So we open a shell. This is to show you how an attacker would do it more stealthily. But visually, you mount the EFI system partition like this, mount vol, drive name, slash s. We take the startup script that we have already placed as an attacker. We edit it in Notepad because we're late. And we have smiley.efi. We changed that to, this is my, this is a bug in the demo. I didn't remember if it was red skull or red underscore skull, so I had to list the files. So red underscore skull.efi, change the file name, put it back, save it to the EFI system partition and reboot. Theoretically, TPM should catch this and because it's different binary, it would cause different measurements and BitLocker should go into recovery. However, five minutes, six? Okay. Then we reboot and we see the red skull. But at this point, BitLocker recovery should kick in. But it doesn't. So whoop. Thank you. So yeah, then we go and check everything. BitLocker is on and SecureBoot is on. Trust me, it's on. I'm going to skip a little bit. We have five slides in five minutes. I'm going to try to rush these a little bit. That's the link for the Microsoft patch. What they did was they issued a DBX update and a DB update. You can go get the update that was issued in patch Tuesday. In that page, there is this reference to say if you have credential guard enabled, sorry, if you do not have credential guard enabled, you need to spend BitLocker for one restart cycle and you can see you changed the reboot count to one. But if you have credential guard enabled, you need to suspend BitLocker for two restart cycles, but you put the reboot count to three. I don't know how this math works, but it's what the website says. It's funny and it's also the command line you want to use as an attacker to suspend BitLocker and re-register your own boot loader or whatever. Fun story? Just to follow up on that sec, this command to suspend BitLocker, you can use that as an attacker where when you replace the legitimate boot loader with your malicious boot loader, you just suspend BitLocker, reboot, and it will measure your malicious boot loader into the BitLocker measurements. So then after that, you need to have your malicious boot loader and if you replace it with the legit one, then you go into BitLocker recovery. Yeah, so if you run Windows, you can get the update since August 9th, Patch Tuesday. If you don't run Windows, you're fucked. Sorry for my French. I told you, I warned you. What happened was there was an update released, but Microsoft didn't explicitly release a DBX binary. Usually what you do is you get it from the UEFI forum, which is a group of people who dedicate a lot of their time to make sure that all the OEMs and all the vendors, like Dell, HP, Lenovo, all the MSI, Asperock have a copy of the latest version so they can update their BIOSs and update all the systems. And then, you know, it's a big landscape. There's a lot of vendors out there. And if you run Linux then. So how do you avoid the bypasses? So there are things out there that can block you from avoiding the bypass. The easiest one is just put a password in your BIOS. If you really care about this, if you tend to have your laptop or computer, I don't know how your computer will be away from your line of sight, you just put a password on the BIOS and don't forget it. HP SureStart has mechanisms to check. It's a special solution they have. It's a custom chip on the board that does checks with a golden image and does a lot of nifty cool stuff. But it's enterprise, right? So again, remember, we're also talking about this this this threat for Windows home users and non-corporate and enterprise people that use this as gaming and 15-year-olds that want to play Apex Legends all day. Or you can use hardware from a closed garden like Microsoft Surface. It's all their vertical so they control the firmware, the boot loaders, everything. They have their own trust chain. It's great if you really want to do that for Windows, if you want to be a secure, you have a question? So the question was, how does this work with secure core PCs? You mean replacing the boot loader? Yeah. So secure core PC is a name Microsoft gives to a set of features that are enabled. Is it like something you can go into Windows and check, is this a secure core PC? No. I don't know. It's a title. There's some, you can find documentation for certain models and things, but yeah, we can talk about this later in the Q&A. You want to? So just to follow up, one thing that they are doing with secure core PC is this is all boot loaders are signed by the Microsoft UAFI third party certificate authority and they're having OEMs disable that by default for secure core PC systems. So let's see. So Microsoft's response, I think you kind of get the drift. They get the DBX update. The issue, not on just the DBX update, they also add a DB update, which means they add another CA to the chain that allows other boot loaders that are signed by that CA. If you ask me right now, what's in the DBX? What's in the DB? I would love to tell you. I asked multiple times, multiple people, I still have no answer. Microsoft will not share information with us or I guess maybe it's just us, with us about what signatures are being added, what is revoked, what binaries have they signed that are now not good. They just say, oh, they don't say, we asked, but we assume that they just don't want to share that information because it's Microsoft signing this. Keep in mind, Microsoft is the one signing all the boot loaders for the shim, so everything that loads canonical and Fedora and all that grub, there's a shim signed by Microsoft. There's an open source committee that does all that stuff, but there's a CA from Microsoft UFI that sits in your everyone's firmware. And the vendor response, I didn't hear anything from the vendors. We have Microsoft as a focal point. We talked to Microsoft on this and then we added cert because Microsoft wouldn't issue a CVE. So we just asked them to help us with the CVEs. And we kind of assumed that Microsoft will quarterback all of this and make sure that they would notify everyone that's basically affected by their firmware signing capabilities. Crickets. But is it over? It's done. It's kind of but it's not done done. Why? I found these tweets yesterday. Apparently, some people are already seeing this update fails. They try to have this update be done automatically. In some cases, in that Dell, in the lower example, there's a guy trying to update his Dell and it's not updating. He's found a solution. You have to turn Secure Boot off, apply the update, and then turn on Secure Boot on again. Okay, we try to turn it off and turn it on again. It's possible that within a week, if this goes worse, since it just came out three days ago, that Microsoft will pull this update. I don't know. I hope not. So everyone can just live boot Windows to update your DBX if you want to. In our Linux system. Second to last slide. With the 302 vulnerability, that's the boot loader that loads anything. You can just go have fun. If you're researching, if you want to play with pre-boot stuff, if you want to load, I don't know, tools or debug tools or hypervisor, whatever you want. Go take it. It's in that GitHub one boot loader to load them all. And yellow. That's it. Thank you. Q&A will be right here in the hallway outside, if you want to ask questions.