On February 19, 2024, ConnectWise published a [security advisory](https://www.connectwise.com/company/trust/security-bulletins/connectwise-screenconnect-23.9.8) 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.
The ConnectWise advisory indicated that in all versions of ScreenConnect below 23.9.8 there were two vulnerabilities:
1. CWE-288 Authentication bypass using an alternate path or channel
2. CWE-22 Improper limitation of a pathname to a restricted directory (“path traversal”)
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:
ScreenConnect/App\_Data/User.xml
ScreenConnect/Bin/ScreenConnect.WindowsFileManager.exe
ScreenConnect/Bin/ScreenConnect.ClientService.exe
ScreenConnect/Bin/ScreenConnect.Client.Agent.zip
ScreenConnect/Bin/ServedArtifacts/ScreenConnect.Windows.dll
ScreenConnect/Bin/ServedArtifacts/ScreenConnect.Core.dll
ScreenConnect/Bin/ScreenConnect.Core.jar
ScreenConnect/Bin/ScreenConnect.Service.exe
ScreenConnect/Bin/ScreenConnect.WindowsClient.exe
ScreenConnect/Bin/ScreenConnect.WindowsServer.dll
ScreenConnect/Bin/ScreenConnect.Server.dll
ScreenConnect/Bin/ScreenConnect.ClientSetup.exe
ScreenConnect/Bin/ScreenConnect.Client.exe.jar
ScreenConnect/Bin/ScreenConnect.Web.dll
ScreenConnect/Bin/ScreenConnect.Client.Bundle.zip
ScreenConnect/Bin/ScreenConnect.Windows.dll
ScreenConnect/Bin/ScreenConnect.ClientSetup.msi
ScreenConnect/Bin/ScreenConnect.WindowsInstaller.dll
ScreenConnect/Bin/ScreenConnect.WindowsBackstageShell.exe
ScreenConnect/Bin/ScreenConnect.Client.apk
ScreenConnect/Bin/ScreenConnect.Client.dll
ScreenConnect/Bin/ScreenConnect.Client.application
ScreenConnect/Bin/ScreenConnect.Client.exe
ScreenConnect/Bin/ScreenConnect.Core.dll
ScreenConnect/Bin/ScreenConnect.Relay.dll
ScreenConnect/Bin/ScreenConnect.Client.manifest
ScreenConnect/Bin/ScreenConnect.Client.jar
ScreenConnect/Bin/ScreenConnect.ClientBootstrap.jar
ScreenConnect/Bin/ScreenConnect.ClientService.dll
ScreenConnect/SetupWizard.aspx
ScreenConnect/web.config
[view raw](https://gist.github.com/JohnHammond/fac42eefb1bb137d1d8b5707d67d6964/raw/b5a20fc9f6755de41955d529f85f39d11e77fb6d/gistfile1.txt)[gistfile1.txt](https://gist.github.com/JohnHammond/fac42eefb1bb137d1d8b5707d67d6964#file-gistfile1-txt) hosted with ❤ by [GitHub](https://github.com/)
**CWE-288 - Authentication Bypass**
-----------------------------------
Most of these changes observed in the new version were binary files, which require decompilation to compare; however, **SetupWizard.aspx** is a text file. When looking at the differences in this file, it immediately looked promising:
1a2
\> <%@ Implements Interface="ScreenConnect.ISetupHandler" %>
5a7,14
\>
\> protected override void OnInit(EventArgs e)
\> {
\> base.OnInit(e);
\>
\> if (SetupModule.IsSetup)
\> throw new InvalidOperationException("Already setup");
\> }
[view raw](https://gist.github.com/JohnHammond/a1bf6c78769ea253e43326ca23d3c2b8/raw/2f12bda8ae4e324be4451ed2c04d3a23b52b4c62/SetupWizard.aspx.diff)[SetupWizard.aspx.diff](https://gist.github.com/JohnHammond/a1bf6c78769ea253e43326ca23d3c2b8#file-setupwizard-aspx-diff) hosted with ❤ by [GitHub](https://github.com/)
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 **ScreenConnect.SetupModule** inside of **ScreenConnect.Web.dll** sheds more light on the exploitation path.
![https://images.seebug.org/1708509981772-w331s](https://images.seebug.org/1708509981772-w331s)
In previous versions of ScreenConnect, this handler was registered for the **OnBeginRequest** event, while in 28.9.8 it is registered for the **OnPostMapRequestHandler** event. This was seemingly done so that the **context.Handler** field will be populated. A new check is added to validate if the resolved HTTP handler implements the new **ISetupHandler** interface whereas the old code simply checked that **Request.Path** string matched “**/SetupWizard.aspx**”. This change implies that there was some way to bypass the string comparison of **Request.Path** in previous versions. **If the request path does not match “/SetupWizard.aspx,” 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 **Request.FilePath**, **Request.PathInfo** and **Request.Path**. For example, if there is a legitimate path “**/something.aspx**”, then .Net will allow the user to request “**/something.aspx/anythingelse**” and will pass along the trailing bit after the file path via the **Request.PathInfo**. However, **Request.Path** always contains _both_ **Request.FilePath** _and_ **Request.PathInfo** per [MSDN documentation](https://learn.microsoft.com/en-us/dotnet/api/system.web.httprequest.path?view=netframework-4.8.1):
![https://images.seebug.org/1708509985092-w331s](https://images.seebug.org/1708509985092-w331s)
Putting this together, it means we can simply request “**/SetupWizard.aspx/literallyanything**” and we should be allowed to access the setup wizard on already-configured ScreenConnect instances.
![https://images.seebug.org/1708509987353-w331s](https://images.seebug.org/1708509987353-w331s)
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 **SYSTEM** on the ScreenConnect server.
![https://images.seebug.org/1708509989761-w331s](https://images.seebug.org/1708509989761-w331s)
**CWE-22 - Path Traversal**
---------------------------
The second vulnerability referenced in the ConnectWise ScreenConnect advisory presents a risk of ZipSlip attacks. We observed changes to **ScreenConnect.Core.dll**:
11057c11057
< public void ExtractAllEntries(string basePath)
\---
\> public void ExtractAllEntries(string basePath, string requireEntriesInMoreStringentPath = null)
11062c11062
< FileSystemExtensions.DemandInParentPath(basePath, text);
\---
\> FileSystemExtensions.DemandInParentPath(requireEntriesInMoreStringentPath ?? basePath, text);
[view raw](https://gist.github.com/JohnHammond/ca3824104f47498768a5ccee49af95b3/raw/9e7333b7945ca8b5b5298c80cf72e04bef4ed69d/ScreenConnect.Core.dll.cs.diff)[ScreenConnect.Core.dll.cs.diff](https://gist.github.com/JohnHammond/ca3824104f47498768a5ccee49af95b3#file-screenconnect-core-dll-cs-diff) hosted with ❤ by [GitHub](https://github.com/)
and **ScreenConnect.Server.dll**:
8392a8393
\> DirectoryInfo extensionsDirectory = GetExtensionsDirectory();
8398c8399
< zipFile.ExtractAllEntries(GetExtensionsDirectory().FullName);
\---
\> zipFile.ExtractAllEntries(extensionsDirectory.FullName, extensionDirectory.FullName);
[view raw](https://gist.github.com/JohnHammond/16b19436045484ccf2aad539f31271ea/raw/9fee111c21c06f99b0896cdb5d8be1d36455265b/ScreenConnect.Server.dll.cs.diff)[ScreenConnect.Server.dll.cs.diff](https://gist.github.com/JohnHammond/16b19436045484ccf2aad539f31271ea#file-screenconnect-server-dll-cs-diff) hosted with ❤ by [GitHub](https://github.com/)
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 **C:\\Program Files (x86)\\ScreenConnect\\App\_Extensions** instead of being properly restricted to their extension subdirectory.
While this is another vulnerability fixed in version **23.9.8** 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 **.aspx** or **.ashx** files within the root of **C:\\Program Files (x86)\\ScreenConnect\\App\_Extensions\\** 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](https://www.huntress.com/blog/detection-guidance-for-connectwise-cwe-288-2), the below listed SIGMA rules that leverage [Windows Event ID 4663](https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/event-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.
**CWE-288 - Authentication Bypass**
-----------------------------------
While replicating the Authentication Bypass exploit, Huntress observed IIS logs for the malicious **SetupWizard.aspx** URL path, which can be used as an indicator of compromise:
![https://images.seebug.org/1708509995776-w331s](https://images.seebug.org/1708509995776-w331s)
The following Sigma rule will detect requests made to **SetupWizard.aspx** with a trailing path segment. This behavior is never legitimate, and should clearly indicate malicious intent if observed in the wild.
title: ConnectWise ScreenConnect SetupWizard Authentication Bypass (Feb 2024)
id: d27eabad-9068-401a-b0d6-9eac744d6e67
status: experimental
description: Detects http requests to '/SetupWizard.aspx/' that indicate exploitation of the ScreenConnect vulnerability.
references:
\- https://www.connectwise.com/company/trust/security-bulletins/connectwise-screenconnect-23.9.8
\- https://www.huntress.com/blog/vulnerability-reproduced-immediately-patch-screenconnect-23-9-8
\- https://www.huntress.com/blog/detection-guidance-for-connectwise-cwe-288-2
author: Huntress DE&TH Team
date: 2024/02/20
logsource:
category: webserver
product: windows
detection:
selection:
cs-uri-query|contains: '/SetupWizard.aspx/'
condition: selection
falsepositives:
\- Unknown
level: critical
tags:
\- attack.initial\_access
\- attack.persistence
[view raw](https://gist.github.com/JohnHammond/65cee24bc949be53e6744a84e78b7239/raw/a3c7504fd570daa5a17f1df0c36763674d421999/SetupWizard_sigma_rule.yml)[SetupWizard\_sigma\_rule.yml](https://gist.github.com/JohnHammond/65cee24bc949be53e6744a84e78b7239#file-setupwizard_sigma_rule-yml) hosted with ❤ by [GitHub](https://github.com/)
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.
title: ConnectWise ScreenConnect SetupWizard User Database Modification
id: 4109cb6a-a4af-438a-9f0c-056abba41c6f
status: experimental
description: This detects file modifications to the temporary xml user database file indicating local user modification in the ScreenConnect server. This will occur during exploitation of the ScreenConnect Authentication Bypass vulnerability in versions <23.9.8, but may also be observed when making legitimate modifications to local users or permissions. This requires an Advanced Auditing policy to log a successful Windows Event ID 4663 events and with a SACL set on the directory.
references:
\- https://www.connectwise.com/company/trust/security-bulletins/connectwise-screenconnect-23.9.8
\- https://www.huntress.com/blog/vulnerability-reproduced-immediately-patch-screenconnect-23-9-8
\- https://www.huntress.com/blog/detection-guidance-for-connectwise-cwe-288-2
author: Huntress DE&TH Team
date: 2024/02/20
logsource:
product: windows
service: security
detection:
selection:
EventID: 4663
ObjectType: 'File'
ProcessName|contains:
\- 'ScreenConnect.Service.exe'
AccessMask: 0x6
ObjectName|endswith: '.xml'
ObjectName|contains|all:
\- 'Temp'
\- 'ScreenConnect'
condition: selection
falsepositives:
\- Unknown
level: critical
tags:
\- attack.initial\_access
\- attack.persistence
[view raw](https://gist.github.com/JohnHammond/4bffa96fe54aa6c1cb35509e9d7ad0b1/raw/096f897aab6ac6bb2660bfb8948deec6d86591f8/ScreenConnect_modification_sigma_rule.yml)[ScreenConnect\_modification\_sigma\_rule.yml](https://gist.github.com/JohnHammond/4bffa96fe54aa6c1cb35509e9d7ad0b1#file-screenconnect_modification_sigma_rule-yml) hosted with ❤ by [GitHub](https://github.com/)
The following YARA rule is similar to the IIS log Sigma rule given above. It will detect IIS log entries that reference **SetupWizard.aspx** with a trailing path component. As mentioned previously, a trailing path component on this file is always associated with malicious activity.
rule ConnectWise\_ScreenConnect\_Authentication\_Bypass\_Feb\_2024\_Exploitation\_IIS\_Logs {
meta:
description \= "Detects an http request to '/SetupWizard.aspx/' with anything following it, which when found in IIS logs is a potential indicator of compromise of the 2024 ConnectWise ScreenConnect (versions prior to 23.9.8) vulnerability that allows an Authentication Bypass"
author \= "Huntress DE&TH Team"
reference \= "https://www.connectwise.com/company/trust/security-bulletins/connectwise-screenconnect-23.9.8"
date \= "2024-02-20"
id \= "2886530b-e164-4c4b-b01e-950e3c40acb4"
strings:
$s1 \= "/SetupWizard.aspx/" ascii
condition:
$s1
}
[view raw](https://gist.github.com/JohnHammond/e07caff1b2d4526b7fabbecd63784258/raw/66cdc50a6e88a43b9175b2451ed63d2f606d74d8/SetupWizard_IIS_log.yara)[SetupWizard\_IIS\_log.yara](https://gist.github.com/JohnHammond/e07caff1b2d4526b7fabbecd63784258#file-setupwizard_iis_log-yara) hosted with ❤ by [GitHub](https://github.com/)
**CWE-22 - Path Traversal**
---------------------------
The path traversal exploit allows attackers to write files within the root of the **App\_Extensions** directory. The following Sigma rule should alert on file modifications at the root of the **App\_Extensions** directory while excluding legitimate modifications to extensions themselves.
title: ConnectWise ScreenConnect ZipSlip Exploitation (Feb 2024)
id: 4c198a60-7d05-4daf-8bf7-4136fb6f5c62
status: experimental
description: This detects file modifications to ASPX and ASHX files within the root of the App\_Extensions directory, which is allowed by a ZipSlip vulnerability in versions prior to 23.9.8. This does occur during exploitation of the vulnerability. This requires an Advanced Auditing policy to log a successful Windows Event ID 4663 events and with a SACL set on the directory.
references:
\- https://www.connectwise.com/company/trust/security-bulletins/connectwise-screenconnect-23.9.8
\- https://www.huntress.com/blog/vulnerability-reproduced-immediately-patch-screenconnect-23-9-8
\- https://www.huntress.com/blog/detection-guidance-for-connectwise-cwe-288-2
author: Huntress DE&TH Team
date: 2024/02/20
logsource:
product: windows
service: security
detection:
selection:
EventID: 4663
ObjectType: 'File'
ProcessName|contains:
\- 'ScreenConnect.Service.exe'
AccessMask: 0x6
legitimate\_path:
ObjectName|endswith: 'ScreenConnect\\App\_Extensions\\\*\\\*'
illegitimate\_path:
ObjectName|endswith: 'ScreenConnect\\App\_Extensions\\\*.as?x'
condition: selection and illegitimate\_path and not legitimate\_path
falsepositives:
\- Unknown
level: critical
tags:
\- attack.initial\_access
\- attack.persistence
[view raw](https://gist.github.com/JohnHammond/d6b7b067b300770636a585e1b42eddc7/raw/c9583f6abebfeba88e11ad1421d14b115139152e/App_Extensions_sigma_rule.yml)[App\_Extensions\_sigma\_rule.yml](https://gist.github.com/JohnHammond/d6b7b067b300770636a585e1b42eddc7#file-app_extensions_sigma_rule-yml) hosted with ❤ by [GitHub](https://github.com/)
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.](http://www.huntress.com/start-trial)
暂无评论