A Catastrophe For Control: Understanding the ScreenConnect Authentication Bypass (CVE-2024-1709 & CVE-2024-1708)

On February 19, 2024, ConnectWise published a security advisory for ScreenConnect version 23.9.8, referencing two vulnerabilities and software weaknesses. The same day, Huntress researchers worked to understand this threat and successfully recreated a proof-of-concept exploit demonstrating its impact.

This write-up will discuss our analysis efforts and the technical details behind this attack, which we’re coining as “SlashAndGrab.”

The ConnectWise advisory indicated that in all versions of ScreenConnect below 23.9.8 there were two vulnerabilities:

1. CVE-2024-1709: Authentication bypass using an alternate path or channel (CWE-288)
2. CVE-2024-1708: Improper limitation of a pathname to a restricted directory (“path traversal”) (CWE-22)

The first vulnerability was disclosed with a critical base CVSS scoring of 10, the highest possible severity. The authentication bypass would ultimately open the door for the second vulnerability.

ConnectWise made a patch available and expressed that all on-premise versions of ScreenConnect 23.9.7 and below must be updated immediately—cloud instances were already automatically patched.

At the time of release, the ConnectWise advisory was very sparse on technical details. There was not much information available as to what these vulnerabilities really consisted of, how they might be taken advantage of, or any other threat intelligence or indicators of compromise to hunt for.

Once we recreated the exploit and attack chain, we came to the same conclusion: there should not be public details about the vulnerability until there had been adequate time for the industry to patch. It would be too dangerous for this information to be readily available to threat actors.

But, with other vendors now publicly sharing the proof-of-concept exploit, the cat is out of the bag. We now feel that sharing our analysis shares no more threat than what is already available. So, we’re ready to spill the beans.

The “exploit” is trivial and embarrassingly easy.

Below is a video demonstration of our recreated proof-of-concept exploit, which performs the simple authentication bypass but takes it a step further to showcase remote code execution.

Our Analysis

When the Huntress team was made aware of the ConnectWise advisory, our team began to dig into what changes were made in the patch that could help explain what these vulnerabilities were.

We could simply look for the differences between code present in the new, patched version, and the previous, unpatched version. Creating a local testing environment for both of these states of the ScreenConnect software, we could easily see the delta that might clue us into the potential exploit.

We observed that these files differed: 

CVE-2024-1709 - Authentication Bypass

Most of these changes observed in the new version were binary files, which require decompilation to compare; however, [.highlight]SetupWizard.aspx[.highlight] is a text file. When looking at the differences in this file, it immediately looked promising:

In the newest update, we can see there is a new check to ensure that the instance is set up before allowing the user to use the setup wizard. This piqued our interest as, at face value, version 23.9.7 already blocked access to the setup wizard after authentication. Looking closer into [.highlight]ScreenConnect.SetupModule[.highlight] inside of [.highlight]ScreenConnect.Web.dll[.highlight] sheds more light on the exploitation path. 

In previous versions of ScreenConnect, this handler was registered for the [.highlight]OnBeginRequest[.highlight] event, while in 28.9.8 it is registered for the [.highlight]OnPostMapRequestHandler[.highlight] event. This was seemingly done so that the [.highlight]context.Handler[.highlight] field will be populated. A new check is added to validate if the resolved HTTP handler implements the new [.highlight]ISetupHandler[.highlight] interface whereas the old code simply checked that [.highlight]Request.Path[.highlight] string matched “[.highlight]/SetupWizard.aspx[.highlight]”. This change implies that there was some way to bypass the string comparison of [.highlight]Request.Path[.highlight] in previous versions. If the request path does not match “[.highlight]/SetupWizard.aspx[.highlight],” then the setup wizard will be allowed regardless of the setup state of the instance.

This would normally not be exploitable, but .Net has weird functionality that allows URL path components after a mapped legitimate URL to be passed along to the application. This information is exposed in [.highlight]Request.FilePath[.highlight], [.highlight]Request.PathInfo[.highlight] and [.highlight]Request.Path[.highlight]. For example, if there is a legitimate path “[.highlight]/something.aspx[.highlight]”, then .Net will allow the user to request “[.highlight]/something.aspx/anythingelse[.highlight]” and will pass along the trailing bit after the file path via the [.highlight]Request.PathInfo[.highlight]. However, [.highlight]Request.Path[.highlight] always contains both [.highlight]Request.FilePath[.highlight] and [.highlight]Request.PathInfo[.highlight] per MSDN documentation:

