Let’s Continue
Hi everyone!
This is the second part of UEFrIze – Next-Gen UEFI rootkits.
In the first part, we walked through the common way of flashing the BIOS region
This time we will discuss a more sophisticated way to bypass SMM protection.
Then we will talk about the rootkit itself – OuterEdge and the advanced new threat it brings to the table.But first I want to take a deeper look into the race condition exploit, as some of you requested.
RaceCon
As I mentioned you need two kernel threads running for you.
I used two signed drivers – RWEverything and Intel ME.
The wrapper for writing to the PCI ISA bride to unset the lock bit looks like this:
Yes, Notepad++ is a great code editor. If you think otherwise you are welcome to exit this post and never return again.A very tight loop of the specific IOCtl.
The second action you have to do is flashing your BIOS region.
For simplicity, I used Intel’s CSME official tool.
The command looks like this:
Combining these two should do the work.
What Now?
So, we bypassed BLE protection, but Intel got another surprise for us.When the transition from ICH to PCH happened, Intel had an opportunity to insert a new defense mechanism – SMM_BWP.
As we can see, the fifth bit of the BIOS_CNTL register that was previously reserved now serves as a SMM_BWP.
SMM Bios Write Protection system doesn’t allow writing to the BIOS region unless all processors are in SMM.
Although escalating to SMM is possible we will not use it because it belongs to the old, complex, and model-specific vectors that require special equipment and a lot of time.
This protection will destroy the race condition.
let’s look farther down the road
We found out that the only bit preventing us from editing the entire register is called FLOCKDN.
If we can somehow gain control of this bit, every other protection will be irrelevant (except Protection Range Masks).
Taking a deeper look we see that the bit is cleared by hardware reset and partition reset in ME enabled systems.
That’s it! Sleep and suspend will cause ACPI S3 sleep that will clear the lockdown bits. When it happens, we get a small window of opportunity to bypass the protection mechanisms!!!
Just Script it
During a normal boot procedure, a script named “Boot Script” is saved by a startup DXE driver which scans the system configuration.
The script contains the configuration values of the systems.
These values are used when the system resumes, to make the procedure more efficient.
During the resume procedure, a driver parses the script and puts the values in the right places. The locking registers – TSEG and BIOS_CNTL also included in the boot script.
Our goal is to get to the boot script and edit it, then cause an S3 resume that will un-set the locking bits.luckily, the boot script’s table is located in ACPI NVS which is just normal RAM!
The flow goes like that:
⦁ Load a kernel driver
⦁ Call GetFirmwareEnvironmentVariable
⦁ Get to offset +0x18 from AcpiGlobalVariable. This is a pointer to the BootScript
⦁ Modify the boot script to unset the lockdown registers.
And that’s about it.
I will not go to implementation specifics because it will triple the post size, so if you want to do it yourself, enjoy your research!
PowerRangers – Protected Range Registers
PRRs are the most powerful protection mechanism because it’s based on hardware only.It’s power lie within its simplicity – registers that define unwritable address space within the flash.
Even an attacker who escalated to SMM cannot edit them.
The truth is – there is no way (yet) to bypass this protection but
:⦁ The registers never cover a whole region so you can edit the relevant parts that aren’t protected.
⦁ The majority of the manufacturers don’t even bother to initialize them (except HP).
The realistic way to bypass it is to escalate to SMM, using a relatively complex exploit (but not super complex), and then edit the encryption key that signs firmware updates and then update normally.
There are more methods to bypass PRR but they belong to the old complex methods which require a lot of time and expensive equipment.
So, our vector so far looks like this:
OuterEdge vs Lojax
First of all, Lojax doesn’t support SMM Lock bypass, but the main difference is that Lojax and most of the other bootkits uses it to plant a User-Space agent that will be dropped and executed every boot.Bottom line – they are OS dependent and they’re payload runs within the OS.
When I was wandering around russian blogs, I found an interesting post:
Another major upgrade is that UEFI supports TCP/IP and manages its own stack.
This is exactly what I was aiming for – this feature helped me to develop a different line of thought about these kinds of rootkits.
In the previous post, we talked about UEFI driver development.
OuterEdge rootkit’s UEFI driver got three main parts:
Sign itself to a callback SMI that will surely reoccur periodically
Deploy a relevant file system driver (in our case – NTFS) you can easily find it online.
Note that new computers already support NTFS and EXT so for them, these part is unnecessary.
If you wish to check this out, look inside the BIOS reg dump for their drivers.
Implement ICMP ping (you can find open source implementations)
Fire Your Guns
The rootkit’s payload is to search for interesting files using the NTFS driver and leak them using PING messages that run over the TCP/IP stack of the UEFI.
This method is extra powerful because it’s entirely out of the OS scope and almost impossible to detect and remove within the OS environment.
Powerful tools like Wireshark and Sysinternals will not help in this case. Plus, the rootkit can run on many different OS.
It goes without saying that it enjoys all the advantages of the UEFI resident rootkit discussed in the first part. You’re more than welcome to take it to the next level.
Personally, I think that opening a TCP socket will be pretty neat.
That’s it – Hope to see you next time!
Comments are closed