CVE-2026-20230 Cisco Unified Communications Manager SSRF Beliebiger Datei-Schreibzugriff zu RCE PoC – Ableitungsprozess und Überlegungen

Anwendungsbereich: Nur für lokale Testumgebungen, autorisierte Reproduktionsumgebungen, Schwachstellenverifizierung und Analyse von Schutzregeln. Nicht gegen nicht autorisierte Ziele verwenden. Dieser Artikel analysiert hauptsächlich die Angriffskette von CVE-2026-20230, verifizierbare Phänomene, Bewertungslogik und Verteidigungsgedanken, liefert jedoch keine direkt ausführbaren Angriffsnachrichten, WebShell-Inhalte oder Befehlsausführungslasten.

1. Hintergrund der Schwachstelle

CVE-2026-20230 ist eine Server-Side-Request-Forgery-Schwachstelle (SSRF) in Cisco Unified Communications Manager (Unified CM / CUCM) und Cisco Unified Communications Manager Session Management Edition (Unified CM SME). Diese Schwachstelle resultiert aus unzureichender Eingabevalidierung im Verarbeitungsablauf bestimmter HTTP-Anfragen. Ein Angreifer kann ohne Authentifizierung Anfragen konstruieren, die das betroffene Gerät dazu veranlassen, im Namen des Angreifers auf interne Schnittstellen oder lokale Ressourcen zuzugreifen.

Die Auswirkungen dieser Schwachstelle gehen über gewöhnliche SSRF-Erkundung hinaus. Öffentliche technische Analysen zeigen, dass unter bestimmten Versions- und Dienstaktivierungsbedingungen die SSRF zu einer beliebigen Datei-Schreibfähigkeit erweitert werden kann. Der Angreifer kann kontrollierten Inhalt in den zugrunde liegenden Betriebssystempfad schreiben und dann über das Web-Container-zugängliche Verzeichnis oder den Serverkomponenten-Lademechanismus das Dateischreiben in Code-Ausführung umwandeln.

Cisco bewertet diese Schwachstelle mit einem CVSS v3.1-Score von 8,6, Vektor:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:N

Obwohl der CVSS-Score als "High" eingestuft wird, hat Cisco die Security Impact Rating dieser Schwachstelle als "Critical" markiert. Der Grund ist, dass bei erfolgreicher Ausnutzung Dateien im zugrunde liegenden Betriebssystem geschrieben werden können und möglicherweise eine Rechteausweitung auf Root erfolgen kann.

Besonders zu beachten ist, dass die wesentliche Voraussetzung für diese Schwachstelle ist, dass der WebDialer-Dienst aktiviert sein muss. WebDialer ist standardmäßig deaktiviert, daher kann nicht allein aufgrund des Vorhandenseins eines CUCM-Assets auf eine ausnutzbare Schwachstelle geschlossen werden. Die tatsächliche Risikobewertung erfordert die gleichzeitige Bestätigung der Produktversion, des Patch-Status, des WebDialer-Dienststatus und der Zugänglichkeit der relevanten Schnittstellen.

2. Warum kann man nicht nur darauf achten, ob eine Schnittstelle 200 zurückgibt?

Diese Schwachstelle ist keine gewöhnliche Web-Schwachstelle, bei der "Zugriff auf eine bestimmte feste URL und Rückgabe von 200 = Schwachstelle vorhanden". Ihre Angriffskette umfasst mindestens drei Ebenen:

1. Extern zugängliche WebDialer- oder cmplatform-bezogene Schnittstellen.
2. Interne Zugriffslogik, die durch SSRF beeinflusst werden kann.
3. Dateischreib- oder Dienstbereitstellungsverhalten, das durch interne Anfragen weiter ausgelöst werden kann.

Daher kann der alleinige Zugriff auf eine bestimmte Schnittstelle und der Erhalt von HTTP 200, 302, 401, 404 oder 500 weder das Vorhandensein noch das Fehlen der Schwachstelle direkt beweisen.

Zum Beispiel zeigt die Zugänglichkeit der WebDialer-WSDL-Schnittstelle nur, dass das Ziel die WebDialer-Funktionalität offengelegt hat, nicht aber, dass die anschließende SSRF die Filterung durchdringen kann. Die Zugänglichkeit der installClusterStatusExecute-Schnittstelle zeigt nur das Vorhandensein eines entsprechenden Einstiegspunkts, nicht aber, dass ein beliebiges Dateischreiben bereits etabliert ist. Umgekehrt könnte ein Fehler in einem Schritt auf Zielversion, Patch, Hostname-Auflösung, Pfadberechtigungen, Proxy-Gerät oder Dienststatus zurückzuführen sein, nicht unbedingt darauf, dass die gesamte Angriffskette nicht existiert.

Eine sicherere Bewertung sollte eine mehrstufige Beweiskombination verwenden:

