Last year, Nozomi Networks Labs published research revealing 13 vulnerabilities affecting the Baseboard Management Controllers (BMCs) of Lanner Electronics devices. BMCs are components found in computer motherboards and contain independent CPU, memories, and LAN interfaces that allow remote admins to connect to or send commands to the PC/server to perform various operations. Manipulation of these controllers, designed for remote monitoring and management of a computer, could lead to the complete compromise of the device by an unauthenticated adversary.
Following upon that research, we have discovered five new vulnerabilities affecting the American Megatrends (AMI) MegaRAC BMC software solution. The vulnerabilities explained below specifically affect the AMI MegaRAC SP-X codebase, upon which the firmware of multiple BMC devices is based. As this firmware is widely adopted by numerous vendors for creating their unique remote management solutions, these vulnerabilities are not limited to a specific range of products or an individual vendor. Instead, they have the potential to impact all products by all vendors (being OT, IoT, or IT devices) whose BMC firmware is derived from the affected codebase. Notably, for some devices, we have evidence that these vulnerabilities affect the latest available firmware releases.
In this blog, we share an overview of the AMI MegaRAC SP-X service processor, describe the vulnerabilities, and illustrate the attack scenario that can lead to a persistent backdoor on the BMC web interface.
BMCs and AMI MegaRAC SP-X
A Baseboard Management Controller (BMC) is a specialized microcontroller that is integrated into a server’s motherboard to manage and monitor various aspects of the system’s hardware, such as power consumption, temperature, fan speed, and storage devices. The BMC operates independently of the main CPU, allowing administrators to remotely access and control the server even if the main processor is not functioning correctly.
The American Megatrends (AMI) MegaRAC SP-X is one of the most famous commercial firmware solutions for BMC chips available on the market. Based on a Linux kernel, it offers a wide range of features, including remote power management, keyboard-video-mouse interaction, virtual media support, etc. Administrators and operators can interact with the BMC through a variety of interfaces, such as the web portal, the standard Redfish APIs, the IPMI service, and others.
Vendors whose BMC firmware is known to be based or have been based on the AMI MegaRAC SP-X include Asus, Dell, Gigabyte, Hewlett Packard Enterprise, Lanner, Lenovo, NVIDIA, and Tyan. These vendors can decide to deploy the standard MegaRAC SP-X firmware image “as-is” or customize and configure it according to their needs.
Our research has identified vulnerabilities in the file hash verification for backup files and BMC host-based web interfaces. Additionally, in case integrity checks are not enforced by the motherboard BIOS or firmware (e.g., the UEFI that measures firmware integrity during the Secure Boot process), we discovered and present an attack scenario that could allow an attacker to hide a backdoor on the web-based BMC management interface. This backdoor access could persist even across reinstallations of the host operating system or hard resets of the BMC configuration itself. We conclude by explaining the available and suggested remediations for asset owners.
MegaRAC SP-X Vulnerabilities Found
The list of vulnerabilities found in the standard MegaRAC SP-X codebase follows:
High risk:
- CVE-2023-34337: Inadequate Encryption Strength (CWE-326), CVSS v3 7.6 (AV:A/AC:H/PR:L/UI:R/S:C/C:H/I:H/A:H)
- CVE-2023-34338: Use of Hard-coded Cryptographic Key (CWE-321), CVSS v3 7.1 (AV:A/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H)
Medium risk:
- CVE-2023-34473: Use of Hard-coded Credentials (CWE-798), CVSS v3 6.6 (AV:A/AC:L/PR:H/UI:R/S:U/C:H/I:H/A:H)
- CVE-2023-34471: Missing Cryptographic Step (CWE-325), CVSS v3 6.3 (AV:A/AC:H/PR:H/UI:R/S:U/C:H/I:H/A:H)
- CVE-2023-34472: Improper Neutralization of CRLF Sequences in HTTP Headers (‘HTTP Request/Response Splitting’) (CWE-113), CVSS v3 5.7 (AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N)
CVE-2023-34337, CVE-2023-34473, and CVE-2023-34471 affected SPx_12 up to update-2.00 (excluded). CVE-2023-34338 affected SPx_12 up to update-3.00 (excluded). CVE-2023-34472 affected LTS_12 up to 4/16/2021, LTS_13 up to 7/14/2021, SPx_12 up to update-5.00 (excluded), SPx_13 up to update-3.00 (excluded).
Attacking the BMC through the File Integrity Hash and Backup Restoration Files
While testing the BMC web interface of a motherboard for OT/IoT purposes in our lab environment, we noticed that it offered the possibility to perform the backup and restore of the BMC configuration (Figure 1). This functionality was not present in the Lanner IAC-AST2500 that we assessed in our previous Part 1 research blog.
By inspecting the content of a backup file, we immediately noticed that it contained sensitive data of the underlying Linux system, such as network configuration files or authentication information. Notably, there were also some Bash scripts inside the backup file, an evident opportunity for obtaining Remote Code Execution (RCE) on the BMC. However, simply changing the content of the backup file led to it being rejected. We thus decided to investigate how the BMC was validating the integrity of the file.
After unpacking the firmware of the device and loading the spx_restservice binary in IDA Pro (the main binary responsible for handling web requests), we soon noticed that the backup/restore functionality was handled through an additional shared object called libBackupConf.so and more specifically, by the RestoreConfFile export function (Figure 2).
The core of the validation procedure is done inside the VerifyFileIntegrity function. After reversing the function, we were able to understand that the integrity was verified by comparing an HMAC-SHA1 hash computed on the supplied file against the one included in the file trailer. If matched, the file was accepted. Otherwise, the file was discarded.
However, we soon noticed the following pitfalls in the process:
- The secret used to compute the HMAC-SHA1 turned out to be one among ten values hardcoded in the library. Additionally, in our specific BMC firmware, further analyses on the function that generated backup files unveiled that the value used as a secret was always the first one in the list;
- The HMAC-SHA1 construction was not the one described in the related RFC that defines the standard cryptographic primitives and algorithms used ( H(K XOR opad, H(K XOR ipad, text)) ), but it was a custom simplified version ( H(text, K) ).
- This simplified version is less secure than the standard cryptographic primitive because it does not provide any resistance against collisions on the SHA1 of the message (which have proven to be feasible);
- Finally, of the entire 20 bytes of the resulting HMAC-SHA1 output, only 2 bytes were verified by the algorithm, resulting in only 65’536 possible HMAC-SHA1 combinations. This limitation makes the hashing function much more susceptible to a successful network brute-force attack.
In a short time, we were able to inject some lines to add a reverse shell in one of the Bash scripts and craft a valid HMAC-SHA1, which gave us root access to the BMC (Figure 3).
As expected, the backup and restore functionality was restricted to authenticated users only. However, unauthenticated attackers may be able to indirectly exploit some of these issues by poisoning a backup and restore file in a repository server and then waiting or convincing an unaware victim/user into using that file to restore from backup, triggering the execution of the malicious code.
Attacking the BMC from the Host and Achieving Reset-Resistant Persistence
Considering how powerful the web interface of a BMC is, Cross-Site Scripting (XSS) represents one of the most dangerous vulnerabilities that may arise, given that an attacker would be able to surreptitiously launch commands on the controlled host. In our analysis we extensively tested the web application for XSS vulnerabilities, but we were unable to find any in the fields that an attacker may control. This pushed us to think out of the box and try to test for XSS in fields that normally an attacker is not expected to target.
Among other things, the BMC web interface displays asset information related to the managed system. An example is the “Field Replaceable Units” webpage (Figure 4).
After some investigation, we discovered that some of this data was extracted from the values hardcoded in the host system BIOS/UEFI. If in the past updating a BIOS was a task that could be performed only by booting into a special motherboard functionality, nowadays it is more and more prevalent to perform BIOS/UEFI updates straight from the host OS (e.g., through a manufacturer’s ad-hoc application, or the Windows Update service). Thus, we decided to explore editing the BIOS image and reflashing it to test for Stored XSS by abusing some of these fields.
As a proof of concept, using one of the AMI BIOS editing tools available on the Internet, we injected an XSS payload in the vendor and product names hardcoded in the BIOS image, as shown in Figure 5. We could also have used fields that are not normally displayed during the boot process.
Afterwards, we logged in to the BMC web interface and reopened the FRU webpage. We were soon greeted with the alert, confirming the execution of our arbitrary JavaScript code.
In spite of its relative simplicity, this attack would cause extensive consequences. An attacker that has achieved admin privileges on a managed host would be able to move laterally and hide a backdoor on the web-based BMC management interface. This access could persist despite multiple reinstallations of the host operating system, hard drive changes, or hard resets of the BMC configuration itself. The only way to remove it would be by reflashing the BIOS/UEFI with a clean image. It is also worth noting that the likelihood of a similar attack is low but not impossible: cases where persistence was achieved through firmware reflash in state-sponsored, targeted attacks have already been registered.
According to AMI’s threat model protection against scenarios like this is provided by the BIOS/UEFI integrity checks and are the responsibility of the BMC manufacturer and/or end user. Consequently, this finding failed to be considered a vulnerability and a CVE ID has not been assigned.
Available Remediations
All BMC firmware in all devices that are based on these versions up to Q3 2021 of the MegaRAC SP-X are impacted (unless the vendor has applied specific customizations to change or remove the vulnerable portions of code). Notably, for some devices, we were able to confirm these vulnerabilities in the latest available firmware versions. A BMC firmware is thus patched to all aforementioned CVE IDs only if the respective vendor has chosen to base it on one of the fixed versions that have been released after that time (or if the vendor has applied specific customizations to change or remove the vulnerable portions of code).
Given that the web-based BMC management interface does not clearly provide information about the MegaRAC SP-X codebase version from which it is derived, precise information about the vulnerability status of devices must be provided by the respective manufacturers. We urge asset owners to verify with the manufacturers and apply patched versions of the BMC firmware when available.
In case the manufacturer does not provide any information or solution, the following mitigations can be applied:
- CVE-2023-34337, CVE-2023-34471, CVE-2023-34472, CVE-2023-34473: review all accounts with access to the BMC and remove unnecessary ones; avoid restoring configuration files from untrusted sources;
- CVE-2023-34338: manually regenerate the TLS certificate through the web-based BMC management interface.
As for the persistent attack scenario, it might be still feasible even on fully patched BMC solutions. The recommendation to avoid abuses of this case is to always enable all BIOS/UEFI integrity protections (e.g., enforcement of signed firmware updates, secure boot, etc.).
Conclusions
The AMI MegaRAC SP-X is a powerful and comprehensive remote management BMC firmware solution designed for data center and enterprise-class servers, adopted by a wide range of recognized vendors. BMCs play a vital role in efficiently managing and monitoring of server hardware, but their continuous operation and remote accessibility can also introduce security risks.
In this article, we have identified and explained 5 new vulnerabilities that affect the standard MegaRAC SP-X codebase that is deployed across multiple devices by a variety of high-profile vendors. We have also presented an attack scenario where an attacker may achieve reset-resistant persistence on the BMC. We ultimately suggest all asset owners apply the official patches or, if unavailable, enact the recommended mitigations listed above.
