rapid7
CVE-2024-30078: Windows WiFi Driver RCE
Summary
This module would exploit CVE-2024-30078 a remotely accessible RCE vulnerability in the Windows WiFi driver which requires no user authentication. It affects a wide range of Windows devices (like all of them Vista and up apparently).
In order to exploit the attacker would have to be within WiFi range of the victim, which seems like a reasonable requirement for physical pen tests.
Basic example
No PoC seems to be available at the time
https://catalog.update.microsoft.com/Search.aspx?q=KB5039212 patch link I also have Unpatched Windows 11 H23H2 ISO
@blkph0x has made a WIP PoC of the exploit! An additional explaination can be found on that some user's Reddit post:
NO so explanation on a simple level windows wifi driver has a buffer of 512 bytes to store the ssid the normal limit is 32 chars so heaps of space right? wrong you can create a chunked frame beacon to create an ssid more then 512 bytes long and at this point we are getting some strange issues the wifi task bar tab stops responding and may fail to show at all. im currently researching this for a 1day and should have a rce POC going tonight
This REPO does not seem to be hitting the same bug as in the stated CVE new information has came to my attention thaks to FarmPoet, The CVE-2024-30078 vulnerability is in Dot11Translate80211ToEthernetNdisPacket() of the native wifi windows driver (nwifi.sys) and a very specific frame needs to be constructed to even get to the vulnerable code path (which this code does not).
yeah.. so it seems they talked this up a lot there are some pre requests for this to be exploited as it currently is. 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. But is the exploitability feasible? Well... not easily since there's a check that ensures the 12 bits of the vlan ID field must be zero (at the location where the dot1q header was expected). In order to overflow the buffer you can't send those extra bytes so you depend on what was there in the first place. You can either send 1 zero byte after the SNAP header overflowing 1 byte, or none at all and overflow 2 bytes. Keep in mind you must brute force sending packets until the 2 bytes after the buffer are both zero. Possible but not easy since there are 65535 possibilites. This is not where the hurdle stops. The heap memory disposition adjacent to the buffer matters. You do control the 2 bytes that are overwritten (they'll be the last 2 octets of the transmitter MAC address) but what you overwrite is important and will decide if there's a crash. If you're lucky, you might overwrite some memory pointer that is later dereferenced and cause a crash but the exploitability to get remote code execution will be very very slim. At the very least you'd need another vulnerability that remotely leaks a kernel pointer. So, in a nutshell, the impact of the CVE is imho much less severe than anticipated from the Microsoft advisory. You need to share the same network as the target, need to brute force a specific memory layout and still need extra information to perform anything other than a DoS.
@blkph0x has made a WIP PoC of the exploit! An additional explaination can be found on that some user's Reddit post:
NO so explanation on a simple level windows wifi driver has a buffer of 512 bytes to store the ssid the normal limit is 32 chars so heaps of space right? wrong you can create a chunked frame beacon to create an ssid more then 512 bytes long and at this point we are getting some strange issues the wifi task bar tab stops responding and may fail to show at all. im currently researching this for a 1day and should have a rce POC going tonight
This was unrelated and still need to check it out but it may be caused by the wifi card vendor itself and not the windows driver.
update: the repo quoted here has been updated to attack this issue although its hit and miss works on some cards and some networks need someone with a bit more wifi knowledge to get this working