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.
Don't worry. AI and autonomous driving and quantum computing are right around the corner. That will fix all these issues.
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?
So UEFI allows persistent code to exist in it from a 3rd party for example these laptop security/tracking apps? Who didn't think this would eventually be abused by malware or some 3 letter agency?
What's even better than the malware back in the day that would attempt to modify known BIOS code, or maybe brick a BIOS it didn't know? A known documented API into UEFI that allows for "sanctioned" persistent code! yay!
UEFI and IME sounds like a 3 letter agencies wet dream.
Money. To a lot of companies, the top brass feels that security gives zero return to them, so they skimp as much as possible on it. In fact, the faster they can rush a product out the door, no matter how many odious show-stopping bugs, the better.
I wish we had something like Underwriter's Laboratories, except for computer product security, and security in the correct ways, as most companies only focus on security against the intended user, so a broken device can't be reflashed with custom firmware and made useful again. Or perhaps, take that one step further and go with a Sold Secure like system, where products are white-box tested, black box tested, source code is audited, chip supplies are audited, and so on. Of course, the downside here is regulatory capture, but if this is a multinational organization with people who are not beholden to one country, this could be an acceptable solution.
Until this, or some regulatory system is in place, these compromises will only happen more often, as one attack based on UEFI allows others to happen, and we have only seen the start persistant threats. Things like ransomware that quietly encrypts files via a transparant driver, so even backups have the files encrypted, then a certain date elapses, and the decryption keys are chucked, all drives are ATA locked and the machine puts up a message demanding whatever currency is in fashion (Bitcoins, e-Gold, etc.)
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.
Those functions (when wanted) should be provided by a bootloader like object that gets loaded by the BIOS. So far, the biggest use of secure boot seems to be making sure your computer doesn't do things you want it to if the *IAA don't want it to.
Meanwhile, other architectures don't use EFI and I see no signs that any want to, so that makes platform independant boot ROMS a bit pointless. If wanted, that could be bolted on as well.