1
00:00:00,000 --> 00:00:18,200
<i>35C3 preroll music</i>

2
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

3
00:00:22,599 --> 00:00:33,137
warm round of applause.
<i>Applause</i>

4
00:00:33,137 --> 00:00:39,450
Vachon: Okay so hello everyone. Thank you
for having me today. I'm really happy to

5
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,

6
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

7
00:00:51,489 --> 00:00:57,600
a UEFI rootkit. So very quickly. My name
is Frederic Vachon, I'm a malware

8
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

9
00:01:04,959 --> 00:01:12,000
last year or so I've been really focusing
on boot level threats and UEFI firmware

10
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

11
00:01:17,369 --> 00:01:23,259
want to talk about is what is Sednit very
quickly. Then I'll talk about LoJack,

12
00:01:23,259 --> 00:01:28,460
which is an anti-theft software and past
research related to this software and the

13
00:01:28,460 --> 00:01:33,450
reason for that is that the UEFI rootkit
that I'll talk about really mimics the

14
00:01:33,450 --> 00:01:39,330
architecture of this legitimate software.
Then we'll move on and I'll talk a little

15
00:01:39,330 --> 00:01:44,439
bit about compromised LoJack agents that
were found in the wild, and finally I'll

16
00:01:44,439 --> 00:01:50,499
jump into the UEFI rootkit, well, where
I'll talk about the tools around the

17
00:01:50,499 --> 00:01:56,880
rootkit and the UEFI rootkit itself. So,
Sednit. Sednit is an espionage group

18
00:01:56,880 --> 00:02:04,820
active since the early 2000s and it is
also known as Fancy Bear, APT28 and

19
00:02:04,820 --> 00:02:12,110
STRONTIUM, so maybe you know this group by
one of these alternative names. And Sednit

20
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

21
00:02:19,290 --> 00:02:25,400
few years as being allegedly behind some
pretty mysterious hacks like the hack

22
00:02:25,400 --> 00:02:29,620
against the Democratic National Committee,
the DNC, where some emails were leaked

23
00:02:29,620 --> 00:02:36,090
online. The hack against the World Anti-
Doping Agency as well as the hack against

24
00:02:36,090 --> 00:02:41,610
the French broadcasting network TV5 Monde.
But at ESET when we're talking about

25
00:02:41,610 --> 00:02:45,689
Sednit, we're really talking about the
tools and the different campaigns that

26
00:02:45,689 --> 00:02:52,239
were led using these tools, and we're not
talking about the people who are operating

27
00:02:52,239 --> 00:02:56,780
this malware because we don't have the
information necessary to draw such

28
00:02:56,780 --> 00:03:05,110
conclusions. However, in July 2018 the
U.S. Department of Justice named the group

29
00:03:05,110 --> 00:03:10,640
as being responsible for the Democratic
National Committee hack in this specific

30
00:03:10,640 --> 00:03:17,650
indictment. And what's interesting is that
the tools that we analyzed were... are

31
00:03:17,650 --> 00:03:26,739
named in this specific indictment and they
also mention who's the authors of these

32
00:03:26,739 --> 00:03:37,129
malware. And also early, not earlier, but
closer from from now, in October 2018, the

33
00:03:37,129 --> 00:03:41,370
Department of Justice issued another
indictment naming pretty much the same

34
00:03:41,370 --> 00:03:48,799
people are related to the World Anti-
Doping Agency hack. And the way that

35
00:03:48,799 --> 00:03:53,670
Sednit will usually infect their targets
is by sending phishing emails, so

36
00:03:53,670 --> 00:03:58,829
sometimes they will contain malicious
links and some of the time malicious

37
00:03:58,829 --> 00:04:06,150
attachments. OK. So now let's talk a
little bit about LoJack. So Lojack is an

38
00:04:06,150 --> 00:04:10,480
anti-theft software as I mentioned, and it
was previously known as Computrace. So

39
00:04:10,480 --> 00:04:16,010
maybe you know the solution by this name
instead. And it is made by Absolute

40
00:04:16,010 --> 00:04:26,040
Software. So, yeah, and this solution is
built in many laptops. But an anti-theft

41
00:04:26,040 --> 00:04:30,790
software needs to be as persistent as
possible if you want it to be reliable. It

42
00:04:30,790 --> 00:04:35,650
needs to be... to survive an operating
system re-install or a hard disk

43
00:04:35,650 --> 00:04:41,160
replacement. So to achieve this what
Absolute Software did is that they added a

44
00:04:41,160 --> 00:04:48,930
module in the UEFI BIOS itself. Yeah and
the solution needs to be activated in the

45
00:04:48,930 --> 00:04:53,920
BIOS setup. So with a persistence
mechanism like that coming from the

46
00:04:53,920 --> 00:04:57,690
firmware, it's really attracted the
attention of security researchers, who

47
00:04:57,690 --> 00:05:05,170
looked into this to find vulnerabilities
basically. And at BlackHat in 2009 there

