What You Don’t Know about Firmware Might Get You ∅wn3d

Making the first move to effective platform security takes a stronger understanding of threats to that security.

Technical marketing for firmware is an unusual job. When done properly, initializing the platform and launching an operating system should be an invisible process. Getting developers to notice something that should be invisible is tricky. It’s a lot like plumbing: people don’t appreciate how important it is, or how hard it is to do properly… until something goes wrong.

Unfortunately, there is an audience that has been paying more attention to firmware—computer security researchers —which is a fancy way of saying “hackers.” A firmware attack may try to inject “stealthy compromise” code, bypass platform security features, or perform a denial of service by halting the boot process. Attacks operating at the firmware level can be difficult to detect, compromise software root-of-trust, and have the potential to persist across bare-metal recovery.

Standards and Best Practices

There are a variety of organizations developing guidelines for firmware. Most system firmware follows the Unified Extensible Firmware Interface (UEFI), which is a successor to the legacy 16-bit Basic Input/Output System (BIOS) popularized by the IBM PC/AT and its various clones. The UEFI Forum defines interfaces between the operating system and platform firmware, which include various security mechanisms. This includes using UEFI Secure Boot to verify signed firmware components, using a Trusted Platform Module (TPM) to ensure platform integrity using security measurements, and delivering firmware updates via signed UEFI capsules.

The National Institute of Standards and Technology (NIST), part of the U.S. Department of Commerce, has created a series of “Special Publications” specifically for Cybersecurity (SP 800). A number of these directly address firmware security, including “BIOS Protection Guidelines” (SP 800-147) and “Platform Firmware Resiliency Guidelines” (SP 800-193). Microsoft provides a “Standards for a highly secure Windows 10 device” description. Developers use these guidelines to design new platforms, but IT professionals can also use these documents to create purchasing requirements based on best practices.

Common Firmware Attacks

Attacks against platform firmware fall into three general categories:

  1. Malicious code attempts to modify the operating system loader
  2. Malicious code attempts to run from add-in components
  3. Malicious code attempts to directly modify the platform firmware

The first example, often referred to as a “bootkit” or “rootkit” attack, attempts to circumvent operating system protections by executing code during the hand-off from firmware. The most common vector is a modified boot media (SATA, SSD, NVMe, USB, etc.). The second attack is similar but uses modified Option ROMs on add-in peripherals (RAID, Network Card, Thunderbolt, etc.) to execute early in the boot process.

UEFI Secure Boot is designed to prevent the first two attacks exampled above by requiring that bootloaders and Option ROMs be signed against a known entity. This is typically the UEFI Certificate Authority (UEFI CA), but it can also be an operating system vendor or self-signed binaries for closed systems.

Attempts to insert code directly into platform firmware typically attack non-volatile storage on the Serial Peripheral Interface (SPI) bus. These attacks can be prevented by ensuring the SPI region is locked at runtime, which prevents programs from overwriting firmware contents and using signed capsule updates to prevent attackers from tampering with the manufacturer’s firmware image. A TPM can also be used to detect tampering in all three cases, based on changes in measurements made during boot. Manufacturers also offer mechanisms like Intel® Boot Guard to preserve hardware root-of-trust.

Note that attacks may employ more than one method, such as a bootkit attempting to insert malicious code into the platform firmware during the bootloader phase. A comprehensive approach to firmware security employs multiple defensive methods.

Detecting Known Issues

CHIPSEC is an open source framework for analyzing platform security, with a focus on hardware and firmware configuration. CHIPSEC is a cross-platform security test suite with tools for forensics and low-level interface access. The utility detects issues based on common firmware configuration problems and publically available security research. CHIPSEC can also be used to generate a “whitelist” based on verified firmware or to create  a “blacklist” to scan platforms for known malicious components.

While CHIPSEC isn’t designed to be deployed on production systems, it is ideal for testing systems prior to deployment or during forensic analysis. New systems and platform updates can be scanned as part of pre-deployment testing or for periodic risk assessment.

Knowing is Half the Battle

Most of the work I do is working with other firmware developers to make sure they understand current capabilities and trends, but that work may take months or years to hit the market. The people on the front lines of computer security need some understanding of what they can do today to help secure their systems. Fortunately, there are practical methods to prevent a number of common attacks, platform security features to consider when purchasing new systems, and methods for detecting known firmware issues.

No computer system can be completely secure, but understanding potential threats is the first step to proper platform security. A better understanding of firmware and platform root-of-trust helps IT departments and penetration testing teams improve customer security.

In other words, you should know how the pipes work… just in case they break.


Brian Richardson is Technical Evangelist & Senior Technical Marketing Engineer at Intel.

He has spent most of his career as a “BIOS guy,” working on the firmware that quietly boots billions of computers. He has focused on the industry transition to the Unified Extensible Firmware Interface (UEFI) and supporting the TianoCore open source community. Richardson has presented at various conferences and seminars, including Embedded Systems Conference, and is scheduled as a trainer for Black Hat USA 2018. When he’s not talking about firmware at conferences, Richardson takes photos of his travels and procrastinates on various video projects.

Twitter: @intel_brian

Blog: https://software.intel.com/en-us/meet-the-developers/evangelists/team/brian-richardson.


Share and Enjoy:
  • Digg
  • Sphinn
  • del.icio.us
  • Facebook
  • Mixx
  • Google
  • TwitThis


Extension Media websites place cookies on your device to give you the best user experience. By using our websites, you agree to placement of these cookies and to our Privacy Policy. Please click here to accept.