Vulnerability Spotlight: Reverse Analysis of FortiOS Vulnerability CVE-2024-21762 Explained
On 08/02/2024 we stumbled upon a new vulnerability in FortiOS (CVE-2024-21762) published by Fortinet PSIRT Advisory (Reference: https://www.fortiguard.com/psirt/FG-IR-24-015). In the first moment we thought that the vulnerability was related to older vulnerabilities, but to be sure and protected we decided to investigate further.
Methodology
We started by analyzing one of the older versions that was vulnerable to this vulnerability, with a new firmware version that according to Fortinet had the patch applied.
In this process we used Bindiff to compare the two different firmware versions. FortiOS embeds all the binaries in a monolithic big binary called “init”.
From Bindiff with Ghidra we were able to identify the differences between the unpatched and patched version.
From here we can understand that there were some differences. We checked all the function changes, and identified two as the most important that would trigger this vulnerability.
We already knew what to search, as per Fortinet Advisory the vulnerability was described as Out of Bound Write. So we were looking for Improper Input validation to find this vulnerability.
Voila, we were able to find the vulnerability in the code.
The first function: The param_1 variable is checked to see if it's equal to 0. If it is, the program logs an assertion failure and terminates. However, if param_1 is not properly validated and a user can set it to a different parameter other than 0, it could lead to unexpected behavior. For instance, if the program logic relies on param_1 being 0 to execute certain critical operations or checks, bypassing this check by setting param_1 to a different value could lead to unintended behavior or security vulnerabilities.
The second function: The function attempts to create directories. If the input on one of the parameters is controlled by an attacker, they might be able to perform directory traversal attacks by manipulating the path to access or modify sensitive files outside the intended directory structure.
Same parameter was used in both functions.
Dynamic Analysis
The Advisory was telling that the vulnerability is in the SSL VPN module. There are not a lot of public endpoints in SSL. We tried different requests in /remote but no luck with it.
As we were searching on it, Bishop Fox again released a Vulnerability Scanner for this version. (Reference: https://bishopfox.com/blog/cve-2024-21762-vulnerability-scanner-for-fortigate-firewalls).
Checking the scanner we found a bunch of useful information that could help us further in our research. It seems related to the improper Input validation that we discovered earlier on function 1.
The vulnerability is triggered when the chunked data body is not zero. We checked the possible paths where chunked requests could be sent and we discovered that public endpoints don’t support chunked requests.
So to exploit this vulnerability would require to send a chunked request to any path under /remote via POST.
This callbacks to something else that we know, HTTP Request Smuggling in HTTP/1.1.
HTTP Request Smuggling
The front-end server uses the Content-Length header and the back-end server uses the Transfer-Encoding header. The front-end server processes the Content-Length header and determines the request body. This request is forwarded on to the back-end server. The back-end server processes the Transfer-Encoding header, and so treats the message body as using chunked encoding. It processes the first chunk, which is stated to be zero length, and so is treated as terminating the request. The following bytes are left unprocessed, and the back-end server will treat these as being the start of the next request in the sequence. (Reference: https://portswigger.net/web-security/request-smuggling).
Conclusion
This vulnerability is proved to have a high impact and the other exploitation paths can be Stack Buffer Overflow and Remote Code Execution. The administrators of these devices have to make sure that the SSL VPN is turned off or patched to the latest version as is exploitable.
Sphere Detection
In February we also started monitoring scanners searching for Fortigate SSL VPN instances with our proprietary tool Sphere.
From the graph below we can deduce that after this advisory there has been an increase in the scanners looking for Fortigate SSL VPN instances. According to Fortinet Advisory this is being potentially exploited in the wild.
Disclaimer
We conducted these tests because we are users and Service providers for Fortinet. With no information about the vulnerability we decided to check because wanted to be sure if it was an exploitable vulnerability or just something else being patched and prompting administrators to a new version.
The information that we have gathered and analyzed is provided as it is with no warranty that is 100% certain.
