1 00:00:00,000 --> 00:00:18,200 *35C3 preroll music* 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. *Applause* 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 *" and it will change it to "autocheck autoche *" 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 *Applause* 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. *Laughter* 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... *laughing* 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... *laughing* I could say an 404 00:39:28,269 --> 00:39:33,270 alternative platform, but... *laughter* 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 *applause* 417 00:40:29,605 --> 00:40:34,632 *postroll music* 418 00:40:34,632 --> 00:40:53,000 subtitles created by c3subtitles.de in the year 2019. Join, and help us!