Supermicro IPMI BMC firmware: Every affected BMC shares one TLS private key and one SSH host key, baked into the

CVSS 8.1CVE-2013-3619Firmware, BMC & network fabriccurated

Impact

Every affected BMC shares one TLS private key and one SSH host key, baked into the firmware image. The consequence is that the encrypted management plane is not encrypted against anyone who has read the firmware: an attacker positioned on the management network decrypts recorded BMC sessions and harvests the administrator credentials inside them, or stands up a machine-in-the-middle that presents a certificate and SSH host key your tooling accepts without complaint. Host-key pinning and TLS verification - the two controls an operator would normally lean on - are both defeated, because the legitimate key and the attacker's key are the same key.

Who can reach it

Network, requires a position on the path to the BMC (or the ability to redirect traffic to it). Pre-auth: the attacker needs no BMC account, only the publicly extractable key material.

What to do

Firmware flash to SMT_X9_317 / SMT X8 312 or later, and then verify the device actually regenerated unique keys rather than shipping a new shared pair - some BMC firmware regenerates on first boot after reset, some does not, so check the presented certificate fingerprint differs between two of your own nodes. Until that is done, assume all BMC traffic is readable and forgeable, and never carry a credential over it that is also valid elsewhere.

References

https://www.rapid7.com/blog/post/2013/11/06/supermicro-ipmi-firmware-vulnerabilities/https://www.kb.cert.org/vuls/id/648646 https://nvd.nist.gov/vuln/detail/CVE-2013-3619

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.