Fortinet FortiClient EMS SQL 注入漏洞（CVE-2023-48788）

CVE-2023-48788: Fortinet FortiClient EMS SQL Injection Deep Dive ================================================================ by [James Horseman](https://www.horizon3.ai/author/jhorseman/ "Posts by James Horseman") | Mar 21, 2024 | [Attack Blogs](https://www.horizon3.ai/category/attack-research/attack-blogs/) Introduction ============ In [a recent PSIRT](https://fortiguard.fortinet.com/psirt/FG-IR-24-007), 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](https://github.com/horizon3ai/CVE-2023-48788). > 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. [](https://p7i3u3x3.rocketcdn.me/wp-content/uploads/2024/03/Screenshot-2024-03-13-at-4.19.22%E2%80%AFPM.png) 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. [](https://p7i3u3x3.rocketcdn.me/wp-content/uploads/2024/03/Screenshot-2024-03-13-at-4.20.52%E2%80%AFPM.png) 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. [](https://p7i3u3x3.rocketcdn.me/wp-content/uploads/2024/03/Screenshot-2024-03-13-at-4.28.53%E2%80%AFPM.png) 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`. [](https://p7i3u3x3.rocketcdn.me/wp-content/uploads/2024/03/Screenshot-2024-03-13-at-4.37.31%E2%80%AFPM.png) 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: [](https://p7i3u3x3.rocketcdn.me/wp-content/uploads/2024/03/Screenshot-2024-03-13-at-4.41.57%E2%80%AFPM.png) 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](https://learn.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/xp-cmdshell-transact-sql?view=sql-server-ver16) 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](https://github.com/horizon3ai/CVE-2023-48788) 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. [](https://p7i3u3x3.rocketcdn.me/wp-content/uploads/2024/03/image-4.png) 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 -------- [NodeZero Attack Path utilizing CVE-2023-48788 to load a remote access tool and dump LSASS](https://p7i3u3x3.rocketcdn.me/wp-content/uploads/2024/03/Screenshot-2024-03-20-at-4.56.43%E2%80%AFPM.png) Horizon3.ai clients and free-trial users alike can run a NodeZero operation to determine the exposure and exploitability of this issue.