Out-of-Band-Management-Systeme gehören in modernen Rechenzentren zur Grundausstattung. Sie erlauben es Administratoren, Server auch dann zu verwalten, wenn das eigentliche Betriebssystem längst nicht mehr reagiert – vom Neustart über Firmware-Updates bis hin zur kompletten Neuinstallation. Jeder Hersteller setzt dabei auf sein eigenes Ökosystem, HP auf „HO Integrated Lights-Out“ (HP iLO), Dell auf „integrated Dell Remote Access Controller“ (iDRAC), und Cisco auf den Cisco Integrated Management Controller (Cisco IMC). Letzteres kommt dabei auf den weit verbreiteten Cisco UCS C-Series Rack-Servern und S-Series Storage-Servern zum Einsatz.

Gerade diese Systeme sind aus Angreifersicht besonders attraktiv: Wer den Management-Controller kontrolliert, sitzt faktisch „unterhalb“ des Betriebssystems. Der IMC kann das BIOS aktualisieren, SecureBoot konfigurieren und damit direkt mit den auf dem Server laufenden Betriebssystemen interagieren. So gesehen, ein Betriebssystem für das Betriebssystem. Schafft es hier ein Angreifer herein, so kontrolliert er faktisch den Server, und alle dort laufenden Systeme.

Und genau in einer solchen wichtigen Komponente haben wir im Rahmen eines Assessments eine kritische Schwachstelle gefunden, die eine vollständige Systemübernahme als Root-User ermöglicht. Und was diese Sicherheitslücke auch erlaubt, ist einen Einblick hinter den Vorhang des ansonsten sehr verschlossenen Ökosystems Cisco IMC zu werfen, auf Betriebssystem-Ebene.

Hinweis

Die Schwachstelle wurde im Zuge eines beauftragten Assessments entdeckt und im Rahmen einer koordinierten Offenlegung (Responsible Disclosure) an Cisco gemeldet. Cisco hat die Lücke bestätigt und einen Patch bereitgestellt. NSIDE hat dazu auch das Advisory NSIDE-SA-2026-003 zusammengestellt.

Angriffe auf fremde Systeme ohne ausdrückliche Erlaubnis sind illegal und dürfen nicht durchgeführt werden!

Wo die Lücke steckt: der Umweg über einen SSH-Schlüssel

Die Web-Anwendung des Cisco IMC bietet Benutzern eine komfortable Funktion: Sie können ihren öffentlichen SSH-Schlüssel für den SSH-Zugriff auf verschiedene Weise hinterlegen. Der Schlüssel kann direkt eingefügt, als Datei hochgeladen oder sogar von einem anderen Server heruntergeladen werden – etwa per FTP oder HTTP.

Und genau diese letzte, praktische Variante ist der Knackpunkt. Weist man die Web-Anwendung an, einen SSH-Schlüssel von einem externen Server zu holen, führt das Backend im Hintergrund ein Skript mit den übergebenen Argumenten aus. Vereinfacht sieht der Aufruf so aus:

/etc/scripts/download_ssh_keys.sh http 123.123.123.123 /tmp/example.ssh.pub

Dieses Skript nimmt die Parameter entgegen und übergibt sie als Argumente an curl, um die Datei tatsächlich herunterzuladen. Klingt auf den ersten Blick harmlos – ist es aber nicht.

Argument Injection: aus einem Download wird Code-Ausführung

Das Problem bei dieser Lösung: Aufgrund mangelnder Bereinigung werden die vom Benutzer kontrollierten Argumente nicht vollständig gefiltert, bevor sie an curl weitergereicht werden. Dadurch lassen sich zusätzliche curl-Argumente in den Aufruf einschmuggeln. Man spricht hier von einer Argument Injection – der Angreifer beeinflusst nicht nur was heruntergeladen wird, sondern wie curl aufgerufen wird.

Was einige von euch vielleicht gar nicht wissen: curl ist mächtiger, als man es einem reinen „Download-Tool“ zutrauen würde. Wer die aufgerufenen Argumente kontrolliert, kann damit Dateien nicht nur herunterladen, sondern auch auf dem Zielsystem schreiben und auslesen. Und es geht noch weiter: Über geladene Bibliotheken lässt sich das Ganze bis zur Ausführung eigener Befehle treiben. Aus dem eigentlich unscheinbaren „Hol mir bitte diesen SSH-Schlüssel“ wird so ein beliebiges Lesen und Schreiben von Dateien – inklusive Code-Ausführung.

