Inspired by @osxreverser analysis of NSA BPF port-knocking implant, I decided to take a 2nd look at #ShadowBrokers leak of windows implants. Lo and behold, a couple of hardly mentioned kernel drivers (#DoormanGauze and #FlewAvenue) caught my attention. (1/11)
Information publicly available on these drivers is scarce and for the most part flat out wrong. Instead of going for the usual deep-dive blog post, lets try a light-speed tweeter thread analysis. In this thread we'll take a brief look at #DoormanGauze. (2/11)
So, what is #DoormanGauze... In a nutshell, its a plugin for #DanderSpritz / #ExpandingPulley implants implementing an in-kernel mailslot server, allowing for stealthy inter-process communication. This can replace the usual named pipes/windows sockets IPC. (3/11)
The module follows a typical NDIS filter driver, implementing 11 IOCTLs that can be called by other drivers or from userland code. These range from getting version, registering mailslots, fetching status for single/all slots, send messages and clearing triggers. (4/11)
The driver implements 25 slots, which can be individually registered and messages delivered to. Internally a structure is kept which keeps track of slot index, bound process, comms path, last trigger time and status. (5/11)
Strings are obfuscated with a single byte XOR (0x77), and are decoded in memory strictly for the time needed before getting wiped from memory. Other than this, no other attempts are made to obfuscate or otherwise hinder reversing the code. (6/11)
The leak contains both i386 and x64 versions, as well as the respective userland DLLs for interaction with the driver. On load, the driver registers a device and symlink, enumerates ethernet network adapters through registry and bounds to them in order to filter traffic. (7/11)
After the filter is active, all packets on bound interfaces are parsed, checking for IPv4 or IPv6 headers, and delegating execution to the respective parsing routine. These functions sieve the traffic for packets containing specifically crafted data payloads. (8/11)
Parsing roughly checks for a 6 byte tail with data length and MAGIC words XORed respectfully with 0x55aa and 0xaa55. These must further match a 2 byte header to be accepted and the data delivered to the mailslot. Some further checks are made for ICMP and TCP packets (9/11)
If the packet matches the expected payload, the data is dispatched to the registered mailslots, updating the trigger time. If an error is detected while dispatching the message, that mailslot is unregistered to prevent receiving further messages (10/11)
This light-speed/ultra-condensate type of analysis deceitfully hide several hours of reversing. If you find this format useful and would like to see more of these, leave a like or retweet. If a more in-depth blog post is preferred do let me know. (11/11)
• • •
Missing some Tweet in this thread? You can try to
force a refresh
Let's explore China’s 0-day vulnerability research capabilities.
I’ve long been intrigued by the prolific nature of Chinese teams in discovering vulnerabilities. Over the past months, I’ve gathered some data and analyzed reported vulnerabilities to gain a deeper understanding.🧵
Since September 2021, the Chinese government has mandated that any Chinese researchers, businesses, or even foreign companies operating in China who discover 0-day vulnerabilities must report the details to the Chinese Ministry of Industry and Information Technology (MIIT)
The policy in question was formalized through the "Provisions on the Management of Network Product Security Vulnerabilities" issued by MIIT, which obliges entities to report vulnerabilities within within two days (48 hours) of their discovery. chinalawtranslate.com/en/product-sec…
It's time to take a closer look at CVE-2024-38063 (Windows TCPIP RCE).
I usually don't post partial analysis but since most available info is unreliable I'll do my best to try and shed some light.
This time I'll focus on my workflow and thought process as we go. 🧵
MSFT advisory pretty much tells us where to look.
Our target is the tcpip.sys kernel driver which got an update during last patch tuesday.
For the analysis I picked binaries for Windows 11 23H2, builds 3958 (pre-fix) and 4036 (post).
Diffing shows a single function has changed.
In fact, this is the best you could hope for on binary diffing.
Further inspecting the differences on Ipv6pProcessOptions() it comes down to a single change at the end.
A call to IppSendErrorList() has been replaced by IppSendError(). Couldn't get simpler than this right? 😅
Some final notes on CVE-2024-30078 (wifi RCE) exploitability.
If you haven't already done so, I recommend you first take a look at my previous thread on the subject.
🧵
As previously noted, the native driver does not account for 4 extra bytes when the ether type is 0x8100 (Vlan tagged net).
Since the packet is rewritten on the original buffer, it will do so 4 bytes ahead of what is was supposed to because of the dot1q header that should exist.
This will not only corrupt the translated packet (which will be later discarded as invalid) but also overwrite up to 2 bytes outside the MDL buffer that holds the packet. [overflowed bytes marked in red]
But is the exploitability feasible?
MSFT released a patch for CVE-2024-30078 (Wi-Fi Driver RCE) on June cumulative update, however details on the advisory have been very limited.
I'm leaving some quick notes from a quick reverse engineering of the patch that hopefully will shed a little more light on the issue. 🧵
I am not an expert on wireless network protocols so feel free to correct me or add up on the provided info in the comments or through a DM.
The patch targets Dot11Translate80211ToEthernetNdisPacket() of the native wifi driver (nwifi.sys).
The patch expands on a previous check at the beginning of the function which is described in the pseudocode below: