Addressing the growing threat of firmware attacks on enterprise edge computing platforms - Embedded.com

Addressing the growing threat of firmware attacks on enterprise edge computing platforms

The threat landscape facing edge-computing systems in enterprise-level applications is dire. As this threat environment evolves, defending against these intrusions has become increasingly urgent.

Recent high-profile hacks into mission-critical edge computing systems in enterprise-level applications have shown that hackers are growing smarter and more sophisticated in their attempts to avoid detection. With IT security and visibility efforts still largely focused higher in the stack at the application layer, bad actors are seeking to breach systems further down the stack at the firmware level. As this threat environment evolves, defending against these intrusions has become increasingly urgent, though the specifics of how exactly to do so remain frequently overlooked. Prior to proposing solutions for firmware intrusions however, it is important to understand why and how they are happening and what the immediate and long term goals of the attackers are.

Ongoing Threat Environment Facing Computing Platforms

Edge computing platforms in the enterprise are a prime target for cybercriminals. Enterprises have grown wise to their vulnerability however and introduced a bevy of security software to prevent and detect attacks. A significant percentage of these solutions operate only on the application level at the top of the stack. Clever hackers have realized that if they enter the system beneath the application layer at the firmware level, they can avoid detection from software and OS security.

“…fixing zero-day hacks in firmware or hardware can be incredibly time-consuming, leaving the system in question vulnerable for longer than a software breach would.”

Because it takes a higher degree of difficulty to hack the firmware, it is not as well-monitored and defensed as the higher layers in the stack. Firmware, and to an even greater degree hardware, is also not as easily patched or updated as software and is much more costly. Once inside the firmware, hackers can disable remote firmware updates, making it impossible to fix remotely and thus requiring the service of a technician with physical access to the firmware, often requiring a complete shutdown and an on-site visit that can be quite costly for large-scale deployments. This process means fixing zero-day hacks in firmware or hardware can be incredibly time-consuming, leaving the system in question vulnerable for longer than a software breach would. These factors have contributed to a rise in firmware attack frequency both from state-sponsored actors and from smaller and less well-resourced but still dangerous private groups.

Goals of Firmware Attacks

A lack of proportional defenses and visibility tools, increased difficulty in patching, and higher value data and damages each have contributed to a spike in hackers’ firmware attacks. The National Institute of Standards and Technology’s (NIST) National Vulnerability Database (NVD) shows that attacks on firmware have risen by 500% since 2018, and survey data from a new Microsoft report show that 83% of enterprise IT decision-makers have had their systems hit with a firmware attack in the last two years but that only 29% of the average security budget is dedicated to protecting the firmware level. This is unsustainable: a report from Gartner predicted that “by 2022, 70% of organizations that do not have a firmware upgrade plan in place will be breached due to a firmware vulnerability.”

“…it’s pretty much impossible to spot firmware or hardware malware from the software stack.”

While an increased spend on firmware protection would represent an obvious step in the right direction for nearly any organization, education about the natures and goals of the threats facing firmware is another prudent exercise. What are attackers trying to do?

To answer the first question, there are a few goals that hackers will attempt to achieve when executing a firmware attack. The first involves establishing persistency in order to survive a system reboot by tying malware to the hardware of a given device or system rather than its software. In many cases, intrusions that have gained persistency can even survive OS format and restore attempts. Stealth is the next objective, as it’s pretty much impossible to spot firmware or hardware malware from the software stack.

From this position, the hackers have essentially established the ultimate platform demolition vector. Most firmware or hardware malware code is OS agnostic, so with stealth and privilege secured, attackers have the ability to totally corrupt a platform to the point that physical replacements are required. Destruction may not be the final goal however, as attackers can instead leverage the threat of destruction to coerce ransom payment or sell the data on the dark web. Several high-profile breaches in recent years have taken this shape, as rather than try to seize, destroy, or leverage data, hackers will simply release it to the public, as was the case in the 2018 Starwood hack, the 2019 Facebook hack, and the 2021 LinkedIn breach.

How do Firmware Attacks Work?

There are a variety of vectors firmware attacks can choose because firmware is relied on by nearly every component in a computing system. System boot firmware is the first thing that loads and remains in memory since startup, system management mode (SMM) firmware is used during runtime to allow independent low-level actions, baseboard management controllers (BMC) enable out-of-band server management, and network cards (RDMA), USBs, HDDs and SSDs all contain firmware. How do hackers breach these attack surfaces? Typically through one of a few ways, either from the software layer down, from the hardware level up, directly through the network, or via physical access to the system.

Firmware attacks that begin at the software level may gain entry through any number of common strategies like phishing and progress downward to the firmware level by exploiting a vulnerability like the failure of a firmware update agent to require signed updates. Another approach is using legitimate audit tools like CHIPSEC to map firmware problems which can then be exploited.

Whatever the vector may be … the fact of the matter is that the threat landscape facing edge-computing systems in enterprise-level applications is dire.