48
00:05:05,170 --> 00:05:12,140
was a talk there where the architecture of
the solution was described and several

49
00:05:12,140 --> 00:05:18,010
design vulnerabilities in the agent were
also described there. So let's look at the

50
00:05:18,010 --> 00:05:25,920
architecture of LoJack back then. So the
first thing that we have here is a module

51
00:05:25,920 --> 00:05:32,140
in the UEFI BIOS, and this module will
write a file to the Windows partition. So

52
00:05:32,140 --> 00:05:36,940
this file is called autochk.exe, which
replaces the legitimate autochk.exe, whose

53
00:05:36,940 --> 00:05:44,230
job is to perform filesystem integrity
check during early Windows boot. So by

54
00:05:44,230 --> 00:05:50,810
replacing this agent during early Windows
boot it will be executed. And from there

55
00:05:50,810 --> 00:05:57,710
it will drop rpcnetp.exe, which is the
small agent, and will install a service

56
00:05:57,710 --> 00:06:03,490
and when Windows will run it will run this
service, and rpcnetp will be launched at

57
00:06:03,490 --> 00:06:09,300
this point. And it will inject itself into
svchost , and then from there it will

58
00:06:09,300 --> 00:06:13,660
inject itself into Internet Explorer which
is pretty interesting because it's very

59
00:06:13,660 --> 00:06:18,030
shady and that's something that we see
pretty much all the time in malware but

60
00:06:18,030 --> 00:06:24,270
not often in legitimate software. And from
Internet Explorer it will then communicate

61
00:06:24,270 --> 00:06:32,220
with the command and control server and it
will download the full recovery agent. So

62
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

63
00:06:38,190 --> 00:06:44,580
solution. So one of the vulnerabilities
they found is very interesting for us and

64
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

65
00:06:49,140 --> 00:06:55,620
configuration file vulnerability. So the
configuration is embedded into rpcnetp.exe

66
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

67
00:07:00,990 --> 00:07:08,400
single byte XOR key, and it is not
authenticated whatsoever. And what's in

68
00:07:08,400 --> 00:07:14,560
this configuration file? Well, that's
where you can find the server, the command

69
00:07:14,560 --> 00:07:20,860
and control server. So an attacker can
just change this configuration to point to

70
00:07:20,860 --> 00:07:27,900
its own attacker-controlled server. So we
knew that this vulnerability existed for a

71
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.

72
00:07:35,110 --> 00:07:41,120
Until earlier this year, when Arbor
Networks published a blog post where they

73
00:07:41,120 --> 00:07:46,910
described some modified small agent with
modified configuration where the domains

74
00:07:46,910 --> 00:07:55,210
that were embedded in this configuration
were linked to old Sednit domains. So

75
00:07:55,210 --> 00:08:00,550
let's go back to LoJack architecture and
look at where this attack took place. So

76
00:08:00,550 --> 00:08:16,240
it took place at this level here. So from
there we did some detection for this

77
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

78
00:08:24,250 --> 00:08:30,800
it was fairly simple because they always
modified the same exact version of the

79
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

80
00:08:37,280 --> 00:08:42,909
and control server. And here we see the
encrypted version of course. So by looking

81
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

82
00:08:48,709 --> 00:08:53,490
organizations that were hit mostly in the
Balkans, in Central Europe as well as in

83
00:08:53,490 --> 00:08:59,149
Eastern Europe. These were military and
diplomatic organizations. And what's

84
00:08:59,149 --> 00:09:06,666
interesting is that we also found other
Sednit tools in the same organization. So

85
00:09:06,666 --> 00:09:11,689
at this point we wondered how this malware
got there, but since there was other

86
00:09:11,689 --> 00:09:16,789
backdoors of Sednit in the organization we
thought it might be the infection vector,

87
00:09:16,789 --> 00:09:22,190
but by digging a little bit deeper we
found another interesting component. And

88
00:09:22,190 --> 00:09:28,850
if we go back to the LoJack architecture,
the component that we found is at this

89
00:09:28,850 --> 00:09:35,370
step here. So at this step in the LoJack
architecture it's autochk.exe that lives

90
00:09:35,370 --> 00:09:41,140
there. But what we found is another file
called autoche.exe instead of autochk. And

91
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

92
00:09:47,220 --> 00:09:54,249
rpcnetp.exe. But it is the rpcnetp version
that has a modified server in it. So

93
00:09:54,249 --> 00:09:59,759
Sednit domain basically. And we continue
to look at what we can find in this

94
00:09:59,759 --> 00:10:06,160
organization and we found another tool
which is called info_efi.exe, and that

95
00:10:06,160 --> 00:10:10,350
allows to drop... to dump a lot of
information about very low level settings

96
00:10:10,350 --> 00:10:17,960
of the machine. And this tool uses Read
Write Everything's driver. And

97
00:10:17,960 --> 00:10:23,019
Read Write Everything is a software that allows you
to manipulate very low level setting of

98
00:10:23,019 --> 00:10:27,660
your machine. So using this tool you can
read and write to PCI configuration