Der alles entscheidende Punkt dabei: Sowohl das Skript als auch curl laufen mit root-Rechten. Die volle Kontrolle über den curl-Befehl bedeutet damit nicht irgendeine eingeschränkte Ausführung, sondern eine vollständige Übernahme des Betriebssystems des Management-Controllers als absoluter Super-User.  Um den Angriff zu erleichtern und reproduzierbar zu machen, hat NSIDE das Tool CIMCown auf Github veröffentlicht.

Wie kritisch ist das?

Die Schwachstelle ist mit einem CVSS-Score von 9.8 bewertet. In der Praxis heißt das: Ein Angreifer benötigt zwar gültige Zugangsdaten, es genügen jedoch bereits niedrig privilegierte Konten, z.B. Read-Only-Nutzer. Die Lücke ist über das Netzwerk ausnutzbar, führt zu einem Wechsel des Scopes und resultiert im vollständigen Verlust von Vertraulichkeit, Integrität und Verfügbarkeit.

Man sollte sich vor Augen führen, was eine Kompromittierung des IMCs bedeutet: Der Controller sitzt an einer Stelle, an der er BIOS und SecureBoot beeinflussen und mit dem darüberliegenden Betriebssystem interagieren kann. Ein Angreifer, der hier root erlangt, kann sich damit tief und dauerhaft im System einnisten – weit unterhalb dessen, was klassische Schutzmaßnahmen wie EDR-Lösungen auf Betriebssystemebene überhaupt sehen. Der Vertrauensanker der gesamten Server-Hardware ist damit kompromittiert.

Gegenmaßnahmen

Die wichtigste Maßnahme ist die zeitnahe Aktualisierung auf die neueste Version, in der die Schwachstelle geschlossen ist. Ist ein Update kurzfristig nicht möglich, empfehlen wir die Web-Oberfläche (Web-UI) vollständig zu deaktivieren, um den betroffenen Angriffsweg zu unterbinden.

Darüber hinaus gilt für Management-Controller wie auch den Cisco IMC generell: Solche Schnittstellen gehören niemals offen ins interne oder gar öffentliche Netz. Ein streng segmentiertes, separates Management-Netzwerk, restriktive Zugriffskontrollen und ein sauberes Rechte-Rollen-Konzept reduzieren die Angriffsfläche erheblich – und sorgen dafür, dass eine einzelne Schwachstelle nicht gleich das gesamte Rechenzentrum gefährdet. Dennoch ersetzt sie kein Update!

Fazit

Diese Schwachstelle zeigt einmal mehr, wie aus einer komfortablen Funktion ein ernsthaftes Sicherheitsrisiko werden kann. Eine an sich sinnvolle Möglichkeit, SSH-Schlüssel per HTTP nachzuladen, wird durch unzureichend gefilterte Argumente zur vollständigen Systemübernahme als root. Der eigentliche Fehler ist dabei ein Klassiker: Benutzereingaben, die ungeprüft in einen Systemaufruf wandern.

Out-of-Band-Management ist ein mächtiges Werkzeug – aber genau diese Macht macht die dahinterliegenden Systeme zu einem lohnenden Ziel. Wer sie betreibt, sollte sie mit demselben Aufwand absichern und regelmäßig überprüfen wie die produktiven Systeme selbst.

NSIDE kann Sie zu diesem Thema mit folgenden Dienstleistungen unterstützen:

  • Penetrationstests der externen und internen Infrastruktur
  • Sicherheitsanalyse von Management-Schnittstellen und Out-of-Band-Systemen
  • Überprüfung der Netzwerksegmentierung und Härtung von Verwaltungsnetzen
  • Passive und aktive OSINT-Analysen

Wenn Sie Fragen haben oder Unterstützung bei der Überprüfung Ihrer Infrastruktur benötigen, zögern Sie nicht, uns zu kontaktieren.

Die Schwachstelle wurde von Christoph Peil (NSIDE ATTACK LOGIC GmbH) entdeckt und unter CVE-2026-20200 veröffentlicht.