AMI MegaRAC SPx (BMC TLS certificate / cryptographic keys): A hard-coded certificate and its private key ship inside

CVSS 7.1CVE-2023-34338Firmware, BMC & network fabricAMI-SA-2023006Nozomi Labs BMC auditcurated

Impact

A hard-coded certificate and its private key ship inside the firmware, so the same key is on every BMC built from that image across every customer of that ODM. Anyone who extracts it once - and firmware images are downloadable from vendor support sites - can impersonate any BMC's HTTPS endpoint or decrypt intercepted management traffic. The operator consequence is that TLS on your management plane is decorative: admin passwords, Redfish tokens and KVM sessions are recoverable by an attacker who can interpose.

Who can reach it

Adjacent network with the ability to interpose on BMC traffic and some operator interaction (an admin logging into the BMC). No credentials needed - the attacker supplies the trust. A compromised management jump host, a rogue device on the management VLAN, or an ARP/DHCP position on that segment is enough.

What to do

Firmware flash to SPx_12.3 / SPx_13.0 or later, but the flash is only half the fix - a fixed image does not retroactively replace a certificate already in place. After flashing you must generate and install a unique per-node BMC certificate signed by your own internal CA, which is a config operation over Redfish and can be automated, no reboot required. Do the certificate rotation even on nodes you cannot yet flash; it is the part that actually removes the shared key.

References

https://9443417.fs1.hubspotusercontent-na1.net/hubfs/9443417/Security%20Advisories/AMI-SA-2023006.pdf https://nvd.nist.gov/vuln/detail/CVE-2023-34338

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.