Overview
In this article we discuss a recent cross-site websocket hijacking (CSWSH) vulnerability that we identified in MeshCentral, a web-based remote monitoring and endpoint management solution. MITRE assigned the CVE identifier CVE-2024-26135. End users can use MeshCentral to install agents that communicate with a centralized server. The centralized server then allows users to perform remote management tasks such as downloading and uploading files to the system, remote desktop control, and the ability to run and execute commands on the endpoint.
The vulnerability is exploitable when an attacker is able to convince a victim end-user to click on a malicious link to a page hosting an attacker-controlled site. The attacker can then originate a cross-site websocket connection using client-side JavaScript code to connect to the “control.ashx” endpoint as the victim user within MeshCentral. However, exploitation can be difficult in some scenarios due to the SameSite security policy (we cover this in a subsequent section).
Exploitation of the vulnerability results in complete compromise of the victim user’s account with persistent access enabled by the ability to generate login tokens and leak the sessionKey variable used to sign session cookies when the victim user is an administrator. In the subsequent sections we outline the impact of the SameSite=Lax security setting on exploitation and discuss our proof-of-concept exploit for the vulnerability.
Identifying the Vulnerability
When reviewing the MeshCentral management console we observed that the application primarily leveraged websockets for frontend to backend communication. The traffic on the Websocket connection included common management tasks such as adding/deleting user accounts, creating login tokens, and performing other administrative actions (see Figure 1 and Figure 2). We observed that there weren’t any security checks within the application restricting the allowed origins that could initiate websocket connections with the control.ashx endpoint. However, there were some SameSite security restrictions implemented within modern browsers we had to overcome for exploitation to be viable.
Figure 1: We observed that the control.ashx endpoint was leveraged to initiate websocket connections.
Figure 2: We observed the control.ashx endpoint was used for websocket communications used for performing management related tasks within MeshCentral.
What about SameSite=Lax Cookie Settings?
We observed after logging into MeshCentral that the session cookies were configured explicitly with the SameSite=Lax security setting (see Figure 3). This security setting introduced additional restrictions on cross-origin requests including cross-site websocket connections. An attacker that is able to convince a user to click on a malicious link wouldn’t be able to successfully perform the attack from an attacker-controlled hosted origin (e.g. attacker.com) due to the SameSite security setting.
Figure 3: We observed that the session cookie returned after authentication included the SameSite=Lax security setting on the issued cookies.
However, this isn’t entirely correct as there is a core difference between same-site and same-origin policies within all modern browsers. In this case, while it’s valid to say that the attack wouldn’t work in the case of attacker.com targeting a MeshCentral instance at say meshcentral.example.com, there are several scenarios where such an attacker could perform the attack successfully (see Figure 4).
Figure 4: A table from PortSwigger’s article on Bypassing SameSite Cookie Restrictions (source).
From our perspective, the most relevant scenario is when an attacker is able to compromise an adjacent subdomain either through a vector such as a system compromise, exploiting a subdomain takeover vulnerability, or through exploitation of a cross-site scripting vulnerability within an adjacent application running under the same top-level domain.
For example, if an attacker found a cross-site scripting issue on example.com or vulnerable.example.com they would then be able to leverage the cross-site scripting issue on those domains to target meshcentral.example.com to perform a cross-site websocket hijacking attack. There are other factors which could also allow an attacker to bypass the SamSite=Lax setting to perform cross-site websocket hijacking. For a more comprehensive list please see Bypassing SameSite Cookie Restrictions from PortSwigger.
We performed testing by creating an attacker-domain evil.example.com to host malicious content to simulate an attacker exploiting a subdomain takeover vulnerability. We initiated a cross-site websocket connection from evil.example.com to meshcentral.example.com and observed that cookies were sent in the cross-origin request as expected (see Figure 5).
Figure 5: An example exploit leveraging a cross-origin websocket connection from a compromised subdomain to bypass SameSite security restrictions.
Developing an Exploit to Demonstrate Impact
After confirming the vulnerability we then developed a comprehensive exploit payload to demonstrate the impact of the issue (see Figure 6). Our new payload sent the serverconfig, authcookie, and createLoginToken actions to the administrative component through the websockets channel established from evil.example.com. The ability to issue a new login token provided us with persistent access to the victim user’s account after exploitation. The ability to read the serveronfig file allowed us to exfiltrate the session key used to sign sessions allowing the attacker to forge valid session tokens as arbitrary users on the system. Our payload then read the response from the server and exfiltrated the sensitive data exported from the system to an attacker-controlled system for storage purposes (see Figure 7).
Figure 6: A proof-of-concept exploit we developed for the cross-site websocket hijacking vulnerability resulting in complete compromise of the user’s account and persistent access to the MeshCentral application as the victim user.
Figure 7: We performed the attack using the exploit code shown in Figure 7 to invoke the authcookie, serverconfig, and createLoginToken endpoints on the victim MeshCentral system leveraging the cross-origin websocket hijacking vulnerability from evil.example.com.
After performing the attack successfully we used the issued login tokens to authenticate to MeshCentral and access the local console of a node as the NT AUTHORITYSYSTEM user through a windows agent connected to the victim MeshCentral instance. This resulted in a compromise of all the nodes within the impacted MeshCentral instance (see Figure 8). We also demonstrated a compromise of the sessionKey value used to sign session cookies allowing the attacker to authenticate as an user account on the system (see Figure 9).
Figure 8: An attacker could leverage the login token created by the attacker to authenticate to MeshCentral and then leverage this access to compromise nodes managed by the impacted MeshCentral agent.
Figure 9: An attacker could leverage the cross-site websocket hijacking vulnerability to read the configuration file of the MeshCentral system as an administrator to obtain the key used to encrypt sessions (sesesionKey).
Conclusion
In this article we discussed the cross-origin websocket hijacking vulnerability we identified through dynamic testing of the MeshCentral application. It’s easy to dismiss these types of client-side issues as being a largely theoretical vulnerability. However, An Trinh, in his article Argo CD CSRF outlines an interesting case study where he exploited a CSRF vulnerability with similar preconditions targeting a customer’s Argo CD instance during a red team engagement.
Our team continues to perform proactive vulnerability research to identify vulnerabilities in widely used enterprise software applications. Proactive vulnerability research allows us to identify security vulnerabilities in applications within a client’s attack surface before an attacker has a chance to exploit them. Chariot, by monitoring and categorizing external assets, helps us identify applications that warrant further review by our team.
