Zusammenfassung
- Der Scan vom 6. Mai erfasste 36.872 eindeutige öffentliche IPMI-Endpunkte; das ist keine Zahl von Rechenzentren, Servern, Betreibern oder Kunden.
- 24.650 Endpunkte beziehungsweise 66,9 Prozent lieferten mindestens eine passwortabgeleitete RAKP-Antwort vor der Client-Authentifizierung.
- Bei 6.240 Endpunkten passte unter leerem Benutzernamen ein schwacher Kandidat, bei 2.340 benannten Konten ein Kandidat aus einer Liste häufiger Passwörter.
- Für zwei moderne Supermicro-X13DEM-Systeme bei einem ungenannten GPU-Anbieter wurde das dokumentierte Werksformat ermittelt; Lava meldete sich nicht an, der Betreiber behob die Exposition.
- CVE-2013-4786 dokumentiert den RAKP-Mechanismus seit 2013; neu ist die Messung öffentlich betriebener Schnittstellen im Jahr 2026.
- Priorität haben das Sperren von UDP 623 am Rand, ein privates Managementnetz, Zugang aus bekannten Quellen, Kennwortwechsel und unabhängige BMC-Überwachung.
Schicht eins: Das Protokoll verrät etwas, bevor Vertrauen besteht
IPMI 2.0 nutzt RAKP für die Authentifizierung. CVE-2013-4786 beschreibt, dass Nachricht zwei einen aus dem Passwort berechneten HMAC liefern kann. Ein Außenstehender kann dieses Material mitnehmen und Kandidaten offline prüfen, statt jeden Versuch erneut an den Controller zu senden.
Die Schwachstelle wurde im Juli 2013 veröffentlicht. Lava hat im Jahr 2026 keinen neuen kryptografischen Fehler entdeckt. Die Forschung prüft, wie häufig eine alte Protokolleigenschaft noch über eine öffentliche Adresse angesprochen werden konnte.
Von den gemessenen Endpunkten antworteten 24.650 mindestens einmal auf diese Weise. Eine Antwort ist weder Klartextpasswort noch erfolgreiche Sitzung. Sie verlagert lediglich die Prüfung von Kandidaten auf die Rechenressourcen des Fragenden.
Diese Unterscheidung bestimmt die Reaktion. Ein besseres Protokoll kann künftig weniger Material preisgeben. Ein Betreiber muss aber nicht auf einen Standardwechsel warten, um eine unbekannte Quelle von der gesamten Unterhaltung auszuschließen.
Schicht zwei: Ein individuelles Werkspasswort hat zwei Qualitäten
Supermicro erklärt, dass betroffene neue Systeme seit November 2019 mit einem individuell vorprogrammierten BMC-Passwort statt des gemeinsamen Werts ADMIN ausgeliefert werden. Individualität verhindert, dass dasselbe Geheimnis eine ganze Geräteklasse öffnet.
Sie sagt jedoch nichts über die Größe des Suchraums. Ein für jedes Gerät anderer Wert kann trotzdem einem begrenzten Format folgen. Ist das RAKP-Material öffentlich erhältlich, muss zwar jedes Gerät separat geprüft werden, der Aufwand pro Gerät kann aber niedrig bleiben.
Lava berichtet, bei zwei modernen Supermicro-X13DEM-Systemen eines nicht genannten GPU-Anbieters das dokumentierte Format aus zehn Großbuchstaben ermittelt zu haben. Die Forscher authentifizierten sich nicht. Nach der Meldung habe der Betreiber die Exposition beseitigt. Das ist ein Befund zu zwei Systemen, keine Aussage über alle Modelle oder Kunden.
Der HPE-Versuch fand im Labor statt. Eine vollständige Suche durch das dokumentierte achtstellige iLO-Werksformat dauerte laut Lava je erfasster Antwort rund 32 Sekunden auf acht RTX-6000-PRO-GPUs. Damit ist ein Rechenaufwand unter bestimmten Bedingungen gemessen, nicht eine Internetpopulation angegriffener HPE-Geräte.
Schicht drei: Öffentliche Erreichbarkeit ist eine Betriebsentscheidung
Die 36.872 eindeutigen IPMI-Endpunkte sind eine Momentaufnahme öffentlicher Adressen am 6. Mai. Eine Adresse kann später verschwinden, neu vergeben werden oder eine andere physische Struktur darstellen. Sie entspricht nicht automatisch einem Gebäude, einem Server oder einem Unternehmen.
Als Betriebskennzahl zeigt sie dennoch, dass die erste Netzwerkgrenze durchlässig war. Die Anfrage erreichte einen BMC und begann einen Verwaltungsaustausch. Ein privates, nicht aus dem Internet geroutetes Managementnetz hätte diese Stufe unabhängig vom Passwortformat beendet.
Supermicros eigener Leitfaden fordert genau diese Trennung. BMCs sollen weder dem Internet noch nicht autorisierten Nutzern außerhalb einer Firewall ausgesetzt werden. Für unsichere Netze empfiehlt das Dokument, UDP 623 zu blockieren, bekannte Quelladressen zuzulassen und ein eigenes Management-VLAN zu schützen.
Öffentliche Erreichbarkeit kann mehrere Ursachen haben: Inbetriebnahme, Fernwartung, delegierter Hostingzugang oder eine veraltete Regel. Ein externer Scan erkennt die Ursache nicht. Er beweist aber, dass eine temporäre Ausnahme nicht wirksam von einer dauerhaften Veröffentlichungsentscheidung getrennt war.
Schicht vier: Kompensierende Kontrollen müssen unabhängig sein
Eine einzelne Maßnahme darf nicht die übrigen ersetzen. Ein starkes Passwort rechtfertigt keine öffentliche Schnittstelle. Eine Firewall macht den Wechsel des Werkspassworts nicht überflüssig. Ein Firmware-Update ersetzt keine Protokoll- und Ereignisüberwachung.
Der BMC arbeitet unabhängig vom Hostbetriebssystem. Er kann Strom, Konsole, virtuelle Medien und Firmware steuern, wenn der Host selbst nicht verfügbar ist. Darum reichen EDR, Host-Firewall und Betriebssystemkonten nicht als einziger Schutz.
Das Managementnetz braucht eigene Protokolle und Alarme. Authentifizierungsversuche, Konfigurationsänderungen, Firmwareaktionen und Netzwerkflüsse müssen auch dann sichtbar bleiben, wenn der verwaltete Server ausfällt oder abgeschaltet wird.
Zur Schicht gehört ebenso ein Inventar: physisches Gerät, BMC-Adresse, Eigentümer, Kunde, Firmwarestand und Zugangsregel müssen zusammenpassen. Sonst überlebt ein Wartungspfad den Austausch einer Maschine oder den Wechsel eines Hostingkunden.
Die beiden Treffergruppen sind keine gemeinsame Bruchquote
Bei 6.240 Endpunkten stimmte unter einem leeren Benutzernamen Material mit einem schwachen Passwortkandidaten überein. Bei 2.340 Endpunkten passte für ein benanntes Konto ein Kandidat aus einer Liste häufiger Passwörter. Kontozustand und Suchmenge sind verschieden.
Eine pauschale Behauptung, ein bestimmter Anteil aller Hashes sei „geknackt“, würde beide Verfahren und ihre Nenner verlieren. Auch ein kryptografisch passender Kandidat belegt noch nicht, dass das Konto aktiv war, welche Rechte es besaß oder ob jemand es nutzte.
Die Beweiskette hat weitere Stufen: erreichbarer Endpunkt, RAKP-Antwort, Kandidatentreffer, wiedergewonnenes Kennwort, authentifizierte Sitzung, unerlaubte Aktion und Kompromittierung. Lava quantifiziert frühe Stufen und überschreitet die Anmeldegrenze in den dokumentierten Fällen nicht.
Für den Betrieb reicht bereits die frühere Stufe als Handlungsgrund. Eine Schnittstelle kann geschlossen und ein Passwort rotiert werden, ohne dass ein Sicherheitsforscher erst die Kontrolle übernehmen muss.
Mehr als die Hälfte Supermicro ist keine Ausfallrate
Supermicro-Hardware stellte mehr als die Hälfte der antwortenden BMCs im Datensatz. Der Nenner besteht aus den Antworten dieser Messung, nicht aus Supermicros weltweitem Bestand. Ohne installierte Stückzahl, Modellmix und Netzkonfiguration der Eigentümer ergibt sich keine herstellerbezogene Schwachstellenquote.
Hersteller beeinflussen dennoch relevante Schichten: Werksformat, Firmware, Authentifizierungsoptionen und Installationshinweise. Betreiber kontrollieren Routing, Firewall, VLAN, Kennwortrotation und Alarmierung. Integratoren können die technische Umsetzung übernehmen, Hostingkunden gegebenenfalls einen delegierten Zugang.
Geteilte Verantwortung ist nur dann belastbar, wenn jede Entscheidung einen Nachweis hat. Der Hersteller kann dokumentieren, was standardmäßig ausgeliefert wird. Der Betreiber kann zeigen, dass die Schnittstelle nicht öffentlich geroutet ist. Der Kunde kann nachweisen, wer Zugriff erhielt.
Auch ein Hersteller mit wenigen Treffern bekommt kein Sicherheitsprädikat. Eine Organisation sollte ihren eigenen vollständigen Bestand prüfen, statt aus einer Rangfolge externer Antworten auf interne Sicherheit zu schließen.
Die richtige Reihenfolge beginnt am Netzrand
Zuerst wird UDP 623 am unsicheren Rand gesperrt und das BMC in ein separates Management-VLAN oder privates Netz verschoben. Administratoren gelangen über ein kontrolliertes VPN oder einen Bastion Host dorthin; Firewalls und Allowlists beschränken die Quellen zusätzlich.
Danach folgen der Wechsel aller Werkskennwörter, das Entfernen unbenötigter Konten, das Abschalten veralteter Verfahren und aktuelle Firmware. Diese Arbeiten härten die Innenseite der Grenze. Sie ersetzen nicht die Grenze selbst.
Redfish über TLS kann innerhalb des isolierten Managementnetzes eine modernere, verschlüsselte Verwaltung bereitstellen. TLS schützt den Transport, entscheidet aber nicht, wer die Anmeldeseite erreichen darf. Eine öffentliche Redfish-Schnittstelle wäre kein automatischer Sicherheitsgewinn.
Eine vergleichbare Wiederholungsmessung sollte zeigen, ob die Exposition nach der Offenlegung anhält. Sie müsste Adresswechsel, Geräteabbau und echte Isolierung unterscheiden. Ein Nachweis von Ausnutzung bräuchte andere Quellen: erfolgreiche Sitzungen, unerlaubte Befehle, dauerhafte Änderungen oder bestätigte Vorfälle.
Lavas Ergebnis ist kein Zähler für Opfer. Es ist ein Test, bei dem vier Schutzschichten sichtbar werden. Die wirksamste Kombination verhindert, dass eine unbekannte Quelle überhaupt bis zu der Protokollantwort gelangt.