99
00:10:27,660 --> 00:10:32,999
register, to memory-mapped IOs, to IO port
space and you can also access physical

100
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

101
00:10:38,310 --> 00:10:43,360
you need a kernel driver. And this kernel
driver is properly signed so that you can

102
00:10:43,360 --> 00:10:49,800
push it on even a recent version of
Windows. And so yeah, that's the driver

103
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

104
00:10:57,040 --> 00:11:02,220
out is that this specific driver was used
in the past by security researchers to

105
00:11:02,220 --> 00:11:10,040
exploit vulnerabilities at the firmware
level. So, yeah, the last thing that was

106
00:11:10,040 --> 00:11:17,350
missing here to mimic the whole LoJack
solution was a UEFI BIOS module. So at

107
00:11:17,350 --> 00:11:24,560
this point we wondered, did they get
there. So, because of the tool dumping

108
00:11:24,560 --> 00:11:28,220
information about the BIOS that I just
spoke about, we were pretty confident that

109
00:11:28,220 --> 00:11:34,149
something more was happening there. And by
digging a little bit deeper, we found

110
00:11:34,149 --> 00:11:40,310
other tools that strengthen our
suspicions. So the first tool is called

111
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,

112
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.

113
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

114
00:11:59,850 --> 00:12:05,709
write to PCI configuration registers.
What's interesting for us as reverse

115
00:12:05,709 --> 00:12:09,680
engineer is that this tool contains a lot
of debug strings which really made our job

116
00:12:09,680 --> 00:12:16,510
easier. And it consists of the following
operations. So the first thing it will do

117
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

118
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

119
00:12:27,860 --> 00:12:35,439
region base address. And finally it reads
the UEFI firmware content and dump it to a

120
00:12:35,439 --> 00:12:42,110
file. So another tool that we found is
really complementary to the tool to

121
00:12:42,110 --> 00:12:47,279
ReWriter_read and it is called
ReWriter_binary. So it also contains a lot

122
00:12:47,279 --> 00:12:53,920
of debug strings. It also uses
RWEverything's driver. And now the UEFI

123
00:12:53,920 --> 00:12:59,420
firmware is dumped into memory, the next
step is to add the rootkit to the firmware

124
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

125
00:13:02,439 --> 00:13:09,780
does. Okay. So now let's talk about the
patching of the UEFI firmware. But before

126
00:13:09,780 --> 00:13:13,069
we dig into the subjects there are a
couple things that I wanted to introduce

127
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

128
00:13:16,550 --> 00:13:22,910
talk about is UEFI and UEFI stands for
Unified Extensible Firmware Interface and

129
00:13:22,910 --> 00:13:26,769
it is a standardized specification that
defines the interface that exists between

130
00:13:26,769 --> 00:13:31,959
the operating system and the firmware. And
it's kind of a replacement for the legacy

131
00:13:31,959 --> 00:13:39,149
BIOS. So, a UEFI compliant firmware will
provide a set of services to UEFI

132
00:13:39,149 --> 00:13:43,670
applications and here read the operating
system loader. There are other UEFI

133
00:13:43,670 --> 00:13:50,639
applications, but usually it's the
operating system loader that runs. So the

134
00:13:50,639 --> 00:13:55,389
first set of services is called the boot
services and these are services that are

135
00:13:55,389 --> 00:14:00,149
available during the firmware lifetime but
once the operating system is loaded, these

136
00:14:00,149 --> 00:14:04,430
services are not available anymore and
there are the runtime services that are

137
00:14:04,430 --> 00:14:10,629
also available during firmware lifetime.
But once the operating system is loaded

138
00:14:10,629 --> 00:14:14,560
they are still available, so that a kernel
driver for instance can make call in these

139
00:14:14,560 --> 00:14:20,720
services. An example of these services
allows the operating system to read and

140
00:14:20,720 --> 00:14:25,740
write to UEFI variables. And what's
interesting with UEFI is that there is no

141
00:14:25,740 --> 00:14:30,559
more master boot record and volume boot
record involved in the boot process

142
00:14:30,559 --> 00:14:37,959
meaning that there is no easy way to
hijack the early boot control flow. So the

143
00:14:37,959 --> 00:14:43,279
second thing I want to introduce here are
the driver execution environment drivers -

144
00:14:43,279 --> 00:14:47,649
so the DXE drivers. So DXE drivers are
PE/COFF images meaning that they are

145
00:14:47,649 --> 00:14:53,519
basically Windows executables, and they
are kind of the core of UEFI firmware so

146
00:14:53,519 --> 00:14:57,670
that they can do many things, some of them
will be used to abstract the hardware.

147
00:14:57,670 --> 00:15:01,240
Some of them will be used to produce the
UEFI standard interface, so the boot

148
00:15:01,240 --> 00:15:05,889
services and the runtime services, and
they can also be used by firmware vendors

149
00:15:05,889 --> 00:15:11,660
or OEMs to extend the firmware by
registering new services - the so-called

