Author(s): Dennis Carlson

Before delving into the technical details of CVE-2023-47256 and CVE-2023-47257, it is important to recognize the ConnectWise team for their rapid response to this vulnerability disclosure. Gotham Security notes that throughout the disclosure process, ConnectWise worked as an exceptional cybersecurity partner. All disclosures made to ConnectWise were treated with a professional and timely response.

ConnectWise ScreenConnect is a remote support and remote administration tool that is widely used by both IT staff and IT managed service providers (MSPs). Once the ScreenConnect client is installed on a computer, administrators can remotely control the system as if they were physically in front of it. Across the IT industry, many leverage ScreenConnect as their primary resource to assist users or configure systems.

However, with the discovery of CVE-2023-47257, it was found that Man-in-the-Middle (MitM) attackers could perform Remote Code Execution (RCE) as “NT AUTHORITY\System” through the ScreenConnect client. If executed on a local network, it would be possible for an attacker to obtain RCE with local administrative permissions across all network-connected systems where the ScreenConnect client is installed, irrespective of the operating system. Although this attack is more practical to perform on a local network, it is technically possible for this attack to be executed anywhere in the routing chain, though this may prove much more difficult to accomplish.

With CVE-2023-47256, it was additionally found that the ScreenConnect client could be tricked into trusting proxy configurations from non-administrative local users. When combined with CVE-2023-47256, a non-privileged attacker with existing access to a system could reliably perform Local Privilege Escalation (LPE) and Remote Code Execution (RCE) as “NT AUTHORITY\System”. If an attacker leverages this implicit trust of user proxies, they would not need to perform a network-based MitM attack to exploit CVE-2023-47257.

To fully understand this vulnerability, it must first be understood how the ScreenConnect client generally operates under normal circumstances. ScreenConnect is typically used to provide remote assistance or remote administration of Linux, Windows, and Mac systems. This is done by installing the ScreenConnect client to the system as a local service, where the client maintains an active connection to ConnectWise relay servers. Although the client makes this connection outbound on TCP port 443, it does not utilize HTTPS. Instead, it leverages a custom protocol that similarly implements RSA key pairs for the negotiation of the socket’s encryption key.

When validating the authenticity of the relay server, the ScreenConnect client relies heavily on the server's ability to complete the initial handshake. This initial handshake expects the relay server to know a preconfigured RSA private key, which has been hard-coded into the client service’s launch arguments and configuration file. The relay server must use its RSA private key to decrypt a randomly-generated secret received from the client in order to begin encryption on the socket and subsequently complete the handshake. It should be noted that completion of this handshake is the only form of authentication performed by the client against the relay server.

Leveraging CVE-2023-47257, it is possible to skip the initial handshake (and, by extension, verification of the relay server) by sending crafted messages to the client. If the ScreenConnect client is also installed as a local service, which is commonly done when deployed for remote management, the MitM attacker could pose as a legitimate relay server and perform Remote Code Execution (RCE) as “NT AUTHORITY\System” under Windows or a privileged user account under Linux/Mac.

The vulnerable code exists within "ScreenConnect.Core.dll" under the ScreenConnect.SocketEndpointManager.RunIncomingThread function. By decompiling the code, we can see at the beginning of the message processing loop, all incoming messages will be validated as sub-classes of HandshakeMessage until IsHandshakeComplete is set. This is meant to ensure that a fake relay cannot send privileged messages until a handshake has been completed.

Looking further into the message processing loop, we can see that after checking whether the message is a HandshakeMessage, there are several other HandshakeMessage sub-classes allowed aside from the ServerHelloMessage. It should be noted that the ServerHelloMessage is what typically begins transparent encryption on the socket.

Specifically, focus your attention on the SessionInfoMessage and SessionInfoMessageOld5 handler. Under this handler, we can see that the first action performed is to flip the session's IsHandshakeComplete value to true. Once this value is set, the message type restriction to HandshakeMessage is cleared, and the fake relay can then send arbitrary messages to the client.

What this ultimately means is that if a remote attacker can route the client into connecting to their fake relay through something like a MitM attack, it is possible to bypass the socket's encryption and relay validation step by sending a fake SessionInfoMessage to complete the handshake. From that point onward, it is possible to transfer files, execute commands, or any other actions that would be allowed by a legitimate connection.

Supposing an attacker is able to perform a MitM attack anywhere in the routing process, we believe it is possible to leverage this vulnerability remotely. Given the level of access granted to the local system, which extends beyond just the ScreenConnect component, we believe this also widens the scope of the vulnerability. Taking into account the added complexity of performing a MitM attack, this levels out to a CVSS score of 9.0 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H).

During the analysis of the ScreenConnect client, it was found that the local service could be tricked into trusting the proxy configuration for non-administrative local users. This vulnerability was not only reliable in exploitation but could also result in Local Privilege Escalation when chained with CVE-2023-47257.

If we decompile "ScreenConnect.Windows.dll" and look at the ScreenConnect.WindowsClientToolkit.WindowsProxyAttempter.GetPossibleProxyUris function, we can see the exact process used to determine which proxy URI should be used. For now, take note that this function will first attempt to use the configuration's ExplicitProxyUri and DiscoveredProxyUri values.

If neither of these options produces a working proxy URI, ScreenConnect will attempt to enumerate through active user sessions and connect to the relay server using their proxy configurations. This is where we can trick the system into connecting to our fake relay. By setting the local user's proxy configuration to the fake relay, disconnecting from the network, and sleeping/awakening the device, ScreenConnect will see our proxy as functional, and we can perform privilege escalation through CVE-2023-47257.

Interestingly, this seems to be an intentional feature of ScreenConnect. If ScreenConnect encounters a situation where no other connections to the relay server are functional, it will save the first functional user proxy to its configuration file as the DiscoveredProxyUri value. As noted above, the DiscoveredProxyUri value is one of the first proxy URIs attempted. So once this change is made, re-connection through the proxy should be fairly reliable.

This vulnerability has a standalone negligible score. With the latest patches especially, this vulnerability simply allows users to route initial relay connections to a proxy server under their control. Without chaining this vulnerability, there is minimal impact to any resources. We believe this is worth rating as a 3.3 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N).

Together with CVE-2023-47257, the chained score for CVE-2023-47256 is boosted greatly compared to its standalone score. When these two vulnerabilities are chained, we believe that the ease of reproduction combined with the Local Privilege Escalation (LPE) attack vector contextually changes the score to an 8.8 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H).