First Sednit UEFI Rootkit Unveiled

Video thumbnail (Frame 0) Video thumbnail (Frame 939) Video thumbnail (Frame 1832) Video thumbnail (Frame 2825) Video thumbnail (Frame 4455) Video thumbnail (Frame 5256) Video thumbnail (Frame 6335) Video thumbnail (Frame 7257) Video thumbnail (Frame 9972) Video thumbnail (Frame 11115) Video thumbnail (Frame 12310) Video thumbnail (Frame 13153) Video thumbnail (Frame 14041) Video thumbnail (Frame 14914) Video thumbnail (Frame 15861) Video thumbnail (Frame 16646) Video thumbnail (Frame 17435) Video thumbnail (Frame 19611) Video thumbnail (Frame 21918) Video thumbnail (Frame 23149) Video thumbnail (Frame 24558) Video thumbnail (Frame 25958) Video thumbnail (Frame 29010) Video thumbnail (Frame 30086) Video thumbnail (Frame 31515) Video thumbnail (Frame 32778) Video thumbnail (Frame 33774) Video thumbnail (Frame 34626) Video thumbnail (Frame 35991) Video thumbnail (Frame 38390) Video thumbnail (Frame 40488) Video thumbnail (Frame 42480) Video thumbnail (Frame 43463) Video thumbnail (Frame 44881) Video thumbnail (Frame 45916) Video thumbnail (Frame 50592) Video thumbnail (Frame 51546) Video thumbnail (Frame 53098) Video thumbnail (Frame 54428) Video thumbnail (Frame 60698)
Video in TIB AV-Portal: First Sednit UEFI Rootkit Unveiled

Formal Metadata

Title
First Sednit UEFI Rootkit Unveiled
Title of Series
Author
License
CC Attribution 4.0 International:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
2018
Language
English

Content Metadata

Subject Area
Abstract
UEFI rootkits have been researched and discussed heavily in the past few years, but sparse evidence has been presented of real campaigns actively trying to compromise systems at this level. Our talk will reveal such a campaign successfully executed by the Sednit group. We will detail the full infection chain showing how Sednit was able to install their custom UEFI module on key targets' computers. Additionally, we will provide an in-depth analysis of their UEFI module and the associated trojanized LoJack agent.
Keywords Security

Related Material