150
00:15:11,660 --> 00:15:17,430
protocols in the UEFI specification. And,
the DXE drivers are loaded during the DXE

151
00:15:17,430 --> 00:15:22,269
phase of the platform initialization and
they are loaded by the DXE dispatcher that

152
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

153
00:15:28,829 --> 00:15:34,089
want to introduce for now is the UEFI
firmware layout - so the UEFI firmware

154
00:15:34,089 --> 00:15:40,060
is located in the BIOS region of the SPI
flash memory. And this region will contain

155
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

156
00:15:45,639 --> 00:15:51,120
which is UEFI tool, that is an open source
software that allows you to manipulate

157
00:15:51,120 --> 00:15:57,189
UEFI firmware images. So here I loaded the
typical content of SPI flash memory dump

158
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

159
00:16:01,580 --> 00:16:05,990
is the descriptor region, so it contains...
this region contains metadata about how

160
00:16:05,990 --> 00:16:11,279
the remaining data in the SPI flash memory
is laid out. The second region that we

161
00:16:11,279 --> 00:16:16,629
find here is the ME region which contains
the Intel Management Engine firmware. And

162
00:16:16,629 --> 00:16:20,409
finally we have the BIOS region which is
really the main interest... the main thing

163
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

164
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

165
00:16:32,569 --> 00:16:37,870
firmware filesystem version 2 and this
volume contains multiple files and these

166
00:16:37,870 --> 00:16:42,069
files are identified by GUIDs. So that's
what we can see under the name column

167
00:16:42,069 --> 00:16:49,750
here. And a file doesn't contain directly
the UEFI executable, but it is composed of

168
00:16:49,750 --> 00:16:55,161
multiple sections and one of these section
is the actual UEFI executable, but there

169
00:16:55,161 --> 00:16:59,139
are other section and in this case we see
a DXE dependency section that allows to

170
00:16:59,139 --> 00:17:05,970
define dependencies for this specific UEFI
image and we also see a version section

171
00:17:05,970 --> 00:17:09,920
and a user interface section which allows
to give us a human readable name for this

172
00:17:09,920 --> 00:17:17,020
file instead of the GUID which is very
pretty difficult to remember for humans.

173
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

174
00:17:24,290 --> 00:17:28,610
ReWriter_binary will do is that it will
parse all of the firmware volumes that it

175
00:17:28,610 --> 00:17:36,740
can find looking for 4 specific files. So
it looks for Ip4Dxe, NtfsDxe, SmiFlash,

176
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

177
00:17:42,990 --> 00:17:48,470
are looked for to find the firmware volume
where to install the UEFI rootkit. So

178
00:17:48,470 --> 00:17:54,580
usually in UEFI firmwares all of the DXE
drivers all in the same volume, so when

179
00:17:54,580 --> 00:17:59,140
the tool will parse... will find in fact
Ip4Dxe, it will know it is currently

180
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

181
00:18:03,740 --> 00:18:07,770
candidate for the UEFI rootkit
installation. And it looks for the DXE

182
00:18:07,770 --> 00:18:13,010
Core basically for the same reason, but
sometimes the DXE Core is in a different

183
00:18:13,010 --> 00:18:17,390
volume, so when it will find it, it will
keep the volume as another candidate for

184
00:18:17,390 --> 00:18:22,280
the UEFI rootkit installation and the
chosen volume will be the one with enough

185
00:18:22,280 --> 00:18:31,050
free space available in it. Now, NtfsDxe.
So NtfsDxe is the American Megatron Inc.

186
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

187
00:18:37,880 --> 00:18:44,340
that the UEFI rootkit embeds its own NTFS
driver, so to avoid any conflict with

188
00:18:44,340 --> 00:18:51,890
another NTFS driver it just removes it.
And now SmiFlash, so, SmiFlash is looked

189
00:18:51,890 --> 00:18:57,010
for... and, you know, the tool will... if
the tool finds it, it will keep some

190
00:18:57,010 --> 00:19:00,680
metadata about it in the structure, but in
the version of the tool that we analyzed

191
00:19:00,680 --> 00:19:07,122
it's not used anywhere. But interestingly,
SmiFlash is a known vulnerable DXE driver.

192
00:19:07,510 --> 00:19:11,120
So what we believe is that Sednit might
have been fiddling in another version of

193
00:19:11,120 --> 00:19:16,010
the tool with some exploit for this driver
in order to be able to bypass write

194
00:19:16,010 --> 00:19:22,160
protection mechanisms to the BIOS region
of the SPI flash memory. So now that it

195
00:19:22,160 --> 00:19:28,860
has found the volume where to install the
rootkit, it will add the rootkit, right.

196
00:19:28,860 --> 00:19:33,980
So the first thing it does, it will create
a firmware file system file header, then

197
00:19:33,980 --> 00:19:38,940
it will append the rootkit file, which is
a compressed section that contains two

198
00:19:38,940 --> 00:19:46,750
other sections, one of one of these is the
actual UEFI rootkit image and the other

