Mini: Wild Rootkits - UEFi under attack

[rcmaehl]

Source:

ESET (blog)
ESET (whitepaper)
Business Computing World

 

TL;DR:
While widely theorized for a while, this is the first instance of a UEFI rootkit in the wild

 

Quotes/Excerpts:

Quote

"In theory we were aware that UEFI rootkits existed, our discovery confirms... they are no longer just an attractive topic at conferences, but a real threat". UEFI rootkits are extremely dangerous... a key to the whole computer... hard to detect... able to survive...  reinstallation... or even a hard disk replacement. Even cleaning a system that was infected... requires knowledge... such as flashing the firmware. Sednit, also known as APT28, STRONTIUM, Sofacy or Fancy Bear, is one of the most active APT groups... since at least 2004. The DNC hack...  TV5Monde... World Anti-Doping Agency... and many others are believed to be the work of Sednit. This group has in its arsenal a diversified set of malware tools. The discovery of the first-ever in-the-wild UEFI rootkit serves as a wake-up call. “Now there is no excuse for excluding firmware from regular scanning... Such an attack... would lead to the full control of a computer, with nearly total persistence.

 

My Thoughts:

It was only a matter of time before this became a thing. UEFI is a tough balance between security and features. You could completely lock down UEFI but then never be able to change your OS. 

[EarthWormJM2]

Well then... That would really suck to get. Basically light your computer on fire and start over...

 

[GDRRiley]

Dam it, another thing that will take hardware changes to fix. 

[Master Disaster]

7 minutes ago, GDRRiley said:

Dam it, another thing that will take hardware changes to fix. 

Nope, just a UEFI flash would remove it.

 

[Sniperfox47]

2 hours ago, rcmaehl said:

You could completely lock down UEFI but then never be able to change your OS. 

I mean this is firmware malware that embeds itself into the UEFI image itself, is it not? Secureboot isn't gonna help you there. Even with a fully locked down bootloader that can only load Microsoft signed bootloaders, it'll still be vulnerable.

[Master Disaster]

7 minutes ago, Sniperfox47 said:

I mean this is firmware that embeds itself into the UEFI image itself, is it not? Secureboot isn't gonna help you there. Even with a fully locked down bootloader that can only load Microsoft signed bootloaders, it'll still be vulnerable.

I'm not 100% sure but it's possible they're more like applets than traditional firmware. EFI is almost like a mini operating system, it has a terminal and it's own language and AFAIK it's possible to write applets that run on EFI. Obviously you're heavily memory restricted but I can see it being possible to attack the EFI Shell from the OS and force install an applet into the NVRAM.

 

Obviously im not a security expert and have ZERO idea if what I just said even makes sense, that just my (extremely limited) understanding.

 

I think the point of SecureBoot is to stop anything not signed from talking to the EFI shell from inside the OS at all so technically it should prevent it. I think the issue is most people don't bother enabling SB at all.

[captain_to_fire]

3 hours ago, rcmaehl said:

APT28, STRONTIUM, Sofacy or Fancy Bear

Allegedly Russian speaking threat actors? https://www.google.com.ph/search?q=apt28&oq=apt28&aqs=chrome..69i57j0l5.2128j0j7&sourceid=chrome&ie=UTF-8

[bowrilla]

22 minutes ago, Master Disaster said:

I'm not 100% sure but it's possible they're more like applets than traditional firmware. EFI is almost like a mini operating system, it has a terminal and it's own language and AFAIK it's possible to write applets that run on EFI. Obviously you're heavily memory restricted but I can see it being possible to attack the EFI Shell from the OS and force install an applet into the NVRAM.

 

Obviously im not a security expert and have ZERO idea if what I just said even makes sense, that just my (extremely limited) understanding.

 

I think the point of SecureBoot is to stop anything not signed from talking to the EFI shell from inside the OS at all so technically it should prevent it. I think the issue is most people don't bother enabling SB at all.

Secure Boot requires signatures of your firmware as well. Before there are any Platform Keys or KEKs the UEFI is in Setup Mode and doesn't require any authentication. Once a PK is set along with the KEKs the UEFI is in User Mode you can only change/modify the firmware when the PKpub of the current firmware is signed with the correct PKpriv or if the system is set to Setup Mode again (user input needed) and the firmware is signed with the correct key again. KEKs can always be written in Setup Mode without authentication, once in User Mode every KEK needs to be signed with the PKpriv of the current firmware. 

 

