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