Malicious malware in BIOS again?

I say “again” because we have had BIOS malware before the famous CIH (Chernobyl) virus from 1998. Sophos recount

And the last time the Chernobyl virus activated (April 26th) it caused $250mil dollars of damage in 1999 for South Korea alone.

Even Mac’s can have BIOS infections as from Trendmicro Blog post

Intel and MITRE have been collaborating on the Secure boot BIOS bypass :

From MITRE:

https://cansecwest.com/slides/2014/AllYourBoot_csw14-mitre-final.pdf

2 attacks specifically would allow a malware process towrite to the secure boot BIOS area

recommendations:

Protect Image Verification Policies

– Don’t store them in places writeable by malware (like RUNTIME_ACCESS UEFI Variables)
– Use Pcd (Platform Configuration Database) for the platform specific policies rather than UEFI variables

From Intel:

http://www.c7zero.info/stuff/BIOSandSecureBootAttacksUncovered_eko10.pdf

Intel seemed to have a few more graphical representations where a malicios program would write to the UEFI DXE Core area:

which is located in the Secure Boot section of Windows 8 architecture.

you can see the Secure Boot being disabled, and UEFI being installed.

Unfortunately we also have to discuss Access to System Management Mode

So now we have DMA (Direct Memory Access) access to SMRAM (System Management Random Access Memory)

A better explanation of what SMRAM is: https://cansecwest.com/csw09/csw09-duflot.pdf

A 16-bit mode.

• Used for motherboard control and power management, for instance:

• Thermal management.

• Power management on laptops (sometimes called by ACPI).

Can only be entered when the CPU receives a so-called hardware

System Management Interrupt (SMI).

• SMIs are generated by the chipset (Northbridge).

Here is an image of the computer in a different manner:

You can see with that image – it is obvious that SMRAM is needed by certain functions of the PC (like going to sleep for the monitor)

This is an interesting note from the cansecwest document:

The operating system does not even notice when it is being interrupted by management software running in SMM.

So the end result is that if the D_LCK bit is changed, rootkits and other malicious software can infect the machine(cansecwest).

Intel document has the following vulnerability:

when TS is not locked a reset vector could insert malicious software.

Apparently Signed kernels also can run into problems.

So what to do?

Recommendations by Intel:

Best Practices
• Enable HW protections for the BIOS firmware and SMRAM
• Have a recovery mechanism for BIOS firmware and essential configuration
• Minimize UEFI variables attack surface
• White-list UEFI variables in OS kernel or in SetVariable SMI handler
• Don’t store sensitive data in SPI flash
• Consider all NVRAM contents malicious when handling them in FW
• Thoroughly validate input to SMI handlers from runtime OS
• Assume all input to SMI handlers malicious (variables, CMOS memory, ACPI
tables, ACPI NVS, CPU GP registers, HW registers..)
• Sign firmware updates (UEFI capsules on reset/S3)
• Use secure defaults for static and dynamic Pcd settings
• Sanitize passwords/keys from DRAM
• Frequently sync with edk/UDK

The unfortunate standard “reinstall the Operating System” or recover from backup will not solve this. As it is a BIOS backdoor.

What you have to do is flash the BIOS then restore from backup(reinstall OS). Then after the BIOS is flashed institute a password for BIOS.

Like this: