“Permanently” Bricking
One of my fears is the attacker who is motivated to destroy infrastructure rather than lay low, hide, and steal. Destroying a computer requires a moderate amount of skill compared to the complexities of persisting and evasion involved with non-destructive style attacks. A while back I set out to understand how an attack might be constructed that was focused on bricking the computer, or rendering it useless. I stumbled upon some previously unreleased research conducted by the Eclypsium team some time ago that analyzed how the SPI flash was configured on various models of computers. This was the catalyst for me to unpack some of the vulnerabilities and misconfigurations that lead to the ability to potentially destroy a computer, and a great opportunity to update the research for this talk.
I used air quotes “permanent” deliberately. There are many different configuration settings and conditions that dictate just how unusable a remote attacker could render a given computer. For instance, if you can rebuild the SPI flash on your computer or server, you may recover from the attack. However, in many cases, the user or administrator may not have the means to recover the SPI flash, which means an attacker intent on disruption is likely to be widely successful.
I presented both the existing and new research conducted by the Eclypsium research team at the Shmoocon 2023 conference in Washington, DC.
You can find the video of the presentation here (Please note the audio quality is not the best in this recording and the video is a recording of the live stream from the event).
The presentation walks you through the following:
- Why UEFI firmware is so important to the system and a target for attackers
- The SPI flash layout, some existing protections, and their limitations
- Examples of how attackers could carry out attacks that could “permanently” brick the computer (without too many details so as to not give attackers an “easy button”)
- Research on how vulnerable UEFI firmware is today and the state of security and misconfiguration found in the wild
- The security challenges we face in the supply chain for all PCs, servers, and laptops
After the presentation, I spent some time reflecting on the supply chain issues with a scope larger than just UEFI. In a recent webcast, I communicated the supply chain attack surface as follows:
A few takeaways from this slide:
- The closer we are to the hardware supply chain the more difficult it is to detect and remediate supply chain security issues
- Supply chain security issues that come along with the pre-installed software on your computers often go unnoticed (largely because you bought a computer and expected the OEM to handle ALL of the security when in reality they are a link in the supply chain)
Prevention
Recommendations for defense against the attacks mixed practical advice with some community calls to action:
- As always upgrading the firmware to the latest version is one of the most important defenses
- Where possible ensure that SPI flash contents are backed up (using additional SPI flash chips on supported hardware) and/or work with the OEM to ensure you have access to the components to rebuild the SPI flash in case of emergency
- Encouraging the hardware manufacturers in the supply chain to deliver secure firmware configurations
- Creating a community project where we can share information about the state of firmware and hardware security. For example, I’ve scanned the SPI flash configuration on several devices, others could benefit from this information as part of a larger project
- An SBOM is not enough, simply knowing that you have insecure or misconfigured components improves awareness but does not directly improve security (e.g. knowing the contents of an asteroid does not directly influence its trajectory toward earth). Taking action on the information contained in SBOMs has a great effect.
- Verify the integrity of critical code including the SPI. It is important to remember that the SBOM is what “should” be in the device, but there are many hands involved in the supply chain, and thus many chances for things to go awry. Active integrity checks are where the rubber meets the road in terms of what you think about a device versus what you know.
