A Watchguard Vulnerability That's a "Feature"- GuardLapse

On some days in cybersecurity engagements, you expect the ordinary. Then there are moments that catch you completely off-guard.

The Feature

WatchGuard firewalls offer a nifty feature. Network managers can ensure users sign in to the firewall before they get internet access.

Of course, making users authenticate every day would annoy them. So, it's beneficial if the WatchGuard device could associate an IP address to a domain user based on domain logins.

Enter WatchGuard's Active Directory (AD) Single Sign On (SSO).

WatchGuard's AD SSO feature offers two methods attackers might find interesting: the Event Log Monitor and the AD Mode with the SSO Agent. Let's see what the WatchGuard documentation reveals about these methods.

AD Mode - SSO Agent

In AD Mode, to get the user credentials, the SSO Agent makes a NetWkstaUserEnum call to the client computer over TCP port 445. The SSO Agent then uses the information it gets to authenticate the user for SSO. The SSO Agent uses only the first answer it gets from the computer. It sends a notification about that user to the Firebox as the user that is logged on.

Event Log Monitor

If you use the Event Log Monitor, when a user tries to authenticate, the SSO Agent sends the IP address of the client computer to the Event Log Monitor. The Event Log Monitor then uses this information to query the client computer over TCP port 445 and retrieve the user credentials from the Windows security event log file on the client computer.

Documentation: How Active Directory SSO Works (watchguard.com)

Both methods count as options for Clientless SSO where the PC doesn't have the optional SSO client installed.

Represented in a flowchart, this is how I understand Clientless SSO works at a high level:

The Issue

If you've done some threat modeling, you might already see the issue.

The feature, though well-intentioned, assumes all devices on the network are trustworthy. However, should a rogue actor like Malicious Malory lurk on the network instead of a standard workstation, it could lead to a bit of a problem.

When Malory tries to browse the internet, her IP isn't linked to a domain user. If any of the aforementioned Clientless SSO methods are enabled, she can capture authentication requests from a WatchGuard AD account just by trying to browse the internet.

This behavior is exactly what I observed on a recent engagement.

Lacking an official CVE number to label this issue, I'll be calling it "GuardLapse" for easy reference.

Exploitation and Impact

In GuardLapse, there are two main exploitation routes:

1. Cracking the Password Hash

Malicious Malory can set up a rogue SMB server. Instead of working as expected, this server accepts authentication requests and grabs the password hash.

If she cracks the password hash successfully, she gains access to whatever the WatchGuard AD account can access.

Even with ZERO privileges assigned to the WatchGuard AD account, authenticated access to the domain in AD environments exposes many attack avenues - Kerberoasting, user enumeration for password spraying, BloodHound recon, and more.

2. SMB Relaying

If other domain PCs don't require SMB signing, she can directly relay the authentication requests to access targeted hosts, eliminating the need to crack the password hash! (This depends on the AD account having admin privileges on targeted hosts).

To show the impact, in my recent engagement, we transitioned from an unauthenticated device on the network to Domain Admin using this issue. We relayed WatchGuard authentication requests to get an initial foothold on several devices. We then exploited other vulnerabilities to secure Domain Admin privileges.

WatchGuard's Response

When I contacted WatchGuard about the behaviour I observed, they responded promptly and helpfully.

They pointed me to the documentation about WatchGuard's Clientless AD SSO methods, which they thought explained what I saw. When I asked about their plans to retire or rework this feature, WatchGuard said they might retire AD Mode but would keep the Event Log Monitor.

They also said they were exploring options to enhance the visibility of security risks associated with Clientless SSO based on my report.

Action

If you use a WatchGuard firewall and rely on clientless SSO, my current, unvalidated recommendation is:

1. Switch off AD mode and rely on the SSO Client.
2. Remove the Event Log Monitor if you've installed it.

NOTE: I haven't validated this fix because I don't own a WatchGuard firewall. If you want to collaborate to validate this fix, please get in touch!

I've also asked WatchGuard for their remediation advice given their customers' current risk. Once they reply, I'll update this post with their guidance.