Intro
Hello everyone!
It’s been a while since my last post but I guarantee it was worth it.
I promised that this post will be the best one yet and I tend to keep my promises.
A couple of months ago I got invited to present my latest research at a conference. Tell you the truth, I wasn’t researching anything special at that time.
I decided to show up with something new and relevant, but what would it be?
A few days later, just when I was about to take routoast and be done with it, my friend whatsapped me about a new campaign of the infamous group – APT28/Fancy Bear/Sednit.
The name of the rootkit they used was LoJax.
That was exactly what I was aiming for.After reading the technical review of this rootkit, I decided that I want to develop one of my own that will take it to the next level.I divided the post into two sections because it was very long and pretty complicated.
In the first one (this one) I will give a background and explain the first common phase in order to escalate to the privilege level needed.So after all the bullshit, it’s time to start the journey to the UEFI.
Load First, Load Deep (The legendary “Rootkit Arsenal”)
I’m sure most of you heard about things like patching the MBR/VBR or hijacking the boot procedure to plant a driver, but why do we even want to run code on the boot procedure? What does it get that a regular user-mode code can’t do?I think that the next picture really explained the motivation behind attacking the boot procedure and more specifically the UEFI.
So, to sum the advantages:
⦁ We control the whole Software Stack of the system.
⦁ We can survive OS format or even OS replacement. As long as the FLASH chip on the motherboard is there, our code will run.
⦁ We can brick the system but really brick it – the computer won’t boot at all. Not even to UEFI/BIOS. Just a black screen. Not fun. Been there. Don’t try it.
⦁ The last, most significant one will be presented at the end of this post.
Flash Splash
In most modern computers we will find a Flash chip that contains the system firmware (which replaced the old ROM).That is where we will find our target – UEFI (among other things).
The content of the flash is separated into regions that contain code and data that essential to the basic functionality.
The main regions are:
Flash Descriptor (FD) – Defines mappings of the entire flash descriptors and regions. It defines most of the flash protection that is supported by the controller hub.
Gigabit Ethernet (GbE) – Various technologies for transmitting Ethernet frames.
Platform Data – Added in ICH9.
BIOS and Intel Management Engine (ME) will be discussed in detail.
Good ol BIOS
Unified Extensible Firmware Interface is the tech that replaced BIOS.
In spite of the major differences between the two (which we won’t discuss here), the region of the UEFI is still called the BIOS region.
As mentioned earlier, most of today’s computers use UEFI (except for the one that thrown in your grandma’s garage).
The region’s size is pretty dynamic, but on most systems, it’s around 9000kb.
An interesting fact is that UEFI is about the same size as MS-DOS!
UEFI works fine with FAT, and surprisingly supports PE executables (Yes, like windows).UEFI uses GPT to support large disk size and it can use network services even without OS installed.
The system also allows information sharing with the OS in runtime, driver loading, graphics, etc.Supply Secure Boot (😊) ability.It provides a simple shell.
Can’t Touch ME
“…an autonomous subsystem that has been incorporated in virtually all of Intel’s processor chipsets blah blah blah…”
Basically, the whole thing is just a management interface of the intel chipset (It supports things like remote shutdown).
The interesting thing about it is what Intel doesn’t want you to do. If you try to take apart a firmware update from your UEFI manufacturer, you’ll probably find some executables that been taken from a project called “Intel CSME”.
Intel CSME is a firmware & security management tool, developed by Intel and released only for the firmware manufacture companies.
CSME is a truly powerful and multifunctional firmware managing tool that allows you to do almost everything.
If you like it then you should have put a ring on it
Back to basics.
I’m sure that all of you heard about the four protection rings mechanisms in Intel’s processors. Let’s add some flavor to it.
Ring -1 HypervisorOS and hardware abstraction (Intel VT-x)
Not a real execution mode of the processor, but it should be mentioned.
Ring -2 System Management Mode
Special execution mode which pauses all other execution modes.Used to run programs that need isolation and high privileges.
These programs usually reside in the system’s firmware.
It’s a well-known system in the firmware vulnerability research community because of the large attack surface it provides to kernel space (Interrupts, function table, etc.)
Ring -3 ME
Discussed earlier.
An autonomous system, transparent to the processor.
It goes without saying that these so-called “rings” are not part of the ring selector that your system implements.
Vendo(r)s
The flash chip in your system has two main features:- Reprogramming of the firmware- Protection against unwanted programming.
The vendor’s responsibility is:
⦁ Periodically update the firmware.
⦁ Protect the firmware from malicious reprogramming.
Interesting fact – reprogramming firmware is also called firmware flashing because, in the past, you have to expose a small window on your chip to strong light in order to reprogram it.
Recent Attacks
If you all wondering (like I did) why we starting to see UEFI attacks in the wild just now, here are the answers:
⦁ Firmware vulnerabilities are complex memory corruption.
⦁ Exploit developing for the firmware requires expensive equipment and testing.
In addition, it’s super exhausting to develop a stable exploit.
⦁ The exploit is very system-dependent.
⦁ It’s hard to reproduce and distribute
Diving to UEFI
Our target is to run our code in UEFI.In order to do that we obviously need to write to it, specifically to the BIOS region.
In order to perform firmware flashing and plant our malicious code inside the UEFI, we need to bypass three layers of protection mechanisms.
BIOS_CNTLThe first protection that we need to kill is a register called BIOS_CNTL.
The register size is eight-bit and it is responsible for Read/Write operation on the BIOS region.
There are two bits that interest us:
BIOS Write Enable (BIOSWE)
Obviously, in order to write our code to the bios region, we need this bit to be set.
BIOS Lock Enable (BLE)
Take a quick look at the new protection rings diagram.As discussed, SMM is a special execution mode that pauses all other execution modes in the processor.
If BLE is set and we set the BIOSWE bit, a System Management Interrupt (SMI) is fired. The interrupt unset the bit and prevent us from writing to the BIOS. It goes without saying that we can’t edit this bit.
The next diagram will make it clearer.
A simple try to write to the BIOS region will look like this (never mind the other registers):
Then, the SMI will be fired and prevent us from writing:
Wait…
On almost any computer there are several cores working simultaneously.
It sounds like a classic Race Condition.
We need two kernel threads that run simultaneously.
On a thread in a tight loop that sets the BIOSWE bit repeatedly.
The other simply tries to write to the BIOS region before the SMI locks it again.
We will exploit it using two legitimate signed drivers, but first, we need to understand how UEFI works and how to modify it with our rootkit.
Back to Basics
As I mentioned earlier, UEFI uses regular PE format to load its drivers.
But there is a major difference. We are programming for a very different runtime environment, which means different libraries, different functions, etc.
Lucky for us there is a formal project named EDK-II by tianocore that contains everything you need for developing a UEFI driver.
I recommend you use Alex Lonescu’s project that allows EDK-II to work with Visual Studio. The drivers are developed in C.The package includes some sort of emulator for debugging.UEFI drivers extension is usually EFI.
In order to modify our BIOS and still keep a bootable computer, we will try to change as little as possible.
We will do it by dumping our current BIOS and adding our driver to it, then, we will flash it back and overwrite the existing driver.
I highly recommend you don’t try this on your computer before you get some experience.There is a super-easy way to try it with VMware virtual machine.
On your computer, find your CSME version and use the “Flash Programing Tool” with the following command:fptw -d biosreg.bin -bios
This command will dump your current BIOS region.Now it’s time to patch it. We will use a tool named UEFITool. This tool is used to parse, extract and modify UEFI firmware images.
Load the bios IMAGE to the UEFITool and search for the FAT driver.
The use the action “Insert After” and choose your driver.
Then all you need to do in order to run your code is to flash it back:fptw -f biosreg.bin -bios
Flash me like you do
Back to business.
The first driver that we will use is the Intel ME driver, wrapped by Intel CSME (which we talked about earlier).
This driver will take care of the writing with the simple commandshown above.
We will run it in a loop until the race condition will work using a batch script.
The second driver that we will use is RWEverything.
The driver’s sole purpose is to read and write everything you want to anywhere you want in the system. This driver will help us unset the BLE bit in a tight loop.
The BIOSREG resides in PCI.
After a little bit of reverse engineering, we find out that the IOCTL for reading PCI configuration register is 0x222840 and the one for writing is 0x222834.
That’s great because we need an extra tight loop on this one. We will do it by writing our own wrapper to this driver instead of using the slow complicated GUI one that offered. It should be enough.
Bingo!
If you succeeded to flash your BIOS – congrats!
If not, don’t worry about it. At least you didn’t brick your computer 😎
Stay tuned for the next part 😊
In the next one, I will explain the second phase and the renewal that the rootkit I developed presents.
I promise to post it in a few days.
see ya soon 🙋
https://www.google.com/search?q=uefi&oq=UEFI&aqs=chrome.0.0j69i60l2j0j69i60j0.2983j0j7&sourceid=chrome&ie=UTF-8
https://bromiumlabs.files.wordpress.com/2015/01/speed_racer_whitepaper.pdf
https://www.win-raid.com/
https://www.codeproject.com/Articles/9504/Driver-Development-Part-1-Introduction-to-Drivers
https://github.com/tianocore/edk2
https://www.welivesecurity.com/wp-content/uploads/2018/09/ESET-LoJax.pdf
Comments are closed