Keep up with the latest cybersecurity threats, newly discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.
Designing Firmware Resilience for 3 Top Attack Vectors
Firmware has become an increasingly prevalent target for hackers. Here's how to stop them.
May 5, 2020
6 Min Read
Smart hackers always want to take the least cumbersome route. Historically, that meant targeting vulnerabilities in software, and in the early 2000s, the software industry began focusing on security-conscious designs to reduce the attack surface of their products. Software security rapidly improved to the point that cybercriminals were forced to look elsewhere for productive entry points. This led them further down the stack to firmware — a natural transition given the fact that anti-malware services can't easily access and scan firmware like they can scan disk storage or memory. Because firmware is essentially low-level software that only interacts with hardware components, early firmware hackers could modify the same old bag of tricks on firmware they traditionally used to attack software.
About 10 years ago, there was little being done on the firmware security front because it hadn't yet become a target. As attackers began targeting vectors further down the stack, this had to change — and fast. The industry made tremendous strides in securing firmware. However, in our massive digital economy with billions of active devices across the globe, there will always be room for improvement. Let's take a look at the three major attack vectors and how to build more resilient firmware against each:
Bypass and Privilege Escalation
Using the bypass approach, attackers look for ways to utilize firmware to circumvent authentication, prevention, and detection mechanisms. One of the first examples took place back in 2006, when researcher Luic Duflot and team successfully developed a proof of concept (PoC) that demonstrated they could coopt System Management Mode (SMM) to elude security protections at the operating system (OS) level. Then in 2008, Jonathan Brossard's presentation at DEF CON showcased a PoC attack that instrumented the BIOS keyboard buffer to bypass preboot authentication passwords. While these findings have been mitigated for some time, insights from discoveries like these have helped researchers continue to harden firmware security across the industry.
Generally speaking, attackers tend to use the bypass method to achieve privilege escalations. There are multiple privilege levels for any computer system, starting with basic access to everyday applications enabling file navigation, Internet browsing, and email to the level where the OS, drivers, and kernels run all the way down to firmware, and then the hardware level. Any attack that enables a hacker to traverse from one mode to another is an escalation of privilege. The higher level they achieve, the more access and power they have.
So, how can you better deter bypass attacks and privilege escalation? Approach firmware security with a systems view. OEMs, customers, and the broader industry should prioritize hardened firmware and follow the latest firmware security guidelines. That means:
Reduce your attack surface by minimizing the number of ways that firmware interfaces with the outside world.
Request and store only as much information as you need.
Avoid storing particularly sensitive information.
Test for potential vulnerabilities, especially in code that accepts external input, processes sensitive information, or executes complex security operations.
Consistently revisit existing mitigations to eradicate known vulnerabilities while making your firmware more resistant to attack.
Understand that even if you have performed a thorough security evaluation, your product might still be susceptible to new attacks. For this exact reason, building in redundant security features is well worth the investment.
Make sure that there is a clear path for updates to ensure that even if vulnerabilities in your product surface after shipment. Since the threat landscape is continually evolving, this will give you the means to deliver mitigations and updates.
This threat category includes any attack wherein the perpetrator's intention is to expose information, such as classified keys and sensitive or secret information. To accomplish this, hackers can attempt to leverage a variety of methods to exploit existing hardware behavior. Stored data in the cache of modern processors can be a target for efforts to gain information from hardware components. For example, these cache attacks in 2016 enabled bulk key recover on the cloud, and there were instances of data leakage in USB flash drives back in 2010.
To help prevent leakage attack vectors, leverage security assurance processes to identify and mitigate potential firmware vulnerabilities before product releases. Then, communicate and influence the coordinated administration of proper mitigations and try to examine the possible scenarios in which your sensitive data might be leaked via firmware and focus on securing those avenues. You can also write application code to take advantage of certain hardware capabilities that help to mitigate leakage. When used properly, hardware hooks and features can be immensely effective at reducing the attack surface, minimizing the window of attack and shifting the target to the hardware itself, which in many cases can be much harder to break.
One attack methodology people often overlook is misuse, or whenever hackers corrupt legitimate features by leveraging them for unintended and dangerous purposes and with no true security flaws.
If unknown code is allowed to execute in your firmware, create a plan to mitigate code that could potentially be malicious. For example, isolate trustlets such that, even if one trusted process ends up being malicious, it will be harder to access the entire execution environment. Put yourself in the adversary's shoes and think through surprising, unpredictable ways they might leverage legitimate firmware features for illegitimate means — and then work to resolve those potential issues. Putting a security feature in place may not be enough. Provide detailed usage guidelines for each of these features, regularly update those guidelines and promote their adoption by helping users better understand the benefits of adhering to them and the risks of failing to do so.
To help improve resiliency against attackers that target firmware specifically:
Develop high-quality firmware code and focus on raising the security assurance bar. But avoid evaluating your firmware in isolation. Keep the entire platform and environment in mind when planning security assurance processes.
Pay special attention to published research that affects your firmware and try to stay one step ahead by proactively assessing for potential vulnerabilities in these areas. Assume that further advancements will be made by both researchers and malicious actors based on new research.
Study the known underlying hardware vulnerabilities to which your firmware might be susceptible and, where possible, include hardware mitigations in your security assurance model.
Integrate automated static analysis tools into your commit and build processes to proactively identify and resolve vulnerabilities.
Take a holistic systems approach to firmware security. Attackers usually go after a specific goal, such as circumventing secure boot, breaking out of isolation, and escalating privilege. Take the same approach when evaluating your firmware for potential weak spots.
Establish a well-defined, strategic update/patch path and make it readily available to customers. Analyze any newly reported vulnerabilities, deploy mitigations, and promote user awareness as quickly as possible.
Check out The Edge, Dark Reading's new section for features, threat data, and in-depth perspectives. Today's featured story: "5 Ways to Prove Security's Worth in the Age of COVID-19."
About the Author(s)
Senior Offensive Security Researcher Manager, Intel Corp.
Burzin Daruwala is a manager and founding member of the Intel Product Assurance and Security (IPAS) OSR Client Security research team, where he helps develop and guide the team's technical strategy and focus areas. He has 12 years of experience researching vulnerabilities across a range of different products and technologies. Prior to vulnerability research, Burzin worked for eight years as a research scientist at Intel Labs, with a particular focus on pathfinding new trusted platform technologies.
You May Also Like
Your Everywhere Security guide: Four steps to stop cyberattacksFeb 27, 2024
Your Everywhere Security Guide: 4 Steps to Stop CyberattacksFeb 27, 2024
API Security: Protecting Your Application's Attack SurfaceFeb 29, 2024
API Security: Protecting Your Application's Attack SurfaceFeb 29, 2024
Securing the Software Development Life Cycle from Start to FinishMar 06, 2024