1. Bestätigen, dass das Ziel ein Cisco Unified CM / Unified CM SME ist.
2. Bestätigen, dass der WebDialer-Dienst aktiviert ist.
3. Bestätigen, dass der tatsächliche Hostname oder die interne Dienstkennung des Ziels abrufbar ist.
4. Bestätigen, dass der SSRF-Einstiegspunkt erreichbar ist und es Anzeichen für vom Server initiierte interne Anfragen gibt.
5. In autorisierten Testumgebungen bestätigen, ob kontrollierte Dateischreibnachweise erzeugt werden können.
6. In Kombination mit Serverprotokollen, Dateisystemänderungen, Web-Container-Protokollen und Alarmdaten beurteilen, ob eine tatsächliche Auslösung erfolgt ist.

Nur wenn "WebDialer aktiviert + betroffene Version + SSRF-Verhalten bestätigt + kontrolliertes Dateischreiben bestätigt" gleichzeitig auftreten, sollte dies als hochvertrauenswürdig ausnutzbar eingestuft werden.

3. PoC-Konstruktionsgedanken

Der Kern der aktuellen öffentlichen Angriffskette ist nicht nur die reine SSRF, sondern die Kombination von SSRF mit Axis/Java-Web-Service-Mechanismen, Log-Schreiben oder Verarbeitungslogik von Deployment-Deskriptordateien.

Der Gesamtgedanke lässt sich wie folgt zusammenfassen:

Informationserfassung über WebDialer
    ↓
Abrufen des tatsächlichen Hostnames des Ziels
    ↓
Auslösen von SSRF über cmplatform-bezogene Schnittstellen
    ↓
Zugriff auf internen WebDialer / Axis-Verwaltungspfad
    ↓
Schreiben oder Bereitstellen von kontrolliertem Dienstbeschreibungsinhalt
    ↓
Bildung neuer aufrufbarer Dienste oder Dateischreibfähigkeit
    ↓
Umwandlung der Dateischreibfähigkeit in ein Web-zugängliches Skript
    ↓
Unter bestimmten Umgebungen weitere Erreichung von Befehlsausführung

Aus dem Kettendesign ist der Hostname ein entscheidender Punkt. Einige Filterlogiken blockieren gängige lokale Adressen wie 127.0.0.1, localhost, aber der tatsächliche Hostname des Ziels kann in den nachfolgenden Anfrageablauf zugelassen werden. Daher extrahiert der PoC zuerst den tatsächlichen Hostnamen aus den WSDL-Informationen von WebDialer und verwendet ihn dann als internes Zugriffspräfix in der SSRF-Kette.

Der zweite entscheidende Punkt ist die Logik im Zusammenhang mit Axis-Diensten. Der PoC lädt keine Dateien direkt in das Web-Verzeichnis hoch, sondern bewirkt über die interne Dienstverarbeitungskette, dass Serverkomponenten den vom Angreifer kontrollierten Inhalt in bestimmte Pfade schreiben. Dieser Prozess ist im Wesentlichen eine Kombination aus "interne Serveranfrage + Komponentenkonfiguration/Log-Schreibverhalten + Pfaddurchquerung/Pfadkontrolle".

Der dritte entscheidende Punkt ist das zweistufige Schreiben. Die erste Stufe dient in der Regel dazu, einen stabileren Dateischreibeinstieg zu schaffen. Die zweite Stufe schreibt dann das Befehlsausführungsskript in ein Web-zugängliches Verzeichnis. Der Grund dafür ist, dass ein direkter einstufiger Schreibvorgang der vollständigen Befehlsausführungslogik über SSRF durch Kodierung, Länge, XML-Struktur, Pfadberechtigungen und Serververarbeitungsverhalten beeinträchtigt werden kann, während der zweistufige Ansatz die komplexe Last einfacher aufteilen kann.

Dieser Artikel liefert keine vollständigen Nutzlastnachrichten und WebShell-Inhalte. Für Schutz und Verifizierung reicht es aus, die folgenden Kernmerkmale zu verstehen:

Externer Anforderungseingang: cmplatform-Installationsstatus-Schnittstellen
Informationserfassungseingang: WebDialer WSDL / Services-Schnittstellen
Internes Weiterleitungsziel: WebDialer / Axis / AdminService-Pfade
Kernverhalten: SSRF, interne Serveranfragen, kontrolliertes Dateischreiben, Web-zugängliche Dateiablage
Endrisiko: Beliebiges Dateischreiben, WebShell-Ablage, Befehlsausführung, Root-Rechteausweitungspfad

4. Hostname-Ermittlungslogik

Der PoC muss zunächst den tatsächlichen Hostnamen des Ziels ermitteln, nicht nur die IP-Adresse oder den externen Domänennamen verwenden.