Is it still possible? Probably. Will individual user be targeted with this kind of malware? Hardly – this is on a level of sophistication that exceeds every proportion when talking about average people randomly targeted. These kind of attacks are aiming at specific targets.

 

Still – a UEFI reflash via USB or built in dual UEFI will erase any tampered firmware. 

[Guest]

Apple’s EFI is pretty locked down, and you can change the OS just fine - but not what the majority of people who buy motherboards want.

[GDRRiley]

3 hours ago, Master Disaster said:

Nope, just a UEFI flash would remove it.

 

I'm saying the root issue, yeah you can remove it with a bios flash but how many people actual do that. 

[sazrocks]

What kind of access is required for the malware to be installed? Physical access, administrator privileges, or low permissions?

[dfsdfgfkjsefoiqzemnd]

So ... does this affect those of us who use legacy BIOS on their UEFI-capable machines?

[EPENEX]

I assumed everyone knew that UEFI is an insecure CIA backdoor by now.

[Sniperfox47]

7 hours ago, bowrilla said:

Secure Boot requires signatures of your firmware as well. Before there are any Platform Keys or KEKs the UEFI is in Setup Mode and doesn't require any authentication. Once a PK is set along with the KEKs the UEFI is in User Mode you can only change/modify the firmware when the PKpub of the current firmware is signed with the correct PKpriv or if the system is set to Setup Mode again (user input needed) and the firmware is signed with the correct key again. KEKs can always be written in Setup Mode without authentication, once in User Mode every KEK needs to be signed with the PKpriv of the current firmware. 

 

Is it still possible? Probably. Will individual user be targeted with this kind of malware? Hardly – this is on a level of sophistication that exceeds every proportion when talking about average people randomly targeted. These kind of attacks are aiming at specific targets.

 

Still – a UEFI reflash via USB or built in dual UEFI will erase any tampered firmware. 

Isn't this only true of external firmware modules (i.e. uefi drivers and utilities)? I was under the understanding that the UEFI implimentation itself isn't signed (except for verification during the flashing process), because there's no way to self-signiture check.

 

Secureboot really doesn't matter against attacks like this because any attack that comprises the base firmware can compromise the signature checking element.

 

To the best of my knowledge there's no hardware firmware validation on most x86 platforms is there? HPE has a hardware validation module, and I think some ARM servers do, but I've never seen anything on the AMD/Intel side unless they do some kind of firmware validation with the TPM?

 

3 hours ago, Captain Chaos said:

So ... does this affect those of us who use legacy BIOS on their UEFI-capable machines?

These specific attacks exploit vulnerabilities in the UEFI management and update service to install themselves, so these specific attacks do not.

 

In general Legacy CSM is *way* more vulnerable than UEFI and I would really be surprised if there aren't attacks in the wild. CSM is problematic because it inherits a lot of the same vulnerabilities as classic BIOS, but where classic BIOS had a bunch of different implimentations from different vendors CSM basically has one (Tianocore) making it a much larger targetbase.

[Master Disaster]

4 hours ago, Sniperfox47 said:

Isn't this only true of external firmware modules (i.e. uefi drivers and utilities)? I was under the understanding that the UEFI implimentation itself isn't signed (except for verification during the flashing process), because there's no way to self-signiture check.

 

Secureboot really doesn't matter against attacks like this because any attack that comprises the base firmware can compromise the signature checking element.

 

To the best of my knowledge there's no hardware firmware validation on most x86 platforms is there? HPE has a hardware validation module, and I think some ARM servers do, but I've never seen anything on the AMD/Intel side unless they do some kind of firmware validation with the TPM?

I remember reading somewhere about Microsoft mandating the use of TPMs in OEM machines that sell with Windows 10 so I'm assuming it's for that reason. Secure hardware storage of encryption keys for the secure enclave part of the UEFI for hardware verification.

 

Doesn't help anyone who builds there own PC though.

 

I also remember seeing something about a software/emulated TPM option being available for some UEFIs however i fail to see how that could help, as you pointed out if you compromise the UEFI then you also compromise the TPM.

[Stefan Payne]

ALL-FALL is here!!!

 