199
00:19:46,750 --> 00:19:53,060
one is a user interface section defining
the name for this rootkit which is SecDXE,

200
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

201
00:19:59,800 --> 00:20:02,202
of the firmware volume that was chosen.

202
00:20:11,050 --> 00:20:14,310
So now that the UEFI rootkit is inside the

203
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

204
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

205
00:20:23,870 --> 00:20:28,530
talk about BIOS write protection
mechanisms. So the chipset exposes write

206
00:20:28,530 --> 00:20:33,536
protection mechanisms that need to be
properly configured by the firmware. So

207
00:20:33,536 --> 00:20:38,650
there are no such thing as, you know, BIOS
write particular mechanism enabled by

208
00:20:38,650 --> 00:20:43,160
default. It's really the job of the
firmware to do that. And today will only

209
00:20:43,160 --> 00:20:48,160
cover relevant protections to our
research. So only the protection mechanism

210
00:20:48,160 --> 00:20:54,700
that are looked for by 
REWriter_binary. And yeah the protection

211
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

212
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

213
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

214
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

215
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

216
00:21:21,180 --> 00:21:26,038
be able to modify your UEFI firmware and
potentially brick your machine. So there's

217
00:21:26,038 --> 00:21:29,840
a protection mechanism there which is
another field in the BIOS control register

218
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

219
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

220
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

221
00:21:48,760 --> 00:21:50,426
than performing a full platform reset.

222
00:21:53,013 --> 00:21:56,100
But there's a problem here, and it lies in the

223
00:21:56,100 --> 00:22:03,220
fact that BIOS lock enable implementation
is vulnerable. So how it works is that

224
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

225
00:22:10,930 --> 00:22:16,060
control register for a small amount of
time. And then the platform will issue a

226
00:22:16,060 --> 00:22:22,240
system management interrupt and the SMI
handler will set BIOS write enable back to

227
00:22:22,240 --> 00:22:28,180
0. But, yeah, the firmware must implement
this SMI, otherwise this mechanism is

228
00:22:28,180 --> 00:22:35,080
totally useless. But maybe you've guessed
it. But what happens if we write to the

229
00:22:35,080 --> 00:22:41,020
SPI flash memory before the SMI handler
sets BIOS write enable back to 0? So there

230
00:22:41,020 --> 00:22:45,750
is a race condition vulnerability here.
And there is a paper about it which is

231
00:22:45,750 --> 00:22:50,240
called "speed racer". And to exploit this
what you need to do is, you need one

232
00:22:50,240 --> 00:22:55,460
thread that continuously sets BIOS write
enable to 1, while another thread tries to

233
00:22:55,460 --> 00:23:00,130
write the data to the SPI flash memory.
And according to this paper it works on

234
00:23:00,130 --> 00:23:03,740
multicore processors as well as on single
core processors with hyper-threading

235
00:23:03,740 --> 00:23:09,820
enabled. So Intel came up with a fix for
this issue and was introduced in the

236
00:23:09,820 --> 00:23:15,490
platform controller hub family of Intel
chipsets around 2008. And what they did

237
00:23:15,490 --> 00:23:20,060
is, that they added a field in the BIOS
control register. And this field is called

238
00:23:20,060 --> 00:23:25,480
SMM BIOS write protect disable. And the
name is a little bit misleading, but if

239
00:23:25,480 --> 00:23:30,370
you remove disable, that's actually what
it does. And if this mechanism is

240
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

241
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

242
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

243
00:23:47,760 --> 00:23:53,674
available to system management mode. And
once again the firmware must set this bit.

244
00:23:53,674 --> 00:24:02,750
Otherwise this mechanism is not activated,
right. Okay so let's go back to

245
00:24:02,750 --> 00:24:06,830
ReWriter_Binary. So of course if I talk
about all of these mechanisms it's because

246
00:24:06,830 --> 00:24:11,350
ReWriter_Binary checks for them. So it
will check if the platform is properly

247
00:24:11,350 --> 00:24:16,720
configured and it implements the exploit
for the race condition that I just spoke

248
00:24:16,720 --> 00:24:22,750
about. So let's look at the writing
process decision tree. So the first thing

249
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

250
00:24:28,700 --> 00:24:34,910
set there, then there's nothing stopping
it from writing the UEFI image. But if it

251
00:24:34,910 --> 00:24:40,290
is not set, then it will check "Oh, is
BIOS lock enable activated?". And this, if

252
00:24:40,290 --> 00:24:45,850
this mechanism is not activated then it
will just flip BIOS write enable to 1, and

253
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

254
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

255
00:24:57,280 --> 00:25:02,940
exploit the race condition that we spoke
about. And if it is set, then the tool

256
00:25:02,940 --> 00:25:11,260
will just fail. So the tool only works if
the platform is misconfigured. And we

257
00:25:11,260 --> 00:25:17,060
spoke about SmiFlash, the vulnerable DXE
driver. So yeah, what we think is that by

