ConnectWise sounds the alarm on two vulnerabilities

[Note: for further information on this topic, please see the X-Ops blog article here]

On February 19, 2024, ConnectWise released a security advisory for its remote monitoring and management (RMM) software. The advisory highlighted two vulnerabilities that impact older versions of ScreenConnect and have been mitigated in version 23.9.8 and later. ConnectWise states in the advisory these vulnerabilities are rated as “Critical—Vulnerabilities that could allow the ability to execute remote code or directly impact confidential data or critical systems”. The two vulnerabilities are:

• CVE-2024-1709 (CWE-288) — Authentication Bypass Using Alternate Path or Channel
  • Base CVSS score of 10, indicating “Critical”
• CVE-2024-1708 (CWE-22) — Improper Limitation of a Pathname to a Restricted Directory (“Path Traversal”)
  • Base CVSS score of 8.4, still considered “High Priority”

Cloud-hosted implementations of ScreenConnect, including screenconnect.com and hostedrmm.com, have already received updates to address these vulnerabilities. Self-hosted (on-premise) instances remain at risk until they are manually upgraded, and it is our recommendation to patch to ScreenConnect version 23.9.8 immediately. The upgrade is available on ScreenConnect’s download page.

On February 21, proof of concept (PoC) code was released on GitHub that exploits these vulnerabilities and adds a new user to the compromised system. ConnectWise has also updated their initial report to include observed, active exploitation in the wild of these vulnerabilities.

What you should do

• Confirm whether you have an on-premise deployment of ScreenConnect
  • If an on-premise version is present in your environment and is not on 23.9.8 or later, proceed to upgrade to the newest version
  • If an on-premise version is present in your environment and already on 23.9.8 or later, you are not at risk and no further action is necessary
• If not on-premise and are instead cloud-hosted, you are not at risk and no further actions are necessary
• If your deployment is managed by a third-party vendor, confirm with them they have upgraded their instance to 23.9.8 or later
• If patching is not possible, ensure that the ScreenConnect server is not accessible to the Internet until the patch can be applied
• Once patching has been completed, perform a thorough review of the ScreenConnect installation looking for unknown accounts and abnormal server activity.

What Sophos is doing

Sophos is actively tracking the ongoing developments with these ScreenConnect vulnerabilities and their exploitation. The following detection rules were previously implemented to identify abuse of ScreenConnect and are still viable for identifying post-exploitation activity.

• WIN-EXE-PRC-SCREENCONNECT-COMMAND-EXECUTION-1
• WIN-EXE-PRC-SCREENCONNECT-REMOTE-FILE-EXECUTION-1
• WIN-EXE-PRC-SCREENCONNECT-RUNFILE-EXECUTION-1

We are continuing to ensure protection and detection coverage as changes happen and have released a prevention rule (ATK/SCBypass-A) and are testing similar network-based (IPS) signatures to combat the public proof of concept and other future abuse.

Our Incident Response team has published eight XDR queries to their public GitHub repo:

• ScreenConnect.01.0 – Check version of ScreenConnect Server.sql
• ScreenConnect.01.1 – Check version of ScreenConnect Server.sql (datalake)
• ScreenConnect.02.0 – ScreenConnect Relay IP.sql
• ScreenConnect.03.0 – SetupWizard.aspx in IIS logs.sql
• ScreenConnect.04.0 – Checks user.xml file for new users created.sql
• ScreenConnect.05.0 – Evidence of temporary User File creation.sql
• ScreenConnect.06.0 – Check for .ASPX .ASHX files in App_Extensions folder.sql
• ScreenConnect.07.0 – Identify shells being spawned from ScreenConnect.sql

For MDR (Managed Detection and Response) customers, we have initiated a customer-wide threat hunting campaign, and our MDR analysts will promptly reach out if any activity is observed. Our MDR team will be diligently monitoring our customer environments for suspicious behavior and responding as necessary. We will provide further updates as more information becomes available.

Acknowledgements

Anthony Bradshaw, Paul Jaramillo, Jordon Olness, and Benjamin Sollman assisted in the development of this post.