CVE-2023-48788: Analysis and mitigation

Fortinet recently disclosed CVE-2023-48788, identifying a SQL injection vulnerability within FortiClient EMS that poses a risk of Remote Code Execution (RCE). FortiClient EMS serves as an endpoint management platform for enterprises, offering centralized administration of enrolled endpoints. The vulnerability stems from the direct inclusion of user-controlled strings in database queries. Our discussion will take a dive into the mechanics of the exploit, further details about the proof of concept (POC) can be found Horizon3’s PoC. 

  

What is CVE-2023-48788?

Categorized as improper neutralization of special elements in an SQL Command (‘SQL Injection’), the vulnerability [CWE-89] has been identified in FortiClientEMS. This flaw could potentially enable an unauthorized attacker to execute code or commands via meticulously crafted requests, without authentication.   

To fully comprehend the nature of this vulnerability, it’s essential to understand the components within FortiClient EMS. FortiClient EMS’s Architecture is built of the following components: 

• FmcDaemon.exe – The primary service responsible for interacting with enrolled clients. By default, this service listens on port 8013 for incoming client connections. 
• FCTDas.exe – The Data Access Server tasked with translating requests from various server components into SQL queries. This service directly interacts with the Microsoft SQL Server database. 
• One or more Endpoint clients – clients that communicate with the FmcDaemon on the server, typically using tcp/8013 as the default communication protocol.   

To dentifyi the vulnerable element (and given the SQL injection nature of the vulnerability), Horizon 3’s researchers began their triage which involved scanning the installation directory for common SQL strings. 

After further analysis, the researchers discovered that FCTDas.exe is establishing connections with the local database via tcp/1433. Additionally they reported the FCTDas.exe is listening for incoming connections on localhost port tcp/65432. 

Among further inspection of other services running on this server, they also had observed that FcmDaemon.exe establishes connections with FCTDas.exe and externally listens on tcp/8013. This discovery lead them to believe that tcp/8013 could be utilized indirectly to interact with FCTDas and execute database queries. 

 

 

The process of finding and executing the vulnerability

The researchers aimed to understand the standard communication protocol between a client and the FcmDaemon. To achieve this, they set up an installer and deployed a basic endpoint client for testing purposes.

Through their analysis, they discovered that typical communications between an endpoint client and FcmDaemon.exe were encrypted using TLS. Decrypting this encrypted traffic posed a challenge as there was no straightforward method to extract TLS session keys for decryption.

Fortunately, upon enabling Debug logging, the FcmDaemon log provided some insights into the communication process:

 

 

Armed with this initial information, the researchers developed a Python script to establish communication with the FcmDaemon. However, their attempts only resulted in receiving a continuation message without further meaningful responses. 

Subsequently, they engaged in reverse engineering efforts using IDA Pro on the FcmDaemon executable. During this process, they noted that several message handling functions relied on functionality from policyhelper.dll.

Instead of reverse engineering the entire message format, they opted to use Windbg and set a breakpoint on policyhelper!processRequest. After some time, the client initiated communication with the server, allowing them to inspect the message buffer located in rdx. 

The message format followed a straightforward text-based structure. The message header contained several fields, each separated by a newline. A carriage return and newline separated the header from the body, and two carriage return newlines were used to signify the end of the body.

Armed with this understanding, they were able to enhance their Python script to establish meaningful communication with the FcmDaemon. 

 

 

In the DAS log, the researchers were able to see a wide range of SQL statements that used the FCTUID as part of the query, and were therefore hoping that updating the FCTUID within numerous FcmDaemon messages could potentially activate a SQL injection. 

 

 

Following a 10-second delay in the response, they confirmed the successful triggering of the exploit. 

 

 

Signs of compromise

Within the directory C:\Program Files (x86)\Fortinet\FortiClientEMS\logs, numerous log files offer insights into potential connections from unfamiliar clients or any malicious activities. Additionally, examining the MS SQL logs can reveal indications of xp__cmdshell usage, indicating potential command execution attempts.  

It’s crucial to acknowledge that attackers might employ various methods to achieve execution and could potentially clear evidence from logs post-exploitation. 

 

 

To transform the SQL injection vulnerability into remote code execution, they leveraged the xp__cmdshell functionality inherent in Microsoft SQL Server. Initially, the database lacked the configuration to execute the xp__cmdshell command.

However, enabling it was a straightforward process involving a few additional SQL statements. The proof of concept (POC) being released merely verifies the vulnerability using a basic SQL injection without utilizing xp__cmdshell. Enabling RCE requires modifying the POC accordingly. 

Next steps 

Each new vulnerability is a reminder of where we stand and what we need to do better. Check out the following resources to help you maintain cyber hygiene and stay ahead of the threat actors: 

1. 2023 Vulnerability watch reports 
2. The MITRE ATT&CK framework: Getting started
3. The true impact of exploitable vulnerabilities for 2024
4. Multi-cloud security challenges – a best practice guide
5. How to properly tackle zero-day threats