Fortinet FortiOS suffers from an out of bounds write vulnerability. Affected includes Fortinet FortiOS versions 7.4.0 through 7.4.2, 7.2.0 through 7.2.6, 7.0.0 through 7.0.13, 6.4.0 through 6.4.14, 6.2.0 through 6.2.15, 6.0.0 through 6.0.17, FortiProxy versions 7.4.0 through 7.4.2, 7.2.0 through 7.2.8, 7.0.0 through 7.0.14, 2.0.0 through 2.0.13, 1.2.0 through 1.2.13, 1.1.0 through 1.1.6, and 1.0.0 through 1.0.7.
advisories | CVE-2024-21762
# CVE-2024-21762
out-of-bounds write in Fortinet FortiOS CVE-2024-21762 vulnerability
Vulnerability
=====
FortiGate released a version update in February, fixing multiple medium- and high-risk vulnerabilities. One of the severe-level vulnerabilities is an unauthorized out-of-bounds write vulnerability in SSL VPN. The vulnerability warning states that this vulnerability may be exploited in the wild. This article will introduce the author's analysis of the process of exploiting this vulnerability to achieve remote code execution.
The environment used for vulnerability analysis in this article is `FGT_VM64-v7.4.2.F-build2571`
diff
======
Comparing the binaries of the repaired versions (7.4.2 and 7.4.3), the analysis found that the repair code is located in function `sub_18F4980`(7.4.2).
Analyzing this function, it is not difficult to find that the logic of this function is to read the body data of the HTTP POST request. At the same time, Transfer-Encodingit is determined according to the request header whether to read in chunk format or based on Content-Lengthreading. According to the control flow graph comparison results, there are two code modifications:
When parsing the chunk format, call ap_getlinethe read chunk length and check ap_getlinewhether the return value is greater than 16. If it is greater than 16, it is considered an illegal chunk length.
When reading the chunk trailer, the source of the written rnoffset is `line_offthe` assignment source, `line_offthe` value before repair is from , and the return value after `*(_QWORD *)(a1 + 744)` repair is . `line_offap_getline`
Continuing to trace forward, `*(_QWORD *)(a1 + 744)` the value that can be found is the length of the chunk length field of the first verification.
Continuing to trace forward, `*(_QWORD *)(a1 + 744)` the value that can be found is the length of the chunk length field of the first verification.
At the same time, reading the code can tell that when the value of the chunk length field is 0 after hex decoding, it will enter the logic of chunk trailer reading.
Triggering out-of-bounds
=========
After analyzing the patch, we can draw the following conclusions:
1. When parsing a chunk, if the hex decoded value of the chunk length field is 0, start reading the chunk trailer.
2. After calling ap_getline to read the chunk trailer, it will be written to the buffer according to the length of the chunk length field `rn`.
3.
Therefore, if many 0s are passed in the chunk length field, and the length of 0s is greater than 1/2 of the remaining buffer length, an out-of-bounds write will be triggered rn. Through debugging, we can know that the target buffer is located on the stack `(function sub_1A111E0)` , and the return address is stored at offset 0x2028. If written at offset 0x202e `rn`, reta crash will occur due to an illegal address when the function returns to execute the instruction to resume rip.
Crash PoC:
```http
pkt = b"""
GET / HTTP/1.1
Host: %s
Transfer-Encoding: chunked
%srn%srnrn""" % (hostname.encode(), b"0"*((0x202e//2)-2), b"a")
ssock = create_ssock(hostname, port)
ssock.send(pkt)
ssock.recv(4096)
```
Crash scene:
By analyzing the cause of the vulnerability, it can be seen that the vulnerability can be used to write `rn` two bytes out of bounds on the stack, and the out-of-bounds range is close to `0x2000`. Since the written content is very limited, RCE cannot be achieved by directly hijacking rip. Therefore, you need to focus on the memory pointer saved on the stack.
failed attempt
============
What is easier to think of is to hijack rbp and overwrite the low byte of rbp so that rbp just points to a controllable memory area. When the upper-level function returns to execute the instruction, rip can be completely hijacked. However, during verification, it was found that even if rbp on the stack is overwritten, rsp and rip cannot be hijacked, and the program will not even crash. Continuing to trace back up, we find the parent function . This function is not called to restore rsp when it returns , but directly , so it cannot achieve the expected effect. leave retsub_1A111E0sub_1A26040 leave retadd rsp, 0x18
Find another breakthrough point
======
As seen in the previous section, the function saves the values of the five registers `rbx` and r12-r15 on the stack, and restores these registers when the function returns. Continue backtracking to find the parent function . You can see that what is saved in r13 is exactly the parameters `sub_1A26040sub_1A27650a1` .
a1 is a structure pointer. Through debugging, we can also see that a heap address is saved on the stack r13
If the memory in the red area in the figure is overwritten by out-of-bounds writing, then the r13 register is restored when the function returns, and the value of the pointer can be tampered with . If the heap memory can be laid out so that a1 points to a memory area arranged in advance, then the entire a1 structure can be hijacked. At the same time, through analysis of the code logic of and , there are a large number of dynamic function calls of a1 multi-level structure members, so there will be more opportunities to hijack **a1.sub_1A26040a1sub_1A27650sub_1A26040**
Hijacking a structure
==============
According to the assumption, after the low byte of the a1 pointer is overwritten , it can point to the pre-arranged memory. as the picture shows: `rn`
In order to achieve this effect, the following conditions need to be met:
The `a1` structure address is higher than the heap spray area address, and the gap between them is very small.
`0x7fxxxxxxx0a0d` Must point to the forged structure.
Debugging can find that the size of the a1 structure is `0x730` . According to the alignment rules of jemalloc, a heap block of size `0x800` will be allocated. The 0x800 heap block is not commonly used during request processing, so it is easy to exhaust the `0x800` heap block in tcache, and at the same time apply for more new 0x800 blocks, so that they can enter tcache after release. Heap injection also selects heap blocks of uncommon sizes so that the newly applied heap blocks are continuous and close to the newly applied 0x800; heap injection chooses to use larger heap blocks to ensure that their addresses are aligned with 0x800, so that It is easy to ensure that the lower 12 bits of each forged structure address are 0xa0d; the heap spray range is not less than `0x10000` to ensure that it points to the heap spray area. The effect after hijacking is as follows: `0x7fxxxxxxx0a0d`
Find exploitable multi-level pointers
======================
Through the above operations, the hijacking of the a1 structure can be achieved. Combing through the code of function sum, there are many dynamic calls to the second-level pointer and third-level pointer of the a1 structure member, for example: `sub_1A27650sub_1A26040`
When `(0<N<5)` is satisfied , it will be called dynamically . Therefore, the member needs to be faked into a multi-level pointer, which ultimately points to the function we want to call. Since the target binary does not have PIE protection turned on, you can find qualified multi-level pointers in the target binary. Analyzing the binary, we can find that the first points to the GOT table address of the corresponding function.`*(_BYTE *)(a1+0x20*(N+6)+0x10)&6==0*(__int64 (__fastcall **)(__int64))(*(_QWORD *)(*(_QWORD *)(a1 + 0x298)+0x70)+0xC0)(a1)a1 + 0x298`
Therefore, taking functions as an example, you can find qualified multi-level pointers **system**
During heap spraying, changing the value at offset 0x298 of the structure can be used to call the system function. The effect is as follows: `0x4368d0`
As shown in the figure, the parameter of the dynamic call is exactly a1, and the memory pointed to is controllable. At this point, you can normally use the system function to execute any command. However, in FortiGate, the file does not have the ability to execute commands, so using the system function to execute commands cannot be executed successfully. `/bin/sh`
Hijack RIP
============
Since the system function cannot execute commands, we can only find other ways to complete RCE. The existing condition is that any GOT table function can be called, and the memory pointed to by the first parameter of the function is controllable. Therefore, if there is a function in the GOT table that will call back a certain member of the parameter, there is a chance to achieve RIP hijacking. It’s easy to think of functions that were often used in previous FortiGate exploits . **SSL_do_handshake**
You only need to construct the SSL structure so that the conditions are met and the final call is made to realize rip hijacking and hijack rip to 0xdeadbeef as shown in the `figure:s->handshake_func(s)`
The FortiGate main program is an All-in-One binary with a size of over 70MB. There are a large number of gadgets that can be used. It is not difficult to implement RCE using ROP, so I won’t go into details.
### demo :
Although web mode is turned off by default in SSL VPN version 7.4.2 and browser access returns 403, this vulnerability can still be exploited in the default configuration.
This vulnerability is similar to the heap overflow vulnerability caused by XOR last year . They are both seemingly useless overflow vulnerabilities. The exploitation process is more tricky and more like a CTF question. However, compared with traditional CTF problems that attack heap managers, real vulnerabilities require more context structures and code logic to be exploited. The author's level is limited. If there are any mistakes, please correct me.CVE-2023-27997
original post In Chinese : https://mp.weixin.qq.com/s?__biz=Mzk0OTU2ODQ4Mw==&mid=2247484811&idx=1&sn=2e0407a32ba0c2925d6d857f4cdf7cbb&chksm=c3571307f4209a110d6b28cea9fe59ac0f0a2079c998a682e919860f397ea647fa0794933906&mpshare=1&scene=1&srcid=0313EaETjGzEAvOdByUt6ovU#rd
