New Windows WiFi RCE vulnerability

Full Disclosure: I am just posthing this because of the meme. It sure beats the usual "hacker (because wearing hoodie) in a dark room with computers" picture that is so common in these posts. Yes, I am looking at you Tom's Hardware.

A "Remote Command Execution" (RCE) vulnerability just means that someone can send remote commands to something whose software have this vulnerability. A classic case of a RCE Vulnerability that was exploited is the log4j one (hello 2021!). These commands can be something like uploading malicious code to the computer or application which can be unleashed in the computer running this application. On June 12th, Microsoft's Patch Tuesday to address 49 CVE-tagged security flaws. Amongst them there was a patch for CVE-2024-30078, which deals with the WiFi RCE Vulnerability that is the topic of this post.

The main difference here is that this vulnerability is on the (Windows) drivers for a network card. The beauty about such attack is the attacker does not need the help from the user (as in phishing) to get the malware into the computer. In fact, chances are unless the code is patched, there may not be much stopping such an attack; all they need it to send a malicious networking packet to enable the remote code execution, which would then be followed with them uploading their own code to start exploring their new acquisition.

To add insult to injury, the attackers may not even need to be in the same network; all they have to be is within the range of the vulnerable computer. Witht he right equipment, "within range" can be measured in feet or even miles.

from Imgflip Meme Generator

Microsoft, who issued a patch for that, stated that there are no reported malware exploiting this vulnerability and that "Exploitation Less Likely" while the Cyber Security Agency of Singapore thinks it is a high-severity vulnerability and everyone using the Windows versions affected by this (pretty much everything remotely recent) should "update to the latest versions immediately". I do not know about you, but I would side with the Singapore agency on this one.

TL;DR:

Have Windows computer? Patch it. Immediately

Bloatware/Spyware: TikTok & Meta preinstalled in Windows 11 devices

Have you heard of the term "promoted apps?" That is the euphemistic term for programs that were preinstalled in a new computer. People like me knew them by a different term, bloatware, they were popular in the old Microsoft Windows and MacOS installs; the idea was companies would give money to OS and/or computer/smart phone manufacturers to bundle the former software with the later's products. Think of it as a variation of paid advertising or infomercial. This junk was grouped into:

• Trialware
• Adware
• Spyware, like those bundled by cell phone carriers.
• And, on a rare occasion, something useful. Somewhere out there there is an example.

That trend has not diminished. If you check your brower, you may find it is ready to connect to offer a youtube search engine built-in. People have been reported Windows 11 coming with TikTok and Meta installed at least since 2022. No matter what people said, I do not mind TikTok/Meta/Twitter/youtube as long as I decide to install it. I mean, what is wrong with going to an app store and getting it? But, why should any of them be bundled into a new Windows 11 tablet? Yes, there are tricks and instructions online to remove them, but they should not be there to begin with.

BadUSB, or There and Back Again

In that often misunderstood time between mullets and the switch to laptops without normal USB ports (I am looking at you, Apple), a traditional part of an on-premises pentesting was to grab all those USB drives you got from those many conferences you attended, wipe them to remove the informercials, white papers, and and other cruft, put a little script that would be called when the drive was automounted in a Windows or Mac (primarily Windows because it was easier), and then drop them on the parking lot of the company you are doing your engagement on.

The script was pretty simple: when run it would collect the IP, some computer info, and username. And then it would send that info to a collecting site (cannot call it C&C because it is not doing that much work), which would then parse all the info in a nice spreadsheet which you would then bring to your meeting with your customer as the list of users that may need some security retraining. After all, if a pentester can do that, so can a malicious attacker (are there non-malicious attackers?). It is a nice way to deploy a virus, or a program to help the attacker to get a foothold in the system.

Those were simpler times.

Talks were given and dongles were created to avert such an attack because, well, it was easier to buy them than asking IT department to push a group policy to disable automount. Or telling users not to mount any USB device they find on their computers.

But, we are talking about BadUSB! Yes, and it was first mentioned in 2014. The short version is that thanks to the typical development methodologies similar to those used in IoT development, namely get a product out there as quickly and cheaply as possiblw with complete disregard to supply chain security or security testing in general, a lot of USB devices are built on controllers which can be reprogrammed in the field. And reprogrammed they are, this time carrying malicious payloads like programs to spy on the user or get a foothold on the system.

Sounds familiar? I think so. Adding your code to the USB device's hardware to it is but an evolution of the principle of having code in a USB drive that is run when it automounts.

Fast forward almost a decade and we begin the year with the FBI sending warnings about this new attack vector called BadUSB that groups like FIN7 created to deploy ransomware even though they have been doing that for many years now.

