Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Attacks/Breaches

5/5/2020
10:00 AM
Burzin Daruwala
Burzin Daruwala
Commentary
Connect Directly
LinkedIn
RSS
E-Mail vvv
50%
50%

Designing Firmware Resilience for 3 Top Attack Vectors

Firmware has become an increasingly prevalent target for hackers. Here's how to stop them.

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.

Leakage
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.

Misuse 
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.

Hardening Firmware
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.

Related Content:

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."

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 ... View Full Bio
 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 5/28/2020
GDPR Enforcement Loosens Amid Pandemic
Seth Rosenblatt, Contributing Writer,  5/27/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
How Cybersecurity Incident Response Programs Work (and Why Some Don't)
This Tech Digest takes a look at the vital role cybersecurity incident response (IR) plays in managing cyber-risk within organizations. Download the Tech Digest today to find out how well-planned IR programs can detect intrusions, contain breaches, and help an organization restore normal operations.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-4306
PUBLISHED: 2020-05-29
IBM Planning Analytics Local 2.0.0 through 2.0.9 is vulnerable to cross-site scripting. This vulnerability allows users to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session. IBM X-Force ID: ...
CVE-2020-4352
PUBLISHED: 2020-05-29
IBM MQ on HPE NonStop 8.0.4 and 8.1.0 is vulnerable to a privilege escalation attack when running in restricted mode. IBM X-Force ID: 178427.
CVE-2020-4490
PUBLISHED: 2020-05-29
IBM Business Automation Workflow 18 and 19, and IBM Business Process Manager 8.0, 8.5, and 8.6 could allow a remote attacker to bypass security restrictions, caused by a reverse tabnabbing flaw. An attacker could exploit this vulnerability and redirect a vitcim to a phishing site. IBM X-Force ID: 1...
CVE-2020-5572
PUBLISHED: 2020-05-29
Android App 'Mailwise for Android' 1.0.0 to 1.0.1 allows an attacker to obtain credential information registered in the product via unspecified vectors.
CVE-2020-5573
PUBLISHED: 2020-05-29
Android App 'kintone mobile for Android' 1.0.0 to 2.5 allows an attacker to obtain credential information registered in the product via unspecified vectors.