New proof-of-concept bootkit targets UEFI and Windows 8

The UEFI (Unified Extensible Firmware Interface) platform is the “next-gen” technology designed to replace the ancient BIOS contained within the most basic layer of hardware logic in PCs, bringing not only a more flexible environment but strong security features as well. The fact is that the UEFI platform has been already “cracked” open by a new bootkit created by Italian security researchers.

Developed by ITSEC, the new bootkit is able to attack the UEFI firmware and its basic security features, possibly showing a new avenue for cyber-criminals and malware writers focused on creating “invisible” malware to hijack computers, steal user’s data and remotely-manage botnets.

The tests run by ITSEC showed how the proof-of-concept bookit had been able to install itself and work “very well”, disable the Windows 8 drivers signature feature and the Patch Protection feature for the OS kernel. Conversely to the previously mentioned Stoned Lite bootkit, this new “boot rootkit” is tailored to work with the UEFI firmware.


Thanks to the new firmware, ITSEC researchers highlight, development of bootkit code is now easier than ever: coding older bootkits required a pretty good knowledge of the Assembly language and the inner workings of the BIOS technology, creating UEFI-tailored bootkits is much simpler because within the new platform “everything is abstracted from the machine”. And the new UEFI bootkits could easily target other operating systems besides Windows 8 as well.

In the end, the researchers say that UEFI is not and cannot be the only answer to security concerns of modern PC users: cracking the new infrastructure proved to be an easy task, while the security enforcement promised by the much discussed Secure Boot feature (not attacked by the UEFI bootkit… at least for now) brings many concerns as for the openness of the PC architecture.

Source: Hardware Upgrade

Report a problem with article
Previous Story

Microsoft developing new Windows 8 note-taking app

Next Story

Weekend downloadable PC games sales for Sept. 21-23

22 Comments

Commenting is disabled on this article.

Yet again it is proven that having the physical access to the box makes things a lot easier, eh? Even if Secure Boot is not enabled - this still requires physical access as well as credentials.

TheNetAvenger: I totally agree! Show me a machine that had its bootloader compromised with secureboot enabled. <sheesh>

No news here, moving on...

I'm surprised this is was worth building a proof of concept, as anyone that has worked with UEFI, essentially builds their own version of this 'proof of concept' if they make any modifications to the UEFI.

This is nonsense at best for it generate any response from Neowin or anyone else.

Let me guess, you can successfully make an application show green dots on the screen if your compile and run it too?

It really is this simple of a concept, as there is no inherent 'signing' or protection of code in UEFI. All they are doing is writing code that installs to the UEFI, which is what happens if you open Visual Studio and write a program to install to the UEFI.

This is why SecureBoot is important, and not the anti-linux or Microsoft is evil crap talk that it first received.

Without signing code via SecureBoot, there is NO WAY to secure the UEFI. PERIOD. (Intel and Microsoft knew this years ago, go look it up.)

Traditional BIOS is just as vulnerable. The only difference, you have to be smart enough to write assembly to install working code in the BIOS. I know OSS people will be shocked, but there are a lot of people that can easily code in assembly, and don't need pretty C to read or write code.

So UEFI less secure than BIOS? Nope.

UEFI with Windows SecureBoot is far more secure than plain UEFI and far more secure than BIOS. However, it means the bootloader must remain Windows (but other OSes can still boot from the Windows Bootloader if allowed by the mainboard/OEM.)

BTW in case people didn't notice, it does require security elevation to Admin/Installer (aka root) to modify the UEFI. Additionally the way 'Defender' works in Windows 8, even without Secureboot, it can successfully check the UEFI for malware, as it can run and not be influenced by modified UEFI code.


So thank Intel and Microsoft for SecureBoot and use it when you can.


How 'newsy', if you write code for the UEFI and install it to the UEFI it runs. What next, if you put your hand in water it gets wet?

As I recall the RedHat bootloader is already signed for functioning with UEFI Secure Boot. So no, it shoulden't need to stay Microsoft's boot loader, it just has to stay a trusted one.