Video is cited by the following resource
Roundness (object) Musical ensemble Semiconductor memory
Data mining Malware Malware Rootkit Rootkit Energy level Booting Reverse engineering
Group action Email Information Bit Local Group Message passing Malware Exterior algebra Software Rootkit Hacker (term) Rootkit Software testing Hydraulic jump Computer architecture
Latent heat Group action Malware Boris (given name) State of matter Authorization Identity management
Module (mathematics) Laptop Installation art Email Email Graphics tablet Link (knot theory) Multiplication sign Projective plane Bit Information privacy Neuroinformatik Software Googol Software Operating system Hard disk drive Information security Identity management Laptop Identical particles Self-organization
Point (geometry) Game controller Server (computing) Module (mathematics) Installation art Service (economics) Computer file INTEGRAL Multiplication sign Data recovery Architecture Mechanism design Malware Internetworking Military operation Rootkit File system Information security Firmware Booting Partition (number theory) Vulnerability (computing) Computer architecture Module (mathematics) Support vector machine Server (computing) Data recovery Weight Drop (liquid) Semiconductor memory Flow separation Virtual machine Process (computing) Internetworking Software Uniform resource name Window Booting
Vulnerability (computing) Game controller Server (computing) Computer file Ring (mathematics) Key (cryptography) Weight Single-precision floating-point format Configuration space Configuration space Vulnerability (computing)
Domain name Link (knot theory) Module (mathematics) Installation art Server (computing) Data recovery Weight Set (mathematics) Drop (liquid) Virtual machine Type theory Internetworking Software Military operation Blog Configuration space Energy level Normal (geometry) Domain name Vulnerability (computing) Booting
Revision control Malware Game controller Server (computing) Symmetry (physics) Revision control Self-organization Configuration space Self-organization
Point (geometry) Installation art Module (mathematics) Server (computing) Data recovery Connectivity (graph theory) Physical law Drop (liquid) Bit Virtual machine Mechanism design Malware Internetworking Vector space Logic Military operation Self-organization Backdoor (computing) Computer architecture Self-organization Booting
Domain name Server (computing) Service (economics) Computer file Information Virtual machine Set (mathematics) Revision control Virtual reality Befehlsprozessor Computing platform Self-organization Energy level Data buffer
Strut Virtual machine Device driver Set (mathematics) Process capability index Electronic signature Area Revision control Uniform resource locator Semiconductor memory Kernel (computing) Software Energy level Information Information security Firmware Vulnerability (computing) Data type Public key certificate Information View (database) Bit Digital signal Software Configuration space Window Spacetime Address space
Point (geometry) Module (mathematics) Installation art Internetworking Information Data recovery Military operation Ring (mathematics) Drop (liquid) Bit Virtual machine Booting
Reading (process) Game controller Computer file Flash memory Device driver Process capability index Content (media) Code Writing Latent heat Read-only memory Semiconductor memory String (computer science) Operator (mathematics) Rootkit Spacetime Configuration space Information Firmware Address space Operations research Key (cryptography) Information Binary code Content (media) Process capability index Core dump Bit Device driver Process (computing) Sample (statistics) Rootkit String (computer science) Configuration space Reading (process) Spacetime Reverse engineering Address space Firmware
Web page Standard deviation Service (economics) Service (economics) Run time (program lifecycle phase) Patch (Unix) Interface (computing) Device driver Set (mathematics) Control flow Volume (thermodynamics) Instance (computer science) Cartesian coordinate system Variable (mathematics) Latent heat Arithmetic mean Interface (computing) Operating system Extension (kinesiology) Firmware Booting Row (database) Firmware Booting
Standard deviation Service (economics) Run time (program lifecycle phase) Computer-generated imagery Flash memory Device driver Medical imaging Latent heat Read-only memory Phase transition Core dump Computer hardware Integrated development environment Communications protocol Firmware Booting Computing platform Service (economics) Standard deviation Interface (computing) Computer file Volume (thermodynamics) Device driver Integrated development environment Computer hardware Phase transition Interface (computing) Computing platform Volume Communications protocol Abstraction Window Firmware
Email Intel Freeware Open source Computer file Computer-generated imagery Flash memory Sheaf (mathematics) Counting Metadata 19 (number) Revision control Medical imaging Latent heat Regular graph Read-only memory Befehlsprozessor Hash function Core dump File system Spacetime Integrated development environment Information Firmware Data type User interface Trigonometry Computer file Content (media) Volume (thermodynamics) Bit Group action Device driver Repeating decimal Type theory Array data structure Data management Benz plane Software Personal digital assistant Sheaf (mathematics) Ubiquitous computing Interface (computing) Gezeitenkraft Volume Data structure Systems engineering
Wechselseitige Information Installation art Texture mapping Computer file Computer file Flash memory Binary code Coroutine Device driver Core dump Volume (thermodynamics) Device driver Metadata Revision control Mechanism design Rootkit Core dump Order (biology) Rootkit Volume Firmware Proxy server Vulnerability (computing) Firmware
User interface Email Email Computer file Flash memory Flash memory Sheaf (mathematics) Core dump Volume (thermodynamics) Device driver Writing Medical imaging Read-only memory Rootkit Semiconductor memory Rootkit File system Spacetime Right angle Volume Firmware Firmware
Game controller Flash memory Virtual machine Device driver Field (computer science) Product (business) Writing Mechanism design Firmware Default (computer science) Predictability Default (computer science) Binary code Range (statistics) Attribute grammar Core dump Bit Control flow Power (physics) Mechanism design Process (computing) Computing platform Right angle Writing Firmware Address space
Implementation Game controller Thread (computing) Multiplication sign System administrator Flash memory Coprocessor Hypercube Data management Writing Mechanism design Read-only memory Befehlsprozessor Single-precision floating-point format Core dump Interrupt <Informatik> Lie group Implementation Firmware Multiplication Computing platform Condition number Vulnerability (computing) Vulnerability (computing) Core dump Thread (computing) Hypercube Mechanism design Interrupt <Informatik> Right angle Multi-core processor Physical system Writing Firmware
Intel Game controller System administrator Flash memory Coprocessor Field (computer science) Writing Mechanism design Bit rate Befehlsprozessor Core dump Set (mathematics) Firmware Computing platform Condition number Game controller Bit Mechanism design Process (computing) Computing platform Right angle Family Writing Asynchronous Transfer Mode Firmware
Decision theory Computer-generated imagery Exploit (computer security) Device driver Decision tree learning Writing Medical imaging Mechanism design Process (computing) Network topology Right angle Process (computing) Computing platform Condition number Vulnerability (computing)
Point (geometry) Email Cybersex Source code Flash memory Virtual machine Exploit (computer security) Virtual machine Proof theory Arithmetic mean Read-only memory Rootkit Software Rootkit Implementation Information security Firmware Firmware
Point (geometry) Functional (mathematics) Group action Computer file Multiplication sign Keyboard shortcut Virtual machine Device driver Device driver Coprocessor Event horizon Goodness of fit Integrated development environment Whiteboard Rootkit Phase transition Rootkit Booting Firmware Information security Physical system Booting
Windows Registry Installation art Functional (mathematics) Computer file Patch (Unix) Weight Patch (Unix) Computer file Device driver Drop (liquid) Device driver Flow separation Windows Registry Leak Partition (number theory) Writing Function (mathematics) Rootkit Hacker (term) Window Partition (number theory)
Windows Registry Parsing Computer file Key (cryptography) Patch (Unix) Weight Instance (computer science) Device driver Coprocessor Windows Registry Whiteboard Logic Rootkit Operating system Pattern language Data structure Chi-squared distribution Booting Window Booting
Malware Rootkit Virtual machine
Slide rule Intel Open source Multiplication sign Flash memory Virtual machine Process capability index Mechanism design Computer configuration Computer hardware Rootkit Operating system Information security Booting Firmware Validity (statistics) Key (cryptography) Content (media) Mechanism design Arithmetic mean Computer configuration Software Rootkit Computer hardware Information security Firmware Booting
Greatest element Real number Flash memory Stress (mechanics) Shared memory Word Computer configuration Rootkit Motherboard Computer configuration Endliche Modelltheorie Information security Firmware Information security Firmware
Pointer (computer programming) Rootkit Personal digital assistant Musical ensemble Semiconductor memory Window
Axiom of choice Computer file Multiplication sign Flash memory Number Mechanism design Internetworking Encryption Software testing Firmware Booting Software development kit Execution unit Touchscreen Fitness function Volume (thermodynamics) Flow separation Personal computer Befehlsprozessor Software Rootkit Configuration space MiniDisc Right angle Musical ensemble Routing Asynchronous Transfer Mode Spacetime
Cartesian closed category Coma Berenices Musical ensemble Semiconductor memory
[Music] okay so our next talk is given by Frederick Vishal 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 to be here so today I'm gonna talk about a research that a colleague of mine Ryan buta and I did earlier this year and which led us to the discovery of a UEFI rootkit so very quickly
my name is Frederick vassal I'm a malware researcher at ESET and I've been over yet working there for the last two years and for the last year or so I've been really focused 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 setting it very very quickly then I'll talk about LoJack which is a ninja test software and pass research related to this software and the reason for that is that the you if I relive 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 compromise LoJack agents that were found in the wild and finally I'll jump into the you if I rootkit will where I'll talk about the tools around the efi rootkit and efi rootkit itself so sitting it said that
is an espionage group active since the early 2000s and it is known also known as fancy bear a PT 28 and strontium so maybe you know this group by one of these alternative names and and sendeth is the name basically that we at a tea set 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 didn't see where some emails were leaked online the hack against the world anti-doping agency as well as the AK against the French Broadcasting Network TV 5 mounted but he said when we're talking about setting it we're really talking about the tools and the different campaigns that were that were led using these tools and we're not talking about the people who are operating these 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 hacked in this specific indictment and what's interesting is that the tools that we analyzed were are named in this specific indictment and they they also mentioned who's who's the authors of these of these malware and also early not earlier
but closer from from now in October 2018 the Department of Justice issued another indictment naming pretty much the same same people related to the world anti-doping agency hacked and the way
that Senate will usually have infect their targets is by sending phishing
emails so sometime they will contain malicious links and some other time Malchus attachments okay so now let's
talk a little bit about LoJack so project an entity F software as I mentioned it was previously known as computer ace so maybe you know hi you know the solution by by this name instead and it is made by absolute
software so yeah and this solution is
built in many laptops but an anti-death software needs to be as persistent as possible if you want it to be reliable it needs to be to survive an operating system or install or a hard disk replacement so to achieve this what absolute software did is that they added a module in the UEFI bias itself yeah and the solution needs to be activated in the bias setup so with persistence
mechanism like that coming from the firmware actually attracted the attention of security researchers who looked into this in two days to find vulnerabilities basically and at
blackhat in 2009 there was a talk there where the architecture of the solution
was destroyed and several design vulnerabilities in the agent were also described there so let's look at the
architecture of hello jack Bogdan so the first thing that we have here is a module in the UEFI bias and this module will write a file to windows partition so this file is called to check that X Z so it replaces the legitimate AutoCheck that is e whose job is to perform file system 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 our PC net Peter digsy which is the small agent and will install a service and when Windows will will run it will run this service and our PC net P will be a lunch at this point and we will inject itself into SVC OS 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 the firm 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 with this in this solution so one of the
vulnerabilities they found is a very interesting for us and in fact that's really the only one that matters for for this talk and it is a configuration file vulnerability so the configuration is embedded into our PC net Peter digsy and
it is encrypted but it is ring encrypted with a very wicked garden so it is in single bite Zhora key and it is not authenticated whatsoever and what's in this configuration file well well that's
where you can find the the servers of the command and control server so in attacker can just change this configuration to point to its own ethical control server so we knew that
this vulnerability existed for a while which was back in 2009 but we had no evidence of it being used in the wild until earlier this year when arbor
networks polish a blog post where they described some modified small agent with modified configuration where the domains that were embedded in this configuration were linked to old set nets old set net domains so let's go back to the LoJack
architecture and look at where this attack type took place so to place at this level here so from there we we did some detection
for for this malware and it was and we we hunted to gather as much samples as as we could and it was fairly simple because they always modified the same exact version of the of the agent and they modified so that's what we can see here they modified the the the command control server and here we see the encrypted version of course so by looking at this we will look at ESET symmetry and found out that there was a
few organization that were hit mostly in the Balkans in Central Europe as well as in Eastern Europe these were military and diplomatic organizations and what's interesting is that we also found other
Sedna tools in the same organization so
at this point we wondered how this this malware got there but since there was other backdoors of setting it 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 LoJack
architecture the component that we found is at this this step here so at this step in the law in the logic architecture it's to check that eggsy that lives there but what we found is
not a file called Auto cheat that exist instead of other check and it does pretty much the same thing so it also installs a service and it also drops our PC NAT periodically but it is the RPC native version that has a modified server in it so sitting it's our domain basically and we continue to look what
we can find in these organization and we we found another tool which is called info EFI that XZ and that allows us to drop to to dump a lot of information about very low level settings of the the machine and this tool uses read/write
everything's driver and read/write
everything 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 mapped i/o s to i/o port 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 this point wonder did they did they get there
so because of the the tool dumping information about the bias 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
re writer read and it is it will use to dump the content of the SPI flash memory and it also uses readwrite everything this driver and it uses these specific IO control codes so it's all I was allowed to read and write to memory mapped i/o space as well as really write to PCI configuration registers what's
interesting for us as reverse engineer is that this tool contains a lot of debug strings which really made our job easier and consists of the following operations so the first thing it will do is that it will log information on the bias control register and we'll talk a lot of detail about this register a little bit later in this talk then it locates the bias region base address and finally it reads the UEFI firmware content and dump it to to a file so another tool that we we found is really complementary to the tool to re write or read and it is called re writer binary so it also contains a lot of debug strings it also uses RW everything'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 the SPI flash memory and that's exactly what this tool does ok so now let's talk
about the patching of the UEFI firmware but before we dig into the subjects
there are a couple 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 replacing 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 which usually it's the operating system loader that that runs so the first set of services has 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 argue runtime services that are also available during firmware lifetime but once the operating the operating system is loaded they are still available so that a kernel driver for instance can make calling 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 the XE drivers RPE cough images meaning that they are basically windows execute and they are kind of the core of a UEFI firmware so they can do many things some of them will be used abstract D 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 OAM to extend the firmware by registering new services the so-called protocols in the UEFI specification and the Dixie drivers are loaded during the next phase of the platform initialization and they are loaded by the exe dispatcher that will also refer to as the DEXA core the last thing that
I want to do I want to introduce for 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 and 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 unloaded 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 it contains this region contains metadata about how the remaining data and the SPI flash memory is laid out the scan region that we find here is the ME region which contains the Intel management in China firmware and finally we have the bias region which is really the main interest the main thing that we want to look at today so the bias region
contains multiple volumes so let's look at one volume a little bit more detail so here we have a volume of type firmware file system version 2 and this volume contains multiple files and these files are identified by GU 'its so that's what we can see under the name column here and F file doesn't contain directly the UEFI executable but it it it is composed of multiple sections and one of these section is the actual UEFI executable but there are other section and in this case we see a DEXA dependency section that allows to define dependencies for this specific UEFI image and we also see a version section in a user interface section which allows to gives a human readable name for this file instead of the gooood which is very pretty difficult to to remember for humans okay so now that we have all this
in mind let's go back to re-write or binary so what are you writer binary will do is that it will parse all of the firmware volumes that it can find looking for for specific files so it looks for IP for Dex see NTFS Lexi SMI flash and the next Accord so why does it
look for ID for Dex in the DEXA core well these files will look for to find the firmware volume where to install the UEFI rootkit so usually in UEFI firmwares all of the exe drivers are in the same volume so when the tool will parse will find in fact ID for deck C it will known as it is currently parsing the volume with all of the deck C drivers in it and it will keep it as a candidate for the EFI routine installation and it looks for the texture core basically for the same reason but sometimes the the deck C core is in a different volume so when it will find it it will keep the volume as another candidate for the if I rootkit installation and the chosen volume will be the one with enough free space available in it now NTFS deck C so NTFS deck C 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 rootkit embeds its own NTFS a driver so to avoid any conflict with another ntfs driver it just removes it and now SMI flash so SMI flash is looked for and you know the tool will if the tool finds that it will keep some metadata about it in a structure but in the version of the tool that we analyzed it's not used anywhere but interestingly SMI flash is a non vulnerable exe driver so what we believe is that Sydney it might have been fiddling in another version of the tool with some exploit for this for this driver in order to be able to bypass protection mechanisms to the bias region of the spi flash memory so now that it
has found the volume were to install the rootkit it will ask the rootkit right so the first thing it does is that it will create a firmware file system file header then it will happen the rootkit file which is a compressed section that contains two other sections one of one of these is the actual UEFI rootkit image and the other one is the user is a user interface section defining the name for this rootkit which is SEC exe as insecure elixir and then I will take this blob of data and write it at the end of the firmware volume that that was chosen so now the d efi rootkit is
inside the firmware into 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 chipset exposes write protection mechanisms that need to be properly configured by the firmware so there are no such thing as you know bias read protection mechanism enable by default it's really the job of the firmware to do that and today will only cover relevant protections to our research so only the prediction mechanism that are looked for bar by re writer binary and yeah the production we'll talk about are exposed via the bias control register that we 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 right enable field of the bias control register to 1 and then you're able to write to the DSP flash memory but of course you don't want any current 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 by a central register and this feels called bias lock enable and it allows to lock bias right enable 2 to 0 and this field is readable and wll Welo means right lock once and what it means is that once the firmware has said 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 right are enabled is set to 2 1 it's value will actually change in the bias control register for a small amount of time and then the the platform which issue assessment is the system management interrupt and the SMI handler will set by us write enable back to to 0 but yeah the firmware must implement this SMI otherwise this mechanism is totally use this 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 to 0 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 in a 1 thread that continuously set bias write enable to 1 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 with hyper threading enable so Intel came up
with a fix for this issue and was introduced in the platform controller hub family Wintel chipsets around 2008 and what they did is that they added a field in the bias control register and this fields call SMM bias write protect disable and did 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 SPX to the bias region of the SPI flash memory then if you don't have all of the cores of your processor running into it 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 it's not activated right ok so let's go
back to re write your binary so of course if I talk about all of these mechanism it's because I rewrite their binary checks for them so it will check in 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 right enable is set and if bias right enable is set there and then there's nothing stopping it from writing the UEFI image but if it is not set then it will check oh is bias lock enable activated and this if this mechanism is not activated then it will just flip bias right enable to 1 and then it will write the UEFI image but if it is activated the last thing it will check for is is SMM bias right protect set and if it is not set then it will exploit the race condition that we spoke about and if it is not if it is set then the tool will just fail so the tool only works if the platform is misconfigure and we spoke about SMI flash the vulnerable next to 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 that works even when when the platform is properly configured so which it's a very good example of I mean if for more vendors would have done their job correctly here this tool would have fail
at flashing the UEFI firmware so that's a great example of how you know what for more 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 you know in fact my my target the way I usually do let's say by sending a phishing email and once I have a foothold on the machine I can use this tool to deploy the UEFI rootkit and when we knew about in the past was hacking teams UEFI a rootkit and it needed physical access to be to be deployed so it's so much more convenient to be able to do it remotely and let's not here that there's no proof of hacking teams rootkit being used in a an actual cyberattack it has never been found on a victim's machine or at least it was 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 CBF eye scanner telemetry to see if we can find something when it turns out that we found the if I rootkit in the SPI flash memory of a victims machine making it the first publicly known UEFI root kit to be used in a in an actual cyberattack
ok so now let's look at the UEFI rootkit itself so the UEFI rootkit is a taxi
driver so it is loaded by the Dex dispatcher every time that the machine will boot its filename is sexy as we've seen earlier and here's the file good for future reference so let's look at
the UEFI 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 fi initialization phase and then there's the drive execution environment phase and that's where it begins to be interesting for for this rootkit so that's where the DEXA dispatcher lives so that's when all of the Dexy drivers will be loaded so at some point the UEFI rootkit will be will be loaded and what what will happen is that the Rickett will create an event attached to efi group ready to boot and it will bind a notify function to this to this Evan so in the next phase when the boot manager will run at some point it will it will signal this event and the notify function will be will be called so the
notify function does three things the first thing is that it will install ntfs driver then it will drop but to cheetah XZ and RPC net peta digsy using this ntfs driver and finally will patch a value in the Windows registry so the intestine the ntfs driver is needed to get file based access to Windows partition and Senate separator did not write their own ntfs driver what they did is that they they use hacking teams ntfs driver from acting teams leaked and
yeah so here's the called responsible for dropping the file so as we can see here this dropping our PC net Peter digsy and here it is dropping a Tucci that that agree and the last step is to
patch the Windows registry so how it does that is that it will open the file backing the htlm system registry hive and it doesn't have all the logic to parse Windows registry structures so it will only look for a textual pattern and the textual pattern will look for is to check out to check star and it will change it to check to chi star and it happens to be modifying the buddha execute key so the buddha execute key is the key responsible for launching or to check that exceed during Windows early boot so by modifying it to Auto Chi instead of auto check that's to cheat exceeded will be executed instead of auto check and so here if we go back to
the UEFI rootkits workflow when the operating system will run then it will I will be the cuter to cheated eggsy when otoshi Alexa will will drop the small agent the RPC net periodically and so on but what's interesting here is that it will revert back the modification in the Windows registry from a to cheat to auto check so that as a Windows user for instance if I look in the Windows registry
I won't find that anything any modification occurred there so that's a pretty interesting stealth technique that is enabled by the fact that the malware is coming from 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 against this kind this kind of attack and if ever you were you find out that you you have a UEFI rootkit in your machine what 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 of today to make sure that if you know security researchers found some issues with with your firmware and they disclosed it and the firm or vendor fixed them you want to make sure that you have the latest patches available on your and your machine then the second thing is that you should really enable secure boot but let's not hear 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 validates then right well secure boot will check what's coming from outside of the SPI flash memory meaning is the PCI option roms and probably the most important thing the operating system our loaders so it's really a mechanism that checks that the operating system loader hasn't it hasn't been tampered 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 into some some piece of hardware so it must be in a you know one time for grama Bowl chip that is that is programmed during manufacturing time and that cannot be written to ever after and example of this exists a 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 for more security assessment tool available out there and an example of that is Intel chipset so with Intel chips which is an open source software - so you can just download this this tool put it in a USB key boot from it and then this tool will check for all of the security mechanism that we spoke about today we'll check if they are properly configured and it also checks for a bunch more a bunch more stuff and now also chips tech checks if your firmware has this LoJack LoJack's rootkit 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 kind of short and the
reason for that is that if you find out that your you have a UEFI rootkit in your new spi flash there's not pretty much you can do you really need to reflash your UEFI firmware and 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 our conclusion
so our research shows that UEFI root kits are not only toys for researchers to play with but they are real word threats used in actual cyberattacks 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 from the bottom up and things are getting better because there are more and more security researchers looking into this but there still work to do and then hopefully our research helped share knowledge about how to prevent and mitigate UEFI Bay's threats so that is pretty much it for me today so thank you for for having me and if ever you're interested to know more details about about this research the white paper is available at we live security comm and you can grab a copy
there so thanks [Applause] [Music]
[Music]
in this case well that's kind of the pretty much the only one were aware of apart from hacking teams UV fi rootkit and this one only works on the windows so we have no we don't know about any other that the targets linux or mac OS pointers please refrain from walking in front of
the cameras when you leave me thank you [Music]
could we get microphone number two please it's called UEFI too so you can find it on github as the internet please well thank you just the route could kit also work when the you efe is in bios legacy mode that is a pretty good question I think it should but I I'm not sure about it that's a that's a good question I I'd have to look into this to have a a an answer I'm 100% sure about sorry for that microphone on the screen please it's you in the back I you know that's fall I'm sorry so that's the you if you I think it's the work I enabled I know oh yeah yeah yeah we test death no it it doesn't work if BitLocker is enabled so it doesn't wait for the the for BitLocker to have decrypted all of the data so now it doesn't work if the clickers enabled number one place I'm not sure I heard all of the question but if it works if there's oldest encryption is it the question right I think it should be because the LoJack software is legitimate one the NT test solution they are able to make it work even if BitLocker is is enabled or full full disk encryption 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 a valid prevention no I don't know 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 there is no a real possibility to secure everything but what are your daily choices that you use like on your personal computer to be fully secured well I could say Sandahl but yeah if you have a modern Intel CPU and you have secure boot enabled and you have you know all of the latest UEFI for more updates that's kind of the best you can you can do to to be safe Franky I guess that kind of may have like this number one in peace the configuration file is the no no the configure in fact it's there it's not a separate configuration file the configuration is embedded inside the executable so it is embedded into our be seen at periodically and fortunately we are already out of time so please thank our speaker again [Applause]
[Music] [Music]
Feedback