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.

AMD Vulnerability Leaks

AMD has identified a security problem in how some of its processors verify the signature of microcode updates. That’s basically all we know about the issue, because the security embargo still isn’t up. Instead of an official announcement, we know about this issue via an Asus beta BIOS release that included a bit too much information.

I Read the Docs

There’s nothing quite as fun as winning a Capture The Flag (CTF) challenge the wrong way. The setup for this challenge was a simple banking application, with the challenge being to steal some money from the bank’s website. The intended solution was to exploit the way large floating point numbers round small values. Deposit 1e10 dollars into the bank, and a withdraw of $1000 is literally just a rounding error.

The unintended solution was to deposit NaN dollars. In JavaScript-speak that’s the special Not a Number value that’s used for oddball situations like dividing by a float that’s rounded down to zero. NaN has some other strange behaviors, like always resulting in false comparisons. NaN > 0? False. NaN < 0? False. NaN == NaN? Yep, also false. And when the fake bank web app checks if a requested withdraw amount is greater than the amount in the account? Since the account is set to NaN, it’s also false. Totally defeats the internal bank logic. How did the student find this unintended solution? “I read the docs.” Legendary.

Another Prompt Injection Tool

[Utku Sen] has a story and a revamped tool, and it leads to an interesting question about LLMs. The story starts with a novel LLM prompt, that gives more natural sounding responses from AI tools. LLMs have a unique problem, that there is no inherent difference between pre-loaded system prompts, and user-generated prompts. This leads to an attack, where a creative user prompt can reveal the system prompt. And in a case like [Utku]’s, the system prompt is the special sauce that makes the service work. He knew this, and attempted to protect against such attacks. Within an hour of releasing the tool to the public, [Utku] got a direct message on X with the system prompts.

There’s a really interesting detail, that the prompt injection attack only worked 1 out of 11 times. This sent me down an LLM rabbit hole, asking whether LLMs are deterministic, and if not, why not. The simple answer is the “temperature” control knob on LLMs add some random noise to the output text. There seems to be randomness even when the LLM temperature is turned to zero, caused either by floating point errors, or even a byproduct of doing batched inference. Regardless, prompt injection attacks may only work after several tries.

And that brings us to promptmap tool. It is intended to evaluate a system prompt, and launch multiple attempts to poison or otherwise inject malicious user prompts into the system. And of course, it is now capable of using the approach that successfully revealed [Utku]’s system prompt.

Cloudflare’s Unintentional GPS

There’s a really interesting unintended side effect of using Cloudflare’s CDN network: Users load data from the nearest datacenter. Unique data can be served to a target user, and then the cache can be checked to leak coarse location information. This is novel research, but ultimately not actually all that important from a security perspective. The primary reason is that the same sort of attack has always existed and can be used to extract a much more valuable piece of user identifying data: The user’s IP address.

The Unauthenticated, Unencrypted radios that control The German Power Grid

[Fabian Bräunlein] and [Luca Melette] were just looking for radio-controlled light switches, to pull off a modern take on Project Blinkenlights. What they found was the Radio Ripple Control protocol, an unauthenticated, unencrypted radio control protocol. That just happens to control about 40 Gigawatts of power generation across Germany, not to mention street lamps and other bits of hardware.

The worst-case scenario for an attacker is to turn on all of the devices that use grid power, while turning off all of the connected devices that generate power. Too much of an imbalance might even be capable of resulting in the dreaded grid-down scenario, where all the connected power generation facilities lose sync with each other, and everything has to be disconnected. Recovery from such a state would be slow and tedious. And thankfully not actually very likely. But even if this worst-case scenario isn’t very realistic, it’s still a severe vulnerability in how the German grid is managed. And fixes don’t seem to be coming any time soon.

Bits and Bytes

The Brave browser had a bit of a dishonest downloads issue, where the warning text about a download would show the URL from the referrer header. The danger is that a download may be considered trustworthy, even when it’s actually being served from an arbitrary URL.

If JavaScript in general or next.js in particular is in your security strike zone, you’ll want to check out the write-up from [Rachid.A] about cache poisoning in this particular framework, and the nice cache of security bounties it netted.

Zoom has a weird security disclosure for one of their Linux applications, and it contains a description I’ve never seen before: The bug “may allow an authorized user to conduct an escalation of privilege via network access.” Given the CVSS score of 8.8 with an attack vector of network, this should probably be called a Remote Code Execution vulnerability.

Subaru had a problem with STARLINK. No, not the satellite Internet provider, the other STARLINK. That’s Subaru’s vehicle technology platform that includes remote start and vehicle tracking features. That platform had a pair of flaws, the first allowing an attacker to reset any admin’s password. The second is that the Two Factor Authentication protection can be bypassed simply by hiding the pop-up element in the HTML DOM. Whoops! Subaru had the issues fixed in under 24 hours, which is impressive.

And finally, Silent Signal has the intriguing story of IBM’s i platform, and and a compatibility issue with Windows 11. That compatibility issue was Microsoft cracking down on apps sniffing Windows passwords. And yes, IBM i was grabbing Windows passwords and storing them in the Windows registry. What a trip.

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.

My Gmail is My Passport, Verify Me

Here’s an interesting question. What happens to those “Log In With Google” accounts that we all have all over the Internet, when the domain changes hands? And no, we’re not talking about gmail.com. We’re talking about myfailedbusiness.biz, or any custom domain that has been integrated with a Google Workspace. The business fails, the domain reverts back to unclaimed, someone else purchases it, and re-adds the [email protected] Google Workspace account. Surely that doesn’t register as the same account for the purpose of Google SSO, right?

The answer to this question is to look at what actually happens when a user uses Google Oauth to log in. The service sends a message to Google, asking Google to identify the user. Google asks the user for confirmation, and if granted will send an ID token to the service. That token contains three fields that are interesting for this purpose. The domain and email are straightforward, and importantly don’t make any distinction between the original and new users. So when the domain and email change hands, so does ownership of the token.

Oauth does provide a sub (subject) field, that is a unique token for a given user/service combination. Seems like that solves the issue, right? The problem is that while that identifier is guaranteed to be unique, it’s not guaranteed to be consistent, and thus isn’t widely used as a persistent user identifier. Google is aware of the issue, and while they initially closed it as a “Won’t fix” issue, the concept did eventually earn [Dylan Ayrey] a nifty $1337 bounty and a promise that Google is working on unspecified fixes. There is no immediate solution, and it’s not entirely clear that this is strictly a Google problem. Other SSO solutions may have the same quirk.

Fortigate Under Attack

Fortiguard has reported that a vulnerability in FortiOS and FortiProxy is under active exploitation. Fortiguard lists quite a few Indicators of Compromise (IoCs), but as far as the nature of the vulnerability, all we know is that it is an authentication bypass in an Node.js websocket module that allows a remote attacker to gain super-admin privileges. Yoiks.

Actic Wolf has more details on the exploit campaign, which was first found back in early December, but appears to have begun with widespread scanning for the vulnerability as early as November 16. Attackers moved slowly, with the goal of establishing VPN access into the networks protected behind the vulnerable devices. Arctic Wolf has provided additional IoCs, so time to go hunting.

Ivanti Connect, Too

There’s another security device under attack this week, as watchTowr labs has yet another fun romp through vendor mis-security. This time it’s a two-part series on Ivanti Connect Secure, and the two buffer overflows being used in the wild.

Ivanti has already released a patch, so the researchers ran a diff on the strings output for the patched and unpatched binary of interest. Three new error messages are in the new version, complaining about client data exceeding a size limit. The diaphora binary diffing tool found some interesting debbuging data, like Too late for IFT_PREAUTH_INIT. “IF-T” turns out to be an open VPN standard, and that term led to a statement about backwards compatibility in Ivanti code that had terrible “code smell”.

The IF-T protocol includes the optional clientCapabilities field, and Ivanti’s implementation used a fixed length buffer to store it when parsing incoming connections. The client code almost gets it right, using a strlen() check on the data, and strncpy() to ensure the right number of bytes are copied. Except both of those best-practices are completely useless when the result from strlen() is fed directly into strncpy() as the maximum byte count, without checking whether it overflows the buffer.

The second watchTowr article goes through the steps of turning the vulnerability into a real exploit, but doesn’t actually give away any exploit code. Which hasn’t really mattered, as Proof of Concepts (PoCs) are now available. The takeaway is that Ivanti still has security problems with their code, and this particular exploit is both fully known, and being used in the wild.

Pentesting Mushrooms

The folks at Silent Signal have an off-the-beaten-path write-up for us: How to get hired as a pentester. Or alternatively, the story of hacking Mushroom Inc. See, they built an intentionally vulnerable web application, and invited potential hires to find flaws. This application included cross-site scripting potential, SQL injection, and bad password handling, among other problems. The test was to take 72 hours, and find and document problems.

Part of the test was to present the findings, categorize each vulnerability’s severity, and even make recommendations for how the fictional business could roll out fixes. Along the way, we get insights on how to get your job application dismissed, and what they’re really looking for in a hire. Useful stuff.

Bits and Bytes

Secure Boot continues to be a bit of a problem. Microsoft signed a UEFI application that in turn doesn’t actually do any of the Secure Boot validation checks. This is only an issue after an attacker has admin access to a machine, but it does completely defeat the point of Secure Boot. Microsoft is finally rolling out fixes, revoking the signature on the application.

