This Week In Security: Anthropic, Coinbase, And Oops Hunting

July 7, 2025 by Jonathan Bennett 5 Comments

Anthropic has had an eventful couple weeks, and we have two separate write-ups to cover. The first is a vulnerability in the Antropic MCP Inspector, CVE-2025-49596. We’ve talked a bit about the Module Context Protocol (MCP), the framework that provides a structure for AI agents to discover and make use of software tools. MCP Inspector is an Open Source tool that proxies MCP connections, and provides debugging information for developers.

MCP Inspector is one of those tools that is intended to be run only on secure networks, and doesn’t implement any security or authentication controls. If you can make a network connection to the tool, you can control it. and MCP Inspector has the /sse endpoint, which allows running shell commands as a feature. This would all be fine, so long as everyone using the tool understands that it is not to be exposed to the open Internet. Except there’s another security quirk that intersects with this one. The 0.0.0.0 localhost bypass.

The “0.0.0.0 day exploit” is a bypass in essentially all the modern browsers, where localhost can be accessed on MacOS and Linux machines by making requests to 0.0.0.0. Browsers and security programs already block access to localhost itself, and 127.0.0.1, but this bypass means that websites can either request 0.0.0.0 directly, or rebind a domain name to 0.0.0.0, and then make requests.

Continue reading “This Week In Security: Anthropic, Coinbase, And Oops Hunting” →

Video Cable Becomes Transmitter With TEMPEST-LoRa

July 4, 2025 by Tyler August 9 Comments

EFI from cables is something every ham loves to hate. What if you modulated, that, though, using an ordinary cable as an antenna? If you used something ubiquitous like a video cable, you might have a very interesting exploit– which is exactly what [Xieyang Sun] and their colleagues have done with TEMPEST-LoRa, a technique to encode LoRa packets into video files.

The concept is pretty simple: a specially-constructed video file contains information to be broadcast via LoRa– the graphics card and the video cable serve as the Tx, and the Rx is any LoRa module. Either VGA or HDMI cables can be used, though the images to create the LoRa signal are obviously going to differ in each case. The only restriction is that the display resolution must be 1080×1920@60Hz, and the video has to play fullscreen. Fullscreen video might make this technique easy to spot if used in an exploit, but on the other hand, the display does not have to be turned on at the time of transmission. If employed by blackhats, one imagines syncing this to power management so the video plays whenever the screen blanks.

This image sends LoRa. Credit: TEMPEST-LoRa

According to the pre-print, a maximum transmission distance of 81.7m was achieved, and at 21.6 kbps. That’s not blazing fast, sure, but transmission out of a totally air-gapped machine even at dialup speeds is impressive. Code is on the GitHub under an MIT license, though [Xieyang Sun] and the team are white hats, so they point out that it’s provided for academic use. There is a demo video, but as it is on bilbili we don’t have an easy way to embed it. The work has been accepted to the ACM Conference on Computer and Communications Security (2025), so if you’re at the event in Taiwan be sure to check it out.

We’ve seen similar hacks before, like this one that uses an ethernet cable as an antenna. Getting away from RF, others have used fan noise, or even the once-ubiquitous HDD light. (And here we thought casemakers were just cheaping out when they left those off– no, it’s security!)

Thanks to [Xieyang Sun] for the tip! We’ll be checking the tips line for word from you, just as soon as we finish wrapping ferrites around all our cables.

The door-unlocking mechanism, featuring a 3D printed bevel gear and NEMA 17 stepper.

Hack Swaps Keys For Gang Signs, Everyone Gets In

July 2, 2025 by Tyler August 12 Comments

How many times do you have to forget your keys before you start hacking on the problem? For [Binh], the answer was 5 in the last month, and his hack was to make a gesture-based door unlocker. Which leads to the amusing image of [Binh] in a hallway throwing gang signs until he is let in.

The system itself is fairly simple in its execution: the existing deadbolt is actuated by a NEMA 17 stepper turning a 3D printed bevel gear. It runs 50 steps to lock or unlock, apparently, then the motor turns off, so it’s power-efficient and won’t burn down [Binh]’s room.

The software is equally simple; mediapipe is an ML library that can already do finger detection and be accessed via Python. Apparently gesture recognition is fairly unreliable, so [Binh] just has it counting the number of fingers flashed right now. In this case, it’s running on a Rasberry Pi 5 with a webcam for image input. The Pi connects via USB serial to an ESP32 that is connected to the stepper driver. [Binh] had another project ready to be taken apart that had the ESP32/stepper combo ready to go so this was the quickest option. As was mounting everything with double-sided tape, but that also plays into a design constraint: it’s not [Binh]’s door.

[Binh] is staying in a Hacker Hotel, and as you might imagine, there’s been more penetration testing on this than you might get elsewhere. It turns out it’s relatively straightforward to brute force (as you might expect, given it is only counting fingers), so [Binh] is planning on implementing some kind of 2FA. Perhaps a secret knock? Of course he could use his phone, but what’s the fun in that?

Whatever the second factor is, hopefully it’s something that cannot be forgotten in the room. If this project tickles your fancy, it’s open source on GitHub, and you can check it out in action and the build process in the video embedded below.

After offering thanks to [Binh] for the tip, the remaining words of this article will be spent requesting that you, the brilliant and learned hackaday audience, provide us with additional tips.

Continue reading “Hack Swaps Keys For Gang Signs, Everyone Gets In” →

Break The Air Gap With Ultrasound

June 29, 2025 by Jenny List 15 Comments

