>>So thanks, everybody. um. We're here to talk about a bunch of scary low level stuff that
nobody knows about, right? So we're going to give a summary of attacks against bio sense secure
groups. A group of here is from Intel Security. The rest of my friends here are from a group
called Advanced Threat Research and it's their job to find new attacks and find mitigation so
we can deploy stuff and make things better overall, across all sorts of platforms, right?
I'm actually from the products security and response team. We uh, coordinate a lot of these
issues. Been working with our friends at Miter -- presented yesterday and gave an awesome
talk. We have been coordinating a lot of this stuff, and, you know, we'd love to hear about
more, even though we'd like to believe that there isn't more, but there's always something.
And we'd love to hear from you at secure@Intel.com. Um. So we're talking about bios, right?
And so bios, um . . . in the beginning, there was what we now call legacy bios and it involves
a lot of texts. Textual menus and according to this slide, a lot of blue, comes in various
shapes and sizes, but mostly just blue. Um. And it had to do all of these things. The system
powers on and it has to go and put some instructions in the spy flash to start getting the
system ready. Um, we're going to start running out of cache, we're going to start configuring
memory, start running out of memory, we're going to start configuring a bunch of devices
and get everything ready to go, run a bunch of option ROMS and eventually we're going to find
some kind of hard drive or boot media and we're going to go ahead and find the master boot
record and load it and then that thing will start up on operating system, we think. And then along
came the unified extensible firmware interface and we got icons. >> [Laughter]. >> And
it's really interesting because now we also got a new color, black! And then I mean it did
all sorts of good things, but really it's more about creating a standardized set of what I
would call APIs, right? Things that you can rely on having happened by the time you run it.
And here's this slide, right, and everyone who has presented on security regarding UFI has
put this slide in their presentation, so here it is. We're doing that, too because
it's obligatory right? And what it's really talking about is there's different phases. It
breaks up the whole boot process into these different phases. And what is really going on is you
are building upon the phase before you. It does all the same stuff that I was talking about.
You start out running out of cache and then you go ahead and set up memory and then you go
ahead and configure all these devices and eventually you come to the point where you're going
to make a decision about what you're going to boot off of. You go ahead and make that decision,
you load up a binary and then that thing is a boot loader and loads up an operating system,
right? So um one of the things that UFI does is it gives you, well, two things. It gives you,
it tries to get up to 32 bit virtual very quickly and it just starts to run things. Just like,
you know, regular loading of an executable and then it also gives you these run time
services which are standardized APIs that you can call even after the boost, uh, bios has
finished its job and you're running at run time. So with this came a standard for secure
boot. Right? And the way this sort of works is that, I'm trying to see my slide here, um,
it's basically checking signatures, right? We start with assigned bios because if
you could put whatever you wanted in the spy flash, I don't know how many of you guys heard
Miter's talk yesterday, but they said it very nicely, right? Gee, what attacks can I come up with
that I could do if I controlled whatever was in the spy flash? Which is the first thing that
gets executed when the machine powers on. That would be any attack you can think of. So.
It's pretty nice, it's pretty nice if you can get there. So we have to start with this ability
to ensure that what's there is right. And that's where the signed bios update comes from.
And after that you start checking signatures on everything that runs after you.
Right. So we get to the stages we're running a Dispatcher and we'll check a signature before
we run it. We get to the boot loader and we'll check a signature before we run it. And
that allows you to create an operating system secure boot that can then check the
signature on all of the drivers before it runs those. And we'll be talking about attacks against
all of that. And so, let's start. Well, so the way we're going to go about this, is we're
going to go around this wheel and we're basically going to talk about different facets of
attack surface on platform firmware. And we're going to start with the spy flash. Now
like I was saying, it's a pretty nice place. And so what we do on the platform, so the nature of
this, first of all, step back. There's a whole bunch of stuff here. There's, uh . . . We're
going to blow through it really fast. That's why we mentioned we'll be in the hardware village
afterward, if you really want to go into some detail and try to understand it with us we'll be
happy to walk you through it. So. Back to spy flash, like I said, it's a really good place
to be. There's two real sort of methods, to protecting it, right? One is based on system
management mode. System Management Mode is a different mode of the CPU. It executes out
of a kind of protected region of memory. And it's protected such that that you can't read or
write this while not in system management mode, all of the sudden you transition into
system management mode and there it is. Um. So one method is to use system management mode to
protect it. You set a bunch of, uh, you basically disable write access and then you lock it and
if you try to re-enable it, it will generate a system management interrupt and that's
what transitions the machine into system management mode and it starts executing the SMI
handler. Um. So you have to set a bunch of bits and a bios control register and that will
lock the spy flash from writes and it will also, um, it can also force writes which can only
occur when in system management mode. The alternate way if you're not using SMM would be to
use the spy protected ranges that are PR 0-4, there's five sort of ranges. And you can
basically set up a base and a limit and that region gets protected and you can set it to
be write protected. And it will be that way up until your boot platform. So there's two
different methods, you know, you can sort of see what your platform does. You can go and
find the bios control registry, you can read it and say, gee, what bits are set? So you can
do that with some tool manually and that's kind of a pain, so we wrote a tool called chip set and
Miter has a tool called Pernicious. You can basically go and see what these bits are set
to. So you can see at the top there you have got bios write enable, right? And then you want
to see that's disabled, so zero. You've got Bios lock enable, you would like to see this is locked
and that's what will generate the SMI. And then you have got SNMBW3. That forces the write to
occur when you are in SNM. So then we are checking the other mechanism as well. The red line
down below is talking about what the spy protected ranges are doing. So you've got the range
itself and write protect, and it will be checking to see that your covering the entire Bios
region. You can do either one of these things and it can work. So if you don't cover the
entire Bios region, then you're allowing somebody to write to that. And if they do that, then
you get things like what Uri presented last year at blackhat where you can just sort of write
whatever you want there, which could be shell code, it could bejust random junk that breaks
the platform, it's bad. We're going to push all of our demos to the end because we've got a
lot of stuff and we're afraid of running out of time, so we've got them, we'll get to them at
the end. If you are really interested or if we miss stuff, come see us in hardware village
and we'll have everything for you there. So here's the nice one, Teddy Reed presenting
something really cool recently where he was looking at a bunch of Bios updates and seeing what
they were doing and in particularly seeing who wasn't doing that. This was really
interesting. He calls this one day from hell, which is kind of a good word for it actually. In
this update you can actually see the patch is adding the lock bits being set. All right? But
remember in the last slide I was actually saying there's a few lock bits you have to set, and
there are a couple of things you have to do and it's not actually doing them all, so that's even
more interesting. Um. So the first mechanism was the system management mode, right? If you
use system management mode, then you get a system management interrupt triggered when you try
to flip -- when you try to flip the Bios write, the write protection off. What if you
could suppress SSMIs? If you could suppress SSMIs then that system interrupt would not
occur. The system would simply have the spy flash unlocked and now you can write to the spy
flash. Well, Miter presented a little bit earlier this year an attack where if the SMI lock bit
is not set, then you can actually disable SMIs. And that does what I said, it kind of
causes a problem. So basically you want to check your platform to see that this is set up and
that it's locked, in particularly that it's locked. Remember the other mechanism,
you can use the spy flash itself with these protected ranges. Well, you have to configure
those properly, right? So that's what we were talking about earlier, but, you know, you also
have to lock that. So you can set it up and then not lock it and then somebody can change it.
So that's what the F lock down bit is all about. Again, you can just check for that. So now
let's talk about a different interface. We talked about spy flash. Let's talk about Bios
update as an interface itself. We're talking about these Bios attacks and we're thinking, this
is really complicated, low level stuff people don't know anything about, so you'll never see it,
right? Well, Mebroni is an example of this actually being done in malware, right? So they
basically used a particular Bios that did not enforce any sort of protection on its Bios update
interface, simply used that Bios update interface to introduce its little boot kit directly
into the Bios. Another issue, even if you have tried to protect the interfaces, there's
occasionally some data that you don't -- can't really trust. So a few years ago, the talk by
invisible things lab showed an issue with an Intel bios where basically the image that gets
displayed on your screen when you power up, yeah, that was just an image that was being
parsed and it was not really verified in any way, so they found on inner droner flow that
allowed them to take control that bios there just by substituting that image.
Similarly, a little while ago Miter published an interesting thing with the update packets.
So bios updates often, they break up the update into a bunch of little sections, right? Which
then need to be put together when, after you reboot and you're going to actually install
the Bios update. Well, what they found is that when they were putting this together, they
were talking the fields of these packets and they were using that in an MEM copy and then they
could basically use maliciously formed packets to take control right as you are doing the Bios
update itself. So then there's SM RAM. So I mentioned some of the protections are dealing with
system management mode, right? So system management mode, I think I described it as having,
being a separate execution mode that's protected. Well, it's protected as long as it protects
itself, right? So the first bit that we'll talk about is the sort of legacy or compatibility
SM RAM. And I think this is best done with a picture. So normally you have code executing
and you're writing memory addresses and you're usually writing to D ram, but
occasionally you find things like memory map bio. With SM RAM when you are in normal execution
mode, you will basically pass through and go straight through the system bus, right? When
you're in SM -- or when you set up SM ram, you need it to be able to talk to actual D ram,
right? And that is flipped with these, with this particular register, some particular bits
in this register. Basically bios will set it up and say, it will start up open and it will load
up SMI handlers there and close it and lock it. So you want to check it is actually closed and
locked in SM ram. So after that attack, a few years later, so that was found like back in
2006, I think by both Invisible Things Lab and the Lloyd group. You have got the same people, a
couple years later, figuring out, gee, if I -- if I'm really just running out of ram, the way
the processor works is it just caches stuff, so if I can get the instructions that I want to
execute in the cache for those addresses, then I could get it to run whatever I want. And that
works, right? So Intel introduces these system management range registers which
will force the non-cached area for those ranges that would be SM ram. So what you can do is
just look at the platform and see, are those things configured? Is that set up
properly? I think I'm going to turn it over here so that the rest of this talk can be in
Russian, because I think that would be really helpful to everyone because it's really
easy to understand this stuff. >> Hey, everyone. Thanks for coming. Even if you were here
for Dan's talk. I don't know if this mic works or not, but, I mean, so I didn't know the dude
actually knew that much about bios, yeah, so it was awesome. Okay, I'll continue describing
the attacks against SM RAM, it's important. There are still questions. You know, why do you
need to get into the SM RAM, why do you need to compromise SMI handlers? If you have S-kernel
privileges, for example. You can do pretty much everything. Well, there are a couple of reasons to
do that. For example, according to Government, you can get more influence. You know? According
to our friends from Miter team, you can be bitten by a tick or a flea. Just imagine, just think
about that, none of the other exploits can get you fleas. So on a more serious note, SM ram,
first you gotta to code there and it's pretty much protected, so you cannot really get it out
there. Plus it can patch the OS, it can patch the head provisor, more importantly it can patch to
Bios so it can get persistency. As we showed some time ago, you can get the early compromised
device you can bypass, or you can melt the evil main attacks even against the full decryption
systems that do use TPM. Or you can bypass security. So continuing in the line of the
attacks, one of the attacks that has been demonstrated using the chip set remapping capability,
without going into gory details, basically on the platform you have low MMIO which can be
gigabyte and if you have 8 gigabyte of memory, you don't want to waste one gigabyte of
memory to the MMIO. So there's a mechanism called Reclaimed. It intends to reclaim that memory.
The way it works, there's a window, if you access like Windows, typically about four
gig, it will get remapped by a chip set to the place, to the D ram behind that or lost to that
MMIO. So there's -- it has to be locked because if it's not locked then the molar can use
that, and the way exploit works is that the attacker can drop this boundary between D ram and
MMIO below SM RAM and use that remapping mechanism to remap to the SM ram, so now your SM ram
is in the memory covered by MMIO. So obviously the mitigation to that is just use
the, you know, lock down the configuration. Don't allow a OS malware to reconfigure. Oh,
yep, that's a good nice slide with a nice picture of how it actually works. This is a normal
memory map. That's how it actually works, the attack. You drop TOL, you access the memory
reclaim range, about four gigabits, and the chip remaps it to above, which is now SM RAM.
You modify the SM handler, you inject a key logger or something like that, and then you return
back to that configuration. So your SM has malicious code. And there's a check for that. So
I'll be flying through those type of slides. So the other type of attack and I'll show you
a picture, so normal, normal system looks like that, including graphics and graphic
stuff. So for example, there's an MMIO bar that points to a graphics translation table. And
so they are used to translate access coming to this graphic separator which is the second
yellow box. And it translates access to that graphic separator to graphics memory. However,
that can be used to attack SM RAM as well. Assuming the configuration is not locked, as
in the previous remapping attack. For example, the bios forgot to lock the TOL. You can
see how that would be used to attack. Somebody drops a TOL, similar to the previous attack.
But instead of using remapping, the exploit can now -- you can see that SM ram is now in MMIO,
so when SMI event occurs, CPU tries to fetch something, but not from D RAM, but from MMIO,
but there is nothing there. So the attacker overlaps the graphic separator on top of
that. So there's a double redirection and it redirections the graphic separator, so
according to GTT interest that have also been replaced by the attacker, somewhere else, that
is the third redirection. I call it in the tradition of Jean Claude VanDamme, I call it
triple redirection attack, so using these multiple hubs the attackers to force CPU to fetch
the code from some other place outside of the protected range. So the solution is the same as
in the previous attack. It's -- just make sure the attacker cannot do those tricks, cannot
do the reconfiguration. So you heard there was a lot of research on DMA attacks and if
someone can use DMA let's say from a graphics card or network card, if firmware on the card is
compromised, or even from the west kernel exploit that directly asks some of the cards
to do the DMA to protected memory, you want to be able to protect the system management
mode and a code from those kind of attacks. And the way it's done in the platforms is there
is a protection on the chip set level that basically says there's an enough stream
transaction, memory targeting SMN memory which is defined as BoV Tsvg base, which in that
case, just lock that, don't allow that. However, it still relies on the platform channel,
the bios firm ware to lock down the configuration. So for example, in the previous attacks
if the bios forgets to lock down configuration and allows malware to modify it, the malware could
change the base of where the SM ram is from, perspective. And, therefore, once you do that, now
the attack, the DMA attack can work. So the DMA cycles are below T seg and they are allowed
to get through to the memory. Right? There are two actually variances of this attack though.
One variance is regular DMA from some unknown card, for example, a network card at the bottom of
the slide. And there is also another variant through the graphic separator, which is
treated as a DMA as well. Yeah, and in a couple of weeks we're releasing a test for the
vulnerability in the open source section and you can take a look at that. So other than
protecting SM ram, obviously there may be other issues, you know, issues with the hardware
configuration that it can be improperly configured, it can be reconfigured by the malware and
that can result in certain attacks on bios, secure boot and so on. One of those attacks
was demonstrated in 2007 at POC conference by a person from McAfee and it was a bios swap,
but a block/swap attack. There's a mechanism in trip set that allows you to do full tolerant
update of the bib lock. The bib lock is the top most lock of the spy flash ware. The bios is
where the reset factor is and so on. So normally CVU coming out of reset, it starts fetching
instructions from the catch line below for a gig. So FFFFF, zero address. That's the reset
vector. However, in order to do the full tolerant update, there's a mechanism that allows
you to switch where the reset vector is. Basically which block the reset vector will be
executed in. To show that on a better picture, so the top most picture is the original boot and
the bottom part of the slide is when this top swap mechanism is enabled. So you can see that any
access that targets spy flash a firmware hub or basically anywhere bios firmware is, it
gets swapped, so now the reset factor, it's now an alternate bios bib lock, backup bib lock.
So obviously if bios allows to do those kinds of tricks to the OS malware, OS malware could
enable top swap mode and then because this has to survive the reboot, the malware reboots the
system. The CPU will fetch the instructions from somewhere else. It could be an OS and
you'll get an unbootable system or it could be malicious code, if that piece, if that alternate
bib block wasn't protected, it could be a malicious virus. So the way to mitigate that is
essentially, you know, block malware's capability to modify the bib block. Okay, so now
obviously people realize that attacking SM ram through some hardware tricks or configuration
tricks is not enough. There's a whole bunch of stuff running in the SM ram those are called SY
handlers. And they have been developed a couple of decades ago with nobody thinking about
security back then, well, not security of SMN. Not that role. there may be bugs there. One of
these types of attacks had been discovered and published in 2008 or 2009, I forgot, so basically
you have SM ram and you have a bunch of firmware running. And I'm due for a shot, sorry.
>>Take your time. You all know why we're here! >> [Applause]. >> I just want to
point out, as we were walking up here to shot these guys, there was a guy walking out and I
said, why are you walking out of this talk? I thought this would be a pretty good one. He said oh
man, it's over my head. I'm a colonel programmer from way back. That guy is a pussy. >>
Oh, you? You've got it going on. All right, how about some love for the new speakers. >>
[Applause]. >> where are his shots?! That was wrong, that was wrong! As you were. >> Okay. So
where I was. Oh man, memory plays tricks on me. So, types of vulnerabilities in the SMI
handlers. The first type was discovered, as there are a lot of SMI handlers, but a lot of
the routines that they use, let's say talk to hardware, talk to RTC, talk to registers and so
on, they are wrapped in two functions. But there's a precious space, spyflash is a
precious space and so you can not really move that code to the SM ram all the time. You already
have that code in the bios, which is in the D ram. So why not just use it and call it? And
that's what SMI handlers did. You can say call F 0000, segment selector, call segment
selector, with some EIP. And it happens to be translated to a physical address in F segment
below one megabyte which is not protected. So that's how it works. Somebody found this out
and replaced that function that the SMI handler calls with the malicious code and the SMI
handler will do the job for you. It will just invoke that function. So yeah, that has
been published. And what's interesting is that the vulnerability disclosure just
disclosed fourteen issues in one SMI handler out of 30, which amounts for hundreds in one
single bios. And remember that flash ware typically uses the same bios. So, in going to EFI,
obviously this type of vulnerability, this is almost away, almost, because EFI bios
still want to invoke something from outside of SM RAM and in that particular example, the
SMI, the EDK based SMI handler, it wasn't directly calling the function, it was actually
reading the function pointer from the ACPI, from the normal Intel memory which is not solid,
it's in D RAM, and then calling it. So pretty much the same type of problems, but slightly
different. So now I am switching to the attacks against secure boot. We've been
researching that area for a year, year and a half, and I'm giving the microphone to Alex
who will start with the attacks against secure boot. >> My name is Alex. So I would
describe a little bit about secure boot and how we secure boot. So basically there's most
important thing in secure boot implantation is hierarchy and there is the platform key that
you set the vendor key. This you need to verify the exchange key and the change key needs to
verify the wide list and set list signature for modules and banner which can load the secure
boot, and boot disable. platform key is stored in normal memory and spyflash. It is a variable
which is protected and bios check -- if bios can find the platform key, it will allow,
enable the secure boot. If not, bios assumes that secure boot is disabled. So basically this is
where we create our exploit from secure boot bypass. For this exploit, you need to have an
ability to write and protect mechanism bios, so basically we will talk a little bit about
this exploit. So we just as a regular variable, the platform key has a name and body, so if
you corrupt the name of the variable, then bios didn't find the variable and you can assume
bios is disabled, so you have a secure boot. And as you can check in this slide, in the left
hand we have the original down post spyflash platform key, and on the right hand we have the
identification like this and we have this corrupt platform key. There is a high level picture
of our attack. So. We corrupt the platform key to compromise bios enough so that we install
boot key to unify partition and compromise the full system. And this is the demo. This part
should be joke, but I skip it. >> [Laughter]. >> We want to start thinking about how we can
bypass a secure boot, and how bios should implement secure boot internal. This should be
the variable of the secure boot enable which is enabled and by here should be different and
related to this variable. And you can check and it should find. So the next very good
experiment which we did, it's great too, was full spy flash. One of the secure boot enable
and one secure boot disable. And compare this dump. So if you are trying to do that, it's not
really easy. But after that we implemented some forensics. So after that we implement the chip
set and you can sparse the spy image, and extract all DLLs, all D drivers, all EFI variables and
compare it independently. And to be cached, we're interested in BFI variable, the set up
variable, it's a run down variable so you can modify it from Windows EPI. And if you
flip back to this, you can very easily disable secure boot. So basically just run very simple
Windows EPI function and flip two bits from three you can do that with security boot. So that
will be the second demo. And we will continue to talk about this. >> The policies,
policies is the way of the bios to configure the image verification behavior. So they
may choose to skip image verification if the image is loaded from protected spy flash
or choose a different behavior in the image verification is failed. Like, ask a user, or It
allows the image execution. So this is how it's implemented in open source, ETK2, so as you can
see there, there are fixed values taken from the configuration database, so they
cannot be changed in run time. But sometimes bios may choose some flexibility and it decide
can be set up. So this is an actual screen shot from an a secure boot image verification
violation. And that variable, did have these values, after some trials and errors, we found
the location. So here they are. As you can see this 044 is for optional policy, fixed media
policy and removal media policy. 0 is for the all execute, 4 is for deny execution. So all they
need to do is just modify the set up variable and change the subset notice to zero. And we
have execution. So this way the secure boot is still enabled, but no verification is performed
so you can load whatever you want. And this issue was discovered together with the
Miter guys -- this is a slide from their presentation. They do a reverse engineer and this
shows the values for the policy are taken from the set up variable. This should be a demo.
So a couple of guidelines to bios, how to avoid these issues. So first of all, if you protect
the settings, if you decide to move them into EFI variables, make those variables
inaccessible and don't expose them to a breaking system and untrusted software. The
variables are authenticated, so only you can change and update them. And to check that the user
is physically present and modifying those. And, of course, the default and image
verification policies to secure those. Don't use always execute or allow execute and default
variables. And image verification handlers should take care not only on secure
boot settings and policies, but it should also check if the executed image has a supported
format. Currently the only supportive format for this is the Bkav image software. The
bios firmware can verify the signature and image only if it's Bkav. Sometimes bios
specifications are defined as executable from us. Yes. The two other formats, the first one is
the EFI Bitcord, which actually is the same Bkav image wrapping around the EFI Bitcord. And
there so-called Terse, executable G. Which is not a Bkav image. But the only
difference from the Bkav image is G hello. This is much smaller than Bkav and this was done to
conserve the precise space in spy flash. So the G images are usually always from spy flash.
Let's take a look at the actual implementation inside EFI bios. So the parse spy flash dumped
this and we found that the dixit drivers that actually implement the image verification library.
It's core dixit. E file. So load it into IDA Pro and we found that the function that is
left is the image verification heller and what it does is it calls functions that checks that
the executable image is a valid Bkav image. And it returns an error if it's not. And if
results in an error, the image verification hierarchy just checks, if the error is set. If
not, it will continue execution. But if the error was returned it just returns zero, which
actually is a success. So no verification is performed, it just skipped. So secure boot is
still enabled, but no verification is done. So that is simple. Just get the executable
and bootkey go to T format by replacing the Bkav heller and replace a break in system orders
on the partition and that's it. >> All right, we have 5 minutes and I want to show at
least one demo because we have four or five demos. You can catch us later and we can show
more demos. But a couple more issues, so other problems that we have discovered in some of
the bios, they enable CSM which is a compatibility support module, which allows you to boot
legacy OS on top of the EFI firmware, basically enabling CSM with secure boot. That's a bad
idea. Secure boot should check signatures, but legacy boot doesn't know about the
signatures at all. So the other problems are some of the systems allows the systems restore to
secure boot configuration and keys or set them to restore to default, or clear them. So
remember the first attack corrupting PK? You can clear secure boot configuration which
will disable, which will remove platform key. And guess what will happen? Secure boot will
get disabled. So some of the bios they actually store a bit that tells them to start this
clearing in an unprotected configuration available to the ring three. And this is, was my
favorite. This was not really an exploit because we didn't need to do anything. I mean, what we
did is on some of the laptops, on specific models of specific vendors, what we figured is we
can change the configuration secure bit, we could disable it, but they've implemented a
signature hashing scheme where they actually store the hash, the critical configuration
somewhere and they check if it's changed. And they tell the user, hey, it's changed, you know? So
what they do is they do it three times, wait for two seconds. We didn't catch that attack
immediately. We actually figured this out in a week or so. Then they continue booting with the
changed settings. And this is the cryptic message that you should be able to, you know, do
something in urgently because somebody is trying to put a boot kit your system, within 2
seconds or 3 seconds. So there are other problems with the bios, specifically for settings,
for example, Jonathan Brussard disclosed the vulnerability some time ago that the bios don't
clear the keyboard bar first, you tie a bios password, an HDD password, so you have a
pre-authentication system password and then it lies around in memory and is available to
anyone. The bios need to clear that. And we actually have a test you can use to see if your
bios system is clearing that. Oh, SMI handlers, we have one minute, so I'll just say a
couple words that we do continue research in vulnerability affecting bios and secure
booting, we continue coordination with all platform manufacturers and bios vendors,
specifically we are in the middle of coordinating multiple issues with EFI based SMI
handlers. So in the last words, so one may think all of these attacks require kernel mode
privileges. And typically yes, you work with the hardware, you work with the bios, you need to
talk with the hardware interface, IO ports, P second fixed base, physical memory, so,
yes, technically this is a kernel privilege, but what we have co-discovered with the
Miter team is there are kernel mode drivers that actually do that for you. So you can ask to
write to the physical memory or boards or IO, MMIO or P-sec config and they will do it. And
they are assigned for old versions of Windows that require signatures. So, yes, that makes
all of those attacks, even though that initially required kernel mode privileges as a user
mode. You can compromise bios, you can compromise SMM, you can bypass secure boot, you can
enable attack from user mode. There are guidelines. There's lots of research. I do want to
thank all of the researchers that work in that obscure area, because this is a baseline for
the security of the entire platform. You can catch us, I don't have time even for one
demo, but we will have videos available of all of the demos from this talk or you can catch
us at hardware hacking village. Thank you. Thanks everyone for coming. >> [Applause]. >>
Do I have one more minute? No? We're done. >> Yeah. >> Oh, so really sorry, we have one
more minute, so I'll attempt a live demo of bypassing secure boot on the system we've been
actually been presenting. You can see why we waited until the end of the presentation. So
anyway, so secure boot is enabled. I'm not showing that, although I usually do. So we'll
launch the exploit which is BT header exploit. What we did is we just replace the floater.
That's it. But the bit loader with a different boot kit has a different pattern, that's it.