And at least here we have a proof of concept, not like some other Hitjob that only theorized that you can flash a Firmware to own a device...

[bowrilla]

6 hours ago, Sniperfox47 said:

Isn't this only true of external firmware modules (i.e. uefi drivers and utilities)? I was under the understanding that the UEFI implimentation itself isn't signed (except for verification during the flashing process), because there's no way to self-signiture check.

 

Secureboot really doesn't matter against attacks like this because any attack that comprises the base firmware can compromise the signature checking element.

 

To the best of my knowledge there's no hardware firmware validation on most x86 platforms is there? HPE has a hardware validation module, and I think some ARM servers do, but I've never seen anything on the AMD/Intel side unless they do some kind of firmware validation with the TPM?

The standard is speaking of both firmware and KEK. Once entering Setup Mode you can get around it. If you lock down Setup Mode or take other measures of securing it you will need the PKpriv to sign the firmware.

[k3rnel-pan1c]

Greetings all,

I found this today (or more it was pointed out to me by someone not as tech savvy as myself) and I thought I should share it here too.

 

So, what exactly is this news about then?

Well, a UEFI rootkit. A piece of malware that comes bundled with a set of tools to undermine Security at the deepest level. This sort of attack can mitigate "any" security protection in place on an infected machine as it loads and executes before/with the UEFI boot process.

The rootkit gets installed on a chip on the mainboard that isn't reachable from an OS level and therefore is resistant against antivirus software (not detectable). It additionally would survive a hardware swap (as long as the mainboard stays the same) and can only really be "deleted" by flushing your BIOS/UEFI.

Quote

The UEFI rootkit was found bundled together with a toolset able to patch a victim's system firmware in order to install malware at this deep level, ESET researchers said on Thursday.

In at least one recorded case, the threat actors behind the malware were able to write a malicious UEFI module into a system's SPI flash memory -- leading to the drop and execution of malicious code on disk during the boot process.

Not only do such methods circumvent operating system reinstall, but also hard disk replacement. The only way to remove such malware -- assuming victims know they have been compromised in the first place -- is to flash the firmware, a process not often conducted by typical users.

 

Who found this?

The news of such a rootkit being used was broke by ESET at the Microsoft BlueHat conference this year.

 

Who is using it?

The article mentions "Fancy Bear" (also known as "Sednit", "APT28", "STRONTIUM", and "Sofacy") who have been credited the attacks against the US DNC ahead of the US elections (most likely the best-known case) and many more. (please refer to the article in the sources for more information)

 

Am I affected?

Well I'll let this quotte tell you:

Quote

However, it is worth noting that the exploited vulnerability only affects older chipsets that do not contain the Platform Controller Hub, which was introduced with Intel Series 5 chipsets back in 2008.

 

If I'm affected, what shoud I do?

Once again quote to the rescue:

Quote

The use of a UEFI rootkit is enough in itself for businesses to take notice. However, as the rootkit is not properly signed, target systems which have the Windows Secure Boot function enabled will only permit signed firmware to load, and so, exploit is avoided.

"We strongly suggest that you enable it," ESET says. "This is the base defense against attacks targeting UEFI firmware and can be enabled at boot time through your system's UEFI settings. Updating system firmware should not be something trivial for a malicious actor to achieve."

 

So what to take away from this?

In my humble opinion this is interesting and kind of scary news,  but with a rather limited target set (at least for us normal consumers?). It once again proves my view of this year (2018) that it seems to be the year of BIG security flaws and fixes.

Finally, I hope that this won't blow up and all of a sudden also affect more than just chipsets prior to the Intel 5 Series, as the last think I want to worry about is a malicious infection so low that I can't detect it and would have to flush the BIOS or change my mainboard.

 

Source

Source

 

PS.: sorry for any grammar and spelling errors, as English isn't my native tongue (also sorry should I violate the first post restrictions, but in my defense I tried my best to comply)

 

