by: Jonathan Bennett
Here’s a fun thought experiment. UDP packets can be sent with an arbitrary source IP and port, so you can send a packet to one server, and could aim the response at another server. What happens if that response triggers another response? What if you could craft a packet that continues that cycle endlessly? That is essentially the idea behind Loop DoS (Denial of Service).
This unique avalanche of packets has been managed using specific implementations of several different network services, like TFTP, DNS, and NTP. There are several CVEs being used to track the issue, but CVE-2024-2169 is particularly odd, with the description that “Implementations of UDP application protocol are vulnerable to network loops.” This seems to be a blanket CVE for UDP, which is particularly inappropriate given that the first DoS of this sort was first reported in 2009 at the latest.
More details are available in a Google Doc. There some interesting tidbits there, like the existence of cross-protocol loops, and several legacy protocols that are vulnerable by design. The important thing to remember here is you have to have an accessible UDP port for this sort of attack to take place, so if you’re not using it, firewall it.
FLIPPER FLIPS BACK
We’ve covered the saga of the Flipper Zero vs the Canadian government, in the context of car theft. The short version is that Canada has seen an uptick of car thefts from organized crime. Rather than meaningfully dealing with this problem, the Canadian government went looking for scapegoats, and found the Flipper Zero.
Well now, Flipper has responded, and put simply, the message is “stop the madness”. There has never been a confirmed case of using a flipper to steal a car, and it’s very unlikely it’s ever happened. On a modern car with proper rolling-code security, it’s not meaningfully possible to use the Flipper Zero for the theft. The two primary ways criminals actually steal cars are with dedicated keyfob repeaters and CAN bus hackers.
There is a petition to sign, and for Canadians, Flipper suggests contacting your local member of parliament.
DATA-ONLY EOP
In a post on the state of modern exploitation, [Connor McGarr] explores the world of post-shellcode Elevation of Privilege (EoP) exploits. Why are we talking about exploitation without shellcode? Namely because the latest and greatest of Windows kernel hardening: kCET, kCFG, and HVCI. That’s kernel Control-flow Enforcement Technology, kernel Control Flow Guard, and Hypervisor-Protected Code Integrity. Those technologies together essentially guarantee that any area of kernel memory can either be writable or executable, but not both. That’s a pretty hard limit.
So what’s left? Apparently a lot. Starting with the simplest, a data-only exploit, an attacker can sniff the token of a system process and use it to elevate their own. The rest of the post is an in-depth treatment of how an attacker process can sniff and manipulate its way to a nearly kernel-level position. Impressive stuff.
FORTINET OLD AND NEW
We have a deep dive into a Forticlient vulnerability, CVE-2023-48788, a SQL injection in the FcmDaemon process. The vulnerable field here was “FCTUID”, and a WAITFOR DELAY message was enough to prove it was the vulnerability. Turning this into an RCE is trivial thanks to the extremely helpful xp_cmdshell function of Microsoft SQL server. That’s off by default, but can be turned back on… via SQL statements. *sigh* It’s a bit jarring to cover Microsoft’s stellar work on hardening the Windows kernel, only to find old cruft in their SQL server still causing problems like this.
And then there’s the newer Fortinet issue, in the Fortigate SSL VPN. Researchers at Assetnote give us all the details on how they tracked this one down, starting with patch diffing and fuzzing the likely vulnerable endpoint. That led to a crash, which was a great start, but even a Ghidra decompile wasn’t quite enough to work out how to turn the crash into an exploit. What was really needed was to hook a debugger to the crashing function.
And that gets into the hack before the hack. As typically happens, the Assetnote folks had to take a system image and backdoor it to get true root access and a usable system terminal. That was an adventure in itself. With that done, GDB did its magic, revealing that the crash they found was nearly useless for exploitation. But a bit of manipulation with leading 0s in the packet that caused the crash, and they had a primitive: The bytes 0x0a0d could be written to the stack, at a mostly controlled location. Is that enough for an exploit? Just two bytes?
When you can send packets that get stored on the heap, and you have a debugger to watch what happens, it turns out that is enough. A return pointer was chosen, that could be corrupted with this two-byte write, to jump program execution through a gadget right into a carefully controlled heap location. Write the payload that pops /bin/sh, and victory! Except, remember all that hacking they did on their test copy of Fortigate? One of those steps was replacing the /bin/sh binary with something useful. After a bit more wrangling, and borrowing a function or two from the system SSL library, the exploit was finally finished, using a nodejs
