This Week In Security: ClamAV, The AMD Leak, And The Unencrypted Power Grid

Cisco’s ClamAV has a heap-based buffer overflow in its OLE2 file scanning. That’s a big deal, because ClamAV is used to scan file attachments on incoming emails. All it takes to trigger the vulnerability is to send a malicious file through an email system that uses ClamAV.

The exact vulnerability is a string termination check that can fail to trigger, leading to a buffer over-read. That’s a lot better than a buffer overflow while writing to memory. That detail is why this vulnerability is strictly a Denial of Service problem. The memory read results in process termination, presumably a segfault for reading protected memory. There are Proof of Concepts (PoCs) available, but so far no reports of the vulnerability being used in the wild.
Continue reading “This Week In Security: ClamAV, The AMD Leak, And The Unencrypted Power Grid”

This Week In Security: Rsync, SSO, And Pentesting Mushrooms

Up first, go check your machines for the rsync version, and your servers for an exposed rsync instance. While there are some security fixes for clients in release 3.4.0, the buffer overflow in the server-side rsync daemon is the definite standout. The disclosure text includes this bit of nightmare fuel: “an attacker only requires anonymous read access to a rsync server, such as a public mirror, to execute arbitrary code on the machine the server is running on.”

A naive search on Shodan shows a whopping 664,955 results for rsync servers on the Internet. Red Hat’s analysis gives us a bit more information. The checksum length is specified by the remote client, and an invalid length isn’t properly rejected by the server. The effect is that an attacker can write up to 48 bytes into the heap beyond the normal checksum buffer space. The particularly dangerous case is also the default: anonymous access for file retrieval. Red Hat has not identified a mitigation beyond blocking access.

If you run servers or forward ports, it’s time to look at ports 873 and 8873 for anything listening. And since that’s not the only problem fixed, it’s really just time to update to rsync 3.4.0 everywhere you can. While there aren’t any reports of this being exploited in the wild, it seems like attempts are inevitable. As rsync is sometimes used in embedded systems and shipped as part of appliances, this particular bug threatens to have quite the long tail. Continue reading “This Week In Security: Rsync, SSO, And Pentesting Mushrooms”

USB HID And Run Exposes Yet Another BadUSB Surface

You might think you understand the concept of BadUSB attacks and know how to defend it, because all you’ve seen is opening a terminal window. Turns out there’s still more attack surface to cover, as [piraija] tells us in their USB-HID-and-run publication. If your system doesn’t do scrupulous HID device filtering, you might just be vulnerable to a kind of BadUSB attack you haven’t seen yet, rumoured to have been the pathway a few ATMs got hacked – simply closing the usual BadUSB routes won’t do.

The culprit is the Consumer Control specification – an obscure part of HID standard that defines media buttons, specifically, the “launch browser” and “open calculator” kinds of buttons you see on some keyboards, that operating systems, surprisingly, tend to support. If the underlying OS you’re using for kiosk purposes isn’t configured to ignore these buttons, they provide any attacker with unexpected pathways to bypass your kiosk environment, and it works astonishingly well.

[piraija] tells us that this attack provides us with plenty of opportunities, having tested it on a number of devices in the wild. For your own tests, the writeup has Arduino example code you can upload onto any USB-enabled microcontroller, and for better equipped hackers out there, we’re even getting a Flipper Zero application you can employ instead. While we’ve seen some doubts that USB devices can be a proper attack vector, modern operating systems are more complex and bloated than even meets the eye, often for hardly any reason – for example, if you’re on Windows 10 or 11, press Ctrl+Shift+Alt+Win+L and behold. And, of course, you can make a hostile USB implant small enough that you can build them into a charger or a USB-C dock.

USB image: Inductiveload, Public domain.

The WiFi Pumpkin Is The WiFi Pineapple We Have At Home

While networking was once all about the Cat 5 cables and hubs and routers, now most of us connect regularly in a wireless manner. Just like regular networks, wireless networks need auditing, and [Brains933] decided to whip up a tool for just that, nicknaming it the PumpkinPI_3.

The build is inspired by the WiFi Pineapple, which is a popular commercial pentesting tool. It runs the WiFi Pumpkin framework which allows the user to run a variety of attacks on a given wireless network. Among other features, it can act as a rogue access point, run man-in-the-middle attacks, and even spoof Windows updates if so desired.

In this case, [Brains933] grabbed a Raspberry Pi Zero W to run the framework. It was stuffed in a case with a Alfa Network AWUS036NHA wireless card due to its ability to run in monitoring mode — a capability required by some of the more advanced tools. It runs on a rechargeable LiPo battery for portability, and can be fitted with a small screen for ease of operation.

It should prove to be a useful tool for investigating wireless security on the go. Alternatively, you can go even leaner, running attacks off an ESP32.

Continue reading “The WiFi Pumpkin Is The WiFi Pineapple We Have At Home”

ESP32 Powers Covert Pentesting Device

Looking to expand their hardware design experience, [mentalburden] recently put together a low-cost handheld gadget that can be used for various security-related tasks such as logging WiFi traffic, operating as a dead drop, and performing deauthentication attacks.

The custom PCB plays host to the essentials — an ESP32-S microcontroller, AMS1117 3.3 V regulator, a SSD1306 OLED, and a couple of buttons. This lets the user navigate through a simple menu system and select whatever function they wish to enable. During testing, a pair of 18650 cells kept the electronics running for an impressive 22 hours.

A second version of the PCB fixed a few bodges that were required to get the original prototype working, and given how energy efficient the hardware ended up being,  [mentalburden] decided to drop the power supply down to a single 18650 for a total runtime of around 15 hours. A 3D printed case and some silicone buttons, produced with a simple clay mold, completed the package.