And if compromising Windows 11 is of interest to you, HN Security has just wrapped a four-part series that covers finding a vulnerability in an old Windows kernel driver, and turning it into a real read/write exploit that bypasses all of Microsoft’s modern security hardening.

Do you have a website, and are you interested in how your API is getting probed? Want to mess with attackers a bit? You might be interested in the new baitroute tool. Put simply, it’s a honeypot for web APIs.

And finally, the minds behind Top10VPN have released another vulnerability, this time in tunneling protocols like IPIP, GRE, and 6in4. The problem is a lack of validation on incoming tunnel packets. This allows for easy traffic injection, and using the tunnel servers as easy proxies. One of the worst cases is where this flaw allows accessing an internal network protected behind a consumer router.

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.

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.

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.

There’s still some improvements that could be made, namely integrating a battery charging circuit into the PCB and switching over to USB-C, but overall its a solid prototype with an impressive per-unit cost of less than $10 USD. Though if you’re looking for something even cheaper, we’ve seen an even more simplistic approach based on the ESP-01.

Over the last few months we’ve been keeping an eye on WiFiWart, an ambitious project to develop a Linux single-board computer (SBC) small enough to fit inside a USB wall charger. Developer [Walker] says the goal is to create an easily concealable “drop box” for penetration testing, giving security researchers a valuable foothold inside a target network from which to preform reconnaissance or launch attacks. Of course, we don’t need to tell Hackaday readers that there’s plenty of other things you can do with such a tiny open hardware Linux SBC.

Today we’re happy to report that [Walker] has gotten the first version of the board booted into Linux, though as you might expect given a project of this complexity, there were a few bumps along the way. From the single missing resistor that caused U-Boot to throw up an error to the finer points of compiling the kernel for an embedded board, the latest blog post he’s written up about his progress provides fascinating insight into the little gotchas of bringing up a SBC from scratch.

Once the board was booted into Linux, [Walker] started testing out different aspects of the system. A memory benchmark confirmed the finicky DDR3 RAM was working as expected, and he was able to load the kernel modules for the dual RTL8188 interfaces and connect to a network. While the two WiFi modules are currently hanging off the board’s full-sized USB ports, they will eventually be integrated into the PCB.

Critically, this prototype board is also allowing [Walker] to get an idea of what the energy consumption of the final hardware might be. Even at full tilt, this larger board doesn’t go over 500 mA at 5 VDC; so if he designs the power supply with a maximum output of 1 A, he should have a nice safety margin. As mentioned in the previous post, the plan is currently to put the PSU on its own board, which will allow more effective use of the charger’s internal volume.

With the software and hardware now largely locked in, [Walker] says his attention will be turned towards getting everything small enough to fit into the final form factor. This will certainly be the most challenging aspect of the project, but with a growing community of hackers and engineers lending their expertise to the cause, we’re confident the WiFiWart will soon be a reality.

When we last checked in on the WiFiWart, an ambitious project to scratch-build a Linux powered penetration testing drop box small enough to be disguised as a standard phone charger, it was still in the early planning phases. In fact, the whole thing was little more than an idea. But we had a hunch that [Walker] was tenacious enough see the project through to reality, and now less than two months later, we’re happy to report that not only have the first prototype PCBs been assembled, but a community of like minded individuals is being built up around this exciting open source project.

Now before you get too excited, we should probably say that the prototypes didn’t actually work. Even worse, the precious Magic Smoke was released from the board’s Allwinner A33 ARM SoC when a pin only rated for 2.75 V was inadvertently fed 3.3 V. The culprit? Somehow [Walker] says he mistakenly ordered a 3.3 V regulator even though he had the appropriate 2.5 V model down in the Bill of Materials. A bummer to be sure, but that’s what prototypes are for.

Even though [Walker] wasn’t able to fire the board up, the fact that they even got produced shows just how much progress has been made in a relatively short amount of time. A lot of thought went into how the 1 GB DDR3 RAM would get connected to the A33, which includes a brief overview of how you do automatic trace length matching in KiCad. He’s also locked in component selections, such as the RTL8188CUS WiFi module, that were still being contemplated as of our last update.

Towards the end of the post, he even discusses the ultimate layout of the board, as the one he’s currently working on is just a functional prototype and would never actually fit inside of a phone charger. It sounds like the plan is to make use of the vertical real estate within the plastic enclosure of the charger, rather than trying to cram everything into a two dimensional design.

Want to get in on the fun, or just stay updated as [Walker] embarks on this epic journey? Perhaps you’d be interested in joining the recently formed Open Source Security Hardware Discord server he’s spun up. Whether you’ve got input on the design, or just want to hang out and watch the WiFiWart get developed, we’re sure he’d be happy to have you stop by.

The first post about this project got quite a response from Hackaday readers, and for good reason. While many in the hacking and making scene only have a passing interest in the security side of things, we all love our little little Linux boards. Especially ones that are being developed in the open.