The real OSS complaint is that it will prevent a generic bootloaders that are fully open source and untrustworthy from ever being signed. Well boo hoo. Those people will just have to disable UEFI Secure Boot. In time only some developers should have a real valid reason to disable secure boot, but considering how advanced malware keeps becoming, disabling it would be very stupid.


Now that said, all the level one hypervisors need to get their act togeather before the end of 2013 and move from a virtual BIOS to virtual UEFI with Secure Boot.

thenetavenger said,
How 'newsy', if you write code for the UEFI and install it to the UEFI it runs. What next, if you put your hand in water it gets wet?

Thank you for some background information - I could never quite work my head around what the purpose of the news article was. I read it again and again and then one more time to see where the alarm was coming from but it seemed to be little more than confirmation of what UEFI was designed to do and more importantly required the user him/herself to go out of their way to make the whole thing even possible. Am I the only one who is slightly annoyed at the press in how they blame Microsoft for something that is PEBKAC related?

So this is like walking in to a bank and opening the door to an unlocked vault and stealing all the money. Just because I could do that doesn't mean I'm any closer to figuring out how to steal the money if the vault is locked.

That example is similar to difference of their "exploit" working with secure boot off and having it work with secure boot turned on. (It's probably is easier to get in to a locked bank vault)

This is just a rootkit. The type that Windows 8 Secure Boot was designed to break. It doesn't matter if it targets UEFI/MBR. The fact that it explicitly claims to attack Windows 8 also means absolutely nothing.

This is what UEFI Secure Boot fixes, something that Windows 8 requires be enabled by default at least on mobile devices if they want to display the Windows Logo on their hardware. UEFI Secure Boot requires that the boot loader be signed and trusted, which defeats everything about current generation rootkits.

The real question is how good is the trust system for UEFI Secure Boot? How will successful attacks with signed rootkits be defeated? Just by firmware updates, or something else? This is of course assuming that the chips on the motherboard in question are not already pre-loaded with malware before an OS is even brought into the picture.


I agree. They haven't cracked the Secure Boot feature, this is just for UEFI on Win 8. So as long Secure Boot is enabled (and it will be on ALL new Win 8 PC's) i'm guessing this bootkit is useless.

You can also get Secure Boot working on some current motherboards. I've updated my motherboards UEFI and it now supports Secure Boot. I'm running Win 8 with it enabled right now.

And this is also crap in the article: "the much discussed Secure Boot feature brings many concerns as for the openness of the PC architecture."

It doesn't affect the openness of PC's at all. On my motherboard and pretty much all upcoming Win 8 hardware you can disable Secure Boot to install any other OS you like. On my motherboard you can even enable Secure Boot but enter your own security key for another OS (like Linux) if it supports Secure Boot. So you can have Linux running with SB enabled. All those idiots thats were saying SB will stop people from installing another OS on their Windows PC's are just talking crap.

Only ARM/Win RT will not allow SB to be disabled. And thats totally fine, if Apple will not allow another OS to be installed on their tablets then why cant MS? Win RT dont even have any market share yet so it's not like MS have any monopoly here.

Edited by NoClipMode, Sep 23 2012, 5:53am :

Not a problem since every new PC sold with windows 8 will support secure boot exactly to avoid this kind of malware.

If anything, this PoC proves once again that having Secure Boot enabled is important to defend against rootkit more efficiently.

Btw, no news on neowin about the release of the permanent IE security update (available since a few hours) ?

link8506 said,
Not a problem since every new PC sold with windows 8 will support secure boot exactly to avoid this kind of malware.

If anything, this PoC proves once again that having Secure Boot enabled is important to defend against rootkit more efficiently.

Btw, no news on neowin about the release of the permanent IE security update (available since a few hours) ?

If i recall SecureBoot is required and required to be turned on, to get Windows Logo on your PC also.

