CVE-2024-26135

MeshCentral is a full computer management web site. Versions prior to 1.1.21 a cross-site websocket hijacking (CSWSH) vulnerability within the control.ashx endpoint. This component is the primary mechanism used within MeshCentral to perform administrative actions on the server. 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 control.ashx as the victim user within MeshCentral. Version 1.1.21 contains a patch for this issue.

MeshCentral is a full computer management web site. Versions prior to 1.1.21 a cross-site websocket hijacking (CSWSH) vulnerability within the control.ashx endpoint. This component is the primary mechanism used within MeshCentral to perform administrative actions on the server. 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 control.ashx as the victim user within MeshCentral. Version 1.1.21 contains a patch for this issue.

We have identified a cross-site websocket hijacking (CSWSH) vulnerability within the control.ashx endpoint of MeshCentral. This component is the primary mechanism used within MeshCentral to perform administrative actions on the server. To demonstrate the impact of the vulnerability we developed a proof-of-concept which leveraged the cross-site websocket hijacking vulnerability to read the server configuration file to leak the sessionKey variable, generating login tokens, and generating an authentication cookie.

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 “control.ashx” as the victim user within MeshCentral. There are some caveats to exploiting this issue however as MeshCentral configures SameSite=Lax security setting on cookies which introduces some additional preconditions for exploitation which we cover in a subsequent section.

MeshCentral Version Tested

We performed testing against MeshCentral version 1.1.20 which appears to be the latest supported version of the application. This appears to have been the latest version of MeshCentral available at the time we performed testing of the application in January and February 2024 (see Figure 1 and Figure 2).

Figure 1: We determined that MeshCentral version 1.1.20 was the latest version available at the time we performed testing of the application.

Figure 2: We configured our test environment on an Ubuntu server running version 1.1.20 of the MeshCentral application server.

What about SameSite=Lax Cookie Settings?

One may make the counterpoint that the SameSite=Lax security setting (see Figure 4) effectively prevents cross-site websocket hijacking (CSWSH) issues as an attacker origin of attacker.com would not be within the same-site as the victim meshcentral server at say meshcentral.example.com. This means an attacker that is able to convince a user to click on a malicious link wouldn’t be able to successfully perform this attacker to the Lax setting with differing origins.

Unfortunately, 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 meshcentral.example.com when the SameSite setting is configured to Lax for session cookies, there are several other scenarios where an attacker could perform the attack successfully (see Figure 3).

Figure 3: 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 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 issues on those domains to target meshcentral.example.com. There are other factors which could also allow an attacker to bypass the SameSite=Lax setting to perform cross-site websocket hijacking. For a more comprehensive list please see Bypassing SameSite Cookie Restrictions from PortSwigger.

Figure 4: We observed that…

MeshCentral is a full computer management web site. Versions prior to 1.1.21 a cross-site websocket hijacking (CSWSH) vulnerability within the control.ashx endpoint. This component is the primary mechanism used within MeshCentral to perform administrative actions on the server. 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 control.ashx as the victim user within MeshCentral. Version 1.1.21 contains a patch for this issue.

MeshCentral is a full computer management web site. Versions prior to 1.1.21 a cross-site websocket hijacking (CSWSH) vulnerability within the control.ashx endpoint. This component is the primary mechanism used within MeshCentral to perform administrative actions on the server. 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 control.ashx as the victim user within MeshCentral. Version 1.1.21 contains a patch for this issue.

We have identified a cross-site websocket hijacking (CSWSH) vulnerability within the control.ashx endpoint of MeshCentral. This component is the primary mechanism used within MeshCentral to perform administrative actions on the server. To demonstrate the impact of the vulnerability we developed a proof-of-concept which leveraged the cross-site websocket hijacking vulnerability to read the server configuration file to leak the sessionKey variable, generating login tokens, and generating an authentication cookie.

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 “control.ashx” as the victim user within MeshCentral. There are some caveats to exploiting this issue however as MeshCentral configures SameSite=Lax security setting on cookies which introduces some additional preconditions for exploitation which we cover in a subsequent section.

MeshCentral Version Tested

We performed testing against MeshCentral version 1.1.20 which appears to be the latest supported version of the application. This appears to have been the latest version of MeshCentral available at the time we performed testing of the application in January and February 2024 (see Figure 1 and Figure 2).

Figure 1: We determined that MeshCentral version 1.1.20 was the latest version available at the time we performed testing of the application.

Figure 2: We configured our test environment on an Ubuntu server running version 1.1.20 of the MeshCentral application server.

What about SameSite=Lax Cookie Settings?

One may make the counterpoint that the SameSite=Lax security setting (see Figure 4) effectively prevents cross-site websocket hijacking (CSWSH) issues as an attacker origin of attacker.com would not be within the same-site as the victim meshcentral server at say meshcentral.example.com. This means an attacker that is able to convince a user to click on a malicious link wouldn’t be able to successfully perform this attacker to the Lax setting with differing origins.

Unfortunately, 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 meshcentral.example.com when the SameSite setting is configured to Lax for session cookies, there are several other scenarios where an attacker could perform the attack successfully (see Figure 3).

Figure 3: 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 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 issues on those domains to target meshcentral.example.com. There are other factors which could also allow an attacker to bypass the SameSite=Lax setting to perform cross-site websocket hijacking. For a more comprehensive list please see Bypassing SameSite Cookie Restrictions from PortSwigger.

Figure 4: We observed that…