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.
Prompt Engineering & Sicurezza: diventa l’esperto che guida l’AIVuoi dominare l’AI generativa e usarla in modo sicuro e professionale? Con il Corso Prompt Engineering: dalle basi alla cybersecurity, guidato da Luca Vinciguerra, data scientist ed esperto di sicurezza informatica, impari a creare prompt efficaci, ottimizzare i modelli linguistici e difenderti dai rischi legati all’intelligenza artificiale. Un percorso pratico e subito spendibile per distinguerti nel mondo del lavoro. Non restare indietro: investi oggi nelle tue competenze e porta il tuo profilo professionale a un nuovo livello. Guarda subito l'anteprima gratuita del corso su academy.redhotcyber.com Contattaci per ulteriori informazioni tramite WhatsApp al 375 593 1011 oppure scrivi a [email protected] ![]() Supporta RHC attraverso:
Se ti piacciono le novità e gli articoli riportati su di Red Hot Cyber, iscriviti immediatamente alla newsletter settimanale per non perdere nessun articolo. La newsletter generalmente viene inviata ai nostri lettori ad inizio settimana, indicativamente di lunedì. |
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.
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.
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.
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
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.
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.
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
Avevamo già parlato della proposta di regolamento “ChatControl” quasi due anni fa, ma vista la roadmap che è in atto ci troviamo nell’imbarazzo di doverne parlare nuovamente. Sembra però un d...
ShinyHunters è un gruppo noto per il coinvolgimento in diversi attacchi informatici di alto profilo. Formatosi intorno al 2020, il gruppo ha guadagnato notorietà attraverso una serie di attacchi mir...
La notizia è semplice, la tecnologia no. Chat Control (CSAR) nasce per scovare CSAM e dinamiche di grooming dentro le piattaforme di messaggistica. La versione “modernizzata” rinuncia alla backdo...
A cura di Luca Stivali e Olivia Terragni. L’11 settembre 2025 è esploso mediaticamente, in modo massivo e massiccio, quello che può essere definito il più grande leak mai subito dal Great Fir...
Una violazione di dati senza precedenti ha colpito il Great Firewall of China (GFW), con oltre 500 GB di materiale riservato che è stato sottratto e reso pubblico in rete. Tra le informazioni comprom...