KevinN206 said,
How effective would this be with Secure Boot enabled and supported by Windows 8?
Article said,
In the end, the researchers say that UEFI is not and cannot be the only answer to security concerns of modern PC users: cracking the new infrastructure proved to be an easy task, while the security enforcement promised by the much discussed Secure Boot feature (not attacked by the UEFI bootkit… at least for now) brings many concerns as for the openness of the PC architecture.
It looks like it is OK for the time being.

KevinN206 said,
How effective would this be with Secure Boot enabled and supported by Windows 8?

Not effective, because secure boot will refuse to run code not signed with a Microsoft certificate.

Don't think we'll see any generic secure boot bypass anytime soon. Maybe some attacks targeting some specific implementations.

KevinN206 said,
How effective would this be with Secure Boot enabled and supported by Windows 8?

It wouldn't work if you had Secure Boot enabled.

rfirth said,
It wouldn't work if you had Secure Boot enabled.

Then why would one have it disabled?
To make one unsecured?

billyea said,

To run other operating systems like Linux.

That's not required. Microsoft is signing certs for certain linux distros.

chAos972 said,

That's not required. Microsoft is signing certs for certain linux distros.

And you wonder how difficult it would be for a gifted hacker to extract the MS certificate and use it for a not-so-friendly bootkit! UEFI may be raising the bar of security for now but I doubt it will take long until even secure boot won't be a protection anymore.

Tumultus said,
And you wonder how difficult it would be for a gifted hacker to extract the MS certificate and use it for a not-so-friendly bootkit! UEFI may be raising the bar of security for now but I doubt it will take long until even secure boot won't be a protection anymore.

The security system in place has 2 keys, a private key used to sign the kernel, boot manager, etc. and a public key used to verify the stuff.

Within the machines there will only be the public key, to be able to verify stuff not to sign new one, so the bad thing would be if the private key were stolen / leaked theoretically a person could use it to sign executable code and it would be authenticated.

However, I'd say UEFI Secure Boot also has a mechanism to invalidate a certain key (revoking a certificate), to prevent this from happening. At least it'd be the sensible thing to do.

To me the question is, how difficult would it be for a hacker to add its own public key to the UEFI storage? E.g. malware that first infects the UEFI storage and then does what it's supposed to do since its code is already trusted.

chAos972 said,

That's not required. Microsoft is signing certs for certain linux distros.

In theory. For those who can afford it, yes you can get a certificate from Microsoft, if you pay them $99. However, it's not simply a case of allowing Linux to boot. The key simply allows a pre-loader to run, which checks for a key with grub, allows grub to run, wchich checks the kernel which in turn checks all the kernel modules, including drivers.

Hence, if you need to change any kernel module, driver or make any changes to the kernel or boot-loader, the certificate will not be valid. (Otherwise someone could just run the malicious code which is being stopped with the linux kernel.)

So, say for example I want to use the accelerometer in my tablet which meant I had to compile a driver, here are my options.
1) As you say, pay $99 to Verisign to get a Microsoft signature, which allows me to sign my patched Linux pre-loader. I can then run my patched version of grub which will allow my patched version of the kernel to run, which will in turn allow the driver I have just compiled to run.

2) I self-sign my new driver, and submit it to whoever maintains my kernel, if it is a significant driver it should be added to the list if accepted keys. I can also give my driver to a friend and he can add my key to his list.

3) (And probably in addition to 2 whilst I wait for the new kernel update allowing my driver) I add my key to the "system firmware". It's not clear how this will work. At best (fingers crossed) I just sign my driver and add that signature into the bios. This relies on the bios allowing my to add my own keys for secure boot.

4) I turn off secure boot. Loose all the security benefits, but have a completely open system, which is a lot easier to use.

Basically, secure boot should be fine. The majority of Linux users shouldn't even notice it. And those who do, should hopefully be the people who are happy enough adding their own keys to sb.

The only issue arises if a motherboard doesn't let you add your own keys. If you can't add your own keys then,the only option is either to pay $99 to sign your own keys, or to disable secure boot entirely.

The other question is whether anyone can sign with Microsoft. Surely the entire point of Microsoft's keys are than those are the people the trust. It's not an overly secure system if Microsoft trust anyone who can find $99.