Debug mechanisms are standard components that assist in tracing the source of faults in virtually of all platforms.. These mechanisms are primarily used before a platform reaches production, but also are often used for refurbishing and fixing returned platforms. Security researchers have repeatedly published attacks using debug features, including locating and using JTAG, using debug over USB and finding vulnerabilities in System Management Mode (SMM) using debug.
At Eclypsium, we perform security research to create practical defenses for the hardware foundation of computing infrastructure. We confirmed that debug access over USB enables installation of persistent rootkits in UEFI firmware and runtime SMM firmware on systems that do not securely set debug policy (CVE-2018-3652). This weakness would allow an attacker with physical access to the device to perform an “Evil Maid” attack without opening the case. As others have reported, it is quite difficult to defend against this type of attack. To provide visibility into this threat, we have released a module for the open source CHIPSEC framework in order to detect vulnerable systems.
Protecting Firmware
Every time a computer starts, it must execute firmware to initialize hardware in a usable configuration. This creates the expected environment for software to execute. If malware is able to change some of this configuration, it can elevate its privilege above that of other software either by executing in a privileged mode or reconfiguring the system to violate the assumptions of normal software and violate security properties. The most direct way to do this is simply to modify the firmware.
Of course, an attacker with physical access can simply attach a hardware programmer and modify firmware. While this may seem like it requires specialized equipment and detailed knowledge, it is actually quite easy in most cases. Most firmware is stored on a Serial Programmable Interface (SPI) flash chip. This creates a physical standard for reads and writes to the storage chip, and SPI flash programmers are relatively easy to buy or create. It will also be necessary to figure out what to change in order to gain access without breaking the system. However, another researcher (Dmytro Oleksiuk) has developed a generic proof-of-concept backdoor that can be easily installed into most firmware modules. One could say that the ease and availability of these tools and techniques make firmware rootkits accessible to non-experts, even “script kiddie” material. We were able to install this rootkit on an enterprise laptop with under 4 minutes of physical access.
Another way to modify firmware is through privileged software. In order to defend against this type of attack, firmware should configure protection bits related to firmware storage early during boot. Once this is done, normal software (even including malware that elevated privileges to the kernel) would be unable to perform writes to firmware storage until a reboot when firmware should execute protect itself again. However, firmware still writes to the storage for code and configuration updates somehow. This can be done by requiring a reboot, but that is not feasible in all cases. Alternatively, trusted code, executing in SMM during runtime, can be used to bypass the protections and write to firmware storage. Therefore, SMM is a major target for an attacker trying to install a persistent firmware rootkit.
Using Debug with SMM Firmware
As noted earlier, other researchers have demonstrated that debug capabilities can be used to find vulnerabilities and directly bypass software-based protections. Indeed, debug capabilities have long been a favorite method for vulnerability discovery. Our analysis demonstrates that physical attacks are even easier than ever on a debug-enabled system. Attackers don’t need a special hardware programmer and don’t need to open the case. Using publicly available tools they can simply plug into an external USB port to install a persistent rootkit, bypassing secure boot and many other security features.
We have demonstrated that it is possible to halt the system inside SMM and make arbitrary changes to memory from that context. This grants complete control of highly privileged SMM execution to the attacker. By writing code to modify firmware storage (which is also generically available), such attackers can leverage existing firmware rootkits to install persistent malware. While this has major security implications, it turns out to also be an intended feature for debug purposes. Unfortunately, some systems failed to turn off these capabilities in production.
Debug Access on Production Systems
In order to understand the risk to your systems, it is important to know whether debug is enabled on your production systems. Unfortunately, this isn’t easy without a bit of research. We have developed an open source CHIPSEC module to help. This module mainly checks two main components of the platform:
- CPU debug features
- Direct Connect Interface
Let’s dive into these checks and break it down by component. First, the status of CPU Debug Features are located in the IA32_DEBUG_INTERFACE model specific register (MSR). In the Intel Software developer manual we can see the breakdown of this MSR:
If we ignore the reserved bits we can see 3 interesting things:
- An Enable bit.
- A Lock bit.
- A Debug Occurred bit.
According to this specification, by default, debug is disabled and unlocked. In our chipsec module we check if debug is disabled and locked, which would be a secure configuration for firmware to set in production. If this is done, the check will pass. We also check for the Debug Occurred bit, but we do not rely on its result for a pass/fail decision due to cases where it has false positives (according to CHIPSEC maintainers).
CPU debug is only part of the problem, though. The next check is the status of the Direct Connect Interface (DCI). This feature was previously blogged about and exploited in the above references. It is documented in the chipset datasheet for each platform, for example in the “Intel 100 series and Intel C230 Series Chipset Family Platform Controller Hub (PCH) Datasheet Volume 2” , under the name “DCI Control Register”:
Although this register appears to exist in future chipsets made by intel, it is only documented in this specific datasheet.
Inside this register, between a plethora of reserved bits, we find the “Host DCI Enable” bit or HDCIEN. If enabled, the chipset will provide debug capability over USB. The check, therefore, is pretty straightforward; a secure configuration would disable DCI, and the bit should be 0.
Only when both of the above checks indicate that no debug feature is enabled, do we consider a system to be securely configured and return PASSED from our chipsec module. As for the “Debug occured” bit in the CPU debug features MSR, we decided to follow the advice of the CHIPSEC maintainers and only show a warning if said bit is set. In theory, it would indicate that debug has been enabled at some point during boot.
CHIPSEC can be found on github at https://github.com/chipsec/chipsec
Our module is debugenabled.py
With chipsec installed, you can run this module alone by using this command line:
We have observed failures on a few systems, but it is quite difficult to know how many more are affected. Intel has released a security advisory (CVE-2018-3652) about some systems that do not securely set debug policy. We recommend that you run the checks and see for yourself if your systems are affected.
Mitigations
Of course, the first protection is to maintain complete physical control over sensitive systems. This can be difficult, however. If a sensitive system does fail this check, there is very serious risk from anyone who has physical access to the system even for a very limited period of time. Just by plugging a cable into the USB port and running a script, they may be able to bypass nearly all security technologies. For example, as mentioned earlier in this blog, an attacker may infect firmware with their own malware or rootkit, and they can do it without opening the case!
Some systems may have a setting in the BIOS/firmware setup menu to enable/disable debug features. After disabling the setting, administrators can check for for this configuration to pass the chipsec test module mentioned earlier. In this case, it will be important to protect these settings with a strong password or other mechanisms.
In other cases, it may be necessary to contact the system manufacturer and inquire about a version of firmware that securely disables debug access.
Conclusion
In this blog, we have examined attacks that use USB debug to bypass security measures and install firmware rootkits. Although debug should be disabled in production, some quick checks enable you to determine whether your systems are impacted. We hope that our research will help organizations to understand and defend against “Evil Maid” attacks.