In the world of information security, much thought goes into ensuring that no information can leave computer networks without expressly being permitted to do so. Conversely, a lot of effort is expended on the part of would-be attackers to break through whatever layers are present. [Halcy] has a way to share data between computers, whether they are networked or not, and it uses ultrasound.

To be fair, this is more of a fun toy than an elite exploit, because it involves a web interface that encodes text as ultrasonic frequency shift keying. Your computer speakers and microphone can handle it, but it’s way above the human hearing range. Testing it here, we were able to send text mostly without errors over a short distance, but at least on this laptop, we wouldn’t call it reliable.

We doubt that many sensitive servers have a sound card and speakers installed where you can overhear them, but by contrast, there are doubtless many laptops containing valuable information, so we could imagine it as a possible attack vector. The code is on the linked page, should you be interested, and if you want more ultrasonic goodness, this definitely isn’t the first time we have touched upon it. While a sound card might be exotic on a server, a hard drive LED isn’t.

Reading The Chip In Your Passport

June 28, 2025 by Jenny List 37 Comments

For over a decade, most passports have contained an NFC chip that holds a set of electronically readable data about the document and its holder. This has resulted in a much quicker passage through some borders as automatic barriers can replace human officials, but at the same time, it adds an opaque layer to the process. Just what data is on your passport, and can you read it for yourself? [Terence Eden] wanted to find out.

The write-up explains what’s on the passport and how to access it. Surprisingly, it’s a straightforward process, unlike, for example, the NFC on a bank card. Security against drive-by scanning is provided by the key being printed on the passport, requiring the passport to be physically opened.

Continue reading “Reading The Chip In Your Passport” →

This Week In Security: MegaOWNed, Store Danger, And FileFix

June 27, 2025 by Jonathan Bennett 7 Comments

Earlier this year, I was required to move my server to a different datacenter. The tech that helped handle the logistics suggested I assign one of my public IPs to the server’s Baseboard Management Controller (BMC) port, so I could access the controls there if something went sideways. I passed on the offer, and not only because IPv4 addresses are a scarce commodity these days. No, I’ve never trusted a server’s built-in BMC. For reasons like this MegaOWN of MegaRAC, courtesy of a CVSS 10.0 CVE, under active exploitation in the wild.

This vulnerability was discovered by Eclypsium back in March and it’s a pretty simple authentication bypass, exploited by setting an X-Server-Addr header to the device IP address and adding an extra colon symbol to that string. Send this along inside an HTTP request, and it’s automatically allowed without authentication. This was assigned CVE-2024-54085, and for servers with the BMC accessible from the Internet, it scores that scorching 10.0 CVSS.

We’re talking about this now, because CISA has added this CVE to the official list of vulnerabilities known to be exploited in the wild. And it’s hardly surprising, as this is a near-trivial vulnerability to exploit, and it’s not particularly challenging to find web interfaces for the MegaRAC devices using tools like Shodan and others.

There’s a particularly ugly scenario that’s likely to play out here: Embedded malware. This vulnerability could be chained with others, and the OS running on the BMC itself could be permanently modified. It would be very difficult to disinfect and then verify the integrity of one of these embedded systems, short of physically removing and replacing the flash chip. And malware running from this very advantageous position very nearly have the keys to the kingdom, particularly if the architecture connects the BMC controller over the PCIe bus, which includes Direct Memory Access.

This brings us to the really bad news. These devices are everywhere. The list of hardware that ships with the MegaRAC Redfish UI includes select units from “AMD, Ampere Computing, ASRock, ARM, Fujitsu, Gigabyte, Huawei, Nvidia, Supermicro, and Qualcomm”. Some of these vendors have released patches. But at this point, any of the vulnerable devices on the Internet, still unpatched, should probably be considered compromised. Continue reading “This Week In Security: MegaOWNed, Store Danger, And FileFix” →

This Week In Security: That Time I Caused A 9.5 CVE, IOS Spyware, And The Day The Internet Went Down

June 20, 2025 by Jonathan Bennett 18 Comments

Meshtastic just released an eye-watering 9.5 CVSS CVE, warning about public/private keys being re-used among devices. And I’m the one that wrote the code. Not to mention, I triaged and fixed it. And I’m part of Meshtastic Solutions, the company associated with the project. This is is the story of how we got here, and a bit of perspective.

First things first, what kind of keys are we talking about, and what does Meshtastic use them for? These are X25519 keys, used specifically for encrypting and authenticating Direct Messages (DMs), as well as optionally for authorizing remote administration actions. It is, by the way, this remote administration scenario using a compromised key, that leads to such a high CVSS rating. Before version 2.5 of Meshtastic, the only cryptography in place was simple AES-CTR encryption using shared symmetric keys, still in use for multi-user channels. The problem was that DMs were also encrypted with this channel key, and just sent with the “to” field populated. Anyone with the channel key could read the DM.

I re-worked an old pull request that generated X25519 keys on boot, using the rweather/crypto library. This sentence highlights two separate problems, that both can lead to unintentional key re-use. First, the keys are generated at first boot. I was made painfully aware that this was a weakness, when a user sent an email to the project warning us that he had purchased two devices, and they had matching keys out of the box. When the vendor had manufactured this device, they flashed Meshtastic on one device, let it boot up once, and then use a debugger to copy off a “golden image” of the flash. Then every other device in that particular manufacturing run was flashed with this golden image — containing same private key. sigh

Continue reading “This Week In Security: That Time I Caused A 9.5 CVE, IOS Spyware, And The Day The Internet Went Down” →