WEBVTT
00:00:00.000 --> 00:00:18.200
35C3 preroll music
00:00:18.200 --> 00:00:22.599
Herald angel: OK so our next talk is given
by Frederic Vachon, so please give him a
00:00:22.599 --> 00:00:33.137
warm round of applause.
Applause
00:00:33.137 --> 00:00:39.450
Vachon: Okay so hello everyone. Thank you
for having me today. I'm really happy to
00:00:39.450 --> 00:00:45.949
be to be here. So today I'm going to talk
about a research that a colleague of mine,
00:00:45.949 --> 00:00:51.489
Jean-Ian Boutin and I did earlier this
year and which led us to the discovery of
00:00:51.489 --> 00:00:57.600
a UEFI rootkit. So very quickly. My name
is Frederic Vachon, I'm a malware
00:00:57.600 --> 00:01:04.959
researcher at ESET and I've been working
there for the last two years and for the
00:01:04.959 --> 00:01:12.000
last year or so I've been really focusing
on boot level threats and UEFI firmware
00:01:12.000 --> 00:01:17.369
reverse engineering. So let's look at the
agenda for this talk. So the first thing I
00:01:17.369 --> 00:01:23.259
want to talk about is what is Sednit very
quickly. Then I'll talk about LoJack,
00:01:23.259 --> 00:01:28.460
which is an anti-theft software and past
research related to this software and the
00:01:28.460 --> 00:01:33.450
reason for that is that the UEFI rootkit
that I'll talk about really mimics the
00:01:33.450 --> 00:01:39.330
architecture of this legitimate software.
Then we'll move on and I'll talk a little
00:01:39.330 --> 00:01:44.439
bit about compromised LoJack agents that
were found in the wild, and finally I'll
00:01:44.439 --> 00:01:50.499
jump into the UEFI rootkit, well, where
I'll talk about the tools around the
00:01:50.499 --> 00:01:56.880
rootkit and the UEFI rootkit itself. So,
Sednit. Sednit is an espionage group
00:01:56.880 --> 00:02:04.820
active since the early 2000s and it is
also known as Fancy Bear, APT28 and
00:02:04.820 --> 00:02:12.110
STRONTIUM, so maybe you know this group by
one of these alternative names. And Sednit
00:02:12.110 --> 00:02:19.290
is the name basically that we use at ESET.
So this group was very visible in the past
00:02:19.290 --> 00:02:25.400
few years as being allegedly behind some
pretty mysterious hacks like the hack
00:02:25.400 --> 00:02:29.620
against the Democratic National Committee,
the DNC, where some emails were leaked
00:02:29.620 --> 00:02:36.090
online. The hack against the World Anti-
Doping Agency as well as the hack against
00:02:36.090 --> 00:02:41.610
the French broadcasting network TV5 Monde.
But at ESET when we're talking about
00:02:41.610 --> 00:02:45.689
Sednit, we're really talking about the
tools and the different campaigns that
00:02:45.689 --> 00:02:52.239
were led using these tools, and we're not
talking about the people who are operating
00:02:52.239 --> 00:02:56.780
this malware because we don't have the
information necessary to draw such
00:02:56.780 --> 00:03:05.110
conclusions. However, in July 2018 the
U.S. Department of Justice named the group
00:03:05.110 --> 00:03:10.640
as being responsible for the Democratic
National Committee hack in this specific
00:03:10.640 --> 00:03:17.650
indictment. And what's interesting is that
the tools that we analyzed were... are
00:03:17.650 --> 00:03:26.739
named in this specific indictment and they
also mention who's the authors of these
00:03:26.739 --> 00:03:37.129
malware. And also early, not earlier, but
closer from from now, in October 2018, the
00:03:37.129 --> 00:03:41.370
Department of Justice issued another
indictment naming pretty much the same
00:03:41.370 --> 00:03:48.799
people are related to the World Anti-
Doping Agency hack. And the way that
00:03:48.799 --> 00:03:53.670
Sednit will usually infect their targets
is by sending phishing emails, so
00:03:53.670 --> 00:03:58.829
sometimes they will contain malicious
links and some of the time malicious
00:03:58.829 --> 00:04:06.150
attachments. OK. So now let's talk a
little bit about LoJack. So Lojack is an
00:04:06.150 --> 00:04:10.480
anti-theft software as I mentioned, and it
was previously known as Computrace. So
00:04:10.480 --> 00:04:16.010
maybe you know the solution by this name
instead. And it is made by Absolute
00:04:16.010 --> 00:04:26.040
Software. So, yeah, and this solution is
built in many laptops. But an anti-theft
00:04:26.040 --> 00:04:30.790
software needs to be as persistent as
possible if you want it to be reliable. It
00:04:30.790 --> 00:04:35.650
needs to be... to survive an operating
system re-install or a hard disk
00:04:35.650 --> 00:04:41.160
replacement. So to achieve this what
Absolute Software did is that they added a
00:04:41.160 --> 00:04:48.930
module in the UEFI BIOS itself. Yeah and
the solution needs to be activated in the
00:04:48.930 --> 00:04:53.920
BIOS setup. So with a persistence
mechanism like that coming from the
00:04:53.920 --> 00:04:57.690
firmware, it's really attracted the
attention of security researchers, who
00:04:57.690 --> 00:05:05.170
looked into this to find vulnerabilities
basically. And at BlackHat in 2009 there
00:05:05.170 --> 00:05:12.140
was a talk there where the architecture of
the solution was described and several
00:05:12.140 --> 00:05:18.010
design vulnerabilities in the agent were
also described there. So let's look at the
00:05:18.010 --> 00:05:25.920
architecture of LoJack back then. So the
first thing that we have here is a module
00:05:25.920 --> 00:05:32.140
in the UEFI BIOS, and this module will
write a file to the Windows partition. So
00:05:32.140 --> 00:05:36.940
this file is called autochk.exe, which
replaces the legitimate autochk.exe, whose
00:05:36.940 --> 00:05:44.230
job is to perform filesystem integrity
check during early Windows boot. So by
00:05:44.230 --> 00:05:50.810
replacing this agent during early Windows
boot it will be executed. And from there
00:05:50.810 --> 00:05:57.710
it will drop rpcnetp.exe, which is the
small agent, and will install a service
00:05:57.710 --> 00:06:03.490
and when Windows will run it will run this
service, and rpcnetp will be launched at
00:06:03.490 --> 00:06:09.300
this point. And it will inject itself into
svchost , and then from there it will
00:06:09.300 --> 00:06:13.660
inject itself into Internet Explorer which
is pretty interesting because it's very
00:06:13.660 --> 00:06:18.030
shady and that's something that we see
pretty much all the time in malware but
00:06:18.030 --> 00:06:24.270
not often in legitimate software. And from
Internet Explorer it will then communicate
00:06:24.270 --> 00:06:32.220
with the command and control server and it
will download the full recovery agent. So
00:06:32.220 --> 00:06:38.190
now let's look at some of the issues that
the researchers found with this... in this
00:06:38.190 --> 00:06:44.580
solution. So one of the vulnerabilities
they found is very interesting for us and
00:06:44.580 --> 00:06:49.140
in fact that's really the only one that
matters for this talk. And this is a
00:06:49.140 --> 00:06:55.620
configuration file vulnerability. So the
configuration is embedded into rpcnetp.exe
00:06:55.620 --> 00:07:00.990
and it is encrypted but it is encrypted
with a very weak algorithm. So it is in
00:07:00.990 --> 00:07:08.400
single byte XOR key, and it is not
authenticated whatsoever. And what's in
00:07:08.400 --> 00:07:14.560
this configuration file? Well, that's
where you can find the server, the command
00:07:14.560 --> 00:07:20.860
and control server. So an attacker can
just change this configuration to point to
00:07:20.860 --> 00:07:27.900
its own attacker-controlled server. So we
knew that this vulnerability existed for a
00:07:27.900 --> 00:07:35.110
while, it was back in 2009, but we had no
evidence of it being used in the wild.
00:07:35.110 --> 00:07:41.120
Until earlier this year, when Arbor
Networks published a blog post where they
00:07:41.120 --> 00:07:46.910
described some modified small agent with
modified configuration where the domains
00:07:46.910 --> 00:07:55.210
that were embedded in this configuration
were linked to old Sednit domains. So
00:07:55.210 --> 00:08:00.550
let's go back to LoJack architecture and
look at where this attack took place. So
00:08:00.550 --> 00:08:16.240
it took place at this level here. So from
there we did some detection for this
00:08:16.240 --> 00:08:24.250
malware and it was... and we hunted to
gather as much samples as as we could. And
00:08:24.250 --> 00:08:30.800
it was fairly simple because they always
modified the same exact version of the
00:08:30.800 --> 00:08:37.280
agent and they modified, so that's what we
can see here, so they modified the command
00:08:37.280 --> 00:08:42.909
and control server. And here we see the
encrypted version of course. So by looking
00:08:42.909 --> 00:08:48.709
at this we will look at ESET's telemetry
and found out that there was a few
00:08:48.709 --> 00:08:53.490
organizations that were hit mostly in the
Balkans, in Central Europe as well as in
00:08:53.490 --> 00:08:59.149
Eastern Europe. These were military and
diplomatic organizations. And what's
00:08:59.149 --> 00:09:06.666
interesting is that we also found other
Sednit tools in the same organization. So
00:09:06.666 --> 00:09:11.689
at this point we wondered how this malware
got there, but since there was other
00:09:11.689 --> 00:09:16.789
backdoors of Sednit in the organization we
thought it might be the infection vector,
00:09:16.789 --> 00:09:22.190
but by digging a little bit deeper we
found another interesting component. And
00:09:22.190 --> 00:09:28.850
if we go back to the LoJack architecture,
the component that we found is at this
00:09:28.850 --> 00:09:35.370
step here. So at this step in the LoJack
architecture it's autochk.exe that lives
00:09:35.370 --> 00:09:41.140
there. But what we found is another file
called autoche.exe instead of autochk. And
00:09:41.140 --> 00:09:47.220
it does pretty much the same thing. So it
also installs a service and it also drops
00:09:47.220 --> 00:09:54.249
rpcnetp.exe. But it is the rpcnetp version
that has a modified server in it. So
00:09:54.249 --> 00:09:59.759
Sednit domain basically. And we continue
to look at what we can find in this
00:09:59.759 --> 00:10:06.160
organization and we found another tool
which is called info_efi.exe, and that
00:10:06.160 --> 00:10:10.350
allows to drop... to dump a lot of
information about very low level settings
00:10:10.350 --> 00:10:17.960
of the machine. And this tool uses Read
Write Everything's driver. And
00:10:17.960 --> 00:10:23.019
Read Write Everything is a software that allows you
to manipulate very low level setting of
00:10:23.019 --> 00:10:27.660
your machine. So using this tool you can
read and write to PCI configuration
00:10:27.660 --> 00:10:32.999
register, to memory-mapped IOs, to IO port
space and you can also access physical
00:10:32.999 --> 00:10:38.310
memory and this tool uses a kernel driver
of course - if you want to do those things
00:10:38.310 --> 00:10:43.360
you need a kernel driver. And this kernel
driver is properly signed so that you can
00:10:43.360 --> 00:10:49.800
push it on even a recent version of
Windows. And so yeah, that's the driver
00:10:49.800 --> 00:10:57.040
that was used by info_efi here. And by
Googling a little bit around what we found
00:10:57.040 --> 00:11:02.220
out is that this specific driver was used
in the past by security researchers to
00:11:02.220 --> 00:11:10.040
exploit vulnerabilities at the firmware
level. So, yeah, the last thing that was
00:11:10.040 --> 00:11:17.350
missing here to mimic the whole LoJack
solution was a UEFI BIOS module. So at
00:11:17.350 --> 00:11:24.560
this point we wondered, did they get
there. So, because of the tool dumping
00:11:24.560 --> 00:11:28.220
information about the BIOS that I just
spoke about, we were pretty confident that
00:11:28.220 --> 00:11:34.149
something more was happening there. And by
digging a little bit deeper, we found
00:11:34.149 --> 00:11:40.310
other tools that strengthen our
suspicions. So the first tool is called
00:11:40.310 --> 00:11:47.430
ReWriter_read. And it is a tool used to
dump the content of the SPI flash memory,
00:11:47.430 --> 00:11:54.009
and it also uses Read Write Everything's driver and
it uses these specific IO control codes.
00:11:54.009 --> 00:11:59.850
So it allows it to read and write to
memory-mapped IO space as well as read and
00:11:59.850 --> 00:12:05.709
write to PCI configuration registers.
What's interesting for us as reverse
00:12:05.709 --> 00:12:09.680
engineer is that this tool contains a lot
of debug strings which really made our job
00:12:09.680 --> 00:12:16.510
easier. And it consists of the following
operations. So the first thing it will do
00:12:16.510 --> 00:12:22.190
is that it will log information on the
BIOS_CNTL register and we'll talk a lot of
00:12:22.190 --> 00:12:27.860
detail about this register just a little bit later
in this talk. Then it locates the BIOS
00:12:27.860 --> 00:12:35.439
region base address. And finally it reads
the UEFI firmware content and dump it to a
00:12:35.439 --> 00:12:42.110
file. So another tool that we found is
really complementary to the tool to
00:12:42.110 --> 00:12:47.279
ReWriter_read and it is called
ReWriter_binary. So it also contains a lot
00:12:47.279 --> 00:12:53.920
of debug strings. It also uses
RWEverything's driver. And now the UEFI
00:12:53.920 --> 00:12:59.420
firmware is dumped into memory, the next
step is to add the rootkit to the firmware
00:12:59.420 --> 00:13:02.439
and to write it back to the SPI flash
memory and that's exactly what this tool
00:13:02.439 --> 00:13:09.780
does. Okay. So now let's talk about the
patching of the UEFI firmware. But before
00:13:09.780 --> 00:13:13.069
we dig into the subjects there are a
couple things that I wanted to introduce
00:13:13.069 --> 00:13:16.550
here just to make sure that we're on the
same page. So the first thing I want to
00:13:16.550 --> 00:13:22.910
talk about is UEFI and UEFI stands for
Unified Extensible Firmware Interface and
00:13:22.910 --> 00:13:26.769
it is a standardized specification that
defines the interface that exists between
00:13:26.769 --> 00:13:31.959
the operating system and the firmware. And
it's kind of a replacement for the legacy
00:13:31.959 --> 00:13:39.149
BIOS. So, a UEFI compliant firmware will
provide a set of services to UEFI
00:13:39.149 --> 00:13:43.670
applications and here read the operating
system loader. There are other UEFI
00:13:43.670 --> 00:13:50.639
applications, but usually it's the
operating system loader that runs. So the
00:13:50.639 --> 00:13:55.389
first set of services is called the boot
services and these are services that are
00:13:55.389 --> 00:14:00.149
available during the firmware lifetime but
once the operating system is loaded, these
00:14:00.149 --> 00:14:04.430
services are not available anymore and
there are the runtime services that are
00:14:04.430 --> 00:14:10.629
also available during firmware lifetime.
But once the operating system is loaded
00:14:10.629 --> 00:14:14.560
they are still available, so that a kernel
driver for instance can make call in these
00:14:14.560 --> 00:14:20.720
services. An example of these services
allows the operating system to read and
00:14:20.720 --> 00:14:25.740
write to UEFI variables. And what's
interesting with UEFI is that there is no
00:14:25.740 --> 00:14:30.559
more master boot record and volume boot
record involved in the boot process
00:14:30.559 --> 00:14:37.959
meaning that there is no easy way to
hijack the early boot control flow. So the
00:14:37.959 --> 00:14:43.279
second thing I want to introduce here are
the driver execution environment drivers -
00:14:43.279 --> 00:14:47.649
so the DXE drivers. So DXE drivers are
PE/COFF images meaning that they are
00:14:47.649 --> 00:14:53.519
basically Windows executables, and they
are kind of the core of UEFI firmware so
00:14:53.519 --> 00:14:57.670
that they can do many things, some of them
will be used to abstract the hardware.
00:14:57.670 --> 00:15:01.240
Some of them will be used to produce the
UEFI standard interface, so the boot
00:15:01.240 --> 00:15:05.889
services and the runtime services, and
they can also be used by firmware vendors
00:15:05.889 --> 00:15:11.660
or OEMs to extend the firmware by
registering new services - the so-called
00:15:11.660 --> 00:15:17.430
protocols in the UEFI specification. And,
the DXE drivers are loaded during the DXE
00:15:17.430 --> 00:15:22.269
phase of the platform initialization and
they are loaded by the DXE dispatcher that
00:15:22.269 --> 00:15:28.829
will also be referred to as the DXE Core.
The last thing that I'm going to do: I
00:15:28.829 --> 00:15:34.089
want to introduce for now is the UEFI
firmware layout - so the UEFI firmware
00:15:34.089 --> 00:15:40.060
is located in the BIOS region of the SPI
flash memory. And this region will contain
00:15:40.060 --> 00:15:45.639
multiple volume. But let's look at it with
a little bit more detail in this tool here
00:15:45.639 --> 00:15:51.120
which is UEFI tool, that is an open source
software that allows you to manipulate
00:15:51.120 --> 00:15:57.189
UEFI firmware images. So here I loaded the
typical content of SPI flash memory dump
00:15:57.189 --> 00:16:01.580
in this tool and let's look at what we
have. So, the first thing that we see here
00:16:01.580 --> 00:16:05.990
is the descriptor region, so it contains...
this region contains metadata about how
00:16:05.990 --> 00:16:11.279
the remaining data in the SPI flash memory
is laid out. The second region that we
00:16:11.279 --> 00:16:16.629
find here is the ME region which contains
the Intel Management Engine firmware. And
00:16:16.629 --> 00:16:20.409
finally we have the BIOS region which is
really the main interest... the main thing
00:16:20.409 --> 00:16:27.579
that we want to look at today. So the BIOS
region contains multiple volumes. So let's
00:16:27.579 --> 00:16:32.569
look at one volume in a little bit more
detail. So here we have a volume of type
00:16:32.569 --> 00:16:37.870
firmware filesystem version 2 and this
volume contains multiple files and these
00:16:37.870 --> 00:16:42.069
files are identified by GUIDs. So that's
what we can see under the name column
00:16:42.069 --> 00:16:49.750
here. And a file doesn't contain directly
the UEFI executable, but it is composed of
00:16:49.750 --> 00:16:55.161
multiple sections and one of these section
is the actual UEFI executable, but there
00:16:55.161 --> 00:16:59.139
are other section and in this case we see
a DXE dependency section that allows to
00:16:59.139 --> 00:17:05.970
define dependencies for this specific UEFI
image and we also see a version section
00:17:05.970 --> 00:17:09.920
and a user interface section which allows
to give us a human readable name for this
00:17:09.920 --> 00:17:17.020
file instead of the GUID which is very
pretty difficult to remember for humans.
00:17:18.660 --> 00:17:24.290
OK, so now that we have all this in mind
let's go back to ReWriter_binary. So what
00:17:24.290 --> 00:17:28.610
ReWriter_binary will do is that it will
parse all of the firmware volumes that it
00:17:28.610 --> 00:17:36.740
can find looking for 4 specific files. So
it looks for Ip4Dxe, NtfsDxe, SmiFlash,
00:17:36.740 --> 00:17:42.990
and the DXE Core. So why does it look for
Ip4Dxe and the DXE Core? Well these files
00:17:42.990 --> 00:17:48.470
are looked for to find the firmware volume
where to install the UEFI rootkit. So
00:17:48.470 --> 00:17:54.580
usually in UEFI firmwares all of the DXE
drivers all in the same volume, so when
00:17:54.580 --> 00:17:59.140
the tool will parse... will find in fact
Ip4Dxe, it will know it is currently
00:17:59.140 --> 00:18:03.740
parsing the volume with all of the DXE
drivers in it and it will keep it as a
00:18:03.740 --> 00:18:07.770
candidate for the UEFI rootkit
installation. And it looks for the DXE
00:18:07.770 --> 00:18:13.010
Core basically for the same reason, but
sometimes the DXE Core is in a different
00:18:13.010 --> 00:18:17.390
volume, so when it will find it, it will
keep the volume as another candidate for
00:18:17.390 --> 00:18:22.280
the UEFI rootkit installation and the
chosen volume will be the one with enough
00:18:22.280 --> 00:18:31.050
free space available in it. Now, NtfsDxe.
So NtfsDxe is the American Megatron Inc.
00:18:31.050 --> 00:18:37.880
NTFS driver and if the tool finds it, it
will remove it, and the reason for that is
00:18:37.880 --> 00:18:44.340
that the UEFI rootkit embeds its own NTFS
driver, so to avoid any conflict with
00:18:44.340 --> 00:18:51.890
another NTFS driver it just removes it.
And now SmiFlash, so, SmiFlash is looked
00:18:51.890 --> 00:18:57.010
for... and, you know, the tool will... if
the tool finds it, it will keep some
00:18:57.010 --> 00:19:00.680
metadata about it in the structure, but in
the version of the tool that we analyzed
00:19:00.680 --> 00:19:07.122
it's not used anywhere. But interestingly,
SmiFlash is a known vulnerable DXE driver.
00:19:07.510 --> 00:19:11.120
So what we believe is that Sednit might
have been fiddling in another version of
00:19:11.120 --> 00:19:16.010
the tool with some exploit for this driver
in order to be able to bypass write
00:19:16.010 --> 00:19:22.160
protection mechanisms to the BIOS region
of the SPI flash memory. So now that it
00:19:22.160 --> 00:19:28.860
has found the volume where to install the
rootkit, it will add the rootkit, right.
00:19:28.860 --> 00:19:33.980
So the first thing it does, it will create
a firmware file system file header, then
00:19:33.980 --> 00:19:38.940
it will append the rootkit file, which is
a compressed section that contains two
00:19:38.940 --> 00:19:46.750
other sections, one of one of these is the
actual UEFI rootkit image and the other
00:19:46.750 --> 00:19:53.060
one is a user interface section defining
the name for this rootkit which is SecDXE,
00:19:53.060 --> 00:19:59.800
as in security DXE. And then it will take
this blob of data and write it at the end
00:19:59.800 --> 00:20:02.202
of the firmware volume that was chosen.
00:20:11.050 --> 00:20:14.310
So now that the UEFI rootkit is inside the
00:20:14.310 --> 00:20:19.720
firmware into memory, the next step is to
write it back to the SPI flash memory. And
00:20:19.720 --> 00:20:23.870
once again there's a couple of things that
I want to introduce here. So I want to
00:20:23.870 --> 00:20:28.530
talk about BIOS write protection
mechanisms. So the chipset exposes write
00:20:28.530 --> 00:20:33.536
protection mechanisms that need to be
properly configured by the firmware. So
00:20:33.536 --> 00:20:38.650
there are no such thing as, you know, BIOS
write particular mechanism enabled by
00:20:38.650 --> 00:20:43.160
default. It's really the job of the
firmware to do that. And today will only
00:20:43.160 --> 00:20:48.160
cover relevant protections to our
research. So only the protection mechanism
00:20:48.160 --> 00:20:54.700
that are looked for by
REWriter_binary. And yeah the protection
00:20:54.700 --> 00:20:58.730
we'll talk about are exposed via the BIOS
control register that we've seen a little
00:20:58.730 --> 00:21:04.440
bit earlier in this talk. So, if you're a
kernel driver and you want to write to be
00:21:04.440 --> 00:21:08.750
BIOS region of the SPI flash memory, what
you need to do first is you need to set
00:21:08.750 --> 00:21:13.940
the BIOS Write Enable field of the BIOS
control register to 1 and then you're able
00:21:13.940 --> 00:21:21.180
to write to the SPI flash memory. But of
course you don't want any kernel driver to
00:21:21.180 --> 00:21:26.038
be able to modify your UEFI firmware and
potentially brick your machine. So there's
00:21:26.038 --> 00:21:29.840
a protection mechanism there which is
another field in the BIOS control register
00:21:29.840 --> 00:21:35.990
and this field is called BIOS lock enable
and it allows to lock BIOS Writer Enable to
00:21:35.990 --> 00:21:44.890
0. And this field is readable in WLO. WLO
means write lock once. And what it means
00:21:44.890 --> 00:21:48.760
is that once the firmware has set this bit
there's no other way to set it back to 0
00:21:48.760 --> 00:21:50.426
than performing a full platform reset.
00:21:53.013 --> 00:21:56.100
But there's a problem here, and it lies in the
00:21:56.100 --> 00:22:03.220
fact that BIOS lock enable implementation
is vulnerable. So how it works is that
00:22:03.220 --> 00:22:10.930
when BIOS write enable is set to 1, it's
value will actually change in the BIOS
00:22:10.930 --> 00:22:16.060
control register for a small amount of
time. And then the platform will issue a
00:22:16.060 --> 00:22:22.240
system management interrupt and the SMI
handler will set BIOS write enable back to
00:22:22.240 --> 00:22:28.180
0. But, yeah, the firmware must implement
this SMI, otherwise this mechanism is
00:22:28.180 --> 00:22:35.080
totally useless. But maybe you've guessed
it. But what happens if we write to the
00:22:35.080 --> 00:22:41.020
SPI flash memory before the SMI handler
sets BIOS write enable back to 0? So there
00:22:41.020 --> 00:22:45.750
is a race condition vulnerability here.
And there is a paper about it which is
00:22:45.750 --> 00:22:50.240
called "speed racer". And to exploit this
what you need to do is, you need one
00:22:50.240 --> 00:22:55.460
thread that continuously sets BIOS write
enable to 1, while another thread tries to
00:22:55.460 --> 00:23:00.130
write the data to the SPI flash memory.
And according to this paper it works on
00:23:00.130 --> 00:23:03.740
multicore processors as well as on single
core processors with hyper-threading
00:23:03.740 --> 00:23:09.820
enabled. So Intel came up with a fix for
this issue and was introduced in the
00:23:09.820 --> 00:23:15.490
platform controller hub family of Intel
chipsets around 2008. And what they did
00:23:15.490 --> 00:23:20.060
is, that they added a field in the BIOS
control register. And this field is called
00:23:20.060 --> 00:23:25.480
SMM BIOS write protect disable. And the
name is a little bit misleading, but if
00:23:25.480 --> 00:23:30.370
you remove disable, that's actually what
it does. And if this mechanism is
00:23:30.370 --> 00:23:35.470
activated, there will be no other way to
write to the SPI, to the BIOS region of
00:23:35.470 --> 00:23:41.450
the SPI flash memory, than if you don't
have all of the cores of your processor
00:23:41.450 --> 00:23:47.760
running into SMM, meaning that the job of
writing to the SPI flash memory is now only
00:23:47.760 --> 00:23:53.674
available to system management mode. And
once again the firmware must set this bit.
00:23:53.674 --> 00:24:02.750
Otherwise this mechanism is not activated,
right. Okay so let's go back to
00:24:02.750 --> 00:24:06.830
ReWriter_Binary. So of course if I talk
about all of these mechanisms it's because
00:24:06.830 --> 00:24:11.350
ReWriter_Binary checks for them. So it
will check if the platform is properly
00:24:11.350 --> 00:24:16.720
configured and it implements the exploit
for the race condition that I just spoke
00:24:16.720 --> 00:24:22.750
about. So let's look at the writing
process decision tree. So the first thing
00:24:22.750 --> 00:24:28.700
that it will look for is if BIOS write
enable is set, and if BIOS write enable is
00:24:28.700 --> 00:24:34.910
set there, then there's nothing stopping
it from writing the UEFI image. But if it
00:24:34.910 --> 00:24:40.290
is not set, then it will check "Oh, is
BIOS lock enable activated?". And this, if
00:24:40.290 --> 00:24:45.850
this mechanism is not activated then it
will just flip BIOS write enable to 1, and
00:24:45.850 --> 00:24:50.400
then it will write the UEFI image. But if
it is activated, the last thing it will
00:24:50.400 --> 00:24:57.280
check for is "Is SMM BIOS write protect
set?". And if it is not set, then it will
00:24:57.280 --> 00:25:02.940
exploit the race condition that we spoke
about. And if it is set, then the tool
00:25:02.940 --> 00:25:11.260
will just fail. So the tool only works if
the platform is misconfigured. And we
00:25:11.260 --> 00:25:17.060
spoke about SmiFlash, the vulnerable DXE
driver. So yeah, what we think is that by
00:25:17.060 --> 00:25:21.310
being able to exploit this vulnerability,
they would have been able to have a tool
00:25:21.310 --> 00:25:28.440
that works even when the platform is
properly configured. So it's a very good
00:25:28.440 --> 00:25:36.420
example of; I mean if firmware vendors
would have done their job correctly here,
00:25:36.420 --> 00:25:40.580
this tool would have failed at flashing
the UEFI firmware, so that's a great
00:25:40.580 --> 00:25:47.420
example of how, you know, firmware
security is. So here let's just take a
00:25:47.420 --> 00:25:52.100
step back and look at what we have. So
what we have is a software implementation
00:25:52.100 --> 00:25:57.340
to flash the firmware remotely post
exploitation, meaning that as an attacker
00:25:57.340 --> 00:26:03.120
I can, you know, infect my target the way
I usually do - let's say by sending a
00:26:03.120 --> 00:26:07.030
phishing email. And once I have a foothold
in the machine, I can use this tool to
00:26:07.030 --> 00:26:12.770
deploy the UEFI rootkit. And one we knew
about in the past was Hacking Team's UEFI
00:26:12.770 --> 00:26:19.200
rootkit and it needed physical access to
be deployed. So it's so much more
00:26:19.200 --> 00:26:25.020
convenient to be able to do it remotely.
And let's note here that there is no proof
00:26:25.020 --> 00:26:30.310
of Hacking Team's rootkit being used in an
actual cyber attack. It has never been
00:26:30.310 --> 00:26:36.880
found on a victim's machine or at least if
it had, it hasn't been publicly disclosed.
00:26:36.880 --> 00:26:41.271
So what we did at this point is that we
extracted the UEFI rootkit from the tool
00:26:41.271 --> 00:26:47.050
and we looked at ESET's UEFI scanner
telemetry to see if we can find something.
00:26:47.050 --> 00:26:52.030
Turns out that we found the UEFI rootkit
in the SPI flash memory of a victim's
00:26:52.030 --> 00:26:57.990
machine, making it the first publicly
known UEFI rootkit to be used in an actual
00:26:57.990 --> 00:27:01.350
cyber attack. Okay.
00:27:01.350 --> 00:27:14.710
So now let's look at the UEFI
rootkit itself. So the UEFI
00:27:14.710 --> 00:27:19.260
rootkit is a DXE driver. So it is loaded
by the DXE dispatcher every time that the
00:27:19.260 --> 00:27:25.510
machine will boot. Its file name is SecDxe
as we've seen earlier and here's the file
00:27:25.510 --> 00:27:33.520
GUID for future reference. So let's look
at the UEFI rootkit workflow. So UEFI
00:27:33.520 --> 00:27:36.830
firmware we'll go through multiple phases
when it boots. The first phase is the
00:27:36.830 --> 00:27:41.380
security phase, the second one is the pre
EFI initialization phase, and then there
00:27:41.380 --> 00:27:44.540
is the driver execution environment phase
and that's where it begins to be
00:27:44.540 --> 00:27:50.740
interesting for this rootkit. So that's
where the DXE dispatcher lives. So that's
00:27:50.740 --> 00:27:55.650
when all of the DXE drivers will be
loaded. So at some point the UEFI rootkit
00:27:55.650 --> 00:28:01.590
will be loaded. And what will happen is
that the rootkit will create an event
00:28:01.590 --> 00:28:07.710
attached to EFI GROUP_READY_TO_BOOT. And
it will bind a notify function to this
00:28:07.710 --> 00:28:14.340
event. So in the next phase, when the boot
manager will run, at some point it will
00:28:14.340 --> 00:28:22.330
signal this event and the notify function
will be called. So, the notify function
00:28:22.330 --> 00:28:28.504
does 3 things. The first thing is that it
will install an NTFS driver. Then it will
00:28:28.504 --> 00:28:35.460
drop autoche.exe and rpcnetp.exe using
this NTFS driver. And finally it will
00:28:35.460 --> 00:28:42.960
patch a value in the Windows Registry. So,
the NTFS driver is needed to get file
00:28:42.960 --> 00:28:49.700
based access to Windows partition and
Sednit's operator did not write their own
00:28:49.700 --> 00:28:55.500
NTFS driver. What did it is that they use
Hacking Team's NTFS driver from Hacking
00:28:55.500 --> 00:29:03.920
Team's leak. And, yeah, so here's the code
responsible for dropping the files. So as
00:29:03.920 --> 00:29:08.400
we can see here, it is dropping
rpcnetp.exe and here it is dropping
00:29:08.400 --> 00:29:16.640
autoche.exe. And the last step is to patch
the Windows Registry. So how it does that
00:29:16.640 --> 00:29:22.540
is that it will open the file backing the
HKLM\SYSTEM Registry hive and it doesn't
00:29:22.540 --> 00:29:27.680
have all the logic to parse Windows
Registry structures, so it will only look
00:29:27.680 --> 00:29:31.900
for a textual pattern and the textual
pattern it will look for is "autocheck
00:29:31.900 --> 00:29:36.960
autochk " and it will change it to
"autocheck autoche " and it happens to be
00:29:36.960 --> 00:29:43.200
modifying the BootExecute key. So, the
BootExecute key is the key responsible for
00:29:43.200 --> 00:29:50.510
launching autochk.exe during Windows early
boot. So by modifying it to autoche
00:29:50.510 --> 00:29:56.760
instead of autochk that's autoche.exe that
will be executed instead of autochk. And,
00:29:56.760 --> 00:30:01.130
so here if we go back to the UEFI rootkit
workflow, when the operating system will
00:30:01.130 --> 00:30:06.490
run, then it will execute autoche.exe.
Then autoche.exe will drop the small
00:30:06.490 --> 00:30:13.470
agent, the rpcnetp.exe, and so on. But
what's interesting here is that it will
00:30:13.470 --> 00:30:18.620
revert back the modification in the
Windows Registry from autoche to autochk.
00:30:18.620 --> 00:30:23.580
So that as a Windows user, for instance,
if I look in the Windows Registry, I won't
00:30:23.580 --> 00:30:28.710
find that anything, any modification
occurred there. So that's a pretty
00:30:28.710 --> 00:30:32.460
interesting sealth technique that is
enabled by the fact that the malware is
00:30:32.460 --> 00:30:42.360
coming from the firmware. Okay. So, the
last thing that I want to talk about now
00:30:42.360 --> 00:30:50.630
is prevention and remediation, so what can
you do to protect yourself against this
00:30:50.630 --> 00:30:56.191
kind of attack? And if ever you were...
you find out that you had a UEFI rootkit in
00:30:56.191 --> 00:31:04.090
your machine, what can you do? So,
prevention. So the first thing and the
00:31:04.090 --> 00:31:10.800
most important thing, which is also the
most accessible thing, thankfully, is that
00:31:10.800 --> 00:31:16.060
you should keep your UEFI firmware up to
date to make sure that if, you know,
00:31:16.060 --> 00:31:23.550
security researchers found some issues
with your firmware and they disclosed it
00:31:23.550 --> 00:31:27.950
and the firmware vendor fixed them, you
want to make sure that you have the latest
00:31:27.950 --> 00:31:34.180
patches available on your machine. Then
the second thing is that you should really
00:31:34.180 --> 00:31:38.530
enable Secure Boot. But let's note here
that Secure Boot itself would not
00:31:38.530 --> 00:31:43.200
effectively you against this specific
attack. And the reason for that is that
00:31:43.200 --> 00:31:48.520
Secure Boot takes the content of the SPI
flash memory as its root of trust, meaning
00:31:48.520 --> 00:31:55.650
that what's inside the SPI flash memory is
not subject for validation. So what does
00:31:55.650 --> 00:32:00.240
it validates then, right? Well, Secure
Boot will check what's coming from outside
00:32:00.240 --> 00:32:04.480
of the SPI flash memory meanings the PCI
option ROMs and probably the most
00:32:04.480 --> 00:32:08.810
important thing, the operating system
loader. So it's really a mechanism that
00:32:08.810 --> 00:32:14.860
checks that the operating system loader
hasn't been tampered with. So what can we
00:32:14.860 --> 00:32:20.610
do then, right? Well, what we need is a
hardware root of trust. So we need to move
00:32:20.610 --> 00:32:25.760
the root of trust from the SPI flash
memory to some piece of hardware. So it
00:32:25.760 --> 00:32:31.090
must be in a, you know, one time
programmable chip that is programmed
00:32:31.090 --> 00:32:38.960
during manufacturing time and that cannot
be written to ever after. An example of
00:32:38.960 --> 00:32:45.410
this exists - technology like Intel
BootGuard implements this. And also Apple
00:32:45.410 --> 00:32:51.570
T2 security chip has a hardware root of
trust. And then you kind of need to hope
00:32:51.570 --> 00:32:57.210
that your firmware configures the security
mechanisms properly and there's not much
00:32:57.210 --> 00:33:02.230
you can do about it if your firmware is
up-to-date. But thankfully there are
00:33:02.230 --> 00:33:06.050
firmware security assessment tool
available out there and an example of that
00:33:06.050 --> 00:33:13.380
is Intel CHIPSEC. So, with Intel CHIPSEC
which is an open source software tool, so
00:33:13.380 --> 00:33:19.370
you can just download this tool, put it in
an USB key, boot from it and then this
00:33:19.370 --> 00:33:22.940
tool will check for all of the security
mechanism that we spoke about today, it
00:33:22.940 --> 00:33:28.630
will check if they are properly configured
and also it checks for a bunch more stuff.
00:33:28.630 --> 00:33:38.310
And now also CHIPSEC checks if your
firmware has this LoJax rootkit. So if you
00:33:38.310 --> 00:33:42.200
want to know if your firmware properly
configures these security mechanism that's
00:33:42.200 --> 00:33:52.240
really the way to go. Now about
remediation. So, this slide is kind of
00:33:52.240 --> 00:33:57.210
short. And the reason for that is that if
you find out that you have a UEFI rootkit
00:33:57.210 --> 00:34:02.350
in your SPI flash, there's not pretty much
you can do. You really need to re-flash
00:34:02.350 --> 00:34:07.110
your UEFI firmware and that's definitely
not something that is easy to do for
00:34:07.110 --> 00:34:13.489
anybody. And well, if it's not an option
for you, then you kind of need to get rid
00:34:13.489 --> 00:34:19.359
of your motherboard or your laptop and get
a new one basically. So that's how serious
00:34:19.359 --> 00:34:29.480
this kind of attack is. Now, conclusion.
So, our research shows that UEFI rootkits
00:34:29.480 --> 00:34:35.239
are not only toys for researchers to play
with, but they are real world threats used
00:34:35.239 --> 00:34:41.460
in actual cyber attacks. So it might be
something that you want to keep in mind
00:34:41.460 --> 00:34:48.339
when you'll be defining your threat model.
Also we won't stress this enough: firmware
00:34:48.339 --> 00:34:53.489
must be built with security in mind from
the bottom up, and things are getting
00:34:53.489 --> 00:34:57.210
better because there are more and more
security researchers looking into this,
00:34:57.210 --> 00:35:03.750
but there's still work to do. And
hopefully, our research help share
00:35:03.750 --> 00:35:11.130
knowledge about how to prevent and
mitigate UEFI-based threats. So that is
00:35:11.130 --> 00:35:17.160
pretty much it for me today. So thank you
for having me and if ever you're
00:35:17.160 --> 00:35:22.240
interested to know more details about this
research, the white paper is available at
00:35:22.240 --> 00:35:27.974
welivesecurity.com and you can grab a copy
there. So, thanks.
00:35:27.974 --> 00:35:38.259
Applause
Herald: Alright, you know the drill. We
00:35:38.259 --> 00:35:44.177
have 5 minutes for Q&A. So please, quick
and short questions. Number 1 please.
00:35:46.430 --> 00:35:56.480
Question: (incomprehensible) attacking
other operating systems (incomprehensible)
00:35:56.480 --> 00:36:01.260
Answer: In this case, well, that's kind of
the... pretty much the only one we're aware
00:36:01.260 --> 00:36:07.410
of, apart from Hacking Team's UEFI
rootkit, and this one only works on
00:36:07.410 --> 00:36:13.450
Windows, so we have no; we don't know
about any other that target's Linux or Mac
00:36:13.450 --> 00:36:14.297
OS for instance.
00:36:16.403 --> 00:36:19.349
Herald: Please refrain from walking in
front of the cameras when you're leaving.
00:36:19.349 --> 00:36:23.119
Thank you.
Could we get microphone number
00:36:23.119 --> 00:36:28.319
2 please.
Q: Hello, thanks for the talk. On your
00:36:28.319 --> 00:36:35.829
slides you mentioned a tool, open source,
for checking out the layout. What was the
00:36:35.829 --> 00:36:41.530
name of the tool?
A: It's called UEFI tool. Laughter
00:36:41.530 --> 00:36:44.030
Q: Nice.
A: So you can find it on GitHub.
00:36:45.170 --> 00:36:47.090
Q: Thanks.
Herald: The internet please.
00:36:47.090 --> 00:36:54.387
Q: Thank you. Does the rootkit also work
when the UEFI is in BIOS legacy mode?
00:36:56.310 --> 00:37:06.240
A: Uhm... That is a pretty good question.
I think it should, but I am not sure about
00:37:06.240 --> 00:37:12.839
it. That's a good question, I'd have to
look into this, to have a... laughing an
00:37:12.839 --> 00:37:16.650
answer I'm 100 percent sure about. Sorry
for that.
00:37:16.650 --> 00:37:24.630
Herald: Microphone number 3 please. It's
you in the back, are you? No that's 4,
00:37:24.630 --> 00:37:29.900
I'm sorry.
Q: OK. So, does the UEFI dropper still
00:37:29.900 --> 00:37:33.291
work with BitLocker enabled?
00:37:35.370 --> 00:37:37.789
A: I know. Oh yeah. Yeah. We test that.
00:37:37.789 --> 00:37:47.119
No, it doesn't work if BitLocker is
enabled, so it doesn't wait for the... for
00:37:47.119 --> 00:37:52.430
BitLocker to have decrypted all of the
data. So no, it doesn't work if
00:37:52.430 --> 00:37:53.550
BitLocker is enabled.
00:37:55.615 --> 00:37:57.020
Herald: Number 1 please.
00:37:59.710 --> 00:38:08.430
Q: Would it be possible to work within
full disk encryption. (incomprehensible)
00:38:08.430 --> 00:38:12.100
the file system was decrypted and then
installed the dropper.
00:38:12.100 --> 00:38:15.800
A: I'm not sure I heard all of the
question, but if it works if there's full
00:38:15.800 --> 00:38:22.600
disk encryption? Is it the question right?
Q: Would it be possible to make it work
00:38:22.600 --> 00:38:28.609
with full disk encryption?
A: I think it should be because the LoJack
00:38:28.609 --> 00:38:33.480
software is a legitimate one, the anti-
theft solution. They are able to make it
00:38:33.480 --> 00:38:39.310
work even if BitLocker is enabled or full
disk encryption. So yeah, it should be
00:38:39.310 --> 00:38:40.609
possible to do so.
00:38:42.229 --> 00:38:44.390
Herald: One more internet question please.
00:38:44.390 --> 00:38:50.231
Q: Thank you. What if a rootkit doesn't
fit in the SPI flash. Is filling up the
00:38:50.231 --> 00:38:54.749
SPI flash space completely a valid
prevention?
00:38:54.749 --> 00:39:01.829
A: No I don't know... we could really call
it a prevention mechanism. But yeah, if
00:39:01.829 --> 00:39:06.709
there is not enough free space available
on the firmware volumes the tool will just fail.
00:39:09.276 --> 00:39:10.571
Herald: Number two please.
00:39:10.961 --> 00:39:17.229
Q: Hi. You said that there is no real
possibility to secure everything, but what
00:39:17.229 --> 00:39:22.730
are your daily choices that you use like,
on your personal computer, to be fully
00:39:22.730 --> 00:39:28.269
secret?
A: Well... laughing I could say an
00:39:28.269 --> 00:39:33.270
alternative platform, but... laughter
but yeah, if you have
00:39:33.270 --> 00:39:37.230
a modern Intel CPU and you have
00:39:37.230 --> 00:39:43.140
Secure Boot enabled and you have, you
know, all of the latest UEFI firmware
00:39:43.140 --> 00:39:50.381
updates, that's kind of the best you can
do to be safe for... against that kind of
00:39:50.381 --> 00:39:52.885
attack.
Q: I have... I have my like this...
00:39:52.885 --> 00:39:57.061
Herald: Number 1 please.
Q: So, going back to the LoJack
00:39:57.061 --> 00:40:05.900
configuration file vulnerability. Is the
configuration file on the operating system
00:40:05.900 --> 00:40:10.220
file system?
A: No no no, the... In fact it's... there is
00:40:10.220 --> 00:40:15.660
not a separate configuration file, the
configuration is embedded inside the
00:40:15.660 --> 00:40:19.269
executable. So it is embedded into
rpcnetp.exe.
00:40:21.059 --> 00:40:25.680
Herald: Unfortunately, we are already out
of time. So please thank our speaker
00:40:25.680 --> 00:40:26.469
again.
00:40:26.469 --> 00:40:29.605
applause
00:40:29.605 --> 00:40:34.632
postroll music
00:40:34.632 --> 00:40:53.000
subtitles created by c3subtitles.de
in the year 2019. Join, and help us!