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.
Search for 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.
FCTDas connections
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.
FcmDaemon Logs
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.
Using Windbg to examine message format
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:
SQL query in DAS log
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.
xp_cmdshell logs
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
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.
