Remotely Bricking a Server

Visualization of a server rack inside a brick

Even though we may not always think about it, we all depend on computing infrastructure and suffer major disruptions to our business if it becomes unavailable. Whether in the cloud or our own data centers, computing ultimately depends on physical server systems, each with its own myriad of firmware and hardware components that can contain bugs and vulnerabilities. By using the very tools meant to manage these servers, attackers can take advantage of these issues to permanently brick the hardware across entire data centers. For such a fundamental part of every system we depend on, managing these risks is surprisingly difficult. 

To illustrate this issue, we have recorded our own demonstration of a remote attack that bricks a server. Although we’re only filming one example, this attack could apply to numerous different manufacturers with similar vulnerabilities. In this example scenario, an attacker gains remote access to a system. This could be the result of remotely exploiting a vulnerability (such as recent attacks exploiting Apache Struts issues) or compromising credentials, both of which are common attacks. In our demonstration, we use normal update tools to pass a malicious firmware image to the BMC over this interface. This payload could be triggered in a variety of ways at a time of the attacker’s choosing, either triggered by time or by external command and control. These firmware images cause all attempts to boot or recover the system to fail, rendering it unusable. Once firmware is corrupted, most organizations are unable to recover the system. 

Now, let’s explain what happens in the video. In order to manage assets at scale, servers include a Baseboard Management Controller (BMC). You can think of this BMC as an independent computer that lives within a server. It can seem like an odd concept, but this independent BMC is used to remotely configure the system without relying on the host operating system or applications. It can be used to remotely manage the server, reinstall the operating system, and even update the host system firmware. There are multiple ways of communicating with the BMC. Commonly, due to the nature of its role in remote management, we think about network-based methods like using the web interface or the network capabilities of the Intelligent Platform Management Interface (IPMI) protocol where attacks have been published previously.

However, there is also a host-based interface known as the Keyboard Controller Style (KCS), which is defined as part of the IPMI specification. Among other things, this creates a mechanism for firmware updates to be passed back and forth between the host and the BMC. In our demonstration, we use normal update tools to pass a malicious firmware image to the BMC over this interface. No special authentication or credentials are required for this. This malicious BMC firmware update contains additional code that, once triggered, will erase the UEFI system firmware and critical components of the BMC firmware itself. These changes to the host and BMC will cause all attempts to boot or recover the system to fail, rendering it unusable. 

This could enable an incredibly damaging attack scenario. With something as simple as a malware infection or compromising an administrator, an administrator could irrecoverably brick the hardware of a data center. Such an attack could also be easily scheduled to execute at a specific time. They can be implemented as a kill-switch feature in the malicious software, firmware, or hardware components. They can be introduced either physically or remotely, as part of the supply chain, or in operations. And they can stay dormant for arbitrary amounts of time and bring down infrastructure all at once.

Existing procedures and tools need to evolve to provide practical defenses from attacks like these. Research in these threats shows how to scan for vulnerabilities in subsystems like BMC. It also tells us how to check the integrity of these firmware components and how it may be possible to recover them. At minimum it is important that organizations establish processes for regular firmware updates, ensure regular scans for vulnerabilities and monitor critical firmware for malicious modifications.

For more info about these issues contact us at [email protected].