Dear viewer, these subtitles were generated by a machine via the service Trint and therefore are (very) buggy. If you are capable, please help us to create good quality subtitles: https://c3subtitles.de/talk/369 Thanks!
Good evening, everyone.
I hope because you picked this dog
that all of you know what
you stand for
just in case it stands
for Unified Extensible Firmware
Interface and roughly speaking,
a replacement for the successor
for legacy by just
more features, more secure.
The objective of our research was
to get access to this tiny
chip that's normally stored
folder to your motherboard, and
it's named SPEEA Flash Chip, and
it holds the contents of the Wi-Fi
network.
So it holds the code of unify.
The rules of the play is
with physical access.
It's straightforward, right?
All you need is to connect proper
gear, the flash programmer to this
chip and then you can play with it that.
So we consider only software attacks
during this stock, particularly the ones
that can be conducted remotely, but just
much more scary.
Why bother?
Well, biosurgery Wi-Fi is
quite a special piece of code because
that's the code that gets executed first
by the CPU after the machine is
powered up.
So it means if you have control at
this very early stage of execution,
you control what's executed here.
You also control what's
executed later.
We can trojan it at your what
you can see so you can throw down the
kernel that's loaded later on or the
applications.
And this method of Trojan
has a nice advantage that it can
survive Oyston installation.
Right, because the code for the Trojan
does not reside on the hard drive along
with the operating system, but
in the BIOS bodying on the for us.
So that's pretty unique.
Also, if you're not that sophisticated,
you can do much more a trick, just
overwrite the bias
that you have with garbage.
And then what happens is that
the machine will not put aside because
bios will not stand.
And the only way to divide
this machine is just again to connect
the flash programmer. There's no other
way, though. That's pretty nasty attack.
If you consider what happened to Saudi
Aramco a couple of years ago, that
kind of attack would be much more nasty.
So all these three,
there are three reasons why why it is
interesting to get access to them at
flash cheap. It's an ideal place for
rootkit.
You probably don't hear a lot about
these kids being deployed in the wild
because it's a little bit advanced,
but they do happen.
And if you Google for the project
data bounds by NSA,
you can see that really that kind of
could happen either way.
It's so high regarding this
issue, how security is implemented.
Well, first of all, the chipset itself
provides the means, the features to
actually program the flash device.
It's necessary if you want to support,
for instance, by biosolids.
But it also it's
possible to configure the chipset in a
way that prevents access to the
chip and then
it's up to the firmware, biosurgery,
fi, whatever utilizes
it properly.
So that, for instance, before
update the BIOS is applied, Yafei
must have a chance to, for instance,
check the signature to verify that it's
a legitimate happening.
And of course, and the random
attempts to write the
SBA that should be denied
well of this
method of protection.
So there are
vulnerabilities in the past that allowed
us to get past this rate protection for
probably the first one was in 2009,
for a long time ago by Alex
that rescued me from ITIL.
And this gentleman much more recently
presented at least two different ways
of getting right access to the
SBA.
But in fact, these attacks were a bit
theoretical, certainly
some optimal from explications point of
view. The reason was these
attacks were based on complex memory
corruption vulnerabilities and
even developing exploits
for them is very tedious because it's
very difficult to debunk the early
bioscope.
So in reality, to have reasonable
chances to develop such an exploit, you
need equipment like data
debugger plus programing, and
it gets complicated.
Also, the exploits were
quite unstable.
So you were dependent on a particular
version of the chipset etc
etc and deporting them to a different
platform was Manchego.
So for that reason, although
definitely real and possible to exploit
this vulnerabilities are not.
Expected to be really
exploding in a way, but
today will present something better,
namely will present vulnerabilities
which are prevalent among CUFI inflexible
system.
Essentially all
five or six systems that we tested from
different wings were vulnerable.
So it means your laptop is vulnerable
and the consequences are,
again, ability to get the right access
to the flash and also as
a nice bonus ability to get
into some ethem
being system management mode.
It's a very powerful mode of execution of
C.P.U that's
again, usually insulated
from the rest of the operating system.
And finally, they are quite
straightforward, reliable,
simple.
You should be able to reproduce it at
home.
Oh, OK.
Uh, before I begin to make sure my demo
is still up and ready to go.
OK.
So as awful as saying the
protecting the contents of the bias of
the spy flash is of paramount importance
for all those properties he was listing,
and due to this security
critical nature of the bias, there's a
number of protections that surround
making arbitrary programs or any programs
to spy.
So it's not sufficient to just break
down one of these.
You have to really have to break through many
layers if you actually want to, like
insert an implant onto the bias.
And the general flow of the presentation
from here will just be to describe each
of these layers of security,
describe the attack, a service against
them, and then break through them and
hopefully show some large demonstrations
of us doing it on these systems up here.
But we'll see if the Democrats are nice
to us today.
So they're number one, as you can see on
this one, is the the BIOS control
register.
And this is a memory map to register
that you can access memory mattio
or audio.
And it takes the form of many
of these security critical registers on
the six architecture, where you have
some bits that control features
and then you have maybe one locking bit
so that once it's set,
the feature bits can't be
maliciously modified by a compromised
operating system or
a compromised driver or something like
that.
So in this case, this is
responsible for or at least something
that's partly responsible for protecting
the bios. And you can see that number
zeros, the bios try to name a bit.
And this is quite simple when this is one
you can make writes to the BIOS when it's
not, you can simple,
but no one is a bit more interesting.
So as I was saying, normally with these
locking bits, you have it where you set
it to a one and then you can't change
the feature bits anymore until the
platform resets.
They're just locked.
But this one is different.
If you read the fine print text, it says,
OK, if I so I can set to one enable
setting the bias right and able to cause
semis once set.
This bit can only be played by the
platform reset.
So kind of interesting.
It's not saying that just straight up
blocks access to the bios try to enable,
but it just enables essentially S.A.M.
to act as an arbitrator and decide
whether or not try to table should be set
to a one or two, a zero.
And so this puts system management mode
in a position to decide who gets access
to the ship.
So that was a bit abstract.
It's probably helps to clarify with some
diagrams. So if a let's
say this is a malicious kernel, driver
wants to put an implant
onto the ship, the first thing and has to
do is write enable the BIOS because it
has to be one to make programing
operations.
But in this case, the BIOS lock and a
little bit is also sets.
The bias is being protected.
So because obviously being able set
SMI system to interrupt is immediately
generated some kicks in.
And so in this case is going to determine
that, hey, this is an illegitimate
attempt to write, enable the bios.
So we need to come in here and set by
Australian will back to zero and
then eventually the system.
The Senate handler will eventually
return context back to the original
kernel driver that started this whole
attempt to reprogram the ship.
And at the end of the day, the attempt
to write the BIOS fails because
this kernel driver, this thread is
never able to actually execute
instructions in the context of the chips
that went by to try to enable a sequel to
one.
So what do we
have here is the description of the bias
control register from the old days and
from the new days, so the process of
looking at this was kind of like a bendir
thing for vulnerabilities, but in this
case, for dissing the documentation and
you'll see some interesting changes
happen. So back in the old days, the
city takes architecture.
You had the Northbridge Southbridge
style, the memory controller having the
controller hub and then the CPU.
So this is what's up top, the old
what I'm calling style architecture.
But on newer systems, most of them,
they've gravitated away from this
Northbridge Southbridge style
architecture. Now, there's a lot of that
Northbridge functionality has been
migrated into the CPU and
other functionality has been pushed to
the platform controller hub, which is
kind of assume the role of many
of the north and south bridge functions.
So now you just have CPU platform
controller hub.
And I think this happened
around 2010 or so, but I can't say for
sure.
On the old one, you see that big seven
through five are just reserved.
They don't provide any additional
features. But on the new platform
controller hub chipsets,
bit number five is for the cement Binish
right. Protect Vitt, which has some
pretty interesting language.
In particular, it says that when
it's set by this region,
assessment protection is enabled by its
region is not writable unless all
processors are in SMS.
So when we looked at that, it kind of
gave pause to what does that actually
mean? All processors have to be an Samim
for rights to occur.
Well, it turns out that Intel is patching
a latent race condition into the
spice protections provided by byas
control.
And actually the way this
cooperation between the fall and I came
about, as I said, riffel a paper of mines
describing some attacks against legacy
bias and describe this bias control
functionality and are false.
And that seems a bit racy.
We should try to look at that closer.
And some of my colleagues also suggested
that this might be a problem. But as it
turns out, that this bias block enabled
mechanism is subject to a race condition
on multicore systems.
So the way this generally works, it's
really simple to to exploit.
You just need to thread so to
to cause so essentially
to colonel drivers and one will be
attempting to. Right. Enable the bias in
a tight loop.
And then the other core, what
I'm representing here is thread number
two is just going to be attempting flash
programing operations in a tight loop.
So this when we succeed
in the race condition bias.
Right, enable OK, we're doing this a
million times and Simmi
occurs and the handler is going to come
in and try to save the day and set bias.
Right. Enable equal to zero.
But it doesn't happen in time because
thread to here just keeps on, keeps
on trying and eventually they're able to
make that flash programing operation
happen.
And this works pretty easily because
there's no penalty for failure.
You can just attempt this flash
programing operation in a tight loop,
millions and millions of times.
And if it fails because by Astrud and
able to zero, then it just basically
silently fails. Nothing catastrophic
happens like gaming the system or
whatever.
So you can really be quite a brute force
approach and it will work just fine.
And then eventually someone will come in
and set by to be able to zero but too
late, the the implants already been
installed and the game is already lost.
So we're about to attempt a live demo,
No. One. So I'm going to try to
show you this race condition just to make
it more real. It's going on.
So let's give that a try.
Everyone.
So what I have here is I'm currently in
one of these systems and
we're just going to use this race
condition to corrupt the firmware
on this book and just render
it non bootable. That's the goal anyway.
But before we begin, I want to show you,
just to make it even more clear what's
going on at this bias. Right, enable bit.
So this right here on the LPC
device is you can see right here at
Offset, D.C., this is the bias
control register right now, only a
bit one is set, which the bios lock in a
bit. And you can try all you
want to set this thing to one.
And yeah, it appears
maybe to stick for a second.
You see a three there, but that only
appears to because
the refrigerator this is like one time a
second, so we can't we can attempt to by
trying and able, but it's not working
because someone is coming in and setting
bayfront and equal to zero.
But what happens if we just try this
millions of millions of times
simultaneously eventually will succeed?
Hopefully.
OK, before I begin, I just want to show
you the region of the ship that we're
going to change,
if I can remember.
OK, so in here is just essentially unused
space, so it's just
make a change here because it'll be
obvious and what we have to do
and do in these programing operations is
actually clobber a hole for for
a block.
And doing so will corrupt the firmware to
the point where it's not
going to boot anymore. So this is what
will be changing. This is our target.
OK, so what I've already done
previously is I've installed two COL
drivers into this one, eight systems, and
Colonel Driver number one is going to do
biocide enabled in a tight loop when it
receives an IO control code.
And kernel driver number two is
going to attempt to flash programing
operation in a tight loop upon receiving
an audio control code. So then all I have
to do is use choose to use Herland agents
to start sending the IO control codes to
try to win this race condition.
OK, so this one on the right set
by Australian, an agent that's going to
be the one that invokes the by to naval
tight loop code and it's one of the flash
programing now with our flash programing.
And it's a bit odd or I guess not odd,
but you have to do an array operation
before you do a programing operation.
So I'm actually going to have to win this
race two separate times to
actually accomplish this attack.
So let's see if I can be quick about
this.
Oops, I didn't install the drivers.
Here we go.
OK, so right now I'm raising both
those threads are occurring, is happening
millions of times that was
attempting the flash iRace operation
and now I'm going to attempt the
the programing operation.
So let's just try that one more time.
Let it go for a little bit.
OK, that should have been sufficient, but
we can actually check.
So what I have right now is a colonel
driver, which is just dumping the
contents of this by flash so I can just
verify that I've actually won the race
and been able to make these changes.
Yeah, and you can see here, these were
originally asked and I just wrote some
junkier and as I was mentioning,
programing only happened sixty four bites
at a time. So I've only seen sixty four
bites here. I could just continue this
and write even more, but the iRace
happens and a whole four block.
So I actually annihilated a whole lot of
other stuff, including important yafai
data structures, which is basically on a
brick this system when I tried to
reboot it. So let's see what happens when
I try to be done.
So I'm going to reboot and the real race
will be, can I break the system
with the flash program I bought with me
before our fall finishes his portion and
we can continue.
OK, so I just rebooted that system.
Probably it will do something
horrible.
Yeah, so right now it's just stuck in
this diagnostic boot loop.
It'll never but again, the firmware has
been completely like a hosed because I've
overridden critical parts of it.
And you're basically dead in the
water.
You can't attempt to reinstall the
operating system. That's not going to fix
it because the firmware is just
completely blasted at this point.
It'll never turn on.
So this kind of attack was to happen.
Your I.T. department would be pretty ill
prepared to recover from this.
Luckily.
So luckily, I've had the foresight to
make a backup of the firmware with my
flash programmer that I brought here so I
can try to recover the contents of
this, the fall is continuing, which
I'll do after I finish up here.
OK, so one sort of important question
is who is affected?
Now, as I mentioned in earlier,
systems didn't even have this
symbiotes right protect Newar
platform controller hub systems.
It's like doing this CPU loop of doom
right now.
So if
if newer platform controller based
systems, if they set estimate by a ship
protect race condition defeated doesn't
happen. Good to go.
Older systems, they can possibly
protect these sell themselves.
This other layer of protection called
protected range registers.
But even if they use them,
we'll talk more about how these work.
But it might not be sufficient and we'll
talk about why later.
So if you don't set symbiotes
right protect, you're probably
vulnerable, as is the multistory.
And the bad news is most systems
that I've looked at, even systems that
support symbiotes.
Right. Protect, don't set it.
So I did another
paper with some colleagues
earlier this year that talked about a
hack in the box, Amsterdam.
And we surveyed about eight thousand
systems. And granted,
the systems were probably about two
years old on average, I would say, but
less than 10 percent were actually making
use of some right protect.
So there's this fix available for a lot
of systems. But for whatever reason, OEMs
don't seem to be using it like this elite
book supports it but doesn't set it.
And many systems look, that is just
don't bother, use it for whatever reason.
And yeah, just to reiterate, very easy to
exploit. Nothing magical going on.
I just need one thread setting
try enable a bunch another throughout a
typical flash programing and then wait a
second and then you've probably won no
penalty for brute force. Just keep on
trying.
OK, so that's the
sort of the outermost layer of the bias
protection. But how can we proceed in
work? You get to the promised land of the
flagship of the UNFI firmware.
So next up is if
the OEM, if the BIOS makes use of
symbiotes right protect, we
are essentially forced to break into
system management mode to continue our
assault on the firmware.
And Raphel is going to talk about how we
can attack S.A.M.
on most Yafai systems
with this portion of next.
OK, so attacking S.A.M.
biocide protect us.
So have you ever heard the story of
the wife?
No, I thought so.
That's not the story that the Jedi would
tell you so.
For our purposes, the important
thing is that they are kept
out of the comatose for many years.
In fact, he killed him and revived
a couple of times.
The reasoning behind it was research.
He just wanted to figure out how
many Clarient work and how they're
connected to life and death.
So how is it relevant for
our business and
the relevant parties that you have
already seen, namely the
that registers unlockable and some
of the lakebeds are cleared
only during the whole
three sets.
So the idea is to force
this reset so the death of the platform
and then still gain control over
it while it's being resurrected.
And that that idea
means that we still have control.
Why the
logistics are not locked.
And some of you might already have
guessed that we will use XP as we sleep
because it involves both
death, so sleep and then resurrection.
So as you said, we see
that as we sleep equals the
Ikoma.
So what's the difference between normal
bolt and resume from as we sleep
in context of you?
So if I executions divided into a
couple of days, you have SECC face to
face the XY, then device
selection and operating system look
and the interesting part happens
in the face.
So at this point,
most of the registers are actually
locked.
Interestingly, each time
the platform is being configured by
the means of PCI config space.
Right. Memory, right.
I'll write the information
about an exact
information about what's being.
Configured as recorded in the
data structure means what script?
And what script is just, again,
data structure starting normal
ram, usually, typically
it is in a vessel
area of RAM reserved for
the purposes of you faith
and why it is so it will be useful
on a resume.
So as Friesian, we start
in a very similar way.
So C.P.U is powered
up, jumps to the reset vector,
then the fuckface executes
the phase execute,
but then something else happens.
Namely instead of just loading
all the driver from the flash and
just running of all of them,
we just replay the configuration
actions from the script.
So that's the difference.
So at this point, it's not the content
of the Flash that dictates what is being
executed. In fact, it's just the contents
of this memory of the script
that shows what configuration actions
will be applied.
And then afterwards, as usual,
the operating system is woken up and to
give in control.
So, again, the important part is that
at the moment when the script is
interpreted, most of
the platform registers are not locked
yet.
OK, so obvious
thing, actually, inverse
memory as just normal, it's not
protected against the operating system in
anyway, so it means that the
attacker was at least ability
to access all physical memory
can mess with the contents of the.
And that's what we're going to do.
Yeah, one more thing, this whole
boot script concept is quite a core
feature of UniFi.
So all the Wi-Fi implementations
are used.
Yeah, so how about
script look like so again,
maybe just for completeness, I will quote
some documentation.
The typical configuration can be viewed
as a series of memory eion PCI
configuration operations, which the C
drive is recalled in the framework
script. During a few years, that script
engine executes the script to restart
the chipset settings.
So the script consists of the series of
op codes like Allwright Memory,
Riteish Config Write and parameters
to where there is a very interesting
op code for our purposes.
It's named dispatch and the
semantics of it is essentially
execute arbitrary code, right?
It's very useful.
As you can see in the specification,
uh, the consequences are
obvious. So if we can achieve
any of the following, either alter the
contents of the script, so insert
a malicious dispatch of code into it
or alter the target
of an existing AEF, I would
skip dispatchable code so that different.
We do not mess with the
script itself, but we hook our override
the code that's legally calls from
right.
And finally, we can alter
the data structure used by the farmer
to locate where the script is.
If we can achieve any of the following,
then we can force three, suspend, resume
cycle and run
arbitrary code in the context of the
interpreter.
So how exploitation would look like
that's the normal layout
of data, relevant data structure on most
of the machines that we have a look at.
So at the top of it, there is
a unified environment
variable named ATP Global Variable,
and it starts a value that it is a
pointer.
This pointer points into RAM
into action Invictus and
there is data structure named
also global variable
at certain of that in it,
that is a pointer to their bottom.
Right. So that's how it
looks like.
So the most straightforward way that
works most of the time is
first we will prepare our
script. We copy the original script
here. We prepare and you
will dispatch a barcode that just calls
our show code.
And then we change this pointer
to point to our new
shiny biscuit.
The reason why we copied the original
script is obvious, right?
We want to maintain the stability of the
system as you.
And that's pretty much it.
So the question is, can it be done in
the right way? So
is it possible to implement the concept
of security?
And the answer is yes.
And actually, if a development
kit introduces the concept of
the lock box, so the method to
store certain crucial data structures
in a secure way and
the way how it's achieved is that
these data structures must be stored in
some memory, not in
unprotected RAM, but in the region of
memory assigned for system management
molt that's protecting
against an operating system.
And then these
attacks from above will not work.
But it's possible to screw things in
a number of ways, so
we have seen only a single system that
actually used some lockbox to
store the Bush script and relevant data
structure.
And it was actually a horrifying
development. Mother? What the problem
is that the implementation
contained a legal
code.
Patch of with the arguments being,
again, in unprotected memory,
so this time, instead of messing with the
script or the pointer to the script, we
can just overwrite or hook the code
that's normally called.
And guess who is you?
Again, and the effect would be quite
the same.
And so, again, why why
we're doing that is largely
unlocked at this point, particularly
on all the systems that we have seen from
various OEMs biosynthetic
unlocked.
So that means even if buyers
if Intel biocides protect
the needs that we took previously, even
if it is set, it can be fully answered.
Nothing prevents that.
And at this point, Biosynthesis
does not prevent right.
Access to the chip.
It means that
we don't even necessarily have to
actually get code execution in the same
context. Right.
Because we simply can and set
biocides protected.
Not getting control over a system is
quite nice because, again, of all
the power that this model has
for how it looks.
So generally the memory is protected
by two set of registers.
First of all, you have to protect against
access from the CPU.
So for that purpose, modern Zippos
have dedicated.
And there's already stealth named
some Ranger stealth, and
certainly this word define a region
of memory that cannot be accessed
by the CPO unless it is the.
Interestingly, this
is, again, on the platform that we have
seen. These missiles
are already configured prior to
execution of script all this
time, no luck, at least
no free lunch, even in the context of
the fact that we cannot access from
the C.P.U.
But there is another way how memory
can be accessed, namely the ADMA direct
memory access
triggered by BISHAR devices.
Right. All PCI devices
that are capable can
trigger access to the memory
and there is a separate register of 96.
This time it's a chip register
that again defines a region of memory
that cannot be accessed by the.
Interestingly, this is configured
before the book is interpreted,
but it's not locked, interestingly,
which is good news for us,
what we can do is
change the value of the T Segretti
to something totally bogus volume
and then NFPA device
can execute DMA cycles and
get read and write access to that
assignment.
The only trouble with this approach is
that.
Actually, configuring a device
to do arbitrary DMA to arbitrarily
address is tricky because
essentially you must know full semantics
of the device, right?
And just implementing
it in the household itself would be
quite non-trivial so we can do something
better. So in the so-called itself, we
just move out of the
way.
He says also lock it.
And then after the operating system is
woken up, it's much easier
to do arbitrary dilemma because at that
time you can use all the drivers that
has been loaded by the operating system.
Particularly the most straightforward
way is to use the hard disk drive driver.
Yeah, OK, so
that's again, consequences really
ability to get access
to some memory, so
this vulnerability has been reported to
certain has been assigned this
tracking number.
Again, all of the unified system that we
surveyed were vulnerable one way or
another.
It allows a cabinet level attacker,
right, essentially
to bypass the fiction
employed by biosciences and
also escalate in runtime, which
is also interesting.
And finally, it is more or less easy
to exploit.
The only potential difficulty is that
the book's format varies from vendor
to vendor slightly but significantly.
So if you want to
inject your custom
dispatchable code, you need to know the
format. So some reverse engineer might
be quiet if you need to
party to another system.
Another interesting bit.
This very same vulnerability was
discovered totally independently and
mostly at the same time by
guys from Intel Advanced Threat Research
Team.
So congratulations to them.
It happens rarely, but it does happen.
Oh, OK.
So now let's try to do some
demonstration.
Um, I have set up a clinic system,
it's here, so
you should see the white rectangle,
right? So the machine is powered up.
So I assume you have some access to this
machine machine
doesn't need to be a site.
You could just exploit a browser and then
get Connect Backchat.
And all these attacks are going to
require administrator
privileges.
So lucky that a
couple of ways to do that, it's
irrelevant.
And now we can essentially
get busy.
Um, so, first of
all, let's see what the
location of that.
So is, uh,
registered in the host village interface.
Uh,
it's also a
H.
Yeah. So normally it's a
Sissy and Zeitels film.
Now lets this demo is mostly
about getting access to them.
So now how we can try
what happens when we do the major
address. To do that, we need to
innsmouth, uh, this helper
helper module
and then run
the total.
We will read to the filename Thesiger
at.
This address, uh.
It's interesting and read one page.
So if you do it.
Uh, what do you get?
Let's try to figure it out when I type
comments.
Nothing is kind of expected,
and if you look at the current logs.
Well, something horrible has happened,
right? Essentially, the colonel had to
totally reset the setting
because it complained they
had complained that the Matsen section
has failed. Right.
You can see that right, SPDM.
Again, it means how the
protection offered by the team works
so now will run the exploit
again in just a matter of
running another tool.
So what it does it right shall go to
the location, determines what's
the key variable holds
and then switches the location of the
actual Watsky
and what it does.
It again, loads shall
code. And actually this
so-called is just an old binary
and once it is run, it will log
some information to its body.
So if we dump
the contents of
the memory at this location
and to some log file
of settlements
and you add those strings, log
file.
OK, this is does the contents of the
shell. So nothing has been logged
yet, right.
So what remains?
We can now use the normal
utility bundle with Linux that will arm
realtime clock and
wake the platform,
resuspended to memory and will tell
it to wake after 20 seconds
and then its utility
that's bundled with
most distributions.
OK, so now you can have a look
at this at this machine.
Now it's running.
If I run this command,
you see, you could see it
went blank. So it's suspended now
and you can see that
the shell is hanging.
I cannot, of course, interact with it
because the machine is asleep.
So now we can either wait for it, reboot
or use the force like venom if I command
your ride
and see
the facility.
Yeah, it's like.
Yeah, and now, uh,
let's we do all the things that
we have done previously.
Uh, so now what's
what's the value of to give it
some if it won't
help much.
And let's read
the, um,
you know.
Yeah, let's read the log
of the of the show called
and.
And now you see something
more is logged, so the so-called says
that initial value of this egg was
not logged.
It was possible to overwrite words with F
and most importantly, the value
of biosynthetic was eight.
So the bits, number one, is
not set.
So, again, we have bypassed the
protection offered by biosensor.
And finally, let's try to
do DMA at this point.
OK, and now
let's see if anything interesting
is in there.
Now it looks much better.
Not only is it right, so
let's let's try to disassemble.
Does it look like like eight,
86?
I'm cold.
OK, we have a jump.
I'm 54
and then we have something
very unusual.
We have memory access with six
graphics.
So the selector for the code is used
as a demographic of memory
access. And coupled
with that, we have graphics.
And the fact that you load
global descriptive table, it tells
you that it's really examine
some further proof can be found
below. Unfortunately, if you disassemble
embedded instructions, the reason is
that.
The entry point enters Longmont,
Co. So we need to disassemble
in.
And along long, Mulder
and.
I always mix it,
yeah, and now no more distractions,
and most interestingly,
after a couple of them, you'll see
that this is the smoking gun, right?
Returning from system management about
this instruction can be possibly only
used in a single place in a small
handler. So that really
shows that we can get access to them
by DMA after it can
be moved.
Consequently, we can override the body
of someone and get the code executed in
some context.
OK, so we've broken past biased
control, we've broken into system manager
mode on most systems that we've
evaluated.
But one last hurdle remains
before we get to the sacred land, which
is the flag, the protected range
registers protecting the firmware.
So what are these guys?
Well, it is possible to use
protected range registers such that you
mask off parts of the flagship so it's
not even rideable, even the system
manager mode, this ultra privileged mode
of execution.
So you can you have several regions that
you can declare and as some
can even write to them because protective
arrangements saves the day.
Now, what's interesting about UNFI is
that the protected range registers can't
cover the entire spy flagship because
unifiers this thing is called nonvolatile
variables, which are kind of like Linux,
Unix environment variables, describing
things like the boot order, platform
language, et cetera, et cetera.
And these have to be these
live on the flagship, so co-exist
near the UFC code and all that.
But they have to be updatable by the
runtime of the system, which essentially
means the operating system.
The US has to be able to communicate
information to the firmware and change
changes variables or change the boot
order, et cetera, et cetera.
So these essentially cannot be masked by
the protected range registers.
If we can get to some, we can always
clobber whatever is in this region.
So the question we asked is, if we can
clobber anything in here, can we find
some trusted integer value and
corrupted and some buffer overflow or
something like that?
And General, can we find memory
corruption vulnerabilities by
doing crazy things, this region of the
ship that Saddam has right access to?
Well, obviously, we're up here today
and the UNFI code, a lot
of it. There's a reference implementation
that's open source. You can just go in
and check out or whatever and go to work
and have to do any crazy reverse
engineering.
So Rafil and I went to work on auditing
the FBI code and we found many
of these vulnerabilities that if you
assume an attacker can do some type
of memory corruption vulnerability to
maybe do bad things like get past
protected ranger teachers, it all depends
on how early we can induce these
vulnerabilities in the boot up of the
system. If we can make this vulnerable
line of code, run in the platform, boot
up before the protected rangers are set
and locked, then we can bypass them.
So in this case, pretty simple.
Buffer overflow data size is controlled
by some attacker because it becomes that
variable region and that in
public he stores a fixed size data area.
We can collaborate and you control the
instruction point in the early boot
environment. So blah, blah, blah.
Not very exciting, but let's have
five protected range predators.
And we found other instances of this not
very surprising.
This data, a lot of times just in general
treated as trusted.
If it originates.
If it originates from.
Yeah. You'll have to validate it too much
because that's a meme is like a privileged
type of entity which should have been
instantiated by the bios anyway.
Right. So in this case, we can make
next variable, next variable point
somewhere crazy, which leads to a buffer
overflow on the if I copy them.
So another buffer overflow that we can
possibly use to pivot Parsees protected
range resistors.
But the point of this presentation
is that we don't want to give you complex
memory corruption vulnerabilities because
they're hard to do it yourself.
They're hard to reproduce, they're
implementation dependent, et cetera, et
cetera. They're just hard to deal with.
So we want to
give you some other ideas for how you can
bypass these protected industries without
doing these complicated tricks.
So what's interesting is I
checked out the protected the UniFi
reference code further and it turned out
that data that was within these
authenticated variables, these
nonvolatile variables that some can
control, was used to authenticate
flash updates.
So there is a mechanism for doing
firmware update, firmware updates,
updating your bios and back in the old
days of legacy bios.
It was like the Wild Wild West.
HP would do something different.
Dell would do something different,
merican megatrends or do something
different. And everyone just doing their
own thing. I thought update their bios.
But the UNFI reference, the code
reference implementation code provides
like a clear way called capsule update
for this is how you should do firmware
updates on your eBay system.
All the code is in there and
that code path, the UNFI capsule update
just straight up uses the same control
data to authenticate whether
or not these updates are valid.
So an attacker can just use the
legitimate BIOS update path and
add their malicious rootkit update
as a legitimate update by manipulating
this data, assigning it and then adding
the key to that, one of these
authenticated variables, et cetera, et
cetera. So this
is what I thought when reading the UNFI
code. I was like this.
This can't be right.
You know, there's like a security barrier
here that's just been completely
demolished by this assumption.
So what's the deal?
So we talk to some unify a core
unified developer.
And he basically confirmed our suspicions
that some is just in the trusted
code base for UniFi.
If you can break into smarm, then
it's pretty much game over right now.
Nothing is going to stop you now.
UFC is going to be depending on
a new hardware feature in the future
called Platform Platform.
Firmware armoring technology or Biersack
are afraid exactly what they're calling
it these days. That I think uses the
management engine in some clever way to
protect the the firmware, even from an
awesome imprisoned attacker.
I'm not sure how much data about this is
publicly available. I mostly just found
marketing documents and patent filings
when I was looking at it. So not really
clear how it works. But definitely the
point is to protect UFC from
some imprisoned attacker.
And right now, all systems
you can get DMM through the platform is
probably going to fall.
So the cake is a lie.
There is no protected range registers on
these UAF eBay systems, and it turns
out that you probably do have to bypass
them anyway because many systems
weigh more than 50 percent.
I would say don't even use protected
range registers.
Ruffels Del right here doesn't use them.
I doubt this. Lenovo does Bessel.
And as I haven't some, a lot
of the apps I've seen do use a protected
introducers. But even on the systems I do
use them, they often fail
to cover all the important data.
So, for instance, the Protect
Brain Register should have in theory
protected this book, which I bricked with
a race condition from becoming bricked.
But they didn't because they usually
don't cover all the important data areas,
even if they're used.
Um, I have
another survey paper.
We did that hack in the box, Amsterdam
one. I think the number we were looking
at was only like thirty
percent or something. Systems using
protected range registers out of a mix
of like Lenovo, Dell and HP.
So they're not using a lot of systems, so
you don't have to worry about them.
So the point is you can get DMM firmware
is going to be toast.
So the summary is that
we want to talk about vulnerabilities
that you could take and do it yourself.
You could recreate these.
And because they are relatively easy to
exploit and you can do cool
things with them. The first one is the
race condition in the BIOS control
register. Very easy to exploit.
All you need is to kernel drivers
to side by side, enabling a tight loop.
One attempts you do flash programing in a
tight loop and then you'll probably win.
And that affects a great number of
systems because some systems are to
support the fix and of the ones that do
support the fix, many of them don't
bother using the bootstrap vulnerability
literally affected every unified system
that we looked at, which granted was only
like eight or nine systems, but it
included systems from Dell, one
of the Big Three.
So we suspect that it effects pretty much
all the other systems.
So your system, if it
was bought within the last, I don't know,
four or five years or whatever, probably
as vulnerable to the unified boot script
attack and pretty easy to
exploit it. You just need physical memory
access and you just need to do a tiny bit
of reverse engineering to figure out what
the script looked like.
Exactly. So just to give you an idea,
when Rafil and Alexander Tretiak
and did the first bios memory corruption
vulnerability when they're part of Invisible
Things Labs, they said it took
them like a month to do the exploit
and it probably only worked on one
BioServe Vision for one board, et cetera,
et cetera. So not very portable.
When I did the the bias exploits
recently, it took me about six weeks to
do one and it only worked for one biased
revision on one system, etc., etc.
It was very tedious to do that.
It took exploiting these took her fall.
And I just a few days and we're able to
exploit basically all the systems we had
access to in a few days because
they were simple to exploit and so
go and play them pretty easy to
reproduce. And the last point is system
management mode is just, you know, it's
been a problem and visible things.
Labs talked about this at length back in
the day.
Some can do really bad things.
It's kind of just.
Free to do whatever, and that's still the
case Newfie if you can DMM,
you can wreak havoc on the firmware
industry.
New hardware feature will address this in
the future, but the future is not now.
So now we are vulnerable.
Now, one thing
I'd like to point out is that these UniFi
and Byas vulnerabilities in general are
pretty complex to disclose because they
affect a wide number of people.
They affect HP, Dell, Lenovo, American
Megatrends, Phenix, et cetera, et cetera.
There's a lot of affected parties and
coordinating these vulnerabilities is
real pain. So big thanks to the guys
at Intel served the FBI Security Response
Team and CERT for helping reach out all
the affected parties and help fix
these issues.
Now, it's as I have ten minutes left, so
I'm going to try one last demo for our
viewer audience out there, because the
point is, Rafil
exploited.
His Dell laptop, which is running Linux
with a boot script, but the point is
Rafil uses Linux, I use Windows,
he uses AT&T style syntax,
I use Intel syntax is
is Emax. But we can find a vulnerability
that works for both of us.
And that's exactly what we're going to
do.
I'm just going to yeah.
OK.
So the goal is to break
in a system manager mode by altering the
boot script.
This right here is system manager mode
you can't see, and it's all because the
memory controller hub is blocking access
to it from the CPU.
And we couldn't get into a DMA anyway
because this right here is the TSA get
off set a C set
to seven, seven, eight, which basically
means the same region is protected from
DMA access try to access.
She's going to fail horribly.
That I can show you that.
So I'm attempting a DMA read on
that region, and
it's not going to work, you get this real
nasty, weird error, I'm not really sure
what's going on, but essentially this
is DMA attempt is just failing whatever.
But what we're going to do now is
alter the boot script to move
to seg like we did on the limbic system
to five zero zero zero zero zero zero, so
that DMA protection basically won't exist
anymore in the system.
And we just have to go to sleep now.
I didn't do some fancy
wake up thing like I did because I don't
have the same dark Jedi powers,
apparently. But you could easily do that
by programing an event to just rework the
system immediately using windows.
But I didn't do that.
So I'm going to press the power button
again, basically to make it come back to
life.
Yeah, thank you.
OK, so the system didn't die.
That's good. All of our demos of work.
Yes.
And you can see right here t sag is set
to five zero zero zero zero zero
zero. And I'm be punished by the gods for
saying that all of our demos worked
because I hadn't finished this one.
So let's try the DNA again
seemed to work.
And here so this is the SMI handler,
which previously couldn't read, if you
were to disassemble this, you would see
all the same kind of stuff that you saw
on our fall system.
So at this point, we can use DMA to
blow past the system management
protections and then get DMM and then
corrupt the firmware on here just on all.
So pretty much all your systems are
vulnerable to this attack.
Sorry about that. I don't even think Pat
has been released yet.
Sorry.
Um.
OK, so I think that
reference is if you want to check some of
those things, any questions at this
point?
Access, please line up in front of a mike
if you have a question like one,
and so so I agree with that,
I think and I stopped using it for a long
time. I think I began using
it. I think when when nothing
changed. And in fact, I think I was one
of those people that thought things would
change under Obama.
There would be some accountability, like
if you torture people, you're held
accountable for torturing people and then
that didn't. So.
So, yeah, I agree.
We need a new term for that.
Not going to comment on that question and
wait for the next one.
Next one and.
This is after
work. Yeah, so speaking
of protection, obviously
Intel is supposed to theoretically
protect against these because
we don't want to put trust into
Vieaux, whatever, but of course,
it is vulnerable to some attack,
so.
Because you mentioned you spoke to less
of pictures, Intel and
various developers and other folks.
What's the state of the storm?
Your guess is pretty much as good as
mine. I've never seen one in the wild.
In fact, I believe the specification
is not even public yet.
Right. Can even confirm that.
But I have heard that it's been at
version point nine nine like and
they keep you can't go further.
So just like a provision B, C, D
and E and further.
So I don't really know
what's up with the SDM
vaporware right now.
My understanding.
Can you my two back on
two.
So we ruled out we roll out
at and other alternative protection
you suggest.
What do you use for your laptops.
Faith in God.
Like one eye,
does this attack work regardless if
you're using a modern system in legacy
mode or you unified mode?
I mean, so the race condition works
no matter legacy or
Wi-Fi, because it's it's
a problem with the underlying hardware
itself.
But the boot script, I'm pretty sure it
didn't exist.
And legacy bias stays or might have been
something like that, but I can't speak to
that.
Mike, for hey,
so did the tanks that you demonstrators
were using,
you needed to be able to either excuse
artillery, cozying Carland context or you
needed real access to memory.
So in a situation where you have either
signed a requirement to sign car drivers
or no
ability to perform voluntary DNA from
userspace, do you have an attack
that would still work in that situation?
I still one this lines you mentioned
get foamer variable.
Is there any way to manipulate data via
the if I set variable interface
that can still trigger these
issues?
So I'll answer
that two ways.
One is that I did give a presentation, a
black hat that was only using the set
variable API to get access to the
firmware, but it was doing a very
complicated memory corruption
vulnerability that honestly would be
very hard to do in practice.
And the wild
second answer to your question is you say
that it's a requirement to have early
sign driver like for Windows eight, for
instance, and that's true.
But as Joanna
Rakowski pointed out, like back in twenty
seven, if your administrator
on Windows system, there really is no
barrier to getting into the kernel.
You just have to load is a but vulnerable
driver and then exploit
it. Or you're seeing I was using read,
write everything on the system that's
assigned utility that
reads and writes everything.
So I mean once you have administrator
access on a Windows system, getting a
physical memory access I don't think is
really a barrier
to anything.
Mike, say.
Is it possible for the buyers
or if you want us to
fix this vulnerability
by applying and update?
Yeah, sure.
So the vulnerability can
be solved in two ways, either
using the lockbox as a lockbox that
we talked about and not
screwing up things, or
you can just move the locking
code before interpreting
the script. So both of these
is fixable. And
we contacted the vendors about
in August.
So at least some of them responded
that they have parties ready.
I can say, too, that we did receive
some patches for evaluations from vendors
that did fix the issue correctly, but
I'm not sure if they're publicly
available yet. So if you're like an I.T.
manager for a large organization, my
recommendation is to contact your
guy there and see what the deal is and
see if you can lean on them to get those
patches out faster.
Last question, Mike, for
assuming there is an high malware
on the system, can itself cloak
against those attacks?
Can you make it sort of invisible to
those accesses?
Say it again. I assume you have a malware
on UAP mode.
Where low can it hide itself
from those probings, from those reading
those memory is the way you can
kind make the system look
normal and clean.
OK, so. So you think once I have
all this access in the bioscan, I
load a Trojan in a way that's not
visible.
It can be done in millions of ways.
That's really not not the subject of this
way. But, you know, the generate
responses is something like a blue
light. You can load hypervisor
very early and then wrap the whole system
in.
And then it is very difficult to really
detect that uranium in the hypervisor.
And again, once
you have this level of access, it's
at least cat and mouse
game. Right, because the
of way of hide your presence of the
system, there are millions of ways of
getting them. So that's
difficult.
Right. But the point is that you
need at least to be aware that such a
possibility exists and that way
of persistence is possible.
But that's a topic for a totally
different topic.
But there's another, um,
some colleagues of mine did a
presentation at Canseco this past year
that was basically using a virus
implant. And you can attempt to detect it
by reading this by Flash and looking for
malicious changes.
But there's actually a hardware mechanism
such that S.A.M. can interpose on
attempted reads of the Flash.
And you can use this to, uh, you
know, fake out the attempt to read it.
Now, you could try to detect that with
timing stuff, but then it gets kind
of.
And finally, finally,
I mentioned operating D.T.
Bounds. So what they did was
Trojan biopsies and gain presence
in smen, so then operating system
loads, but also runs concurrent
to it and it's still under attack
control. And once you are in
your control of the operating system in a
pretty stealthy way.
There was a presentation in 2008
about that as well.
So it's fully applicable.
Again, topic for a different OK.
Well, that was a deep dove the last
round of applause for Raffone Corey.