Rechenzentren sind häufig auf den Schutz ihrer Betriebssysteme fokussiert. Doch wer die BMC-Schwachstelle hinter IPMI übersieht, riskiert ein deutlich größeres Problem: Über die Management-Prozessoren der Baseboard Management Controller (BMCs) lassen sich Server auch ohne laufendes Betriebssystem administrieren. Genau an dieser Stelle setzt die Sicherheitslage an, die von einer zuständigen Stelle für Datenzentrumsicherheit (Lava) untersucht wurde.
Die Schwachstelle ist seit rund 20 Jahren bekannt und betrifft eine große Bandbreite typischer Serverplattformen. Weil BMCs zu den privilegiertesten Kontrollpunkten in der Management-Ebene gehören, kann ein kompromittiertes Gerät eine Kette weiterer Angriffe auslösen – oft mit geringerer Überwachung als bei den produktiven Systemen.
Warum BMCs für Angreifer so attraktiv sind
Ein BMC ist dafür da, Servermanagement-Funktionen auch dann bereitzustellen, wenn das Betriebssystem nicht verfügbar ist. In der Praxis können Administratoren darüber unter anderem einen Host neu starten, Firmware-Aktualisierungen durchführen sowie plattformnahe Konfigurationen ändern. Zusätzlich lassen sich Informationen aus Hardware-Sensoren abrufen.
Je nach Implementierung greifen Administratoren auf unterschiedliche Management-Oberflächen zu, zum Beispiel:
- IPMI als Out-of-Band-Protokoll
- Redfish über eine HTTPS-basierte Management-API
- eine webbasierte Administrationsoberfläche
Diese Vielfalt klingt zunächst nach Flexibilität. Für Angreifer kann sie jedoch ein Verstärker sein: Wenn mehrere Oberflächen auf denselben Benutzerbestand oder denselben Identitätsmechanismus zurückgreifen, können Informationen aus einem Kanal die Absicherung eines anderen Kanals unterlaufen.
Der Kern der Gefahr: CVE-2013-4786
Im Mittelpunkt der Untersuchung steht die Schwachstelle CVE-2013-4786. Laut den verfügbaren Informationen wurde sie im Jahr 2004 in Zusammenhang mit dem IPMI 2.0-Authentifizierungsprozess eingeführt. Technisch geht es um den Mechanismus, bei dem ein Angreifer Passwort-Hashes erlangen kann, um sie anschließend offline zu knacken.
Demnach kann der BMC während der Authentifizierung einen HMAC-SHA1-Code zurückgeben. Dieser Code wird unter Verwendung von Kontopasswort und Sitzungswerten berechnet – Werte, die dem anfragenden System bekannt sind oder abgeleitet werden können. Relevant ist außerdem, dass eine nicht authentifizierte Instanz, die die passende UDP-Schnittstelle erreichen kann, die Antwort anfordern und damit Offline-Wiederherstellungen anstoßen kann.
Der entscheidende Unterschied zu klassischen Angriffen: Für das Austesten vieler Passwörter ist keine neue Online-Anfrage für jeden Kandidaten nötig. Das senkt Hürden, weil rate-limiting oder einfache Sperrmechanismen in der Praxis weniger wirksam sein können.
Wenn IPMI, Web und Redfish zusammenhängen
Ein weiterer Punkt, der die Gesamtrisikolage verschärft, betrifft die Art der Authentifizierung. In vielen Implementierungen – so die Einschätzung von Lava – teilen verschiedene Management-Schnittstellen dieselbe Benutzerdatenbank. Dadurch kann ein Passwort, das an einer Stelle funktioniert, auch an anderer Stelle funktionieren.
Noch deutlicher wird es, wenn der Authentifizierungsweg selbst verwertbare Informationen preisgibt. Im Kontext der BMC-Schwachstelle ist entscheidend, dass der IPMI-Authentifizierungsprozess Informationen liefern kann, die eine Offline-Passwortwiederherstellung ermöglichen. Hat ein Angreifer so erst einmal Erfolg, kann das anschließend für andere Schnittstellen wie die Weboberfläche oder Redfish genutzt werden – zumindest sofern sie auf denselben Konten basieren.
Wie viele Schnittstellen sind tatsächlich erreichbar?
Die Untersuchung macht außerdem sichtbar, wie weit die Angriffsfläche in der realen Welt reicht. Laut Lava laufen in der Größenordnung von:
- fast 37.000 serverseitige Management-Schnittstellen, die das IPMI-Protokoll im Internet bereitstellen
- über 24.000 davon, die passwortabgeleitete Authentifizierungshashes bereits vor der eigentlichen Anmeldung offenlegen
Diese Zahlen verdeutlichen: Selbst wenn einzelne Systeme nur selten angegriffen werden, reicht die Anzahl öffentlich erreichbarer Schnittstellen, um ein relevantes Risiko für viele Organisationen zu schaffen. Besonders kritisch ist das, wenn BMCs ohnehin nicht in dem Maß überwacht werden, wie es für klassische Serverdienste üblich ist.
Schwache und fehlerhafte Zugangsdaten als zusätzlicher Hebel
Die BMC-Schwachstelle allein wäre schon problematisch. Verschärfend kommt jedoch hinzu, dass nicht selten auch die Passwortqualität ein Angriffsziel ist. Lava berichtet beispielsweise von Fällen, in denen:
- 6.240 Hosts einen leeren Benutzernamen akzeptierten, aber dabei ein schwaches Passwort nutzten
- bei 2.340 Hosts benannte Konten wie „Admin“ oder „root“ vorkamen, deren Passwörter in öffentlich verfügbaren Wortlisten zu finden waren
Darüber hinaus wurden Konstellationen festgestellt, bei denen BMCs eingeschränkte und vorhersehbare Kennwortformate aus dem Werk nutzten. Gerade diese Muster können die Wirksamkeit von Wörterbuchattacken erhöhen, weil nicht erst eine völlig freie Suche notwendig ist.
Wenn dazu noch moderne Crack-Optionen treten, steigt der Druck: Aus einer einzelnen exponierten Schwachstelle wird ein Einstiegspunkt mit potenziell weitreichenden Folgen.
Folgen für die Management-Ebene
Was macht diese Lage so besonders gefährlich? Lava beschreibt einen breiteren Sicherheitsansatz-Fehler: Die Management-Ebene ist ein Kontrollraum, der kritische Infrastrukturfunktionen steuert. Gleichzeitig erhält er oft weniger Schutz und weniger Monitoring als die Systeme, die er verwaltet.
In Kombination kann die Situation bedeuten, dass ein einzelner öffentlich erreichbarer BMC zum privilegierten Zugriffspunkt wird. Dazu gehört auch die Schwierigkeit, solche Zugriffe im Betrieb schnell zu erkennen, weil die typischen Alarmketten eher auf produktive Dienste ausgelegt sind.
Was Rechenzentren jetzt konkret prüfen sollten
Auch ohne eine vollständige Inventur ist klar: Wer BMC-Zugänge im Internet offenlegt, erhöht die Wahrscheinlichkeit für missbräuchliche Nutzung. Für die Praxis lassen sich mehrere sinnvolle Schritte ableiten:
- Management-Schnittstellen identifizieren: Herausfinden, welche BMCs genutzt werden und welche Protokolle aktiv sind (insbesondere IPMI).
- Netzwerkexponierung reduzieren: Wenn möglich, Management-Zugriffe nicht direkt ins Internet routen, sondern streng segmentieren und absichern.
- Benutzer- und Passwortkonzept prüfen: Schwache Standardkonten, leere Benutzernamen und bekannte Passwortmuster sollten konsequent eliminiert werden.
- Updates und Härtung umsetzen: Firmware- und Sicherheitsupdates entsprechend Herstellerhinweisen installieren und die Konfiguration nach Best Practices härten.
- Monitoring erweitern: Logs und Alarmierung so anpassen, dass auch BMC-bezogene Aktivitäten sichtbar werden.
Diese Maßnahmen adressieren sowohl den technischen Schwachstellenhebel als auch die oft anzutreffenden Schwachstellen bei Zugangsdaten.
Fazit: BMC-Schwachstelle ernst nehmen
Die BMC-Schwachstelle rund um CVE-2013-4786 zeigt, wie riskant es ist, den Management-Zugang als „Nebenbereich“ zu betrachten. Weil BMCs Serverzustand, Firmware und tiefgreifende Konfigurationen steuern und weil IPMI-Authentifizierung verwertbare Informationen preisgeben kann, kann aus einer einzigen exponierten Schnittstelle ein schwer erkennbarer Einstieg werden.
Wer die Angriffsfläche reduziert, starke Zugangsdaten verwendet, Updates einspielt und Monitoring für die Management-Ebene stärkt, senkt das Risiko deutlich – und schützt damit nicht nur ein einzelnes System, sondern die gesamte Infrastrukturkette.