[EDIT #1] - fix in "ps" message

Edited September 28, 2018 by k3rnel-pan1c
fix in "ps" message

[WkdPaul]

@k3rnel-pan1c thanks for the writeup, but this was posted already so it was merged.

[k3rnel-pan1c]

@wkdpaul thanks and sorry I miss that one (fell through when i searched for this )

[Droidbot]

9 hours ago, Sniperfox47 said:

Isn't this only true of external firmware modules (i.e. uefi drivers and utilities)? I was under the understanding that the UEFI implimentation itself isn't signed (except for verification during the flashing process), because there's no way to self-signiture check.

 

Secureboot really doesn't matter against attacks like this because any attack that comprises the base firmware can compromise the signature checking element.

 

To the best of my knowledge there's no hardware firmware validation on most x86 platforms is there? HPE has a hardware validation module, and I think some ARM servers do, but I've never seen anything on the AMD/Intel side unless they do some kind of firmware validation with the TPM?

Completely TPM based if it's available.

 

Secureboot will still shit the bed if an EFI module is loaded that isn't properly digitally signed, and will make you recover the key through various methods, which would tip off literally anybody that something's amiss.

 

Anyway -- SPI should be locked on most systems from being flashed UNLESS the binary is signed with the same key.

HP encrypts the whole UEFI with their own RSA key, and that should be an industry standard IMHO.

[SydneySideSteveSomewheres]

53 minutes ago, k3rnel-pan1c said:

Greetings all,

<snip>

So what to take away from this?

In my humble opinion this is interesting and kind of scary news,  but with a rather limited target set (at least for us normal consumers?). It once again proves my view of this year (2018) that it seems to be the year of BIG security flaws and fixes.

Finally, I hope that this won't blow up and all of a sudden also affect more than just chipsets prior to the Intel 5 Series, as the last think I want to worry about is a malicious infection so low that I can't detect it and would have to flush the BIOS or change my mainboard.

<snip>

1

Greetings @k3rnel-pan1c

I think you are correct to worry about such malware intrusions on your system, even if it just to remind you to be aware that such programs exist out there (spectre and meltdown do too).

I have been using Gigabyte motherboards for a while now because they have a DUAL BIOS chipset that makes this type of issue very hard to implement. There is no way to flash one BIOS chip to the other which is what you would need to do to bypass having two BIOS chips. Also, if the first BIOS somehow became infected the computer may not even boot to the operating system. Making the user aware of an issue well before the code could get a hold of the system’s operating environment. Dual BIOS is not new technology, it has been around since the AMD 780G (November 2007), and Intel G41 LGA775 (September 2009) chipsets and it should be a standard thing, not an enthusiast one.

 

Link: Giga-Byte Technology Co., Ltd

[Speed Weed]

Source: https://www.techspot.com/news/76651-eset-has-discovered-first-uefi-rootkit-wild.html

Quote

Why it matters: Infecting the firmware that loads an operating system gives persistence capabilities like few other pieces of malware from the past. The only means of removing modified UEFIs is to flash the system, leaving novice users somewhat helpless.

Security researchers over at ESET have shown that UEFI rootkits are no longer a theoretical topic for discussion at conferences. Advanced persistent threat group Sednit, otherwise known as Fancy Bear, Strontium, Sofacy, among other names, has found a way to modify the contents of flash memory where the UEFI is stored.

Unlike traditional malware that is installed to a hard drive, components of LoJax malware were discovered in the firmware that helps load an operating system. Colloquially, UEFI is sometimes still referred to as the BIOS of a machine. Formatting and replacing a hard drive does nothing to stop malware hidden away in flash memory on a motherboard. Although it is possible to scan UEFI contents, it is still not a common practice. The only way to remove malware discovered in UEFI is to flash the firmware with a legitimate copy.

Quote

 

Now I wonder if the motherboard manufacturer BIOS safe at all? The chance it could have a malware in it is highly possible to me. 

[thorhammerz]

8 minutes ago, DaPhuc said:

Now I wonder if the motherboard manufacturer BIOS safe at all? The chance it could have a malware in it is highly possible to me. 

Wdym malware? It was verified and signed by the FBI ?!

[SydneySideSteveSomewheres]

13 hours ago, DaPhuc said:

<Snip>

Now I wonder if the motherboard manufacturer BIOS safe at all? The chance it could have a malware in it is highly possible to me. 

 

If that is your board in the attached image, the Phoenix Technologies one @DaPhuc, then the BIOS does not seem to have been updated since 2017. Motherboard manufacturers have been releasing new BIOS updates since spectre and meltdown in January 2018, so there should be an updated version by now surely?