Tyan S5552 BMC web interface, firmware version 3.00: An unauthenticated attacker downloads the BMC's TLS private key

Impact

An unauthenticated attacker downloads the BMC's TLS private key. With it they can decrypt captured management traffic and impersonate the BMC to your own tooling - meaning your provisioning system, monitoring collector and operators can be fed a controller that is not the controller, and will hand over BMC credentials to it. Because vendors frequently ship the same certificate across a production run, a key pulled from one Tyan S5552 may authenticate an impersonated BMC across every node of that model in the fleet. That turns a medium-scored file disclosure into a fleet-wide management-plane credential harvest. The private key for the TLS certificate the BMC presents is retrievable by forced browsing, with no authentication.

Who can reach it

Unauthenticated HTTP access to the BMC web interface - anything routable to the out-of-band management VLAN. No credential and no host foothold required.

What to do

Firmware update from Tyan, and this is where an operator hits a wall: Tyan has been folded into MiTAC Computing, www.tyan.com no longer presents a valid TLS certificate for its own hostname, and mitaccomputing.com returns 403 to automated clients - so there is no reachable vendor PSIRT to obtain a fixed image from. The advisory that exists is third-party, from Nozomi Networks. Regardless of firmware state, replace the BMC's TLS certificate with one you generated and control, and rotate any BMC credentials that were transmitted to that BMC over a session an attacker could have decrypted. Certificate replacement is a config-only change and should be done on every BMC in the fleet as standard practice, not just Tyan ones.

References