Introduction

In a recent PSIRT, Fortinet acknowledged CVE-2023-48788 – a SQL injection in FortiClient EMS that can lead to remote code execution. FortiClient EMS is an endpoint management solution for enterprises that provides a central location for administering enrolled endpoints. This SQL injection vulnerability is caused by user controlled strings that are passed directly into database queries. In this post we will examine the internal workings of the exploit. Our POC can be found here.

An improper neutralization of special elements used in an SQL Command (‘SQL Injection’) vulnerability [CWE-89] in FortiClientEMS may allow an unauthenticated attacker to execute unauthorized code or commands via specifically crafted requests.

FortiClient EMS Architecture

For the purposes of understanding this vulnerability, FortiClient EMS consists the following components:

• FmcDaemon.exe – The main service responsible for communicating with enrolled clients. By default, this service listens on port 8013 for incoming client connections
• FCTDas.exe – The Data Access Server responsible for translating requests from various other server components into SQL requests. This service interacts with the Microsoft SQL Server database.
• One or more endpoint clients – These clients communicate with the FmcDaemon on the server (by default tcp/8013)

Finding the Vulnerable Component

Since we know the vulnerability is a SQL injection, our initial triage consisted of scanning the installation folder for common SQL strings.

Upon further examination, we find that FCTDas.exe has established connections to the local database over tcp/1433. We also see that it listens for incoming connections over localhost port tpc/65432.

Examining other services on this server, we find that FcmDaemon.exe makes connections to FCTDas.exe and listens externally on tcp/8013. We have a decent hunch now that we can use tcp/8013 to interact indirectly with FCTDas and make database queries.

Finding and Triggering the Vulnerability

We wanted to see what normal communications between a client and the FcmDaemon should look like. To accomplish this, we configured an installer and deployed a basic endpoint client. We found that normal communications between an endpoint client and FcmDaemon.exe are encrypted with TLS, and there didn’t seem to be an easy way to dump TLS session keys to decrypt the legitimate traffic. Luckily, after we enabled Debug logging, the FcmDaemon log provided some detail about the communications.

This was enough information to get us started with a Python script to communicate with the FcmDaemon, however, we weren’t able to get it to respond with anything besides a continuation message.

At this point, we opened FcmDaemon.exe and IDA and began reverse engineering the message format. We noticed that many of the message handling functions were making use of functionality from policyhelper.dll. Instead of reverse engineering the entire message format, we opened Windbg and set a breakpoint on policyhelper!processRequest. After some time, the client beaconed to the server and we are able to see the message buffer in rdx.

We can see that the message format is a pretty simple text based format. We have a message header with various fields each separated by a newline, a carriage return and newline separating the header from the body, and two carriage return newlines to end the body. With this information, we are able to update our Python script to meaningfully communicate with the FcmDaemon.

In the DAS log, we were able to see many SQL statements that used the FCTUID as part of the query. For example:

Based on this, we were hopeful that by simply updating the FCTUID present in many of the FcmDaemon messages, we would be able to trigger a SQL injection. We constructed a simple sleep payload of the form <fctid>' AND 1=0; WAITFOR DELAY '00:00:10' -- '. We noticed the 10 second delay in response and knew that we had triggered the exploit!

From SQL Injection to RCE

To turn this SQL injection vulnerability into remote code execution we used the built-in xp_cmdshell functionality of Microsoft SQL Server. Initially, the database was not configured to run the xp_cmdshell command, however it was trivially enabled with a few other SQL statements. The POC we are releasing only confirms the vulnerability by using a simple SQL injection without xp_cmdshell. To enable RCE, altering the POC is necessary.

Indicators of Compromise

There are various log files in C:\Program Files (x86)\Fortinet\FortiClientEMS\logs that can be examined for connections from unrecognized clients or other malicious activity. The MS SQL logs can also be examined for evidence of xp_cmdshell being utilized to obtain command execution.

Its important to realize that an attacker may have used different techniques to gain execution or may have cleaned evidence from logs after exploitation.

NodeZero

NodeZero Attack Path utilizing CVE-2023-48788 to load a remote access tool and dump LSASS 

Horizon3.ai clients and free-trial users alike can run a NodeZero operation to determine the exposure and exploitability of this issue.

Sign up for a free trial and quickly verify you’re not exploitable.

Start Your Free Trial

 

The post CVE-2023-48788: Fortinet FortiClient EMS SQL Injection Deep Dive appeared first on Horizon3.ai.

Introduction

On February 19, 2023, ConnectWise published a security advisory for their ScreenConnect remote management tool. In the advisory, they describe two vulnerabilities, an authentication bypass with CVSS 10.0 and a path traversal with CVSS 8.4 (both currently without assigned CVE IDs). In this post we will dive into the technical details of the authentication bypass. You can view our POC here.

Update: On February 21, 2023, the authentication bypass vulnerability was assigned as CVE-2024-1709 and added to CISA’s Known Exploited Vulnerability (KEV) catalog.

Patch Diffing

Comparing versions 23.9.7.8804 and 23.9.8.8811, we find a small update to SetupWizard.aspx. We see that a check was added to make sure that the initial application setup has not been completed if a user it trying to access the SetupWizard. The SetupWizard is responsible for creating an initial user and password, so it makes sense that this page should be locked down after an initial user has been created.

Figure 1. SetupWizard.aspx

The Vulnerability

There is a HTTP request filter in SetupModule.cs that has two responsibilities:

• If the application hasn’t been setup, redirect all requests to SetupWizard.aspx
• If the application has been setup, deny any requests to SetupWizard.aspx or redirect to Administration.aspx

Figure 2. SetupModule.cs OnBeginRequest

However, there is an issue with how this code checks if the request URL is SetupPage.aspx. The use of string.Equals checks for exact equality, so a URL like <app_url>/SetupWizard.aspx will match. However, there are other URLs that resolve to SetupWizard.aspx that don’t match. If we simply add a forward slash to the end of the URL (<app_url>/SetupWizard.aspx/) we get access to the setup wizard, even after the application is already setup.

Figure 3. SetupWizard.aspx

We can observe the differences in responses using Burp Suite. Notice the request path /SetupWizard.aspx responds with a 302, but the malicious path /SetupWizard.aspx/ responds with a 200.

 

Indicators of Compromise

The application’s Admin -> Audit page displays a list of recent login attempts along with the IP address. You can check this page for any unrecognized users or IP addresses.

Figure 4. Audit Logs

As soon as we had sufficient information, we shared it with GreyNoise for which they developed a tag. Check out their tag here: https://viz.greynoise.io/tags/connectwise-screenconnect-auth-bypass-rce-attempt?days=1

Summary

This vulnerability allows an attacker to create their own administrative user on the ScreenConnect server, giving them full control over the server. This vulnerability follows a theme of other recent vulnerabilities that allow attackers to reinitialize applications or create initial users after setup. See our recent writeup for a CVE-2024-0204 as an example.

Unfortunately, this vulnerability has not yet been assigned a CVE. Users of ConnectWise ScreenConnect should patch immediately to prevent attackers from leveraging this vulnerability.

NodeZero

Horizon3.ai clients and free-trial users alike can run a NodeZero operation to determine the exposure and exploitability of this issue.

Sign up for a free trial and quickly verify you’re not exploitable.

Start Your Free Trial

 

Figure 5. NodeZero Attack Path to Exploitation

Figure 6. Proof of Accessing the SetupWizard.aspx page

The post ConnectWise ScreenConnect: Authentication Bypass Deep Dive appeared first on Horizon3.ai.