Going from the hardware up takes the opposite track. One notable variation involves compromising devices along the supply chain, either pre- or post-deployment. This approach has gained momentum in recent years because it’s extremely difficult to keep track of the entire supply chain and validate every component to the full security extent. Without adequate tracking, visibility, and validation, vulnerabilities are bound to arise. Other hardware approaches involve corrupting a USB device that is then inserted physically or digitally into a system endpoint. An “evil maid” attack is another tactic. This method requires physical access to a device so an attacker can attack from the software, firmware, and hardware levels to compromise the system.

Another strategy is to attack directly via the system’s network when firmware components are directly connected to the internet, often because vulnerable components are configured to allow out-of-band updates. Whatever the vector may be, and however simple or sophisticated the attack may appear, the fact of the matter is that the threat landscape facing edge-computing systems in enterprise-level applications is dire. IoT infrastructure developers and IT security are likely wondering where to start. The answer is at boot.

Security must start with a Hardware Root of Trust

In order to secure a system against ever more ambitious and creative attackers, a Root of Trust (RoT) is necessary as an entity against which to check every layer of the stack from hardware boot to firmware load, OS runtime up until the running applications, throughout the entire stack. Under this protocol, every hardware and firmware component must be authenticated and authorized through a check against an absolutely trustworthy RoT. The only way for a computing component to be trustworthy in this way is for it to be immutable, a condition that eliminates any sort of software solution as an option. A hardware solution is therefore necessitated, often involving storing crypto keys that tie directly to the device owner who provisioned the keys in the silicon of a machine rather than in its software in an isolated implementation. Novel solutions take things a step further by offloading the RoT to a separate security processing unit (SPU) chip entirely to enable remote attestation for all motherboard components but also any peripheral device connected to the system.

A dedicated security processor creates a trust anchor that can’t be accessed from the CPU.

Trusted Platform Modules (TPMs) sit separate from a computing system’s processor and function as a sort of black box that attackers will struggle to access or even see into, assigned to hold valuable assets like keys, credentials, and sensitive data while owning only low-level operations. Unlike processor-based systems that are susceptible to trial-and-error attacks where hackers try various techniques in order to glean information about a system’s defenses, TPMs provide very little visibility to would-be intruders. TPMs are not quite secure enough however and they have proven complicated to use.

That said, the idea of an isolated implementation is on the right track. A dedicated security processor creates a trust anchor that can’t be accessed from the CPU. The chain of trust can be extended from there. The security defenses remain isolated from the attackers thereby creating an architectural advantage for security applications that prevents attackers from disabling or evading defenses. By generating keys and encrypted data in the hardware, hackers can’t access them from the software.

OCP Standardization and FPGA Flexibility

The Open Compute Project advocates for the hardware RoT in the open standard version 1.0 of their RoT specification, something industry movers and shakers believe is pivotal for enterprise data center security as well as for hyperscalers. Until now, hyperscalers have had to build their own custom solutions for firmware protection but with the standardization of RoTs, we can now expect this technology to be available for all data centers. It may even become available for consumer PCs eventually, as OCP-compliant RoTs will even prevent attacks involving physical Flash component replacement.

This formal specification is doubly important: in addition to protecting against firmware persistency attacks, it also helps firmware developers understand how to develop more secure firmware with fewer vulnerabilities, though these learnings can be difficult to implement.

The issue with establishing a RoT on a system’s hardware, or on an isolated security processor, is that by design they are very difficult to access or affect. This makes them more secure against bad actors but leaves them less flexible when new vulnerabilities are found or new functions are required. This is where field-programmable gate arrays (FPGAs) can enter the picture. An FPGA is a semiconductor device separate from the processor that is configurable after manufacturing, which this allows programmers to adjust how components of their larger system are structured without sizable financial or temporal burdens that would otherwise be necessary.

Xilinx is a well-known FPGA manufacturer with whom Kameleon has partnered to create a Proactive Security Processing Unit (ProSPU). This ProSPU works differently than existing passive solutions in that it protects the system both at root and through run-time, a feature enabled by the Xilinx FPGA chips that meet OCP standards for secure boot, remote attestation, and common threats scope.

Conclusion

All told, what edge platform owners at the enterprise and industrial level need to realize is that their systems are very much vulnerable – especially at the firmware level. Enterprises can no longer afford to rely on traditional protection methods. Attacks targeting this level are escalating in severity and sophistication so what is needed is a hardware root of trust which can be used to authenticate and authorize access to and alteration of any stack level and is flexible enough to adapt to new vulnerabilities and enable security applications to do their job. This RoT needs to be able to extend from secure boot to runtime – detecting and preventing incidents and breaches without compromising performance. Senior executives and IT decision-makers must be proactive about security for servers and computing systems by prioritizing spending to protect firmware and hardware levels.  


Jorge Myszne, a veteran semiconductor and cybersecurity expert and the co-founder and CEO of Kameleon Security, a semiconductor startup developing advanced hardware cybersecurity solutions for computing systems that start with the Root of Trust.

Related Contents:

For more Embedded, subscribe to Embedded’s weekly email newsletter.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.