Slashdot Mirror
First-Ever UEFI Rootkit Tied To Sednit APT (threatpost.com)
Researchers hunting cyber-espionage group Sednit (an APT also known as Sofacy, Fancy Bear and APT28) say they have discovered the first-ever instance of a rootkit targeting the Windows Unified Extensible Firmware Interface (UEFI) in successful attacks.
From a report: The discussion of Sednit was part of the 35C3 conference, and a session given by Frederic Vachon, a malware researcher at ESET who published a technical write-up on his findings earlier this fall [PDF]. During his session, Vachon said that finding a rootkit targeting a system's UEFI is significant, given that rootkit malware programs can survive on the motherboard's flash memory, giving it both persistence and stealth.
"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," he said. The rootkit is named LoJax. The name is a nod to the underlying code, which is a modified version of Absolute Software's LoJack recovery software for laptops. The purpose of the legitimate LoJack software is to help victims of a stolen laptop be able to access their PC without tipping off the bad guys who stole it. It hides on a system's UEFI and stealthily beacons its whereabouts back to the owner for possible physical recovery of the laptop.
"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," he said. The rootkit is named LoJax. The name is a nod to the underlying code, which is a modified version of Absolute Software's LoJack recovery software for laptops. The purpose of the legitimate LoJack software is to help victims of a stolen laptop be able to access their PC without tipping off the bad guys who stole it. It hides on a system's UEFI and stealthily beacons its whereabouts back to the owner for possible physical recovery of the laptop.
Yea, a definition would be quite apt here: Advanced Persistent Threat. (per wikipedia APT)
Anyone with a working brain can see that non-removable persistent storage on the mainboard, that can be written from inside a running OS and only be inspected under the control of the software in that storage, is an extraordinarily stupid mistake. Then there are a variety of "management" systems (SMM, IME, ...) which also evade inspection and have full access to everything. The most trustworthy computers these days are small embedded processors (but not phones!). Desktop systems and laptops can practically not be secured. If there is a possibility of a hack, there is no reliable way to restore the system to a safe state.
This. Unlike old BIOS that only needed a few bytes to maintain configuration (commonly battery backed CMOS, but eeprom could be used) the latest abomination from Intel needs a full fledged read/write flash file system. To make it worse, unlike old BIOS where clearing the CMOS would recover from any mis-configuration, some implementations of EFI can be bricked.
Now, from TFA, it turns out UEFI makes a dandy platform for persistent malware.
So, NOW can we go back to BIOS and just make it unstand GPTs?
As someone who writes BIOS for a living, no we can't go back to legacy BIOS at this point. Chipset initialization has gotten too complex to fit in the 1 MB of RAM allowed by 16 bit real mode. UEFI is actually a big upgrade for firmware engineers since it natively supports the C language and 64 bit long mode. None of the silicon released by Intel or AMD in the last 5 years would be bootable with 1 MB of RAM.
As another (former) BIOS writer, why not pop it into flat-32 and go from there? Implementing a complex API complete with a file system seems a bit much for something that will run just long enough to call a boot loader.
IIRC, a number of BIOS do, in fact, go into flat-32 mode. The big catch to using C is not the size of the flash chip, it's the need to have space for the stack before you get memory up. That is handily solved by configuring the CPU to use it's cache as a temporary RAM long enough to get the actual RAM up.
CoreBOOT + SeaBIOS manage to be implemented mostly in C and work just fine. Most server boards still manage to implement "Legacy boot mode".
Unfortunately, UEFI appears to be insecure by design. So, step one, shred UEFI and secure wipe it's source.
CoreBoot has a nice modern design that works. The only thing holding it back is lack of vendor support.
A minimalist extension of the old BIOS system to go to flat 32 bit mode ASAP, and load a bootloader the same way old BIOS does comes to mind. If necessary, expand the CMOS a bit, but under no circumstances allow it to contain code, just settings. And like the old BIOS, if the CMOS doesn't pass a checksum, write sane defaults to it. Writing to the flash should never be needed for normal operation, write should need to be enabled ONLY if a BIOS update is needed, and that should be a very rare event.
A wishlist item is that all of the "secret sauce" that requires vendor support and NDAs should be packed into one section and when it is complete, it should simply jump into a well known location to take care of loading the boot loader. Do NOT implement a memory allocator, filesystem, word processor or Eliza in BIOS. Rule 1, the system must operate normally if writing to flash is disabled.