CVE-2026-20230 Cisco Unified Communications Manager SSRF Scrittura Arbitraria di File a RCE – Processo di Derivazione del PoC e Riflessioni

Ambito di applicazione: solo per laboratori locali, ambienti autorizzati di riproduzione, verifica di vulnerabilità e analisi di regole di protezione. Non utilizzare su obiettivi non autorizzati. Questo articolo analizza principalmente la catena di sfruttamento di CVE-2026-20230, fenomeni verificabili, logica di giudizio e idee di difesa, senza fornire payload di attacco, contenuti di WebShell o comandi eseguibili direttamente copiabili.

1. Contesto della vulnerabilità

CVE-2026-20230 è una vulnerabilità di server-side request forgery in Cisco Unified Communications Manager (Unified CM / CUCM) e Cisco Unified Communications Manager Session Management Edition (Unified CM SME). La vulnerabilità deriva da una verifica insufficiente degli input nel flusso di elaborazione di specifiche richieste HTTP. Un attaccante può costruire richieste non autenticate per far sì che il dispositivo interessato acceda a interfacce interne o risorse locali per conto dell'attaccante.

L'impatto di questa vulnerabilità non si limita alla normale scansione SSRF. Le analisi tecniche pubbliche mostrano che, in determinate versioni e condizioni di servizio abilitato, la SSRF può essere concatenata per ottenere la capacità di scrittura arbitraria di file. L'attaccante può scrivere contenuti controllabili nel percorso del sistema operativo sottostante e quindi, utilizzando il meccanismo di caricamento dei componenti lato server o delle directory accessibili dal container Web, trasformare la scrittura di file in esecuzione di codice.

Cisco ha assegnato a questa vulnerabilità un punteggio CVSS v3.1 di 8.6 con vettore:

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

Sebbene il punteggio CVSS sia Alto (High), Cisco ha classificato il Security Impact Rating come Critico (Critical). Il motivo è che, una volta sfruttata con successo, è possibile scrivere file nel sistema operativo sottostante e potenzialmente elevare i privilegi a root.

Una nota importante: la condizione preliminare chiave per questa vulnerabilità è che il servizio WebDialer sia abilitato. WebDialer è disabilitato per impostazione predefinita, quindi non si può giudicare la vulnerabilità solo osservando un asset CUCM. La reale valutazione del rischio richiede di confermare contemporaneamente la versione del prodotto, lo stato delle patch, lo stato del servizio WebDialer e se le relative interfacce sono accessibili.

2. Perché non si può guardare solo se un'interfaccia restituisce 200?

Questa vulnerabilità non è una normale vulnerabilità Web in cui "l'accesso a un URL fisso che restituisce 200 indica la presenza". La sua catena di sfruttamento include almeno tre livelli:

1. Interfacce esterne accessibili relative a WebDialer o cmplatform.
2. Logiche di accesso interne che possono essere influenzate da SSRF.
3. Comportamenti di scrittura di file o di distribuzione di servizi che possono essere ulteriormente attivati da richieste interne.

Pertanto, l'accesso isolato a una certa interfaccia ottenendo HTTP 200, 302, 401, 404 o 500 non può dimostrare direttamente l'esistenza o l'assenza della vulnerabilità.

Ad esempio, l'accessibilità dell'interfaccia WSDL di WebDialer indica solo che il target espone funzionalità correlate a WebDialer, ma non può dimostrare che la successiva SSRF possa superare i filtri. Allo stesso modo, l'accessibilità dell'interfaccia installClusterStatusExecute indica solo l'esistenza di un punto di ingresso correlato, ma non può dimostrare da sola che la scrittura arbitraria di file sia già possibile. Al contrario, se un certo passo restituisce un'anomalia, potrebbe essere dovuto alla versione del target, alle patch, alla risoluzione del nome host, ai permessi del percorso, ai dispositivi proxy o allo stato del servizio, e non rappresenta necessariamente l'intera assenza della catena.

