uh these speakers really need no introduction but they will introduce themselves and let's
give them a big defcon welcome come on ladies and gentlemen
thank you everyone for coming all 12 of you um before we begin
so before we begin thank you for coming for our talk to our talk um we're gonna try to be quick
because we have a lot of slides and uh a lot of content and oops and uh yeah and a couple of
trigger warnings before we begin there's a lot of lord of the ring content in the slide deck
if you have a problem with it
is your problem go see a therapist um 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
uh 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 we're going to try to make it fun and
entertaining for you guys uh quick introductions i'm mickey that's jesse that's our twitters we
work at a company called eclipsium moving on the uh the agenda we're gonna 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 a
about BIOS or security or anything, 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 the summary we're going to
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 a boot,
everyone needs it. It's awesome, use it. How it works. When you power on your computer,
usually normal boot sequence, you power your computer, there's some magic happening,
then the firmware starts running, firmware finishes its run, hands it off to the assigned
bootloader, that is assigned in the firmware, then the bootloader goes and starts loading
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 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 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, yay, I'm good, I'm authenticated.
In this slide deck,
we're gonna focus on this part.
That's all I wanna say, I'm sorry,
I kinda 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 execute
ables 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'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 bootloader
and passes off execution to the bootloader.
So focusing on that area a little bit,
PEI core does things and then it,
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 bootloader in order to continue that change.
So it's a 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, but it was released a few years back, I don't remember exactly, but it was released a few years back, I don't remember exactly,
said to go in by LongHrd and Slipstream.
The, I'm gonna butcher names,
so I just put Twitter handles
and screenshots in the deck.
If I mispronounce the names, apologies.
Sid Bouskut 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 feature.
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 other ‑‑ 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, right?
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.
Okay.
So 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 disc.
For those of you who are Gen Z, that's the round thing.
It's what you use to boot off your ‑‑ put your computer off if something happens
or whatever.
They 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 disc 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 disc.
The disc 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.
Remember 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 and change the boot order to that, and you're golden.
Another one that we discovered.
I'm sorry.
A while back was we called it boot hole.
Basically you find 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, and others added on top of us.
2021, there were eight more, and 2022 there's just one for now as far as I can tell.
But you can definitely see that there is more attention.
If you want to read more on that, I highly recommend go to the Grub 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 disable.
Obviously you can do horrible things, but it can also affect secure boot.
Some of these examples are the binary vulnerabilities, Sentinel 1, ESET, Lenovo's ESET,
and BSSA one 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, like 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, like, yeah, root kits, boot kits, security.
What's the, uh, APT or adversaries, malicious actors?
What's the word for today?
There isn't even a MITRE ATTUCK 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, right?
.
.
you don't 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 dollars in
market share the gaming eSports was 155 or something like that 160 billion
anyway it's a lot of billions it's huge they're kind of similar in an amount but
there is a lot of money in gaming and 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 TPM 2 and that secure boot is on like where have we
ever heard like TPM and secure boot enforcement outside of an enterprise
it's 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 in
the open source source community there are there's Maddie and there's Samuel
too much Samuel has or Sam I don't know her also Sam you know it's just a Samuel
too much Samuel has or Sam I don't know her also Sam you know it's just a Samuel
those two github repos are very very good if you are interested into into doing the
pure OS research and secure boot and all that stuff the the Samuel too much
example here is a driver that loads during boot that allows you to
communicate with the runtime environment from the OS so basically bypass the
there you don't really need ring zero you
can get direct memory access and do all kinds of things using hooks anyway I
know I'm not only getting through 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
Manny 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 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 one 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 to w3
cheats dot com or org or net whatever XYZ it's called today I forgot and they
they sell you a a file scheme basically it's a file structure of a bootloader
that you put on the 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 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's a video there is that there 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 a getting a hardware ID I
To do that, you have to plug in this USB.
Is it playing?
Yeah.
You plug in this USB.
You have to say, go to the boot order.
Go boot from this UEFI USB partition.
And then it goes, it loads their boot loader 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 Face IT Cheats.
It's like a full-on normal product.
There's like a...
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 or whatever.
But that one popped up into our radar because it uses a boot loader.
And it has the 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 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 ESP 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.
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 a...
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, 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 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 and 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.
Disabled.
Disabled 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, 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 a vulnerability is exploited.
If you know the movie, you know what it means.
We have three vulnerabilities.
That we categorize into 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 assigned, their own shim.
That loads among other files that are signed by that company.
One of them is a UEFI shell.
So, 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 is, you know, it's not just a shell.
It just 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.
Wait.
Yeah, basically 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.
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 startup's script.
So, if you do want to have a back door or something automated on a system.
You can.
Put a script in.
And it will just execute it every time it boots.
So, it 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 ten megs or eight megs.
It's a QMU 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 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.
This is the drive.
I try to run the EFI.
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 later on 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.
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 not recognized.
We patch it.
And then we run the file again.
It says hello world.
Okay.
We hackers.
We have to put in a 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.
All right.
Wait, wait.
Don't clap yet.
And secure boot is on.
Thank you.
I don't know exactly why.
It stays on.
But.
It's funny.
Now to the best one.
Best and last.
We said two categories.
One was UEFI signed 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 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 at it.
73 kilobytes.
Tiny file.
Throw it into Benja.
Look at it.
And it's 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 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 the file up.
And jumps to the start of the code in it.
This is a much better bypass.
From an adversarial perspective.
Or.
You know.
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 is.
There are samples of this.
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.
So part of the.
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 unsecure boot.
Because it looks for the.
Security to architecture protocol.
And the security protocol.
And finds those handlers.
Find the.
Find the pointers to the handles.
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 will 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.
Security two protocol.
You can literally just call locate protocol.
And give it the GUID.
And it will 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 will go ahead and run whatever you want.
No matter if the signature is broken.
If the signature doesn't exist.
Or whatever.
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 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.
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.
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.
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 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 the bootloader.
You need to be admin.
But.
The.
It's called service.
Microsoft.
Microsoft has Windows servicing criteria.
Where they decide.
The 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 60 or 90 examples.
Of how to bypass UAC.
But.
In our case.
We found something that we're going to 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.
No.
This has to be.
To be considered a LoL installer.
Has to be a signed installer.
From a major brand.
Major OEM.
That blindly 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.
A phish email look.
You've got to install this Realtek driver.
But it looks lame.
Because the icon is crappy.
So we found a Microsoft one.
Super legit.
By the way.
Both of these are in the GitHub.
If you want to 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 going to see in a second.
In a demo.
And runs stuff as admin.
So again.
How did this work?
How do we infect a system using this?
So this is the same doll.
5520.
We boot it up.
Normal.
You see there's nothing on the screen.
There's no Red Skull.
We check email.
Oh look.
We have an email from Microsoft.
Update.management.
We must install this attachment.
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?
Look at that.
Very suspicious.
I must not trust this.
I'm a dumb user.
What do I know?
Click yes.
This must be related to this update that they gave me.
I don't know.
Installing something?
Drivers, update, setup, installing.
Okay.
I'll wait.
Oh crap.
It's going to sign me out.
Done.
It's IT's will.
So we have a Red Skull.
The bootloader has been swapped.
You can see Microsoft back door 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 is fine.
Looking good.
It's not over yet.
Wait.
There's no detections.
No infections.
The virus is good.
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 it's working.
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.
Yeah.
So we do.
We give this example.
But there's also things like BitLocker.
BitLocker is doing measurements of 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.
So.
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 kind of a fun demo that we'll show in a second.
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.
So we're going to.
I think we have one last video.
By the way.
If anyone has any questions or 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 a new payload.
Keep your rat.
Maintain or whatever if you're a nation state.
Plug your ears.
So how does this really.
How does this translate to real life?
It's fancy in a graph.
In an example.
It kind of looks like this.
You boot.
There's a smiling.
This is the version one of the bootloader payload that's currently on the system.
You boot into Windows.
All right.
BitLocker is on.
Screw boot is on.
So we open a shell.
This is to show you.
An attacker would do it more stealthily.
But visually you mount the EFI system partition like this.
Mount vault.
Drive name.
Slash S.
We take the bootloader.
We take the startup script that we have already placed as an attacker.
We edit it in notepad.
Because we're leet.
And we have the smiley.EFI.
We change that to.
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.
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.
Is that a whoop?
Thank you.
So yeah.
Then we go and check everything.
BitLocker is on.
And secure boot 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.
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.
It's also the command line you want to use as an attacker.
To suspend BitLocker.
And reregister your own bootloader.
Whatever.
Fun story.
You want to 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 a legit one.
Then you go into BitLocker recovery.
Yeah.
So.
If you run Windows.
You can get the update since August 9.
Patch Tuesday.
If you run Windows.
You're fucked.
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.
It's a big landscape.
There's a lot of vendors out there.
And if you run Linux.
So.
How do you avoid the bypasses?
So there are things out there.
That can block you from avoiding the bypasses.
The easiest one.
Is just put a password on your BIOS.
If you really care about this.
Tend to have your laptop or computer.
I don't know how your computer.
Be away from your line of sight.
You just put a password on the BIOS.
And don't forget it.
HP Sure Start has.
Mechanisms to check.
So.
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.
It's enterprise.
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 want to 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.
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 bootloader?
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.
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.
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.
UAFI third party certificate authority.
And they're having OEMs.
Disable that by default for secure core PC.
Systems.
So.
Let's see.
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 bootloaders.
That are assigned by that CA.
If you ask me right now.
What's in the DBX.
What's in the DB.
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.
They don't say.
We ask.
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 bootloaders.
For the shim.
So everything that loads canonical.
And fedora and all the 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.
That sits in everyone's firmware.
And the vendor response.
I didn't hear anything from the vendors.
That was 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 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.
But it's not done done.
I saw 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.
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.
And 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 preboot 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.
We'll be right back.