Late last week, an exploit surfaced on GitHub for CVE-2024-21762 [1]. This vulnerability affects Fortinet’s FortiOS. A patch was released on February 8th. Owners of affected devices had over a month to patch [2]. A few days prior to the GitHub post, the exploit was published on the Chinese QQ messaging network [3]
It took so long for an exploit to materialize because the vulnerability isn’t quite as trivial to exploit as the path traversal and command injection vulnerabilities usually found in similar devices. This is an “old fashioned” out-of-bounds write vulnerability requiring some assembly skills to craft a working exploit.
The vulnerability is triggered by the use of “Chunked Encoding”. Chunked encoding implementations have been problematic in the past. Instead of advertising the length of the HTTP request’s body via a “Content-Length” header, chunked encoding breaks the body into individual “chunks,” each with a length field.
The exploit can be sent via a post request to the index page. But for the exploit to work, the right amount of memory has to be allocated first. This is done by submitting form data first, and the URL allowing an attacker to do so is “/remote/hostcheck_validate”. This URL had its own heap-based buffer overflow last year [4]. However, in this case, it just serves as an “innocent bystander”, minding its business and being abused to prepare the system to exploit the new vulnerability [4].
The “/remote/hostcheck_validate” URL could also be used as a reasonable way to detect honeypots. The index page is quite easy to emulate, but the hostcheck_validate page is very specific to FortiOS.
Looking for scans for “/remote/hostcheck_validate” show little scanning on a few days in January and February:
+————+—————————-+
| date | url |
+————+—————————-+
| 2024-01-10 | /remote/hostcheck_validate |
| 2024-01-11 | /remote/hostcheck_validate |
| 2024-01-23 | /remote/hostcheck_validate |
| 2024-02-09 | /remote/hostcheck_validate |
+————+—————————-+
Further investigation shows that only one actor is scanning for this particular URL. The scans in January come from %%ip:185.224.128.191%%, while the scans in February are all from %%ip:185.224.128.10%%. Not only are both IPs in the same /24, but the scans emitted by these IPs are identical. They are not just looking for this FortiOS vulnerability but also for a range of different vulnerabilities in perimeter security devices, going back to Shellshock exploits.
This vulnerability does not attract a lot of attention from the bad guys. This is likely because the vulnerability is a bit more complex to exploit, and there are plenty of simpler vulnerabilities out there. Exploitation is also not as easy and reliable to “automate” as some other vulnerabilities. Still, exploits are out there, and you should assume compromise if you find an unpatched device in your network.
[1] https://github.com/h4x0r-dz/CVE-2024-21762/blob/main/poc.py
[2] https://www.fortiguard.com/psirt/FG-IR-24-015
[3] https://mp.weixin.qq.com/s?__biz=Mzk0OTU2ODQ4Mw==&mid=2247484811&idx=1&sn=2e0407a32ba0c2925d6d857f4cdf7cbb&chksm=c3571307f4209a110d6b28cea9fe59ac0f0a2079c998a682e919860f397ea647fa0794933906&mpshare=1&scene=1&srcid=0313EaETjGzEAvOdByUt6ovU#rd
[4] https://nvd.nist.gov/vuln/detail/CVE-2023-27997
—
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.