There is no one-size-fits-all technical solution for BadUSB, not that have stopped vendors peddling software to address it. We will go over detailed a plan of action to minimize the effectiveness in a future article, but it sufices to say the old adage of "select your partners and wear protection" still applies. Also, end users are one of the most important lines of defense in the security domain. Work with them, empower them to understand and make the call; it can work if you do it right. Make the presentation enjoyable and memorable. I mean, if I could make that work at a medical institution to the point our box of found USB drives had to be replaced with a bucket, so can you.

Capturing Network Traffic in Windows Without Wireshark

One of the things that drives me nuts in the Windows community, articles found in help web sites included, is the idea that to solve any problem you need download something and run it. And ideally something off a shady site that must be run in Admin mode. Packet capturing is one example.

Yes, I do know of Wireshark, I like it a lot and think it is a brilliant program; the fact you can run it in Linux, OSX, and Windows is a nice touch. But, like everything else it has its place. So, where is that in my opinion? I think it is great for:

• Packet inspection in a nice visual way
• Following all the packets that make a stream. Ex: if you found a file being transfered, you can find every single packet involved.
• Packet filtering. yes, you can do that in tcpdump, but doing it visually and colourfully is so much nicer. Looking for a rogue DNS in a haystack of data? Just tell wireshark to mark any DNS response in purple!
• The massive list of non-TCP/UDP traffic (say, USB) it can handle.
• Deploying a tap or switch port mirror.
• Lots
• Having in your handy pentest/security laptop.

Now, where do I think it should not be used? Servers. The way I was taught in kitty school is that you should only install in the server the programs you need to provide the services said server is supposed to offer (and to secure that). For instance, some good explaining is required to justify running a VPN service in a web server specially in this age of containers. About normal packet capturing, I understand the occasional need for that in a server, but why installing wireshark in it? If its operating system is Linux, there is a perfectly good tcpdump avaiable: you install it, do what you need, and then remove it after the task is done; there is no need for leaving it in the server "just in case." But, what about a Windows server? There is no tcpdump port on it, so wireshark is the logical alternative.

Or is it? What if I told you Windows has a built-in solution?

Enter netsh trace, which allows you to record network traffic without downloading an extra program. It is not as sophisticated as tcpdump but if all we want is to capture packets, it work just fine. It is command line, but I think we can handle that. Here are the avaiable options:

PS C:\Users\user> netsh trace ?

The following commands are available:

Commands in this context:
?              - Displays a list of commands.
convert        - Converts a trace file to an HTML report.
correlate      - Normalizes or filters a trace file to a new output file.
diagnose       - Start a diagnose session.
dump           - Displays a configuration script.
help           - Displays a list of commands.
show           - List interfaces, providers and tracing state.
start          - Starts tracing.
stop           - Stops tracing.

To view help for a command, type the command, followed by a space, and then
 type ?.

PS C:\Users\user>

Recording

The way I usuall start recording network traffic is (and, yes you need to run it as an Admin)

netsh trace start persistent=yes capture=yes tracefile=packets.etl

Where

• persistent: Keep on logging after a reboot. Default is persistent = no
• start: Start packet capture. To stop it, netsh trace stop.
• tracefile: Is the name (and path) of the file the packets will be saved to. If you just enter the filename, it is saved in the same directory/folder you ran the command from. It is comparable to the -w flag in tcpdump. I strongly suggest to save this file somewhere only you (or the Admin) has access to; there are very few times when having a packet capture file available for all makes sense.

Other useful options:

• maxsize: max size of log file before it gets overwritten. maxsize=250 (MB) is the default; if you set maxsize = 0 it would not stop filling it up until running out of disk space (unlimited).

Inspecting

When you finish capturing you will notice that you now have two new files:

Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-a----        4/24/2017   3:59 PM         650033 packets.cab
-a----        4/24/2017   3:58 PM         524288 packets.etl

For this discussion we will only care about packets.etl. Next step is to take the file out of the server to a system where we can analyze it with wireshark (the right tool for the job). Unfortunatelty Wireshark as of the time this article was created (April 2017) can't read a .etl file; more info on a wireshark bug report that started on 2011 and was last updated 2 years ago. The only way I know to convert is using the Microsoft Message Analyzer, which means you need to install it, import packets.etl, and then export it (Save As->Export) as a .cap file. You could argue that if we have Microsoft Message Analyzer, there is no reason to add wireshark, but while I know how to use wireshark I only know how to use the Microsoft product to convert the packet to a format wireshark can use. I do wish there was a way to do this step from the command line; if someone knows, do post in the comments.

What about real time monitoring?

Do you remember the part about tap or switch port mirror? That is what I would do before putting wireshark in the server. If you have to install wireshark in the Windows server, do keep track of the extra programs you also need to install and ensure they are all removed after you are done.