258
00:25:17,060 --> 00:25:21,310
being able to exploit this vulnerability,
they would have been able to have a tool

259
00:25:21,310 --> 00:25:28,440
that works even when the platform is
properly configured. So it's a very good

260
00:25:28,440 --> 00:25:36,420
example of; I mean if firmware vendors
would have done their job correctly here,

261
00:25:36,420 --> 00:25:40,580
this tool would have failed at flashing
the UEFI firmware, so that's a great

262
00:25:40,580 --> 00:25:47,420
example of how, you know, firmware
security is. So here let's just take a

263
00:25:47,420 --> 00:25:52,100
step back and look at what we have. So
what we have is a software implementation

264
00:25:52,100 --> 00:25:57,340
to flash the firmware remotely post
exploitation, meaning that as an attacker

265
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

266
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

267
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

268
00:26:12,770 --> 00:26:19,200
rootkit and it needed physical access to
be deployed. So it's so much more

269
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

270
00:26:25,020 --> 00:26:30,310
of Hacking Team's rootkit being used in an
actual cyber attack. It has never been

271
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.

272
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

273
00:26:41,271 --> 00:26:47,050
and we looked at ESET's UEFI scanner
telemetry to see if we can find something.

274
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

275
00:26:52,030 --> 00:26:57,990
machine, making it the first publicly
known UEFI rootkit to be used in an actual

276
00:26:57,990 --> 00:27:01,350
cyber attack. Okay.

277
00:27:01,350 --> 00:27:14,710
So now let's look at the UEFI 
rootkit itself. So the UEFI

278
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

279
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

280
00:27:25,510 --> 00:27:33,520
GUID for future reference. So let's look
at the UEFI rootkit workflow. So UEFI

281
00:27:33,520 --> 00:27:36,830
firmware we'll go through multiple phases
when it boots. The first phase is the

282
00:27:36,830 --> 00:27:41,380
security phase, the second one is the pre
EFI initialization phase, and then there

283
00:27:41,380 --> 00:27:44,540
is the driver execution environment phase
and that's where it begins to be

284
00:27:44,540 --> 00:27:50,740
interesting for this rootkit. So that's
where the DXE dispatcher lives. So that's

285
00:27:50,740 --> 00:27:55,650
when all of the DXE drivers will be
loaded. So at some point the UEFI rootkit

286
00:27:55,650 --> 00:28:01,590
will be loaded. And what will happen is
that the rootkit will create an event

287
00:28:01,590 --> 00:28:07,710
attached to EFI GROUP_READY_TO_BOOT. And
it will bind a notify function to this

288
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

289
00:28:14,340 --> 00:28:22,330
signal this event and the notify function
will be called. So, the notify function

290
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

291
00:28:28,504 --> 00:28:35,460
drop autoche.exe and rpcnetp.exe using
this NTFS driver. And finally it will

292
00:28:35,460 --> 00:28:42,960
patch a value in the Windows Registry. So,
the NTFS driver is needed to get file

293
00:28:42,960 --> 00:28:49,700
based access to Windows partition and
Sednit's operator did not write their own

294
00:28:49,700 --> 00:28:55,500
NTFS driver. What did it is that they use
Hacking Team's NTFS driver from Hacking

295
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

296
00:29:03,920 --> 00:29:08,400
we can see here, it is dropping
rpcnetp.exe and here it is dropping

297
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

298
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

299
00:29:22,540 --> 00:29:27,680
have all the logic to parse Windows
Registry structures, so it will only look

300
00:29:27,680 --> 00:29:31,900
for a textual pattern and the textual
pattern it will look for is "autocheck

301
00:29:31,900 --> 00:29:36,960
autochk <i>" and it will change it to
"autocheck autoche </i>" and it happens to be

302
00:29:36,960 --> 00:29:43,200
modifying the BootExecute key. So, the
BootExecute key is the key responsible for

303
00:29:43,200 --> 00:29:50,510
launching autochk.exe during Windows early
boot. So by modifying it to autoche

304
00:29:50,510 --> 00:29:56,760
instead of autochk that's autoche.exe that
will be executed instead of autochk. And,

305
00:29:56,760 --> 00:30:01,130
so here if we go back to the UEFI rootkit
workflow, when the operating system will

306
00:30:01,130 --> 00:30:06,490
run, then it will execute autoche.exe.
Then autoche.exe will drop the small

307
00:30:06,490 --> 00:30:13,470
agent, the rpcnetp.exe, and so on. But
what's interesting here is that it will

308
00:30:13,470 --> 00:30:18,620
revert back the modification in the
Windows Registry from autoche to autochk.

309
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

310
00:30:23,580 --> 00:30:28,710
find that anything, any modification
occurred there. So that's a pretty

311
00:30:28,710 --> 00:30:32,460
interesting sealth technique that is
enabled by the fact that the malware is

312
00:30:32,460 --> 00:30:42,360
coming from the firmware. Okay. So, the
last thing that I want to talk about now