Un giudizio più solido dovrebbe utilizzare una combinazione di prove a più stadi:

1. Confermare che il target sia Cisco Unified CM / Unified CM SME.
2. Confermare che il servizio WebDialer sia abilitato.
3. Confermare di poter ottenere il nome host reale del target o identificatori di servizio interni.
4. Confermare che il punto di ingresso SSRF sia raggiungibile e che ci siano segni di richieste interne originate dal server.
5. In un ambiente autorizzato, confermare se si può produrre evidenza di scrittura controllata di file.
6. Combinare log lato server, modifiche del filesystem, log del container Web e dati di allarme per determinare se l'attivazione è effettivamente avvenuta.

Solo quando "WebDialer abilitato + versione interessata + comportamento SSRF confermato + scrittura controllata di file confermata" si verificano contemporaneamente, si dovrebbe giudicare la vulnerabilità come altamente affidabile e sfruttabile.

3. Idea di costruzione del PoC

Il nucleo della catena di sfruttamento attualmente pubblica non è la semplice SSRF, ma una combinazione di SSRF con il meccanismo dei servizi Axis/Java Web, la scrittura di log o la logica di elaborazione dei file di descrizione del deployment.

L'idea complessiva può essere riassunta come:

Recupero informazioni da WebDialer
    ↓
Ottenere il nome host reale del target
    ↓
Attivare SSRF tramite interfacce correlate a cmplatform
    ↓
Accedere a percorsi interni di WebDialer / Axis management
    ↓
Scrivere o distribuire contenuti controllabili di descrizione del servizio
    ↓
Formare una nuova capacità di chiamata di servizio o scrittura di file
    ↓
Trasformare la capacità di scrittura di file in script accessibili via Web
    ↓
In ambienti specifici, raggiungere ulteriormente l'esecuzione di comandi

Dalla progettazione della catena, il nome host è un punto chiave. Alcune logiche di filtraggio intercettano indirizzi locali comuni come 127.0.0.1, localhost, ma il nome host reale del target potrebbe essere permesso nel successivo flusso di richieste. Pertanto, il PoC prima estrae il nome host reale dalle informazioni WSDL di WebDialer, quindi lo utilizza come prefisso per l'accesso interno nella catena SSRF.

Il secondo punto chiave è la logica relativa al servizio Axis. Il PoC non carica direttamente file nella directory Web, ma tramite la catena di elaborazione interna del server, fa sì che i componenti lato server scrivano contenuti controllabili dall'attaccante in percorsi specifici. Questo processo è essenzialmente una combinazione di "richiesta interna lato server + comportamento di configurazione/scrittura di log dei componenti + path traversal/controllo del percorso".

Il terzo punto chiave è la scrittura in due fasi. La prima fase viene solitamente utilizzata per creare un punto di ingresso più stabile per la scrittura di file; la seconda fase scrive lo script di esecuzione comandi in una directory accessibile via Web. Il motivo è che scrivere direttamente una logica completa di esecuzione comandi in un unico passo via SSRF potrebbe essere influenzato da codifica, lunghezza, struttura XML, permessi del percorso e comportamento di parsing lato server, mentre l'approccio in due fasi rende più facile separare payload complessi.

Questo articolo non fornisce messaggi di attacco completi o contenuti di WebShell. Per la difesa e la verifica è sufficiente comprendere le seguenti caratteristiche principali:

Punto di ingresso richiesta esterna: interfacce relative allo stato di installazione di cmplatform
Punto di ingresso recupero informazioni: interfacce WSDL/services di WebDialer
Destinazione di inoltro interno: percorsi relativi a WebDialer / Axis / AdminService
Comportamenti chiave: SSRF, richieste interne lato server, scrittura controllata di file, atterraggio di file accessibili via Web
Rischio finale: scrittura arbitraria di file, atterraggio di WebShell, esecuzione comandi, percorso di elevazione a root

4. Logica di recupero del nome host