 Okay, so our next talk is given by Frédéric Vachant, so please give him a warm round of applause. Okay, so hello everyone. Thank you for having me today. I'm really happy to be here. So today I'm going to talk about a research that a colleague of mine, Jean-Yan Boutin, and I did earlier this year in which led us to the discovery of a UEFI root care. So very quickly, my name is Frédéric Vachant. I'm a malware researcher at ESET, and I've been working there for the last two years. And for the last year or so, I've been really focusing on boot-level threats and UEFI for more reverse engineering. So let's look at the agenda for this talk. So the first thing I want to talk about is what is said in it very quickly. Then I'll talk about Lowjack, which is an entity of software and past research related to this software. And the reason for that is that the UEFI root care that I'll talk about really mimics the architecture of this legitimate software. Then we'll move on, and I'll talk a little bit about compromised Lowjack agents that were found in the wild. And finally, I'll jump into the UEFI root kit, where I'll talk about the tools around the UEFI root kit and the UEFI root kit itself. So Cydnit. Cydnit is an espionage group active since the early 2000s, and it is also known as FancyBear, APT28, and Strunchium. So maybe you know this group by one of these alternative names. And Cydnit is the name basically that we use at ESET. So this group was very visible in the past few years as being allegedly behind some pretty notorious hacks, like the hack against the Democratic National Committee, the DNC, where some emails were leaked online. The hack against the world anti-doping GenC, as well as the hack against the French broadcasting network TV5 mode. But at ESET, when we're talking about Cydnit, we're really talking about the tools and the different campaigns that were led using these tools. And we're not talking about the people who are operating this malware, because we don't have the information necessary to draw such conclusions. However, in July 2018, the US Department of Justice named the group as being responsible for the Democratic National Committee hack in this specific indictment. And what's interesting is that the tools that we analyze are named in this specific indictment, and they also mention who's the authors of these malware. And also earlier, but closer from now, in October 2018, the Department of Justice issued another indictment naming pretty much the same people related to the world anti-doping agency hack. And the way that Cydnit will usually infect their targets is by sending phishing emails, so sometimes they will contain malicious links and some other time, malicious attachments. Okay, so now let's talk a little bit about LoJack. So LoJack is an Internet software, as I mentioned. It was previously known as ComputeRace, so maybe you know the solution by this name instead. And it is made by Absolute Software. So, yeah, and this solution is built in many laptops. But an Internet software needs to be as persistent as possible if you want it to be reliable. It needs to be to survive an operating system reinstall or a hard disk replacement. So, to achieve this, what Absolute Software did is that they added a module in the UFI bias itself. Yeah, and the solution needs to be activated in the bias setup. So, with a persistence mechanism like that coming from the firmware, it really attracted the attention of security researchers who looked into this to find vulnerabilities, basically. And at Black Hat in 2009, there was a talk there where the architecture of the solution was described and several design vulnerabilities in the agent were also described there. So, let's look at the architecture of LoJack back then. So, the first thing that we have here is a module in the UFI bias. And this module will write a file to Windows partition. So, this file is called autocheck.exe, which replaces the legitimate autocheck.exe, whose job is to perform file stem integrity check during early Windows boot. So, by replacing this agent during early Windows boot, it will be executed. And from there, it will drop RPCNet p.exe, which is the small agent, and will install a service. And when Windows will run, it will run this service. And RPCNet p.exe will be launched at this point. And it will inject itself into SVCOs. And then from there, it will inject itself into Internet Explorer, which is pretty interesting because it's very shady. And that's something that we see pretty much all the time in malware, but not often in legitimate software. And then from Internet Explorer, it will then communicate with the command and control server, and it will download the full recovery agent. So, now let's look at some of the issues that the researchers found in this solution. So, one of the vulnerabilities they found is very interesting for us, and in fact, that's really the only one that matters for this talk. And it is a configuration file vulnerability. So, the configuration is embedded into RPCNet p.exe, and it is encrypted, but it is encrypted with a very weak algorithm, so it is in single byte XOR key, and it is not authenticated whatsoever. And what's in this configuration file? Well, that's where you can find the server, so the command and control server. So, in Attacker, you can just change this configuration to point to its own Attacker control server. So, we knew that this vulnerability existed for a while, so it was back in 2009, but we had no evidence of it being used in the while. Until earlier this year, when Arbor Networks published a blog post where they described some modified, small agents with modified configuration, where the domains that were embedded in this configuration were linked to old sediments, old sedentate domains. So, let's go back to the Lowjack architecture and look at where this attack took place, so it took place at this level here. So, from there, we did some detection for this malware, and we hunted together as much samples as we could, and it was fairly simple because they always modified the same exact version of the agent, and they modified, so that's what we can see here, they modified the command and control server, and here we see the encrypted version, of course. So, by looking at this, we look at ESET's telemetry and found out that there was a few organizations that were hit, mostly in the Balkans and Central Europe, as well as in Eastern Europe. These were military and diplomatic organizations, and what's interesting is that we also found other sedentate tools in the same organization. So, at this point, we wondered how this malware got there, but since there was other backdoors of sedentate in the organization, we thought it might be the infection vector, but by digging a little bit deeper, we found another interesting component, and if we go back to the Lowjack architecture, the component that we found is at this step here. So, at this step in the Lowjack architecture, it's autochek.exe that lives there, but what we found is another file called autochek.exe instead of autochek, and it does pretty much the same thing, so it also installs a service, and it also drops RPCNetP.exe, but it is the RPCNetP version that has a modified server in it, so sedentate domain, basically. And we continue to look at what we can find in this organization, and we found another tool, which is called info.efi.exe, and that allows to dump a lot of information about very low-level settings of the machine, and this tool uses ReadWriteEverything's driver, and ReadWriteEverything is a software that allows you to manipulate very low-level setting of your machine, so using this tool, you can read and write to PCI configuration register, to memory map IOs, to IOPort space, and you can also access physical memory, and this tool uses a kernel driver, of course, if you want to do those things, you need a kernel driver, and this kernel driver is properly signed so that you can push it on even a recent version of Windows, and so, yeah, that's the driver that was used by info.efi here, and by googling a little bit around, what we found out is that this specific driver was used in the past by security researchers to exploit vulnerabilities at the firmware level. So, yeah, the last thing that was missing here to mimic the whole LoJack solution was a UEFI BIOS module, so at this point we wondered, did they get there? So because of the tool dumping information about the BIOS that I just spoke about, we were pretty confident that something more was happening there, and by digging a little bit deeper, we found other tools that strengthen our suspicions. So the first tool is called REWriterRead, and it will use to dump the content of the SPI flash memory, and it also uses ReadWrite Everything's driver, and it uses these specific IO control codes, so it allows it to read and write to memory map IO space as well as read and write to PCI configuration registers. What's interesting for us as reverse engineers is that this tool contains a lot of debug strings, so it really made our job easier, and it consists of the following operations. So the first thing it will do is that it will log information on the BIOS control register, and we'll talk in a lot of detail about this register a little bit later in this talk. Then it locates the BIOS region base address, and finally it reads the UEFI firmware content and dump it to a file. So another tool that we found is really complementary to the tool to REWriterRead, and it is called REWriterBinary. So it also contains a lot of debug strings, it also uses RWEverything's driver, and now that the UEFI firmware is dumped into memory, the next step is to add the root key to the firmware and to write it back to DSP slash memory, and that's exactly what this tool does. Okay, so now let's talk about the patching of the UEFI firmware, but before we dig into the subjects, there are a couple of things that I wanted to introduce here just to make sure that we're on the same page. So the first thing I want to talk about is UEFI, and UEFI stands for Unified Extensible Firmware Interface, and it is a standardized specification that defines the interface that exists between the operating system and the firmware. It is kind of a replacement for the legacy bias. So a UEFI compliant firmware will provide a set of services to UEFI applications, and here read the operating system loader. There are other UEFI applications, but usually it's the operating system loader that runs. So the first set of services is called the boot services, and these are services that are available during the firmware lifetime, but once the operating system is loaded, these services are not available anymore, and they are the runtime services that are also available during firmware lifetime, but once the operating system is loaded, they are still available so that a kernel driver, for instance, can make call in these services. An example of these services allows the operating system to read and write to UEFI variables. And what's interesting with UEFI is that there's no more master boot record and volume boot record involved in the boot process, meaning that there is no easy way to hijack the early boot control flow. So the second thing I want to introduce here are the driver execution environment drivers, so the Dixie drivers. So Dixie drivers are PECOF images, meaning that they are basically Windows executables, and they are kind of the core of a UEFI firmware, so they can do many things. Some of them will be used to abstract the hardware, some of them will be used to produce the UEFI standard interface of the boot services and the runtime services, and they can also be used by firmware vendors or OEMs to extend the firmware by registering new services, the so-called protocols in the UEFI specification. And the Dixie drivers are loaded during the Dixie phase of the platform initialization, and they are loaded by the Dixie dispatcher that we'll also refer to as the Dixie core. The last thing that I want to introduce for now is the UEFI firmware layout. So the UEFI firmware is located in the bias region of the SPI flash memory, and this region will contain multiple volume, but let's look at it with a little bit more detail in this tool here, which is UEFI tool that is an open source software that allows you to manipulate UEFI firmware images. So here are loaded the typical content of a SPI flash memory dump in this tool, and let's look at what we have. So the first thing that we see here is the descriptor region, so this region contains metadata about how the remaining data in the SPI flash memory is laid out. The scan region that we find here is the ME region, which contains the Intel Management Engine firmware. And finally, we have the bias region, which is really the main interest, that we want to look at today. So the bias region contains multiple volumes, so let's look at one volume in a little bit more detail. So here we have a volume of type firmware file system version two, and this volume contains multiple files, and these files are identified by GUIDs. So that's what we can see under the name column here. And a file doesn't contain directly the UEFI executable, but it is composed of multiple sections, and one of these sections is the actual UEFI executable, but there are other sections, and in this case we see a DEXY dependency section that allows to define dependencies for this specific UEFI image, and we also see a version section and a user interface section, which allows to give the human readable name for this file instead of the GUID, which is very pretty difficult to remember for humans. Okay, so now that we have all this in mind, let's go back to our E-Writer binary. So what our E-Writer binary will do is that it will parse all of the firmware volumes that it can find looking for four specific files. So it looks for IPv4DEXY, NTFSDEXY, SMIFlash, and the DEXY core. So why does it look for IPv4DEXY and the DEXY core? Well, these files will look for to find the firmware volume where to install the UEFI root kit. So usually in UEFI firmware all of the DEXY drivers are in the same volume, so when the tool will parse, we'll find in fact IPv4DEXY, it will know that it is currently parsing the volume with all of the DEXY drivers in it, and it will keep it as a candidate for the UEFI root kit installation. And it looks for the DEXY core basically for the same reason, but sometimes the DEXY core is in a different volume, so when it will find it, it will keep the volume as another candidate for the UEFI root kit installation, and the chosen volume will be the one with enough free space available in it. Now NTFSDEXY, so NTFSDEXY is the American Megatron Incorporated NTFS driver, and if the tool finds it, it will remove it. And the reason for that is that the UEFI root kit embeds its own NTFS driver so to avoid any conflict with another NTFS driver, it just removes it. And now SMIFlash, so SMIFlash is looked for and if the tool finds it, it will keep some metadata about it in the structure, but in the version of the tool that we analyze, it's not used anywhere. But interestingly, SMIFlash is a non-vulnerable DEXY driver, so what we believe is that Sydney might have been fiddling in another version of the tool with some exploit for this driver in order to be able to bypass write protection mechanisms to the bias region of the SMIFlash memory. So now that it has found the volume where to install the root kit, it will add the root kit, right? So the first thing it does is that it will create a firmware file system file header. Then it will append the root kit file, which is a compressed section that contains two other sections. One of these is the actual UFI root kit image, and the other one is the user interface section defining the name for this root kit, which is SECDEXY, as in security DEXY. And then it will take this blob of data and write it at the end of the firmware volume that was chosen. So now that the UFI root kit is inside the firmware in two memory, the next step is to write it back to the SPI flash memory. And once again, there's a couple things that I want to introduce here. So I want to talk about bias write protection mechanisms. So the chip set exposes write protection mechanisms that need to be properly configured by the firmware, so there are no such thing as, you know, bias write protection mechanism enabled by default. It's really the job of the firmware to do that. And today we'll only cover relevant protections to our research, so only the protection mechanism that are looked for by RE writer binary. And yeah, the protection we'll talk about are exposed via the bias control register that we've seen a little bit earlier in this talk. So if you're a kernel driver and you want to write to the bias region of the SPI flash memory, what you need to do first is you need to set the bias write enable field of the bias control register to one and then you're able to write to the SPI flash memory. But of course you don't want any kernel driver to be able to modify your UEFI firmware and potentially break your machine. So there's a protection mechanism there which is another field in the bias control register and this field is called bias lock enable and it allows to lock bias write enable to zero. And this field is readable in WLO. WLO means write lock once and what it means is that once the firmware has set this bit there's no other way to set it back to zero than performing a full platform reset. But there's a problem here and it lies in the fact that bias lock enable implementation is vulnerable. So how it works is that when bias write enable is set to one its value will actually change in the bias control register for a small amount of time and then the platform will issue a system management interrupt and the SMI handler will set bias write enable back to zero. But yeah, the firmware must implement this SMI otherwise this mechanism is totally useless. But maybe you've guessed it but what happens if we write to the SPI flash memory before the SMI handler sets bias write enable back to zero so there's a race condition vulnerability here and there's a paper about it which is called a speed racer and to exploit this what you need to do is you need one thread that continually set bias write enable to one while another thread tries to write the data to the SPI flash memory and according to this paper it works on multi-core processors as well as on single-core processor training enable. So Intel came up with a fix for this issue and it was introduced in the platform controller hub family with Intel chipsets around 2008 and what they did is that they added a field in the bias control register and this field is called SMM bias write protect disable and the name is a little bit misleading but if you remove disable that's actually what it does and if this mechanism is activated there will be no other way to write to the SPI to the bias region of the SPI flash memory then if you don't have all of the cores of your processor running into SMM meaning that the job of writing to the SPI flash memory is now only available to system management mode and once again the firmware must set this bit otherwise it is otherwise this mechanism is not activated right okay so let's go back to RE writer binary so of course if I talk about all of these mechanisms because RE writer binary checks for them so it will check if the platform is properly configured and it implements the exploit for the rate condition that I just spoke about so let's look at the writing process decision tree so the first thing that it will look for is if bias write enable is set and if bias write enable is set there then there's nothing stopping it from writing the UEFI image but if it is not set then it will check oh is bias log enable activated and if this mechanism is not activated then it will just flip bias write enable to 1 and then it will write the UEFI image but if it is activated the last thing it will check for is SMM bias write protect set and if it is not set then it will exploit the rate condition that we spoke about and if it is set then the tool will just fail so the tool only works if the platform is misconfigured and we spoke about SMI flash the vulnerable dexty driver so yeah what we think is that by being able to exploit this vulnerability they would have been able to have a tool that works even when the platform is properly configured so it's a very good example of I mean if firmware vendors would have done their job correctly here this tool would have failed at flashing the UEFI firmware so that's a great example of how firmware security is so here let's just take a step back and look at what we have so what we have is a software implementation to flash the firmware remotely post exploitation meaning that as an attacker I can infect my target the way I usually do let's say by sending a phishing email and once I have a foothold in the machine I can use this tool to deploy the UEFI rootkit and what we knew about in the past was hacking teams UEFI rootkit and it needed physical access to be deployed so it's so much more convenient to be able to do it remotely and let's note here that there's no proof of hacking teams rootkit being used in an actual cyber attack it has never been found on a victim's machine or at least if it had it hasn't been publicly disclosed so what we did at this point is that we extracted the UEFI rootkit from the tool and we looked at ESET's UEFI scanner let me try to see if we can find something and it turns out that we found the UEFI rootkit in the SPA flash memory of a victim's machine making it the first publicly known UEFI rootkit to be used in an actual cyber attack okay so now let's look at the UEFI rootkit itself so the UEFI rootkit is a Dekshi driver so it is loaded by the Dekshi dispatcher every time that the machine will boot its file name is SecDekshi as we've seen earlier and here's the file width for future reference so let's look at the UEFI rootkit workflow so a UEFI firmware will go through multiple phases when it boots the first phase is the security phase the second one is the pre-EFI initialization phase and then there's the driver execution environment phase and that's where it begins to be interesting for this rootkit so that's where the Dekshi dispatcher lives so that's when all of the Dekshi drivers will be loaded so at some point the UEFI rootkit will be loaded and what will happen is that the rootkit will create an event attached to UEFI group ready to boot and it will bind a notify function to this event so in the next phase when the boot manager will run at some point it will signal this event and the notify function will be called so the notify function does three things the first thing is that it will install an NTFS driver then it will drop a tochee.exe and rpc.net p.exe using this NTFS driver and finally it will patch a value in the Windows registry so the NTFS driver is needed to get file-based access to Windows partition and send its operator did not write their own NTFS driver what they did is that they use hacking teams in TFS driver from hacking teams leak and so here's the code responsible for dropping the file so as we can see here it is dropping rpc.net p.exe and here it is dropping a tochee.exe and the last step is to patch the Windows registry so how it does that is that it will open the file backing the hqlm system registry hive and it doesn't have all the logic to parts Windows registry structures so it will only look for a textual pattern and the textual pattern it will look for is autochek autochek star and it will change it to autochek autochee star and it happens to be modifying the bootexecute key so the bootexecute key is the key responsible for launching autochek.exe during Windows early boot so by modifying it to autochee instead of autochek that's autochee.exe that will be executed instead of autochek and so here if we go back to the ufi rootkit workflow when the operating system will run then it will execute autochee.exe autochee.exe will drop the small agent the rpc.net p.exe and so on but what's interesting here is that it will revert back the modification in the Windows registry from autochee to autochek so that as a Windows user for instance if I look in the Windows registry I won't find that any modification occurred there so that's pretty interesting stealth technique that is enabled by the fact that the malware is coming from the firmware okay so the last thing that I want to talk about now is prevention and remediation so what can you do if in fact one can you do to protect yourself again this kind of attack and if ever you find out that you have a UEFI rootkit in your machine what can you do so prevention so the first thing in the most important thing which is also the most accessible thing thankfully is that you should keep your UEFI firmware up to date to make sure that if security researchers found some issues with your firmware and they disclosed it and the firmware vendor fixed them you want to make sure that you have the latest patches available on your machine then the second thing is that you should really enable secure boot but let's note here that secure boot itself would not have predicted you against this specific attack and the reason for that is that secure boot takes the content of the SPI flash memory as its root of trust meaning that what's inside the SPI flash memory is not subject for validation so what does it validate then right well secure boot will check what's coming from outside of the SPI flash memory meaning the PCI option ROMs and probably the most important thing the operating system loader so it's really a mechanism that checks that the operating system loader hasn't been tempered with so what can we do then right well what we need is a hardware root of trust so we need to move the root of trust from the SPI flash memory to some piece of hardware so it must be in a you know one-time programmable chip that is programmed during manufacturing time and that cannot be written to ever after and an example of this exists technology like Intel boot guard implements this and also Apple T2 security chip has a hardware root of trust and then you kind of need to hope that your firmware configures the security mechanisms properly and there's not much you can do about it if your firmware is up to date but thankfully there are firmware security assessment tool available out there and an example of that is Intel chip sec which is an open source software too so you can just download this tool put it in a USB key, boot from it and then this tool will check for all of the security mechanisms that we spoke about today will check if they are properly configured and it also checks for a bunch more stuff and now also chip sec checks if your firmware has this low jack low jacks root kit so if you want to know if your firmware properly configures the security mechanism that's really the way to go now about remediation so this slide is kind of short and the reason for that is that if you find out that you have a UEFI root kit in your SPI flash there's not pretty much you can do you really need to reflash your UEFI firmware that's definitely not something that is easy to do for anybody and well if it's not an option for you then you kind of need to get rid of your motherboard or your laptop and get a new one basically so that's how serious this kind of attack is now a conclusion so our research shows that UEFI root kits are not only toys for researchers to play with but they are real-world threats used in actual cyber attacks so it might be something that you want to keep in mind when you'll be defining your threat model also we won't stress this enough firmware must be built with security in mind from the bottom up and things are getting better because there are more and more security researchers looking into this but there's still work to do and hopefully our research will help share knowledge about how to prevent and mitigate UEFI-based threats so that is pretty much it for me today so thank you for having me and if ever you're interested to know more details about this research the white paper is available at willivesecurity.com and you can grab a copy there so thanks we have five minutes for Q&A so please quick and short questions number one please in this case well that's kind of the pretty much the only one we're aware of apart from hacking teams UEFI root kit and this one only works on Windows so we don't know about any other that targets Linux or Mac OS for instance please refrain from walking in front of the cameras when you're leaving thank you could we get microphone number two please hello thanks for the talk on your slides you mentioned the tool open source for checking out the layout what was the name of the tool it's called UEFI tool so you can find it on Github Sam the internet please thank you does the root kit also work when the UEFI is in BIOS legacy mode that is a pretty good question I think it should but I'm not sure about it that's a good question I'd have to look into this to have an answer I'm 100% sure about sorry for that microphone number three please it's you in the back no that's four I'm sorry so does the UEFI dropper still work with BitLocker enabled oh yeah we test that no it doesn't work if BitLocker is enabled so it doesn't wait for BitLocker to have decrypted all of the data so now it doesn't work if BitLocker is enabled number one please could it just say that the way it decrypted in that way I'm not sure I heard all of the questions but if it works if there's full disencryption is it the question right would it be possible to make it work with BitLocker? I think it should be because the LoJack software is a legitimate one the entity that solution they are able to make it work even if BitLocker is enabled or full disencryption so yeah it should be possible to do so one more internet question please thank you what if a rootkit doesn't fit in the SPI flash is filling up the SPI flash space completely valid prevention? I don't know if we could really call it a prevention mechanism but yeah if there's not enough free space available on the firmware volumes the tool will just fail number two please hi you said that there is no real possibility to secure everything but what are your daily choices that you use like on your personal computer to be feeling secured oh well I could say an alternative platform but yeah if you have a modern Intel CPU and you have secure boot enabled and you have all of the latest UEFI for more updates that's kind of the best you can do to be safe against that kind of attack I have my like this number one please so a really nice configuration by the way is the configuration from the previous system? no no no the configuration in fact it's not a separate configuration file the configuration is embedded inside the executable so it's embedded into rvc.netp.exe unfortunately we are already out of time so please thank our speaker again