Here's How to Protect Firmware Against Cyberattacks

Back to Blog
Here’s How to Protect Firmware Against Cyberattack

protect firmware

In recent years, we have seen a significant rise in attacks on firmware.  A survey conducted by Microsoft concluded that in the last four years, there has been a 500% increase in reported firmware attacks, and 83% of surveyed businesses reported a firmware attack on their network in the last two years. 

Although increasing, firmware attacks are nothing new. They’ve been around in one form or another since the CIH computer virus first appeared on Microsoft systems in 1998. Now, over twenty years later, attacks on firmware are one of the latest growing threats to embedded systems. 

So, why are firmware attacks growing? And what can be done to protect against the threat they pose?

Firmware-level attacks target highly-sensitive information

Firmware attacks are aimed at hardcoded, read-only software that lives just below the operating system on the software stack. Part of the reason firmware attacks are increasing is because traditional cybersecurity defense mechanisms, like antivirus software and firewalls, don’t have access to the firmware. This means successful firmware attacks can fly under the radar and go largely undetected, potentially for years. 

In addition, highly sensitive and valuable information is stored in the firmware—things like credentials and encryption keys. Getting their hands on this type of information gives attackers the ability to escalate privileges to take over a system and exfiltrate confidential data.

Given this, it’s no surprise that cyberattackers are focusing more on the firmware. What may be surprising to some is that, in the same survey by Microsoft, they found that less than one third of organizations have set aside budget for protecting firmware and preventing these types of attacks. The bottom line here is that firmware is extremely vulnerable, but most organizations aren’t doing enough to protect it from attacks.

Unpatched firmware vulnerabilities are equivalent to leaving your key under the mat

There are generally two methods that a cyberattacker can use to gain access to firmware. The first is through the physical tampering of a system’s hardware. This can be done in the supply chain by delivering malicious firmware to a vendor, which is what we saw recently in the infamous SolarWinds attack

Alternatively, if the attacker has physical access to the device, like in an “evil maid” attack, they can inject malicious code into the firmware directly. Luckily, physical tampering attacks are much more difficult to execute and thus, more uncommon. 

On the other hand, the second method of firmware attacks uses compromised software. This type of attack is much easier to execute since it doesn’t require physical access. In this case, the attacker injects malware via a vulnerability in its code or by compromising vulnerable drivers to escalate privileges. Although firmware is hardcoded, it’s still a form of software and thus vulnerable to the exploitation of vulnerabilities, just like any other piece of complex software. However, being hardcoded makes it more difficult to patch and often results in major system downtime.

Protecting the firmware with hardware-based defense-in-depth

So how do you protect against both hardware and software-based firmware attacks?

When it comes to hardware-based attacks, having a defense-in-depth approach to cybersecurity is essential. Not only do you want to protect your supply chain, you also want to employ tamper resistance measures on your embedded systems to deter physical attacks. On top of your tamper protection, you want to layer additional defense mechanisms—starting with a secure boot and immediately followed by an oversight system, like CoreGuard®. On top of that, you may also want to layer a compartmentalization solution, encryption, and/or kernel and application-level cybersecurity solutions.  

In the case of the more common, software-based firmware attacks, an oversight system is essential, again. On the cybersecurity stack, an oversight system operates below the firmware layer—unlike intrusion detection solutions—to immunize processors against the exploitation of vulnerabilities in any layer of the software stack. This means if an attacker attempts to exploit a vulnerability in the firmware (or any other layer of software) to escalate privileges or inject malicious code, the CoreGuard oversight system would stop it before any damage could be done. 

CoreGuard can even stop the exploitation of zero-day vulnerabilities because it’s designed to stop entire classes of attack, not specific known threats. That means if a buffer overflow vulnerability is discovered in the firmware of a system, today, tomorrow, or 10 years from now, CoreGuard would stop it. 

CoreGuard comes with a base set of micropolicies that stop the most common and severe types of attacks that plague every system, and piece of software, regardless of industry or application, including buffer overflow and code injection attacks. On top of the base set, you can layer on additional security defenses, like protection against data exfiltration and data modification attacks, or functional safety for critical systems. 

Now, let’s take a look at a real-life firmware attack and discuss how CoreGuard could have stopped it. 

In September 2011, a malware, called Duqu, exploited a zero-day vulnerability in the Microsoft Windows firmware. Duqu was found to be nearly identical to the infamous Stuxnet worm that temporarily crippled the Iranian nuclear program two years prior. 

Coincidentally, the Stuxnet attack was the reason Dover’s CoreGuard technology was created in the first place. In 2010, the DARPA-funded CRASH program was created with the purpose of finding a solution that could defend against cyberattacks, like Stuxnet, that come across the network.

Network-based attacks almost primarily start out by exploiting a simple vulnerability in the software, like a buffer overflow. Our Heap micropolicy protects memory on the heap by assigning a color to the buffer where the data resides, as well as the pointer to that buffer. The micropolicy dictates that an instruction cannot write data to a buffer with a color that doesn’t match the color of the pointer to the buffer. If an attacker tries to overflow a buffer and write data to a non-matching buffer vs the pointer, CoreGuard issues a violation and stops it from executing before any damage can be done.

To learn more about how CoreGuard can protect against the exploitation of vulnerabilities in any layer of the softwares stack, including the firmware, download The Cybersecurity Stack: Defending Embedded Systems with a Defense-in-Depth Approach.

Share This Post

More from Dover

PublishedOctober 11, 2021

We talk about buffer overflows a lot. So much so, it almost seems silly to be writing another article dedicated to this software vulnerability.  But, it’s worth driving the point home: buffer overflows are one of the most dangerous software...

Security CoreGuard Safety Privacy Defense-in-Depth