>> Hello. Thank you for coming to our talk extreme privileges escalation on Windows 8 UEFI
symptoms. (Applause). >> We're from the Mitre corporation. A federally funded research center
let's continue. Here's outline for today. We'll talk about the agony of ring three, yes you
have a minister of command in Windows 8. New lands we can explore, more extreme places
we'll go. We'll be talking about how we can get to these other areas, what we can do there,
we'll be talking about exploits we used to break into these areas from Windows 8. We'll be
talking about some agents into these extreme areas to do our bidding and then finally we'll
offer how you can detect if someone is attacking you at the EFI level. Windows 8 normally
most researchers would be saying awesome I've won. Give me my money and then that's it.
Presentation is over but there's still limits to ring three. There's things you can't do that
as an administrator there's things you can't do. At as attackers we want more power,
more persistence, more stealth and there are limits to what you can do in ring three even as an
administrator so we must escape beyond ring three into other lands that are completely
unbounded and modest to everything. Now that was my introduction. Some of are you
wondering should I have stood in line for this talk. Definitely you should have come to this
talk. You don't have to take it from me. Take it from the authority figure. He said if you
can re-flash the firmware that is so awesome that would buy again that's exactly what we're
going to do in our presentation. This presentation you definitely what to be here for this talk.
Now, so, generally what we're talking about here is post exploitation privilege
escalation, like I said generally once you have the administrator command from
Windows 8 or whatever you're in the post exploitation phase. There are other places you might
want to go to and secure the boundaries in the way to get into those other areas. The
windows kernel, later versions of windows you can't inject arbitrary code into the kernel
because there's the Authenticode, there's driver signing, only signed drivers can
get into the kernel. There are ‑‑ technically that's case. There are some attacks against
this where you can put arbitrary code into the kernel. This attack model has been explored
by other researchers as well. They talk about loading a known loadable design driver. This has
been hashed out. We don't want to talk more about this. We want to explore extreme
possibilities. Here a few other options what we can do in the post exploitation phase. We can
go from admin ring three to boot kick the system. We can go from ring to zero onto the platform
firmware or jump into system management mode. Unfortunately we live in a dark world today
where we could do any of these things at least not trivially. We can't just boot to the system
because it will prevent from us doing. We can't write to the firmware because firmware only
accepts signed updates because there are flash protective mechanisms. And you can't get
into the system management mode because not even ring zero can even read system management
mode, it's protected by the memory controller hub basically. Now luckily for you you're
coming to this talk and we'll introduce the idea of extreme escalation which lets us go from
administrator to ring three to platform firmware. The important thing is on this diagram these
privileges commands are ordered from on the Y axis. The higher you go the more privileged you
are. Anything more higher up than this diagram. There's a platform firmware, if you can
boot the system you get into ring zero and so forth. You can always snake your way down this
diagram. Once you get to the platform firmware you're free to take out all these other
privileged admins. Yeah. What I just said. All right so it's a Windows 8 system. Most Windows 8
systems today most all will chip with UEFI firmware which is the replacement for conventional
BIOS. Almost guaranteed you have UEFI running underneath the system happening you turn on
your computer so forth and so son. Now this is the obligatory UEFI diagram and essentially all
you have to know about BIOS in the firmware is its job is to turn on the computer and
initialize it find the operating system and transfer it to the operating system. Turn on the
computer find the OS transfer. Transfer control to the OS. The other important thing about this
diagram is that it's advantagous for us to break it to the processor as early as possible
because as the boot up proceeds the system becomes more and more locked down. There's more and
more locks placed on the chip set, less things you can do. The earlier we can break up into the
boot of the system the better. The system will be in an unlocked state and we can do
whatever we want if we can get in early enough. By the time the OS gets control the device is
the firmware is like very locked down and there's really not a lot you can do even from ring
zero: Now, Windows 8 has introduced a new special API called set firmware environment
variable which lets you set, well, exactly what it says, firmware environment variables.
Think about these as Unix, Linux type environment variables. UEFI is the same thing, generally
they look like the platform language, the boot order and lots of other crazy things with
all kinds of crazy environment variables in there firmware. Windows 8 introduce an API that
allows a privilege so admin ring free process to interact with these firmware variables. So
essentially what this looks like is Windows 8 can call this API this set a variable to whatever
and many of these variables will be automatically parsed by the UEFI firmware now I went about
thinking about I wants to audit UEFI, immediately when I saw this environment variable API &
UEFI variables I started to thinking about this is like a lot like Linux environment
variable vulnerabilities back in the early 2000's. Back in the day you could do like set term
equals a million A and then call some privilege application X term or something like that is
that it would try to parse one of those environment variables and it would miss parse it and
there would be a buffer overflow. It was like privilege escalation in Linux, that's
exactly the methodology I had in mind when I started looking at these UEFI variables. There's
lots of these variables and some have complex contents like points, likes of arithmetic on
the integers. This is the type of thing where memory corruption vulnerability occurs. I want to
target this as an attacker. We have already found some vulnerabilities in this variable
interface we thought the computer was a set variable there we could discover the
intel that allowed bypassing of secure boot but to be frank this vulnerability is probably like a
five out of ten on the awesome scale that I attribute in the beginning because it only lets
you bipass secure boot, you couldn't re-flash the firmware, you could break the firmware and
it only affected a number of a like a subset of UEFI symptoms. Because it basically came down a
weird implimentation that some of these OM's were using. Five out of ten is kind of cool but
we can do better. This is the BIOS to development system. We have UEFI and intel provides an
open source UEFI references location that's like open source code for how you should program
UEFI firmware. You have these independent BIOS entities like ‑‑ oops running out of
power. So, we have these IBV's you probably heard their names they make BIOs and sell them to
Dell and HP for them to use on their own personal systems. Theoretically American
Megatrends Phoenix will use the code and sell or license that development kit to Dell and HP
and they'll use those development kits to write their own firmware for their own
systems they ship and sell to you. All right. So, the point is if I can find a vulnerability in
the UEFI open source it will trickle down into all these others that affects all these
other Windows 8 systems that are using UEFI. Okay. So, UEFI like I said it's open source so it's
relatively simple. Check out the code and then go to town. Now as attackers we want to zero in
okay I'm sorting out this code, where are the boundaries between this more privileged piece of
code with attacker control data. One of the intersections is the UEFI variables. We know that
many of these are controlled while the operating systems by the operating some it's an
attacker controlled data and the firmware will parse many when they're created. Now, also last
year at Black Hat we presented a Dell BIOS update routine where normally you can only update
Dell with signed BIOs but we found memory corruption vulnerability in the update
routine and we re-flashed the Dell computer to an arbitrary malicious BIOS image. So, we had
this experience and it just so happened that UEFI outlined a uniform capsule update mechanism
updating UEFI firmware. This is not directly culpable or so there's no interface accessible
to ring three code that says start capsule update. This UEFI variable existed, UEFI would
automatically start the capsule process. Even though it's not directly exposed it's
inadvertently exposed. What that means is that we had a very good intersection between what we
wanted to look at UEFI variables and this is what we have past experience with on our updates.
Capsule update that's good, this is a first good target to attacking UEFI. So, this is
basically how capsule update worked. You would have a firmware capsule that contains
things like a BIOS update. You can do other things but for the sake of discussion let's say
BIOS update. Operating system will take this capsule right at the memory in case ram is
constrained and it will like scatter right to the address space. Then the operating system
creates a special UEFI variable called capsule feed data it's a scatter data list which lynx to
the location of all these individual fragments for the capsule in memory. Now, whenever
UEFI gains control it's going to automatically look for the existence of this capsule update
variable. It will go about trying to coalesce this fragmented capsule there was in
the address space back into its original form. So, once it has the UEFI or the capsule coalesce
it's going to pour some of its envelopes that are encapsulating the update and verify that it
has been signed by the OEM because you don't want to have the firmware just parsing
unsigned capsule. It has to make sure it's originating from the OEM, this is OEM code. You
better verify that capsule as it's coming in. Once the verification passes assuming it
does it will consume the actual contents of the capsule so presumably firmware update but
there's also been proposals for running like malware detection independent of the OS its a
general capability but in general you'll see it for firmware updates. All right. So,
with that in mind we knew what are opportunities for actually exploiting this capsule update
process. We know the vulnerabilities have to occur before the pictographic
verification. UEFI will will not proceed, do not pass go do not collect $200. Vulnerability has
to occur before that. Company we will lessing happens before that. The parsing, the capsule
envelopes, many of the envelopes parsed by UEFI before the signature actually occurred so
it has to parse these envelopes to facilitate the signature checking process so
vulnerabilities in these envelopes could be used to highjack control of the
exploiter in the contents of UEFI. The third and final option was parsing within a capsule.
This is where the first BIOS vulnerability was found. In 2009 lapsed from the BIOS re-flash
attack that revolved around the unsigned splash screen on your system so with this intel BIOS
you could update your splash screen and have your company logo, whatever company you're
working for be displayed. This was unsigned content embedded by the BIOS update. There were
vulnerabilities in the parsing of that unsigned splash screen that allowed them to get
control. These are three main attack vectors, the coalescing, parsing of the envelopes, and
parsing unsigned copy within the capsule. Okay. So, UEFI code and guess what you're here today so
we found lots of bugs obviously. The bugs took the form of do not do this 101, so like arithmetic
before sanity checks and multiplication before allocation. If you're a veteran
you know definitely do not do this. If you're a veteran bug hunter, you would have zeroed in
on these things and you would say I think this is problematic like in this case bug number
three, that block is really large. The multiplication will overflow and it will be
unexpected small so these are actually quite obvious like I said veterans will know that.
Yeah, I could have spotted these things easily. We found a number of bugs. We were able to chain
several together to come up with two different exploits. Because we're nerds we like chess so we
named our chess exploits. . While the platform is completely unlocked the and queen's gamut,
the king's gamut it's known as a Dixie phase. Using both of these exploits we were able to get
control of the point the in the UEFI done nasty things and break into things that normally ring
three codes could not break into. When I was auditing this code, like I said many of the
vulnerabilities are easy to spot. The developers were aware that there were possible ‑‑
possibly like bad things that that could be occurring. This says more liabilities, check
out, will do later and so forth and so on. Whatever. Obviously there was an issue and they
didn't bother to fix them. The presence of these really easy to find vulnerabilities and
security critical code that is open source was disturbing to me and we're forced to conclude
guess what no one else is looking at the BIOS. Otherwise you would have found these
vulnerabilities years ago or maybe you found them. But ‑‑ yeah, so other good, you know ‑‑
researchers aren't coming up here and like reporting these bugs or whatever. So, yeah,
okay, these bugs are easy to spot. Kind of weird. Interesting observation. Now, the bugs are
easy to spot. Exploitation was very complicated. This is despite the fact that code I
just showed you runs in an environment that is completely exploit mitigationless. It runs
in protective mode and that means all code is readable, writable, executable, everything
is predictable locations, so modern mitigation whatsoever. Critical but no mitigations.
Despite all this, exploitation was so brutal it took me months and months to actually
accomplish even though it only took me a week to find the bugs. So, at this point in previous
presentations I've gone line by line, memory map, blah blah, this is how I did X, Y and Z to
exploit the vulnerability. After five minutes of doing that the audience was asleep. I'm going
to show you this crazy diagram and say if you're a fellow vulnerability researcher exploit
developer please read my white paper I spent many days writing a white paper that goes into all
the gory details on how I exploited these vulnerabilities. This is to entice you to read
the white paper if you like that sort of thing. Point being the queen's gamut exploit we
achieved a very reliable searchable write primitive which is the holy grail in
development. King's gamut vulnerability was especially interesting the weren't we call
the Dixie phase because essentially you end up in a situation where there's a
nonterminating loop that's going to overwrite the whole four giga bite address space. You're
covering the address space with values. You don't need complete control. How can we escape? The
only way I think to exploit this was have a nonterminating loop overwrite its own code as it was
executing. In this case we wrote a crazy Python encrypted source root and in one of those
instance I found a case where I can make it so that the self over the nonterminating loop
self override itself with a jump away to a noncorrupted part of the address space that the OS
could control and we could have privilege escalation. This isn't as good as the other one because
it corrupts a lot of the space and destabilizes the system and pretty much what you can do
after you gain control but it's still kind of interesting so please read the white paper if
you're interested in the details. Now, what else is interesting is that we're able
to exploit the queen's gamut vulnerability using only that special Windows 8 UEFI variable.
Part of the exploitation process required me to stage certain things to certain physical
addresses with an address space. Normally in ring three you can't do this. You won't have access
to all of the physical address space you want but I found that by further abusing the Windows 8
UEFI API I could spray the contents of the flash chip and just create many of the these
variables and I created. . I was able to exploit the first vulnerability that queen's gamut
exploited using the Windows 8 UAPI so I didn't have to rely on anything else. The second one
there were some constraints and we had to use a crutch of a third party driver to put things
in certain physical addresses, so. In both cases it was completely unlocked. System
management mode, the flash et cetera so you can do whatever. So, okay, it was totally crazy.
Some of you guys are like I don't understand this after all. Let me sort of narrate it step
by step this is what it would look like. We have our dark Jedi. No for the dark Jedi that
is never enough. He grows his power to the next level he says okay that's great I'm admin but
I must go further, must explore other dimensions, get more knowledge, get more power. So
first he says I'm going to spray the contents of the flash chip with all these UEFI variables
that is contain shell code and a evil capsule to substantiate the vulnerabilities. He will have a
tactical control data that physical address FFF911000 and he needs that. Then after he's
finished his spray variable type thing he creates the evil capsule update data variable
that substantiates that standard capsule of data process in UEFI if it exists and he points that
within his sprayed area basically the evil scatter gather list to substantiate the
vulnerabilities and this is what ‑‑ platform reset occurs. This actually is a bit
implementation specific anded depends on what hardware you're running on. In most cases this
is got a name like F3 sleep but it can mean other things depending on your hardware. Once
a platform occurs UEFI will regain control, you'll be executing the contents of UEFI.
It will check for the existence of scatter type data and if it exists it will start parse the
contents of the list and try to coalesce the capsule and so on. In this case the evil scatter
gather list capsule updated. Point inside the contents of the sprayed data that our more evil
dark Jedi pushed onto the flash chip and in the process of parsing because of those
vulnerabilities that I pointed out the attacker gets control of the construction pointer in the
context of UEFI. Since there's no mitigation no execute stack or whatever the attacker can hit
instruction point back to the contents of one of the sprayed variables which contains some
shell code to do something. In most cases it will be something like copy yourself in the system
admin mode or re-flash the flash chip which normally you can't do but in this case the flash chip
is unlocked so you need to override the contents of the flash chip; inject some type of
agent into the virus or the firmware. No physical presence needed. So, what can they do?
Why would the attacker be incentivized to do these. Once you're in the platform firmware
you can completely break the system by overriding the flash chip so not even ‑‑ it won't
even power on. It can defeat secure boot. It can establish an undetectable SM root kit. Or we
also gave a talk at Black Hat about further developing a undetectable. It can insert
hyper visor and it can interfere with the hyper visor. You don't have an SM transfer monitor. You
probably don't anyway. And then yeah once you're in you can do anything, anything a CPU you can
do at this point. There are no constraints to your power. All right. So, normally does anyone
like to do video demos, because demos are safer. It might not work. Fifty‑50. So, 50‑50. We're
doing one of these development boards and these boards are kind of like finicky. Windows is not
designed to run on it. We hack Windows 8 to run on it so we could exploit the underlying
UEFI code. It may work. He's like the God, the gatekeeper between the spirit world. We'll
call on him. Hear my call. Make our demo work. So, let's give it a go. It's like variable grade
zero, variable grade one. This contains the castle as well as the shell code. He gets the
controlled data in a physical address. You see an error and that's because the flash chip
burns out. Corey is going to work with what you got and it creates the evil capsule update
variable to point and sign the contents of this sprayed flash variables. Go ahead. Okay. So
one other thing I would like to say is that we're going have to link to the UEFI shell because
Windows 8 doesn't know how to put these systems into S3 sleep. Normally you can put the
platform into S3 sleep but there aren't the right drivers so we'll boot to the UEFI shell to
put in it S3 sleep to actually engage the vulnerability. >> (Inaudible). >> Bouncing on the
projector. >> Give us just one second. Okay, so this is the EFI shell over a serial terminal
here and Xeno put it ‑‑ okay. So, we're going to call something that is basically
going to tell us is the exploit going to work or not or at least give us some evidence. You see
the spray location FF940C2. That's great. I assume this to be a reliable address so
everything seems to be great so far. Here is another place where the demo can go wrong. We'll try
to put the minute board in S3 sleep. Even from the shell sometimes this is finicky.
Sometimes will it not go into S3 sleep. Takes sometimes 30 seconds. Let's all sit here and
hopefully the God will be merciful to us. Otherwise we'll have to reset the system. Okay.
So, right, if the system boots up if the demo works it will take the shell code and what
we'll be doing is making writes to the flash kit that will embed the agent in the system
management mode to do our bidding. It's like a back door methodology that Xeno will talk
more about what it's supposed to do and how it works but we'll see. Okay, so s it wasn't going
into S3 sleep. Luckily the exploit is still waiting there in the variable contents for
UEFI to parse and then if we can get it to go into S3 sleep. If it works you'll see it say
something like running from spy flash. That's how we know it's running from S3 sleep. There we
go. Finally. Okay so at this point it has gone into S3 sleep and woke up with an immediate
wake and it started to parse our evil capsule. At this point we've been corrupting the
firmware on the flash trip which we're definitely not supposed to do. Xeno will hook up this
programmer just to show you the writes me made to the flash chip. Normally you can't do
this. Normally to inspect a flash chip you need this special E prompt program. If you have
physical access, yes, you could overwrite the flash chip. You could connect something like
this to it. The important thing is we're actually making them out of chips so we can do this
without ever having physical access to the system. Xeno is going to the point where we
would have inventeded the agent at this point. Yeah, so you can see where it turned red. We
identified a pattern area on the flash chip for this development board. We just inject one of our
agent that is will copy itself into the system management mode. That 's one of our writes.
Everyone should be impressed. Normally you can't do that. (Applause).
>>> So, everyone total unimpressed. You clapped because I told you to. Okay so now I'll
secure everything. All right. So,. >> We just showed that we injected an agent into the flash
chip. That's first. It's going to always exist down at the flash level its going to run
every time you boot the system and it can, you know, do sort of anything. So, looks like we lost
a slide here. But basically the point is we get ‑‑ we get asked the question consequences, what
does it matter if you break into BIOS, who cares if people attack firmware, right? And so the
basic point is we always say okay, what can an attacker do? They can do everything, every
single thing. If there's an attack they can do it because this is the most privileged code
on the system. There's nothing it can't do. And it turns out it also is down there at the lowest
we feel running before all operating systems so you can boot my Linux here, so we just
did the exploit from Windows. We're now going to boot it into Linux instead because we want to
show this agent down at the firmware level is persisting and running and continuing down
below the system and it doesn't really care who actually is up there at the operating system.
So, what is the watcher? It's an agent which is sort of minimally simple. It's like the simplest
possible thing you could make if you wanted to make the back door but it's maximally capable
because all it does is it scans memory and it tries to find special signatures and memory.
When it finds a signature in memory it treats after the signature ‑‑ what's after the
signature as assembly that it should run. It just jumps into that assembly that's after the
signature. And that means we don't need to build in every capable in the world into the
watcher. We have to have it continuously waiting and watching and scanning your
memory. It doesn't care how an upload gets into your memory, use your imagination, someone
shoots some packets at you and your thing says no, I have my firewall on I'm going to drop
those packets and not process them. It doesn't matter. It has got into the memory and the
watcher is waiting for memory and looking for signatures. Whole bunch of different ways.
Maximally flexible because anything that gets into the memory any way the watcher can
find it, watcher can execute it. I'll just speak a little bit about what we did in terms of
design trade‑offs. So it's scanning memory. You don't want to scan all of memory. That's
going the take too long. We want to scan on page boundaries every x1 thousand of memories so
watcher is sitting here running in the background scanning for magic signatures. The controller
somehow positioned data into your memory. It doesn't matter how. You opened a document that
had something attached. Some java script sprayed some pay load into your memory. Somehow
some way the controller gets content into your memory and then the watcher comes along and
finds it and starts executing an arbitrary pay load that can do anything. So, we will show some
simple ‑‑ watcher ‑‑ an important point is the watcher is pretty much an after thought
to this presentation. Corey's attacks on the UEFI. The watcher was ‑‑ people don't get it that
when we say if you break into firmware you win everything, okay. So, we needed to make it
clear because some people only get it when you make it, you know, perfectly clear. So, to
show simple demo, we're into comic books, the watcher is from an alien race which is forbidden
to interfere but he always finds a justification to interfere anyway to warn us about
attackers and so forth. But so in this case what we're ‑‑ you can see here we booted into
Linux, that's the Linux that comes with the board and so to sort of prove that the watcher
is sitting here waiting and watching in the background I'm going to manually invoke a
system management interrupt. We can have it running continuously on the background we ran out of
time for doing demos. Like I said it's an after thought. We'll manually invoke an SMI and
we'll prove that there is someone hidden in the background who is actually executing code.
Right. And the key point is like we're still on the same system. We booted into Linux. This is
still the same development system we were booting, hard drive with Windows, flash chip
with Linux, same system. The watcher is sitting there underneath. It can subvert any
operating system, any hyper visor, it really doesn't care. So, what I'm going to do is I'm
going to make a little EFI art. This is a Linux application. It writes to a port that causes
system management interrupt and it picks up the watcher and it says watcher go scan memory
right now. If I pass argument eight I'm waking up the watcher and he's not finding anything,
I'm not creating magic signatures from the find but if I do IO9 then what I will see is
he will find this pay load and he will execute my code if you want. There we go. The watcher
has infected the system and he's waiting and he's watching and he's executing thing. The
watcher itself printed out watcher go into forbidden, maybe just this once. (Applause).
>>> The pay load for this particular example again just to make it blindingly clear, the
pay load for this, it could do any sort of shell code I want. The watcher passed it the
address of a print function and so the little bit of assembly all it did was it took in, you
know, patched the argument into the print function and then past the pointer to the string and
then the string prints it out. That's an example of the watcher sitting waiting around watching
and executing thing. Now we'll try our 50‑50 probability maybe it will work maybe it won't
thing. It doesn't make it matter how stuff gets in your memory. Here I just ran an application.
The application you know, create add special buffer with a special signature and then some
assembly after the signature to execute I'm going to now try and I'm going to try to send some
ping packets that have watcher signatures and watcher shell code in and specifically the
ping packets I'm going to send, let's talk about the pay load here, the pay load we want to
use is the ultimate nullifier. Going with the comic book reference, this is the Fantasy 4
comic books, the ultimate nullifier was a device that was extremely powerful. It could
destroy universes and destroys the user as well. It's kind of the weapon of last resort. The
ultimate nullifier in our world is a break the system sort of pay load. I'll nullify the first
instruction that the CPU ever pulls out of the flash chip and that means that the first
instruction is junk. Then you can't boot the system. You can't reboot the system into some USB
drive and reimage the system. The first instruction the CPU ever executes is garbage. It's
going to not boot ever again unless you have, you know ‑‑ unless you can go physically
attach a flash chip rewriter. That's again part of the reason why we're using this demo board
is because we can easily reflash it, fix things working on demos and so forth. You can't easily
refix things on your personal laptops. So, ultimate nullifier sent over to the network in ping
packet maybe lit work, maybe it won't. We've been seeing that the networks back here is not so
great but Corey, if you... >> Okay. So, I just want to re‑emphasize. One thing we're
having to do, like the IO8, IO9 normally we could program the watcher to be executing in the
background by causing the clip to, we don't have time to implement that. Any time Xeno
does the IO8, IO9 we have to make it more weaponized. >> Putting up a little local
network and then Xeno will have his Mac book. I'll sends a ping packet through the development
board. Embedded in the packet will be a pay load for the watcher and that pay load for
the watcher will be break the system. The idea here is that some other foreign entity state
has broken into all of your computers and installed this watcher. When hostility break
out country break all your systems right before you, launch an attack on you because I want
to set you back. So at this point ‑‑ okay, so we're going to try to see that it is going to
work. >> All right. >> Keep going. I feel optimistic. Is the IP address correct? >> Yeah,
there's always these minor issues that totally screw up our stuff. Yeah, part of the issue
is ‑‑ it's causing crazy packet loss. So, something we didn't get to work this time. It did
work the last time. So, 50‑50. But we're going to run the pay load. We'll just try to get the
watcher to interpret that way. >> Actually going to run it as a EFI application. That last pay
load ‑‑ that will be fine. So, we actually want to run it just sort of in an EFI shell. These
are EFI applications that can be made into the ‑‑ that are made by the BIOS. We did one pay load
from Linux. This will manually nullify it and we'll read the flash chip and show that we
actually bricked it. All rightly so that was running the nullifier. It's the kind of
thing, the no visible, right. The important thing is if I pull this power out and I put the
power back in again, you're not going to see anything on the screen because this thing is now
bricked. There's no way for it to ever boot ever again unless I come in here with a programmer
and attach it and so forth. So, it will just show that like the bites resect vector have
actually been turned to zeros, nullified. That Black Hat I accidentally wrote to the chip
instead of read to the chip so we're going try to not do that this time. So, the reset vector
for intel CP users is also like 32 bits for FFF0. That's not right. The reset vector on intel
CP U.'s is FFF0. It alliance the flash chip with the end of the physical address space and so
what we see right here is that the original entry vector would have been no op, no op jump
backwards and the ultimate nullifer has written four bites of data set it as 0000, there's
no valid instruction and it is now nullified dead bricked and it is on‑‑ consumer systems
there's pretty much nothing you can do about it. (Applause). >> Running the wrong version of the
script over here so whatever. Okay. So, we don't really have a lot of time but you can go read
these slides later. The main point is the watcher, as I said, it was an afterthought. It took
a couple weeks to build. It's minimally simple. You just have a tiny things that finds and
executes stuff and then it just maximally complex in what it can do. It can execute arbitrary
shell code. The watcher of tomorrow can have improved capabilities but the question is
what can you actually do about this. Can anyone stop attacks like the watcher and the answer
is yes, yes, Copernicus can deal with the watcher. It's basically a system that it does two
things. It tells you whether or not your BIOS is vulnerable to attacks like we talked about and
a lot of vendors don't configure the BIOS correctly so the flash chip is open so that means
anyone can nullify you at any point if they get kernel privileges and that's why we're
trying to raise the awareness of that with Copernicus. We do both integrity checking and
vulnerability checking. It can jump your BIOS and end speculate have there been modifications
that you don't inspect and if I will more time I would show you an example of the different ways
test it. So, I'm just going to blow through this quickly. The vulnerability disclosure we told
intel the bugs back more than six months ago. We have sort of a six month vulnerability
disclosure timeline and read the slide if you want to know more but the one important thing is
that we did show this on a single HP system to prove it was actually vulnerable we showed
these UEFI systems do trickle down into real systems and as of yesterday HP went live with
their advisory saying there's more than 500 different models of HP which are all vulnerable
to these exploitable vulnerabilities so go check that out. You're almost certainly
vulnerable. So in conclusion, we talked about three things today. We've talked about a whole bunch
of other things that at other conferences. We'll talk about more stuff in the future.
There's a whole bunch of other people doing a bunch of talks about other things. There's
going to be a BIOS summary talk tomorrow. You should check that out at noon and you'll find out
more about all of the different ways that you're hose the down at the BIOS level. So that we're
out of time. We'll be outside probably back that direction taking questions. Thanks for
your time. (Applause). "This text is being provided in a rough draft format.
Communication Access Realtime Translation (CART) is provided in order to facilitate
communication accessibility and may not be a totally verbatim record of the event."