Hunting for Fortinet CVE-2024-21762: Vulnerability Research for Detection Engineering

This article steps through the process of discovering CVE-2024-21762, a non-disclosed out-of-bounds write vulnerability in Fortinet FortiOS and FortiProxy.



March 8, 2024


This blog will cover some basic vulnerability discovery methods for developing detections. In early February, Fortinet published two reports warning users of CVE-2024-23113 and CVE-2024-21762. Within a day of their release, CISA added CVE-2024-21762 to its Known Exploited Vulnerability Catalogue. I wondered if we had seen it in our data but didn’t know what it would look like. It’s not every day I get to delve into vulnerability discovery, and this gave me an excellent opportunity to do so! These being unfamiliar waters, it would be nice to put together some documentation on things I learned along the way too.

The Vulnerability

As described in the report, CVE-2024-21762 is:

A out-of-bounds write vulnerability [CWE-787] in FortiOS and FortiProxy may allow a remote unauthenticated attacker to execute arbitrary code or command via specially crafted HTTP requests.
Workaround: disable SSL VPN (disable webmode is NOT a valid workaround)

Also, the report states that versions 7.4.0 to 7.4.2 are affected and should be updated to 7.4.3 or above. Given this information, I suspect that I’m looking for a new conditional statement doing some sort of size check to prevent the out-of-bounds write (oobw) and given the “Workaround,” I bet it has something to do with SSL VPN. This should be enough information to get started, so the question is: Where to start?

How to “Discovery”?

Getting the Software

Knowing both the affected and patched versions is going to mean a patch diff, but with Fortinet being proprietary software, finding these versions and decrypting them is going to be the first battle… which I was lucky enough to bypass via the power of friendship. However, when friendship is lacking one may also be able to get lucky and find the files they need on Grayhat Warfare (less luck needed with a subscription), and then get a nice start on decrypting them with this Bishop Fox writeup.


Now that we have our decrypted file systems, we can start trying to find the changes between them by running:

$ diff -qr rootfs_7.4.2 rootfs_7.4.3

This reveals several differences, but the one that stands out to me is that Files rootfs_7.4.2/bin/init and rootfs_7.4.3/bin/init differ! These two versions of init can be patch diffed, and these differences will, hopefully, reveal where the vulnerability in the older version lies. BinDiff is a commonly used comparison tool for binary files, which have integrations for several decompilers.

I used the workflow for Ghidra, and once finished, I could see that only 3% had been altered.

Figure 1: BinDiff results between the init binary from FortiOS 7.4.2 and 7.4.3

Going through this diff to find changes that may be of interest was becoming a bit of a pain until it was brought to my awareness that the exported .BinDiff file is a sqlite3 database.

$ file init_7.4.2_vs_init_7.4.3.BinDiff
init_7.4.2_vs_init_7.4.3.BinDiff: SQLite 3.x database, last written using SQLite version 3040001

Knowing this, I just ran this query:

select * from function where similarity < 0.99 and confidence > 0.5 and basicblocks > 1;

which returned the following 25 results:


I was worried that there would be a lot more, given the size of this binary! Now the only thing to do was to comb through these and see if any of them are relevant to the known vulnerability (oobw in SSL VPN).


So I did just that: I stepped through each of the 25 methods and took notes on what they appeared to do. Here’s a summarized version:

Figure 2: Brief notes on the 25 BinDiff results

I noticed that several of the changed functions involved
FGFM, and I suspect this has to do with CVE-2024-23113, which is not the topic of this blog but is worth noting regardless. The functions at 0x18f4980 and 0x198bd20 piqued my interest for many reasons. At first glance, I noticed the string, "Chunked request body is larger than limit of %d", which suggests to me that there may have been the potential for an overflow vulnerability in chunked requests in the past. It also stood out to me that 0x198bd20 calls 0x18f4980, and seems to handle web requests. Then, tracing the call tree back I can see that the original function call that leads to 0x18f4980 being executed is FUN_01a29a20, and one of the first lines of code in this function is:

__stream = fopen("/var/run/","w");

Figure 3: Call Graph displaying the control flow from caller function → suspected vulnerable function

Now that the scope is limited to the function at 0x18f4980 — which has been renamed to chunk_overflow_check in the diagram above — returning to BinDiff will help clarify where exactly the code has changed. Only two areas of change can be seen in the graph view:

Figure 4: Graph view of suspected vulnerable function with changes highlighted

After analysis, the change added to 7.4.3 at 0x18f4c01 stands out. It contains a new conditional statement, and there’s a string stating, “chunk trailer: too long.”

Figure 5: New conditional added in init version 7.4.3

This looks promising! My best guess at this point would be that the oobw exists in the handling of requests with chunked Trailer headers.

It makes one wonder if you could just throw a request with a chunked trailer header at an SSL VPN endpoint and get a crash…


I had some difficulty finding which endpoints to target exactly, but looking at FortiOS SSL VPN vulns from the past gave me the sense that the /remote endpoint is related. I searched for this endpoint as a string in Ghidra and came up with a list of possibilities. Having these paired with the Trailer spec, as well as getting the general size of what a chunk encoded trailer would be, should be enough to come up with a tentative detection or watcher to see if we can catch a PoC. Something like

alert http any any -> any any (msg:"Fortinet FortiOS Fortiproxy RCE CVE-2024-21762 Attempt"; flow:to_server,established; \
                                http.uri.raw; content: "/remote/"; fast_pattern; \
                                http.header_names; content: "transfer-encoding"; nocase; \
                                http.header.raw; content: "chunked"; nocase; isdataat:200;\
                                http.request_body; content: "0|0D 0A|"; \
                                http.request_body; content: "|3A|"; \
                                classtype:malicious; sid:123; rev:1;)

should work!

This is my first deep foray into tracking down a vulnerability in a binary of this size, so I’m pretty happy with this. You too can watch for this exploit in our data!

Steps Forward

While waiting for this detection to alert, I’ll be digging back into the RE work to track down specific vulnerable endpoints. With these in hand, the next step will be spinning up a target VM and throwing some chunk encoded Trailer packets at it.