Putting this together, it means we can simply request “[.highlight]/SetupWizard.aspx/literallyanything[.highlight]” and we should be allowed to access the setup wizard on already-configured ScreenConnect instances.

The setup wizard is responsible for setting up the initial administrative user and installing a license on the system during initial setup. The user creation portion of this setup happens immediately after clicking the “Next” button on the setup page, so there is no need to complete the setup wizard fully to exploit the system (i.e. you do not need to replace or have access to a valid license key). Completing this step will completely overwrite the internal user database. All other local users will be deleted aside from the user you specify in the setup wizard.

Once you have administrative access to a compromised instance, it is trivial to create and upload a malicious ScreenConnect extension to gain Remote Code Execution (RCE). This is not a vulnerability, but a feature of ScreenConnect, which allows an administrator to create extensions that execute .Net code as [.highlight]SYSTEM[.highlight] on the ScreenConnect server.

CVE-2024-1708 - Path Traversal

The second vulnerability referenced in the ConnectWise ScreenConnect advisory presents a risk of ZipSlip attacks. We observed changes to [.highlight]ScreenConnect.Core.dll[.highlight]:

and [.highlight]ScreenConnect.Server.dll[.highlight]: 

This adds new function arguments to strictly handle file paths when extracting content from a ZIP file. Looking through the code base, we can see these utility functions only seem to be used when handling ScreenConnect extensions. Prior to this patch, a malicious extension could potentially write files anywhere within [.highlight]C:\Program Files (x86)\ScreenConnect\App_Extensions[.highlight] instead of being properly restricted to their extension subdirectory.

While this is another vulnerability fixed in version [.highlight]23.9.8[.highlight] that could lead to remote code execution in certain conditions, it relies upon having administrative credentials and access to be able to use the Extensions functionality. This capability is “unlocked” by the authentication bypass, but is less severe on its own.

In our recreated proof-of-concept exploit, taking advantage of this potential ZipSlip attack vector was not necessary; after gaining administrator access with the authentication bypass, it was already possible to run arbitrary code with the typical Extensions feature set. The primary difference being that malicious code written using this vulnerability does not necessarily need an installed extension to execute. This means that it may go unnoticed more easily within your environment. Any [.highlight].aspx[.highlight] or [.highlight].ashx[.highlight] files within the root of [.highlight]C:\Program Files (x86)\ScreenConnect\App_Extensions\[.highlight] are likely malicious artifacts. ScreenConnect does not place any files within this directory normally.

Detection Guidance

While researching the above vulnerabilities, Huntress identified Indicators Of Compromise (IOCs) and developed a set of detections that can be used to notify ScreenConnect users of potential malicious activity.

As a reminder, per Huntress’s previous post, the below listed SIGMA rules that leverage Windows Event ID 4663 requires that the Advanced Auditing policy be configured, and an appropriate SACL applied to the directory. Please refer to the previous blog post for how to generate this event.  

CVE-2024-1709 - Authentication Bypass

While replicating the Authentication Bypass exploit, Huntress observed IIS logs for the malicious [.highlight]SetupWizard.aspx[.highlight] URL path, which can be used as an indicator of compromise:

The following Sigma rule will detect requests made to [.highlight]SetupWizard.aspx[.highlight] with a trailing path segment. This behavior is never legitimate, and should clearly indicate malicious intent if observed in the wild.

After accessing the Setup Wizard, an attacker will input new credentials to gain access to Screen Connect. Doing so will write a new user database to a temporary XML file. The following Sigma rule can be used to detect the ScreenConnect server writing to a temporary XML file on the server. While this may be an indicator of compromise, this activity is known to also be observed when legitimately modifying local users or their permissions in ScreenConnect, so there is a non-zero false positive rate.

The following YARA rule is similar to the IIS log Sigma rule given above. It will detect IIS log entries that reference [.highlight]SetupWizard.aspx[.highlight] with a trailing path component. As mentioned previously, a trailing path component on this file is always associated with malicious activity.

CVE-2024-1708 - Path Traversal

The path traversal exploit allows attackers to write files within the root of the [.highlight]App_Extensions[.highlight] directory. The following Sigma rule should alert on file modifications at the root of the [.highlight]App_Extensions[.highlight] directory while excluding legitimate modifications to extensions themselves. 

We encourage customers and partners to reach out if they need assistance. If you are not currently using Huntress and need help monitoring for activity related to this vulnerability, you can use Huntress' free trial.