VMware bypass dell’autenticazione. Analizziamo come si arriva al PoC di sfruttamento

Redazione RHC : 27 Maggio 2022 13:12

VMware ha recentemente corretto una vulnerabilità critica di bypass dell’autenticazione nei propri prodotti VMware Workspace ONE Access, Identity Manager e vRealize Automation (CVE-2022-22972

Un attore malintenzionato con accesso all’interfaccia utente potrebbe essere in grado di ottenere l’accesso amministrativo senza la necessità di autenticarsi.

WMware fornisce istruzioni su patch e soluzioni di mitigazione, ma non dello sfruttamento del difetto di sicurezza. Scavare nella patch è un buon punto di partenza. vRealize Automation 7.6 contiene un vIDM incorporato. Da tenere presente che altri prodotti e versioni hanno flussi di lavoro ed endpoint di autenticazione diversi. 

I download e i dettagli della patch sono disponibili qui https://kb.vmware.com/s/article/70911. 

Al momento della stesura di questo documento, la patch più recente che risolve la CVE-2022-22972 è la 28 che vi consigliamo di installarla il prima possibile.

Come si è arrivati alla PoC

VMware rilascia patch cumulative, il che significa che la patch 28 risolve tutte le vulnerabilità del prodotto. Ciò rende piuttosto difficile scoprire esattamente come viene affrontata la vulnerabilità più recente. 

Per rimediare a questo problema, si possono confrontare le due patch quindi la 27 con la 28.

Dopo aver estratto le patch, si scopre che sono presenti file zip denominati patch-vRA-7.6.0-19482496-HF27.content nella patch 27 e patch-vRA-7.6.0-19772459.19640138-HF28.content nella patch 28.

Estraendo questi file zip si può quindi avere accesso al contenuto delle patch. Non ci sono molte differenze degne di nota nelle cartelle, ma è presente un rpm del servizio Horizon che non è più al suo posto.

Usando rpm2cpio si può quindi estrarre il contenuto. 

Troviamo quindi tre differenze: dbConnection-0.1-jar-with-dependencies.jar, analytics-0.1.war, e frontend-01.war. 

Estraiamo quindi i .warfile per trovare quanto segue relativamente a frontend-01.war:

Diff del war frontend

In particolare, troviamo un nuovo HostHeaderFilter.class e alcune differenze in web.xml dove viene mostrato che il nuovo HostHeaderFilter che viene applicato a tutti i modelli di URL.

web.xml diff

Usando quindi un decompilatore Java, si può convertire il file HostHeaderFilter.class in HostHeaderFilter.java:

HostHeaderFilter.java

Vediamo che questo filtro rifiuta qualsiasi richiesta con un’intestazione Host ritenuta non valida. 

Questa è una cosa interessante da indagare e può essere appunto il modo per inviare strane intestazioni host.

Esame del runtime

Dopo aver esplorato senza successo vari endpoint, si nota qualcosa di strano durante l’invio di un’intestazione host non valida all’endpoint di accesso. 

Si imposta quindi l’ Host su un valore falso, ovvero “asfd”.

richiesta di intestazione host non valida

Non c’è nulla degno di nota nella richiesta stessa, ma se osserviamo horizon.log, possiamo vedere che l’applicazione sta cercando di risolvere “asdf“.

Errore di risoluzione DNS

Ciò indica che l’applicazione sta tentando di stabilire una connessione a ciò che abbiamo inserito nell’intestazione Host.

Esecuzione di un server di accesso

Il prossimo passo è quello di capire come l’app si connetta per vedere che tipo di informazioni stia tentando di inviare. Pertanto è possibile scrivere un semplice server https:

server https

Dopo aver inserito il nostro indirizzo IP nell’intestazione dell’host, vediamo una nuova eccezione nel registro:

Eccezione SSL

Questo errore indica che l’applicazione non è in grado di convalidare il nostro certificato. 

Questo ha senso perché il certificato sul nostro server è self signed. 

Dopo aver aggiunto il nostro certificato nell’archivio certificati Java dell’appliance, possiamo vedere che l’applicazione si connette effettivamente al nostro server e invia le informazioni di accesso in una richiesta HTTP POST. 

Da tenere presente che un utente malintenzionato non dovrebbe replicare questo passaggio. Potrebbero invece ospitare sul proprio server di accesso un server pubblico con un certificato valido.

connessione al server di autenticazione

L’applicazione si aspetta una risposta dal server HTTP per sapere se all’utente deve essere concesso o meno l’accesso. Si riscrive quindi il server per rispondere con uno stato 200 a qualsiasi richiesta POST.

server https

Con il nuovo server, siamo in grado di accedere con successo!

login effettuato con successo

Automatizzare l’exploit

Finora abbiamo utilizzato il proxy di Burp Suite per modificare le richieste inviate da un browser, ma ora vorremmo automatizzare questo flusso di lavoro per utilizzare degli exploit PoC. 

Alla fine si tratterebbe di inviare tramite metodo POST

SAAS/auth/login/embeddedauthbroker/callback

Dove nell’Host venga riportata una intestazione personalizzata. 

Questo endpoint richiede la codifica di alcuni metadati aggiuntivi nel corpo del POST. Se esaminiamo la fonte della pagina di accesso, troviamo le informazioni di cui abbiamo bisogno nei campi e dei moduli nascosti.

campi modulo nascosti

Il nostro POC invia le richieste a partire da /vcac dall’endpoint allo stesso modo di un browser e analizza la pagina di accesso per estrarre questi campi nascosti. 

Questi campi nascosti vengono quindi codificati nel corpo del POST finale con l’intestazione Host impostata sul nostro server di accesso personalizzato. Il POC analizza quindi la risposta per estrarre i cookie di autenticazione. Questi cookie possono essere utilizzati per eseguire azioni come l’utente scelto.

L’exploit PoC

Questo script può essere utilizzato ignorando l’autenticazione su vRealize Automation 7.6 utilizzando la CVE-2022-22972. Workspace ONE e vIDM hanno endpoint di autenticazione diversi, ma il punto cruciale della vulnerabilità rimane lo stesso.

Riepilogo

La CVE-2022-22972 è una vulnerabilità di manipolazione dell’intestazione Host relativamente semplice. 

Gli aggressori motivati ​​non avrebbero difficoltà a sviluppare un exploit per questa vulnerabilità. Una rapida ricerca su Shodan.io per le applicazioni VMware interessate restituisce un numero piuttosto basso di organizzazioni che le espongono a Internet. 

Da notare che l’industria sanitaria, l’industria dell’istruzione e i governi sembrano far parte delle organizzazioni esposte, mettendole a rischio per lo sfruttamento attuale e futuro. 

Le organizzazioni dovrebbero affrontare questi problemi seguendo immediatamente le indicazioni contenute nel VMware Security Advisory.

Fonti
CVE-2022-22972
CVE-2022-22972
CVE-2022-22972

Redazione
La redazione di Red Hot Cyber è composta da un insieme di persone fisiche e fonti anonime che collaborano attivamente fornendo informazioni in anteprima e news sulla sicurezza informatica e sull'informatica in generale.

Lista degli articoli