UEFI malware: How to exploit a false sense of security

When thinking about security we generally take risk into account. It is well known that risk is a composition of likelihood and potential impact.

When it comes to cyberthreats, we in ESET-LATAM Research often see ransomware, banking trojans (especially in my home country – Brazil), botnets or worms. As a consequence, other types of dangerous malware that run inconspicuously might get less of our attention; as is the case with firmware malware or bootkits.

Bootkits run before the OS loads and target OS components in order to modify or subvert their behavior. The fact that bootkits execute early in the system boot gives them the ability to remain stealthy and be persistent, surviving hard drive reformatting or OS reinstallation.

This type of threat targets Basic Input/Output System and Unified Extensible Firmware Interface (BIOS and UEFI) firmware in many different ways, such as firmware flashing, upgrades or vulnerability exploitations, to name but a few. Currently, the very advanced capabilities that make UEFI such an attractive platform also open ways to new vulnerabilities that didn’t exist in the age of the more rigidly structured BIOS. For instance, the ability to run custom executable modules makes it possible to create malware that would be launched by UEFI before any anti-malware solution, or the OS itself, is able to start up.

These characterists make a bootkit the apple of advanced threats’ eye. Despite the fact that bootkits concepts have been implemented for many years, as long ago as 1986 or earlier, advances in cyberthreats skill pose new challenges and concerns for computer users.

Why worrying about bootkits?

When thinking about security we generally take risk into account. It is well known that risk is a composition of likelihood and potential impact, so while a bootkit’s impact is undoubtedly hefty, what can be said about the likelihood of coming across such threat?

Trying to answer this question, we need to think about two issues: on the one hand, we have to identify possible actors and scenarios that may benefit from bootkits and ponder whether they will become more or less common in the future; on the other hand, we must assess our capacity to detect these threats, otherwise “likelihood” won’t go beyond a hunch.

To identify actors and scenarios, let’s take a look at the past to see the most notable bootkit cases. Looking at a timeline, it is clear that the threat has become increasingly frequent.

Mebromi, known to be the first bookit in the wild, comprises a BIOS rootkit, MBR rootkit, a kernel mode rootkit, a PE file infector and a Trojan downloader, executed in such a way that the compromised system requests external content — which could be virtually any malware — every time the system boots. To accomplish the attack, Mebromi escalates privilege by loading its code in kernel mode to gain access to the BIOS.

Interestingly, as of 2014, other bootkits spotted in the wild were often closely related to governmental hacking (directly or indirectly).

In the NSA ANT catalog revelations (2014), DEITYBOUNCE was unveiled — a software application that provided “persistence on Dell PowerEdge servers by exploiting the motherboard BIOS and utilizing System Management Mode (SMM) to gain periodic execution while the Operating System loads”. The usage was similar to that of Mebromi, which again means downloading payloads and running them on the system during the boot process.

In 2015, it was the time for “HT rkloader”, exposed after the Hacking Team leak. Unlike the NSA, the Hacking Team is not a governmental agency; nevertheless, it sells offensive intrusion and surveillance capabilities to different governments. In particular, “HT rkloader” was the first case of a truly malicious UEFI Rootkit being exposed, although no evidence of its use in the wild was ever brought forward to this day.

Unsurprisingly, the leak of the (NSA) Equation Group’s tools by the Shadow Brokers brought more bootkits to light. The catalogue of leaked tools contained some “implants”, namely BANANABALLOT, “a BIOS module associated with an implant (likely BANANAGLEE)”, and JETPLOW, “a firmware persistence implant for Cisco ASA and PIX devices that persists BANANAGLEE”.

Finally, this very year, CIA’s Vault7 revelations disclosed that governmental tools also targeted firmware. The attack exploited an S3BootScript vulnerability (patched in 2015) in order to install UEFI components on Apple systems.

These are just some examples of bootkits caught in the wild that we happen to know of, mainly due to major (and rare) leak incidents. Nevertheless, it shows the appetite that leading actors have for advanced attacks targeting firmware.

Still, you might ask yourself how it can interfere in our “normal lives”. Here we have to take a look to the past again and realize that we stand on treacherous ground. The WannaCryptor (aka WannaCry) pandemic is an example of what can go wrong when advanced hacking tools fall into the wrong hands.

Furthermore, we have seen many cases of attacks aiming at the supply chain, so that devices might get infected even before they are first used by their eventual owners. An attack targeting the firmware supply chain could possibly affect many users, while staying under the radar for a long period of time.

Therefore, it is highly important to have the capability to detect stealth infections, which takes us to the second aspect of this post.

Our capabilities to defend

Nothing is worse or more dangerous than a false sense of security. Snowden’s leaks and the aforementioned cases are wake-up calls to the whole security industry about malware in firmware.

As of 27 January 2016, the day of VirusTotal’s new feature announcement, it is possible to extract and upload UEFI Portable Executables for analysis and these contain “precisely executable code that could potentially be a source of badness”, as the post’s author observed.

This is a great contribution to the security of cyberspace as a whole, since a simple and well-known interface for (firmware) malware analysis has been made available. Nonetheless, its main drawback is the procedure for capturing the firmware images before uploading them for analysis.

VirusTotal suggests some tools capable of doing this task; they are, however, mostly intended for computer experts rather than for the non-expert. Not only that, the suggested tools are explicitly developed for test environments for reasons that range from the broadening of the attack surface to fortuitous errors that may hamper the operating system:

Another option is choosing a security solution that adds an additional protection layer against UEFI bootkits. The advantage in this case is that you could scan the UEFI-enabled firmware without resorting to additional tools that may pose risks to the system. Therefore, it should be much more user-friendly for regular users to scan their computer for stealth malware in firmware.

Findings about highly advanced threats in the wild that target firmware are certainly worrisome, especially because they run in the system concealed. On top of that, detecting this type of malware (in the wild) is difficult and arduous (and barely possible not so long ago), possibly instilling a false sense of security in many of its victims.

But every cloud has a silver lining. This never-ending game of cat and mouse has enabled us to protect ourselves better.