We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

One Bootloader to Load Them All

00:00

Formale Metadaten

Titel
One Bootloader to Load Them All
Serientitel
Anzahl der Teile
85
Autor
Mitwirkende
Lizenz
CC-Namensnennung 3.0 Unported:
Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen.
Identifikatoren
Herausgeber
Erscheinungsjahr
Sprache

Inhaltliche Metadaten

Fachgebiet
Genre
Abstract
Introduced in 2012, Secure Boot - the OG trust in boot - has become a foundational rock in modern computing and is used by millions of UEFI-enabled computers around the world due to its integration in their BIOS. The way Secure Boot works is simple and effective, by using tightly controlled code signing certificates, OEMs like Microsoft, Lenovo, Dell and others secure their boot process, blocking unsigned code from running during boot. But this model puts its trust in developers developing code without vulnerabilities or backdoors; in this presentation we will discuss past and current flaws in valid bootloaders, including some which misuse built-in features to inadvertently bypass Secure Boot. We will also discuss how in some cases malicious executables can hide from TPM measurements used by BitLocker and remote attestation mechanisms. Come join us as we dive deeper and explain how it all works, describe the vulnerabilities we found and walk you through how to use the new exploits and custom tools we created to allow for a consistent bypass for secure boot effective against every X86-64 UEFI platform.
47
Dienst <Informatik>BootenSpeicherabzugFirmwareBootenComputersicherheitLeistung <Physik>EinflussgrößeNormalvektorNeuroinformatikPhysikalischer EffektDatenflussNetzbetriebssystemFunktionalFunktionspunktmethodeDemo <Programm>Mechanismus-Design-TheorieMereologieFolge <Mathematik>Elektronische PublikationBildschirmfensterDifferenteKette <Mathematik>SoftwareschwachstelleProtokoll <Datenverarbeitungssystem>KryptologieProgrammverifikationElektronische UnterschriftOrdnung <Mathematik>DatenstrukturTwitter <Softwareplattform>Inhalt <Mathematik>InformationRechenschieberEinfacher RingObjektorientierte ProgrammierspracheEinsTreiber <Programm>ProgrammierumgebungMAPSichtenkonzeptLaufzeitfehlerSystemstartComputerarchitekturTrennschärfe <Statistik>PhasenumwandlungFlächeninhaltLastCodeUmwandlungsenthalpieElektronischer ProgrammführerAdditionInterface <Schaltung>SchnittmengeProxy ServerServerSchlüsselverwaltungBinärcodePunktTypentheorieZeiger <Informatik>ImplementierungPhysikalisches SystemAuthentifikationFokalpunktGüte der AnpassungHauptplatineModul <Datentyp>Notebook-ComputerFlash-SpeicherProzess <Informatik>SensitivitätsanalyseKreisbogenComputeranimation
SoftwareschwachstelleComputersicherheitBootenKonvexe HülleSCI <Informatik>RechenwerkHill-DifferentialgleichungVIC 20MenütechnikWeb SiteMinimalgradGerichteter GraphLokales MinimumUnternehmensarchitekturBaumechanikSchiefe WahrscheinlichkeitsverteilungExt-FunktorInverser LimesLastOrdnung <Mathematik>MathematikComputersicherheitProgrammfehlerDatenstrukturProxy ServerElektronische PublikationElektronische UnterschriftPhysikalisches SystemEinsDokumentenserverCheat <Computerspiel>Treiber <Programm>BinärcodeHalbleiterspeicherPunktVersionsverwaltungFirmwareOpen SourceVerschlingungLaufzeitsystemYouTubeSystemstartE-MailBitBootenSpieltheorieMini-DiscCodeVirenscannerWurzel <Mathematik>VideokonferenzKategorie <Mathematik>Klasse <Mathematik>Repository <Informatik>HackerInformationMechanismus-Design-TheorieSoftwareschwachstelleLastProdukt <Mathematik>ProgrammierungProgrammverifikationRichtungDigitales ZertifikatTwitter <Softwareplattform>Rechter WinkelNeuroinformatikÄhnlichkeitsgeometrieWiederherstellung <Informatik>SoftwareEinfacher RingComputeranimation
RastertunnelmikroskopIRIS-THill-DifferentialgleichungSchlussregelKonvexe HülleGewicht <Ausgleichsrechnung>FiletransferprotokollLokales MinimumCliquenweiteInnerer PunktWürfelMIDI <Musikelektronik>Patch <Software>ComputersicherheitSpieltheorieMini-DiscSchiefe WahrscheinlichkeitsverteilungWurm <Informatik>Nabel <Mathematik>COMAusgleichsrechnungCADSystemstartSpieltheorieBootenElektronisches ForumComputersicherheitLastHash-AlgorithmusSystemplattformRechter WinkelCodeKernel <Informatik>StrömungsrichtungGruppenoperationPunktBildschirmfensterSoftwareschwachstelleNabel <Mathematik>Klasse <Mathematik>MultiplikationsoperatorFramework <Informatik>SkriptspracheEinfacher RingProdukt <Mathematik>Demo <Programm>DatenbankQuellcodePhysikalisches SystemMereologieZeiger <Informatik>DatenstrukturHardwareCheat <Computerspiel>PartitionsfunktionPay-TVWeb SiteElektronische PublikationMailing-ListePhysikalismusAdressraumVideokonferenzSchlüsselverwaltungVersionsverwaltungDebuggingBinärcodeGüte der AnpassungMathematikATMDefaultMAPUmwandlungsenthalpieNotebook-ComputerFirmwareRoboterHackerWiederherstellung <Informatik>Prozessfähigkeit <Qualitätsmanagement>Lesen <Datenverarbeitung>Schreiben <Datenverarbeitung>Computeranimation
E-MailWurzel <Mathematik>Elektronischer DatenaustauschGammafunktionPatch <Software>Bildgebendes VerfahrenRechter WinkelBootenSystemstartComputersicherheitReelle ZahlGamecontrollerPhysikalisches SystemProgrammierumgebung
CoprozessorSystemstartComputersicherheitSpeicherabzugMereologieMalwareSystemplattformBimodulChiffrierungKonfigurationsraumInformationsspeicherungWiederherstellung <Informatik>Funktion <Mathematik>ComputersicherheitRechter WinkelBootenSystemstartMultiplikationsoperatorComputeranimationJSON
OvalComputersicherheitBimodulCoprozessorSpeicherabzugChiffrierungSystemstartMalwareBootenSystemplattformSystemstartTypentheorieBootenBildschirmfensterPartitionsfunktionPatch <Software>ComputersicherheitElektronische PublikationRechter WinkelComputeranimation
SystemstartMalwareAusgleichsrechnungLokales MinimumCOMCADProxy ServerSummierbarkeitTotal <Mathematik>GammafunktionVerhandlungs-InformationssystemHill-DifferentialgleichungRastertunnelmikroskopRechenwerkBinärcodeNabel <Mathematik>CodeSinusfunktionSpezielle unitäre GruppeDoS-AttackeComputersicherheitBildgebendes VerfahrenProtokoll <Datenverarbeitungssystem>BootenTreiber <Programm>StandardabweichungComputerarchitekturVorzeichen <Mathematik>Zeiger <Informatik>DatenstrukturInstallation <Informatik>SichtenkonzeptStichprobenumfangElektronische PublikationNormalvektorInhalt <Mathematik>TouchscreenMereologieLastRechter WinkelElektronischer FingerabdruckDigitales ZertifikatRechenschieberPlug inFunktionalServerNabel <Mathematik>PerspektiveOvalComputersicherheitEinflussgrößePunktPatch <Software>Funktion <Mathematik>E-MailReelle ZahlBildschirmfensterBitSoftwareschwachstelleZweiPhysikalisches SystemSystemverwaltungBildschirmsymbolSkriptspracheNichtlinearer OperatorCodeMathematikSystemstartElektronische UnterschriftPartitionsfunktionProxy ServerHintertür <Informatik>Prozess <Informatik>SpeicherschutzTypentheorieSpieltheorieBinärcodeProgrammierumgebungBinärdatenComputeranimation
Hough-TransformationElektronisches ForumComputersicherheitGammafunktionLokales MinimumGüte der AnpassungComputersicherheitHackerSystemstartComputervirusTouchscreenMalwareBildschirmfensterVirtuelle MaschinePhysikalisches SystemBootenE-MailInhalt <Mathematik>Computeranimation
Dedekind-SchnittFermatsche VermutungElektronischer DatenaustauschPatch <Software>Physikalisches SystemStabBootenDifferenteComputersicherheitMathematikRechter WinkelEinflussgrößePhysikalischer EffektGraphBildschirmfensterProgrammfehlerSkriptspracheElektronische PublikationNabel <Mathematik>SymboltabelleDemo <Programm>SystemstartPartitionsfunktionBinärcodeWurm <Informatik>VersionsverwaltungComputeranimation
Ganze FunktionBinärcodeMechanismus-Design-TheorieOpen SourceFokalpunktDebuggingVorzeichen <Mathematik>Kette <Mathematik>Gewicht <Ausgleichsrechnung>DefaultBootenComputersicherheitUnternehmensarchitekturDigitales ZertifikatZählenAutorisierungPatch <Software>SystemstartMultiplikationsoperatorPasswortVersionsverwaltungMathematikGruppenoperationsinc-FunktionGibbs-VerteilungFirmwareProxy ServerNotebook-ComputerGüte der AnpassungInformationElektronische UnterschriftBildschirmfensterTwitter <Softwareplattform>HardwarePhysikalisches SystemWhiteboardFormation <Mathematik>RechenschieberZweiVerschlingungLastGeradeNeuroinformatikDreiecksfreier GraphEndliche ModelltheorieEinflussgrößeWiederherstellung <Informatik>Abgeschlossene MengeSchnittmengeLoginExogene VariableOrdnung <Mathematik>Mini-DiscComputeranimation
Transkript: Englisch(automatisch erzeugt)
These speakers really need no introduction, but they will introduce themselves, and let's give them a big DEFCON welcome, come on. Linus here, gentlemen. Thank you everyone for coming, all 12 of you. Before we begin, did it move?
Here we go. So before we begin, thank you for coming to our talk. We're gonna try to be quick, because we have a lot of slides, and a lot of content, and, oops, and, yeah.
And a couple of trigger warnings before we begin. There's a lot of Lord of the Ring content in this 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 gonna mention a lot of Microsoft. If anyone is sensitive to that, please let us know. If you work at Microsoft, if you wanna 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 gonna try to make it fun and entertaining for you guys. Quick introductions. I'm Mickey, that's Jesse, that's our Twitters. We work at a company called Eclipsium. Moving on, the agenda, we're gonna 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 gonna 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 gonna talk about the vulnerabilities we found, and all the demos, and everything that we have to do about it and the summary, we're gonna discuss the experience of how everything went through with the disclosure, the patching, the fixing, everything.
So what's secure boot? Secure boot is the thing that secures your boot, everyone needs it, it's awesome, use it. How it works. When you power on your computer, usually in the normal 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 bootloader that is assigning the firmware, then the bootloader goes and starts loading the chain for starting the OS, whatever OS it is. So for Windows, you have BootManager for Windows, that's usually the bootloader that I use, and then there's other,
Windload, that EFI, and all kinds of other files that go in the path and 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 gonna bore you with the details,
but once a authenticated secure firmware is booted and loaded, it goes and checks, passes the checks along, and checks that the bootloader is signed, and it's verified, and everything's okay, and the bootloader continues the checks with whatever enforcement mechanism it has, and then the windows are, yay, I'm good, I'm authenticated.
In this slide deck, we're gonna focus on this part. That's all I wanna say. 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 and 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. Okay. 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'll 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 two 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 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 Longhurt and Slipstream. I'm gonna 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, but 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 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 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 gonna 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, well, 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 wanna be good, we're gonna do this secure boot right way, so if our customer's 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 secure boot, you just take the whole file system,
the whole file structure for Grub, copy it over to the EFI system partition, change the boot order to that, and you're golden. Another one that we discovered a while back was we called it BootHole. 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, we added in 2020, we added some in 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 onto that area. If you wanna 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 gain code execution in SMM, you can disable, obviously you can do horrible things,
but it can also affect secure boot. Some of these examples are the binary vulnerabilities, SentinelOne, ESET, Lenovo's 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 a lot of firmware versions
is a big pain, so 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, I don't know, 100,000 computers, you end up paying for those.
That's a lot of money for a software bug. So why care, right? Why do we need to even bypass secure boot? So we're all hackers and we do security and stuff, right? 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 isn't even a MITRE ATT&CK category for POS boots. Stealth and persistence, that's all you want, right?
But I want to talk a little bit more about the other side of things, the normal people, right? If you take aside security for a second, how dare we, right? So 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, raise their hand? I hate you, and 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 popups 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 TPM too, and that secure boot is on. Where have we ever heard TPM and secure boot enforcement outside of an enterprise? It's 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's Matty and there's Samuel Tulatch.
Samuel has, or Sam, I don't know how to, 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 Tulatch 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, you don't really need ring zero. You can get direct memory access
and do all kinds of things using hooks. Anyway, I don't wanna get into that too much because that's not the point of the talk, but highly recommend you go look at it. It has also YouTube videos and it's extensively used in the cheating forums.
The other one, the Matty one, the EFI Guard Dixie, it's a very robust repository that has a lot of features including driver signature enforcement bypasses and it is maintained, it is actively maintained. So, highly recommend using that 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 wanna, hey look, you can do this, everyone here, let's learn something together. And then there's those who wanna 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 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 Legend, whatever other, I don't play X-PEX, so I don't know what the version is. And the CSGO, if you play CSGO, my heart goes out to you. That's like the most abused platform ever for cheaters, from what we've seen, at least.
So there's a video there that their support published about how you do this, 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 and to do that, you have to plug in this USB.
Is it playing? Yeah, you plug in 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, 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 FaceIT 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 U-RAN. I don't know why it's called U-RAN, not I-RAN or 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 gaming, gaming cheating website
that's no longer available. Exodos Production and what's it called, Celix. Also, the ZW product had a leak, so their source code leaked for their Valorant ESP AIM bot.
Go have fun. And I'm gonna wrap up this gaming part with, one of the most important things I can tell you, if you're in a security community, Ombre said it best, 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 on 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 gonna let you guess what happened this time around, but yeah, no secret, they patched it with Windows thing. 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 undo 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 wanna play this game and you wanna 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 gonna go into the secure boot menu and in the secure boot menu, I'm gonna tell it, I wanna load my custom keys. So you go and you say enable custom mode and then you go and you select 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. 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 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 gonna 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 that company. One of them is a UEFI shell. So if secure 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, good 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, basically there's a bunch of, it's more of a debug tool that doesn't usually ship with both 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, by default in the UEFI shell, it looks for a startup.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. Usually waits five seconds, executes the script, and then it runs. In the GitHub there is 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 QEMU, download. This is like 10 megs or it's eight megs. It's a QEMU image, OVMF image of a 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 scripts, 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 EFI.
It says no, X is denied, I run the patch, and I try to run it again and it runs it. Later on we're going to talk exactly what the patch is and how it's done. In more of a real world environment, this is how it's done if you have,
this is a Dell 5520, Dell added to 5520. So you have a computer, you go into it, okay. We check, we're not lying, this is secure boot enabled.
Restart. 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 then we run the file again. It says hello world, and then we're just like okay, we hackers, we have to put in a skull, ASCII skull, we got ASCII skull. 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. Right, we obviously show that secure boot is off. Wait, wait, don't clap yet.
And secure boot is on. Thank you. Thank you. So, I don't know exactly why it stays on, but it's funny.
Now to the best one, right, that's the last. So we set two categories, right, one was UEFI signed shells, the other one, I don't know how to call it. It's basically do whatever you want. This bootloader, this shim, is signed by Microsoft.
And in it, we're gonna show you in a second, when we looked at it, it was like what the hell is going on? It basically looks for that file name, the shdmgr.ef underscore, and loads it and runs it. But it does it manually to bypass the security checks.
Which is like, what the hell? So we looked in it, 73 kilobytes, right? Tiny file, throw it into Bingea, look at it, and it was like start image. And in UEFI, there's load image and start image. There's no underscore, it's load image, start image. And even if we ran the UEFI plugin 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 the file up and jumps to the start of the code in it. This is a much better bypass from an adversarial perspective
or 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. 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 wrote a tool that we're gonna describe in a second that does,
we call it unsecure boot, 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 we'll, it's the next slide. You wanna talk about this?
So one of the reasons that we wanted to have this tool that what we're gonna 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 wanna run a bunch of other things.
If I wanna 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 wanna 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, the security two protocol. You can literally just call locate protocol and give it the GUID, 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 a 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 gonna just get EFI success, it'll go ahead and run whatever you want,
no matter if the signature is broken or the signature doesn't exist, or whatever. So it's a really easy fix. This also prevents further measurements into the TPM 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 gonna 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 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 wanna 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 with the 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 gonna 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 the bootloader, you need to be admin, right? But the, what's the, it's called service? Well, Microsoft.
Microsoft has 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 UAC me on GitHub. There's a set of, what, 60 or 90 examples of how to bypass UAC. But in our case, we found something that we're gonna call LoL installers. Anyone here familiar with LoL binaries?
Raise your hand, LoL bins, have you heard that term? Okay, cool, there's a lot of people. So for those who did not, LoL bins are basically binaries that already exist in the system, that are trusted, but you can use them to sideload something that's not. But in this case, what I call a LoL installer has to match the criteria.
Now, it's not the lame DLL load and the DLL sideload shit, no. This has to be, to be considered a LoL installer, has to be a signed installer from a major brand, major OEM, that blindlessly loads an unsigned executable. If you match that, that's a LoL installer.
This example, we started with a Realtek on the left. We found one of those, it's a setup for a driver that's from Realtek. It looks nice, you go, you send a phish email, look, you gotta install this Realtek driver. But it looks lame, because the icon is crappy.
So we found a Microsoft one, so super, super legit. By the way, both of these are in the GitHub. If you wanna play with a UAC, arbitrary UAC bin, LoL, 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 gonna 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 DAL 5520, we boot it up, normal.
You see there's nothing on the screen, there's no red skull. We log in, we check email. Oh look, we have 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? Drivers, update, setup, installing. Okay, I'll wait. Oh, crap, it's gonna sign me out, done. It's IT's will, you know? So we have a red skull. The bootloader's been swapped.
It also did the usual WPBT, Microsoft backdoor, where you drop a file. You can check our 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, virus is good.
Right, I can keep working. I just got a scare, I'm just paranoid. But there's an executable in startup. So we switched 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 bootloader on a system from an email. And secure boot is still on.
Thank you. Thank you. Yeah, so we gave 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 gonna, I think we have one last video. But by the way, if anyone has any questions they wanna interrupt, feel free to interrupt.
So how would we do this if we wanna do the TPM avoidance? So let's assume you already have infected the system prior to BitLocker, right? 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, right?
You can switch it off to a new payload, keep your rat maintained or whatever, if you're a nation state, plug your ears. So how does this really, how does this translate to real life, you know, it's fancy in a graph. In an example, it kinda looks like this. You boot, there's a smiley, 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.
Screw boot's on. So we open a shell. This is to show you how, an attacker will do it more stealthily, but visually, you mount the EFI system partition like this, mount vault, 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 elite, and we have smiley.efi. We change 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. Come on, reboot. And we see the red skull, but at this point, BitLocker recovery should kick in, but it doesn't. Is that a whoop?
Thank you. So yeah, then we go and check everything. BitLocker's on, and secure boot is on. Trust me, it's on. I'm gonna skip a little bit. We have five slides in five minutes. I'm gonna 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, it 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 suspend 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 wanna use as an attacker. To suspend BitLocker. And re-register your own bootloader or whatever. Fun story, you wanna say something? Just to follow up on that a sec, this command to suspend BitLocker,
you can use that as an attacker, where when you replace the legitimate bootloader with your malicious bootloader, you just suspend BitLocker, reboot, and it will measure your malicious bootloader into the BitLocker measurements,
so then after that, you need to have your malicious bootloader, and if you replace it with the legit one, then you'll 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.
I'm sorry for my French, 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, Asrock, have a copy of the latest version so they can update their BIOSes and update all the systems in there. 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 on your BIOS. If you really care about this, if you tend to have your laptop or computer, I don't know how your computer be away from your line of sight,
wow. You just put a password on the BIOS, then 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 it does a lot of nifty cool stuff, but it's enterprise, right? So again, remember, we're also talking about this threat for Windows home users and non-corporate and enterprise people that use this as gaming, and 15-year-olds that wanna play Apex Legends all day.
Or you can use hardware from a closed garden, like Microsoft Surface. It's all there vertical, so they control the firmware, the bootloaders, everything. They have their own trust chain. It's great if you really wanna do that for Windows, if you wanna be a secure, you have a question?
So the question was, how does this work with secure-core PCs? You mean replacing the bootloader? Yeah. So secure-core PC is a name Microsoft gives to a set of features that are enabled.
Is it 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 documentations for certain models and things, but yeah, we can talk about this later in the Q&A. So just to follow up, one thing that they are doing
with secure-core PC is this is all bootloaders assigned by the Microsoft UEFI 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 kinda get the drift.
They get the DBX update, they issue not just a DBX update, they also add a DB update, which means they add another CA to the chain that allows other bootloaders that are assigned 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, 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 ask, but we assume that they just don't wanna share that information because it's Microsoft signing this. Keep in mind, Microsoft is the one signing all the bootloaders for the shim,
so everything that loads Canonical and Fedora and all the grub, there's a shim signed by Microsoft. There is an open-source committee that does all that stuff, but there's a CA for Microsoft UEFI that sits in everyone's firmware. And the vendor response sign in here. 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 us CVEs, 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? Kinda, but it's not done-done. Why? Found these tweets yesterday. Apparently, some people are already seeing this update fails. They tried 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 off and turn on again. It's possible that within a week, if a disk 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. And our Linux system.
Second to last slide. With the 302 vulnerability, that's the boot order 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 bootloader to load them all.
And yellow. That's it. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Q&A will be right here in the hallway. If you want to ask questions.