313
00:30:42,360 --> 00:30:50,630
is prevention and remediation, so what can
you do to protect yourself against this

314
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

315
00:30:56,191 --> 00:31:04,090
your machine, what can you do? So,
prevention. So the first thing and the

316
00:31:04,090 --> 00:31:10,800
most important thing, which is also the
most accessible thing, thankfully, is that

317
00:31:10,800 --> 00:31:16,060
you should keep your UEFI firmware up to
date to make sure that if, you know,

318
00:31:16,060 --> 00:31:23,550
security researchers found some issues
with your firmware and they disclosed it

319
00:31:23,550 --> 00:31:27,950
and the firmware vendor fixed them, you
want to make sure that you have the latest

320
00:31:27,950 --> 00:31:34,180
patches available on your machine. Then
the second thing is that you should really

321
00:31:34,180 --> 00:31:38,530
enable Secure Boot. But let's note here
that Secure Boot itself would not

322
00:31:38,530 --> 00:31:43,200
effectively you against this specific
attack. And the reason for that is that

323
00:31:43,200 --> 00:31:48,520
Secure Boot takes the content of the SPI
flash memory as its root of trust, meaning

324
00:31:48,520 --> 00:31:55,650
that what's inside the SPI flash memory is
not subject for validation. So what does

325
00:31:55,650 --> 00:32:00,240
it validates then, right? Well, Secure
Boot will check what's coming from outside

326
00:32:00,240 --> 00:32:04,480
of the SPI flash memory meanings the PCI
option ROMs and probably the most

327
00:32:04,480 --> 00:32:08,810
important thing, the operating system
loader. So it's really a mechanism that

328
00:32:08,810 --> 00:32:14,860
checks that the operating system loader
hasn't been tampered with. So what can we

329
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

330
00:32:20,610 --> 00:32:25,760
the root of trust from the SPI flash
memory to some piece of hardware. So it

331
00:32:25,760 --> 00:32:31,090
must be in a, you know, one time
programmable chip that is programmed

332
00:32:31,090 --> 00:32:38,960
during manufacturing time and that cannot
be written to ever after. An example of

333
00:32:38,960 --> 00:32:45,410
this exists - technology like Intel
BootGuard implements this. And also Apple

334
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

335
00:32:51,570 --> 00:32:57,210
that your firmware configures the security
mechanisms properly and there's not much

336
00:32:57,210 --> 00:33:02,230
you can do about it if your firmware is
up-to-date. But thankfully there are

337
00:33:02,230 --> 00:33:06,050
firmware security assessment tool
available out there and an example of that

338
00:33:06,050 --> 00:33:13,380
is Intel CHIPSEC. So, with Intel CHIPSEC
which is an open source software tool, so

339
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

340
00:33:19,370 --> 00:33:22,940
tool will check for all of the security
mechanism that we spoke about today, it

341
00:33:22,940 --> 00:33:28,630
will check if they are properly configured
and also it checks for a bunch more stuff.

342
00:33:28,630 --> 00:33:38,310
And now also CHIPSEC checks if your
firmware has this LoJax rootkit. So if you

343
00:33:38,310 --> 00:33:42,200
want to know if your firmware properly
configures these security mechanism that's

344
00:33:42,200 --> 00:33:52,240
really the way to go. Now about
remediation. So, this slide is kind of

345
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

346
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

347
00:34:02,350 --> 00:34:07,110
your UEFI firmware and that's definitely
not something that is easy to do for

348
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

349
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

350
00:34:19,359 --> 00:34:29,480
this kind of attack is. Now, conclusion.
So, our research shows that UEFI rootkits

351
00:34:29,480 --> 00:34:35,239
are not only toys for researchers to play
with, but they are real world threats used

352
00:34:35,239 --> 00:34:41,460
in actual cyber attacks. So it might be
something that you want to keep in mind

353
00:34:41,460 --> 00:34:48,339
when you'll be defining your threat model.
Also we won't stress this enough: firmware

354
00:34:48,339 --> 00:34:53,489
must be built with security in mind from
the bottom up, and things are getting

355
00:34:53,489 --> 00:34:57,210
better because there are more and more
security researchers looking into this,

356
00:34:57,210 --> 00:35:03,750
but there's still work to do. And
hopefully, our research help share

357
00:35:03,750 --> 00:35:11,130
knowledge about how to prevent and
mitigate UEFI-based threats. So that is

358
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

359
00:35:17,160 --> 00:35:22,240
interested to know more details about this
research, the white paper is available at

360
00:35:22,240 --> 00:35:27,974
welivesecurity.com and you can grab a copy
there. So, thanks.

361
00:35:27,974 --> 00:35:38,259
<i>Applause</i>
Herald: Alright, you know the drill. We

362
00:35:38,259 --> 00:35:44,177
have 5 minutes for Q&A. So please, quick
and short questions. Number 1 please.

363
00:35:46,430 --> 00:35:56,480
Question: (incomprehensible) attacking
other operating systems (incomprehensible)

364
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

