We have already seen both proof-of-concept and in-the-wild demonstrations of attacks targeting system firmware such as SMM rootkits, device firmware replacement, and even usurping firmware-based features for malware. As part of our ongoing security research efforts, we recently reviewed various Supermicro systems and discovered serious firmware vulnerabilities. Such issues affect many models and have persisted for many years, which could be problematic since these systems are commonly used as data center servers. As other researchers have shown, Supermicro is not alone. Security vulnerabilities in firmware continue to be discovered regularly. Unfortunately, malicious activity at the firmware and hardware level is invisible to most detection and response mechanisms in use today, leaving many critical systems exposed to attacks that target this area.
Impact
These vulnerabilities are easily exploitable and provide malware with the same impact as having physical access to the kind of system that is usually stored in a secure data center. A physical attacker who can open the case could simply attach a hardware programmer to bypass protections. Using the attacks we have discovered, it is possible to scale powerful malware much more effectively through malicious software instead of physical access.
- CVSS Score: 8.2 (High) CVSS:3.0/AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H
Malware exploiting these vulnerabilities can install persistent and stealthy firmware backdoors to steal sensitive data or manipulate the way a system operates. This sort of attack has been demonstrated numerous times by researchers, and we have seen real-world examples in HackingTeam’s UEFI rootkit and firmware attacks against network equipment.
Also, malware might be able to damage critical hardware and completely prevent the system from booting. We’ve seen this sort of attack in the real world as well, especially in the attacks against Saudi Aramco and the electrical system in the Ukraine.This has also been easily demonstrated by simply corrupting a portion of the update. The corrupted firmware then causes the system to hang during boot. Such an attack could prove costly for victims who are unlikely to have the means to recover unless they have deliberately prepared. Even the most prepared environments tend not to back up firmware images or keep procedures for physically restoring systems from such attacks.
Vulnerabilities Discovered
Missing Firmware Storage Access Controls
In order for Intel-based systems to use the firmware storage properly, they contain a Descriptor Region. This defines the locations and access controls for itself and the other regions, which are used by various components to store firmware and persistent configuration. At this point, you can probably see the problem. Good security practice would be to set the least privilege required. In some cases, however, the descriptor itself is writable by software executing on the host processor. In this case, the mechanism doesn’t protect anything at all! Malware can simply modify the permissions and bypass any protection, potentially leaving firmware exposed.
In general, the flash descriptor region should be “immutable” once the system completes the manufacturing process and is ready for production use. This helps establish the firmware stored in the SPI flash as a root of trust for the system. Specifications like the NIST SP 800-147 BIOS Protection Guidelines depend on this property. By insecurely configuring the descriptor, malicious software with administrative privilege in the host OS may be permitted to modify the contents of firmware code and data that the host processor would otherwise never need to directly read or write.
Eclypsium researchers have observed vulnerable descriptor access controls through runtime examination of various server firmware models. This manual analysis uncovered multiple server models that allowed writes to the flash descriptor from host software. According to Supermicro, some of the products we reviewed date back to 2008 and are currently EOL and no longer supported.
Insecure UEFI Firmware Updates
In order to install updates, it must be possible for software to write/update the firmware storage medium somehow. Normally, this is protected so that malware (or perhaps just buggy software) cannot overwrite the firmware and prevent the system from booting. Over the years, various manufacturers have developed their own formats for packaging an update and causing firmware to process it. However, the UEFI specification has standardized a mechanism for storing and processing updates as a “capsule” that is presented to firmware during the boot process.
The need for authenticated firmware updates is already widely accepted. This is the primary topic of NIST SP 800-147 “BIOS Protection Guidelines” published in 2011. Failure to properly authenticate updates can undermine the integrity of any security features provided by the operating system or applications. This has been demonstrated many times over the years by researchers targeting system firmware to bypass operating system and hypervisor security features.
We have observed insecure firmware updates through runtime examination of various systems. This manual analysis uncovered that Supermicro X9DRi-LN4F+, X10SLM-F and X11SSM-F systems did not securely authenticate firmware updates. We confirmed this result by intentionally modifying the binary in official Supermicro firmware images and observing that the system firmware still accepted and installed the modified package. We were able to download a standard firmware update, change the code to one of the modules, and successfully apply it to systems using the standard update tools.
In addition to authentication, there is also a potential problem when malware can introduce a known and already-fixed vulnerability into a system by automatically running the update process. In such cases the official update process is used with a signed firmware image, but the image happens to be older than the currently installed version. Sometimes this ability to back-out an update is desirable for customers. However, if a security update was introduced, then an older and vulnerable version of firmware exists, and it is properly signed. In order to prevent updates that re-introduce a security vulnerability, some firmware will allow version downgrade only when an update is not marked as a security update. If a properly -signed update is provided but the newer version contains security fixes, the older version is rejected. We also tested Supermicro systems for anti-rollback protections by intentionally updating to an older BIOS. This worked without any trouble.
We contacted Supermicro in January of this year to report these vulnerabilities and recommend that they implement industry standard practices to cryptographically authenticate firmware updates and implement anti-rollback for security fixes.
Mitigation Strategies
The most obvious solution is for system manufacturers to validate the access controls on the descriptor region and release firmware updates. However, there are some actions that could be performed by endpoint security teams to mitigate this vulnerability.
Analysis and Detection
Visibility into vulnerabilities like this is the first step toward mitigation. In order to gain insight into your systems, it is possible to use the CHIPSEC framework to check the descriptor access controls of a system as follows:
chipsec_main -m common.spi_access
If this test fails, then the current descriptor values offer no protection, because they can be changed.
If an attacker were to exploit insecure firmware updates, the obvious goal would be to somehow alter the firmware. This enables very stealthy and persistent malware that can bypass many security controls. However, it may be possible to detect such malware (if it has not taken explicit steps to prevent this).
To defend against these attacks, it is possible to collect hashes of firmware modules. These can be validated against a whitelist from firmware provided by the vendor. If unexpected changes are discovered, expert analysis will be needed to manually assess them.
Recovery
If all else fails, it may be possible to manually recover critical systems using a hardware programmer. Such activities require substantial expertise. However, for most critical systems, recovery may be much faster if procedures are written and executed to collect and archive working images on these systems and successfully reflash them.
Security Improvements
Supermicro has been supportive of our efforts and prioritized understanding and mitigating the issues we have discovered. For the current generation of products, Supermicro indicated that they have already implemented a signed firmware update for several products and are making this update generally available for all future systems. Similarly, for OEM customers who require rollback capability for their customized and locked firmware versions to ensure business continuity, Supermicro indicated that they are supporting anti-rollback as an option for their X11 generation firmware. The SPI flash descriptor is read-only on most boards and we are helping Supermicro identify specific models where this may be incorrectly set.
Conclusion
We have confirmed missing firmware storage access controls and insecure firmware updates on specific Supermicro systems. Many other systems are likely to have similar vulnerabilities, leaving them exposed to attacks targeting firmware and hardware. Since most organizations do not monitor at this deep level, these attacks may go unnoticed for an extended period. By providing this summary of the vulnerabilities, impacts, and mitigation strategies, we hope to assist organizations in understanding and defending against threats at this level.