365
00:36:01,260 --> 00:36:07,410
of, apart from Hacking Team's UEFI
rootkit, and this one only works on

366
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

367
00:36:13,450 --> 00:36:14,297
OS for instance.

368
00:36:16,403 --> 00:36:19,349
Herald: Please refrain from walking in
front of the cameras when you're leaving.

369
00:36:19,349 --> 00:36:23,119
Thank you.
Could we get microphone number

370
00:36:23,119 --> 00:36:28,319
2 please.
Q: Hello, thanks for the talk. On your

371
00:36:28,319 --> 00:36:35,829
slides you mentioned a tool, open source,
for checking out the layout. What was the

372
00:36:35,829 --> 00:36:41,530
name of the tool?
A: It's called UEFI tool. <i>Laughter</i>

373
00:36:41,530 --> 00:36:44,030
Q: Nice.
A: So you can find it on GitHub.

374
00:36:45,170 --> 00:36:47,090
Q: Thanks.
Herald: The internet please.

375
00:36:47,090 --> 00:36:54,387
Q: Thank you. Does the rootkit also work
when the UEFI is in BIOS legacy mode?

376
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

377
00:37:06,240 --> 00:37:12,839
it. That's a good question, I'd have to
look into this, to have a... <i>laughing</i> an

378
00:37:12,839 --> 00:37:16,650
answer I'm 100 percent sure about. Sorry
for that.

379
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,

380
00:37:24,630 --> 00:37:29,900
I'm sorry.
Q: OK. So, does the UEFI dropper still

381
00:37:29,900 --> 00:37:33,291
work with BitLocker enabled?

382
00:37:35,370 --> 00:37:37,789
A: I know. Oh yeah. Yeah. We test that.

383
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

384
00:37:47,119 --> 00:37:52,430
BitLocker to have decrypted all of the
data. So no, it doesn't work if

385
00:37:52,430 --> 00:37:53,550
BitLocker is enabled.

386
00:37:55,615 --> 00:37:57,020
Herald: Number 1 please.

387
00:37:59,710 --> 00:38:08,430
Q: Would it be possible to work within
full disk encryption. (incomprehensible)

388
00:38:08,430 --> 00:38:12,100
the file system was decrypted and then
installed the dropper.

389
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

390
00:38:15,800 --> 00:38:22,600
disk encryption? Is it the question right?
Q: Would it be possible to make it work

391
00:38:22,600 --> 00:38:28,609
with full disk encryption?
A: I think it should be because the LoJack

392
00:38:28,609 --> 00:38:33,480
software is a legitimate one, the anti-
theft solution. They are able to make it

393
00:38:33,480 --> 00:38:39,310
work even if BitLocker is enabled or full
disk encryption. So yeah, it should be

394
00:38:39,310 --> 00:38:40,609
possible to do so.

395
00:38:42,229 --> 00:38:44,390
Herald: One more internet question please.

396
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

397
00:38:50,231 --> 00:38:54,749
SPI flash space completely a valid
prevention?

398
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

399
00:39:01,829 --> 00:39:06,709
there is not enough free space available
on the firmware volumes the tool will just fail.

400
00:39:09,276 --> 00:39:10,571
Herald: Number two please.

401
00:39:10,961 --> 00:39:17,229
Q: Hi. You said that there is no real
possibility to secure everything, but what

402
00:39:17,229 --> 00:39:22,730
are your daily choices that you use like,
on your personal computer, to be fully

403
00:39:22,730 --> 00:39:28,269
secret?
A: Well... <i>laughing</i> I could say an

404
00:39:28,269 --> 00:39:33,270
alternative platform, but... <i>laughter</i>
but yeah, if you have

405
00:39:33,270 --> 00:39:37,230
a modern Intel CPU and you have

406
00:39:37,230 --> 00:39:43,140
Secure Boot enabled and you have, you
know, all of the latest UEFI firmware

407
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

408
00:39:50,381 --> 00:39:52,885
attack.
Q: I have... I have my like this...

409
00:39:52,885 --> 00:39:57,061
Herald: Number 1 please.
Q: So, going back to the LoJack

410
00:39:57,061 --> 00:40:05,900
configuration file vulnerability. Is the
configuration file on the operating system

411
00:40:05,900 --> 00:40:10,220
file system?
A: No no no, the... In fact it's... there is

412
00:40:10,220 --> 00:40:15,660
not a separate configuration file, the
configuration is embedded inside the

413
00:40:15,660 --> 00:40:19,269
executable. So it is embedded into
rpcnetp.exe.

414
00:40:21,059 --> 00:40:25,680
Herald: Unfortunately, we are already out
of time. So please thank our speaker

415
00:40:25,680 --> 00:40:26,469
again.

416
00:40:26,469 --> 00:40:29,605
<i>applause</i>

417
00:40:29,605 --> 00:40:34,632
<i>postroll music</i>

418
00:40:34,632 --> 00:40:53,000
subtitles created by c3subtitles.de
in the year 2019. Join, and help us!