This Week in Security

269 Articles

This Week In Security: Bitchat, CitrixBleed Part 2, Opossum, And TSAs

July 11, 2025 by 10 Comments

@jack is back with a weekend project. Yes, that Jack. [Jack Dorsey] spent last weekend learning about Bluetooth meshing, and built Bitchat, a BLE mesh encrypted messaging application. It uses X25519 for key exchange, and AES-GCM for message encryption. [Alex Radocea] took a look at the current state of the project, suspects it was vibe coded, and points out a glaring problem with the cryptography.

So let’s take a quick look at the authentication and encryption layer of Bitchat. The whitepaper is useful, but still leaves out some of the important details, like how the identity key is tied to the encryption keys. The problem here is that it isn’t.

Bitchat has, by necessity, a trust-on-first-use authentication model. There is intentionally no authentication central authority to verify the keys of any given user, and the application hasn’t yet added an out-of-band authentication method, like scanning QR codes. Instead, it has a favorites system, where the user can mark a remote user as a favorite, and the app saves those keys forever. There isn’t necessarily anything wrong with this approach, especially if users understand the limitations.

The other quirk is that Bitchat uses ephemeral keys for each chat session, in an effort to have some forward secrecy. In modern protocols, it’s desirable to have some protection against a single compromised encryption key exposing all the messages in the chain. It appears that Bitchat accomplishes this by generating dedicated encryption keys for each new chat session. But those ephemeral keys aren’t properly verified. In fact, they aren’t verified by a user’s identity key at all!

The attack then, is to send a private message to another user, present the public key of whoever your’re trying to impersonate, and include new ephemeral encryption keys. Even if your target has this remote user marked as a favorite, the new encryption keys are trusted. So the victim thinks this is a conversation with a trusted person, and it’s actually a conversation with an attacker. Not great. Continue reading “This Week In Security: Bitchat, CitrixBleed Part 2, Opossum, And TSAs” →

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

July 7, 2025 by 8 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” →

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

June 27, 2025 by 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 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” →

This Week In Security: The Localhost Bypass, Reflections, And X

June 13, 2025 by 26 Comments

Facebook and Yandex have been caught performing user-hostile tracking. This sort of makes today just another Friday, but this is a bit special. This time, it’s Local Mess. OK, it’s an attack with a dorky name, but very clever. The short explanation is that web sites can open connections to localhost. And on Android, apps can be listening to those ports, allowing web pages to talk to apps.

That may not sound too terrible, but there’s a couple things to be aware of. First, Android (and iOS) apps are sandboxed — intentionally making it difficult for one app to talk to another, except in ways approved by the OS maker. The browser is similarly sandboxed away from the apps. This is a security boundary, but it is especially an important security boundary when the user is in incognito mode.

The tracking Pixel is important to explain here. This is a snippet of code, that puts an invisible image on a website, and as a result allows the tracker to run JavaScript in your browser in the context of that site. Facebook is famous for this, but is not the only advertising service that tracks users in this way. If you’ve searched for an item on one site, and then suddenly been bombarded with ads for that item on other sites, you’ve been tracked by the pixel.

This is most useful when a user is logged in, but on a mobile device, the user is much more likely to be logged in on an app and not the browser. The constant pressure for more and better data led to a novel and completely unethical solution. On Android, applications with permission to access the Internet can listen on localhost (127.0.0.1) on unprivileged ports, those above 1024.

Facebook abused this quirk by opening a WebRTC connection to localhost, to one of the ports the Facebook app was listening on. This triggers an SDP connection to localhost, which starts by sending a STUN packet, a UDP tool for NAT traversal. Packed into that STUN packet is the contents of a Facebook Cookie, which the Facebook app happily forwards up to Facebook. The browser also sends that cookie to Facebook when loading the pixel, and boom Facebook knows what website you’re on. Even if you’re not logged in, or incognito mode is turned on.

Yandex has been doing something similar since 2017, though with a different, simpler mechanism. Rather than call localhost directly, Yandex just sets aside yandexmetrica.com for this purpose, with the domain pointing to 127.0.0.1. This was just used to open an HTTP connection to the native Yandex apps, which passed the data up to Yandex over HTTPS. Meta apps were first seen using this trick in September 2024, though it’s very possible it was in use earlier.

Both companies have ceased since this report was released. What’s interesting is that this is a flagrant violation of GDPR and CCPA, and will likely lead to record-setting fines, at least for Facebook.

Continue reading “This Week In Security: The Localhost Bypass, Reflections, And X” →

This Week In Security: Roundcube, Unified Threat Naming, And AI Chat Logs

June 6, 2025 by 4 Comments

Up first, if you’re running a Roundcube install prior to 1.5.10 or 1.6.11, it’s time to update. We have an authenticated Remote Code Execution (RCE) in the Roundcube Webmail client. And while that’s not quite the level of chaos that an unauthenticated RCE would cause, it’s still to be taken seriously. Mainly because for the majority of the 53 million Roundcube installs out there, the users aren’t entirely trusted.

The magic at play in this vulnerability is the Roundcube user session code, and specifically the session deserialization scheme. There’s a weird code snippet in the unserialize function:
if ($str[$p] == '!') {
$p++;
$has_value = false;

The exclamation mark makes the code skip a character, and then assume that what comes next has no value. But if it does actually have a value, well then you’ve got a slightly corrupted deserialization, resulting in a slightly corrupted session. This really comes into force when combined with the file upload function, as the uploaded filename serves as a payload delivery mechanism. Use the errant exclamation mark handling to throw off deserialization, and the filename can contain arbitrary session key/value pairs. A GPG class from the PEAR library allows running an arbitrary command, and this can be hijacked with the session manipulation. Continue reading “This Week In Security: Roundcube, Unified Threat Naming, And AI Chat Logs” →

This Week In Security: CIA Star Wars, Git* Prompt Injection And More

May 30, 2025 by 3 Comments

The CIA ran a series of web sites in the 2000s. Most of them were about news, finance, and other relatively boring topics, and they spanned 29 languages. And they all had a bit of a hidden feature: Those normal-looking websites had a secret login and hosted CIA cover communications with assets in foreign countries. A password typed in to a search field on each site would trigger a Java Applet or Flash application, allowing the spy to report back. This isn’t exactly breaking news, but what’s captured the Internet’s imagination this week is the report by [Ciro Santilli] about how to find those sites, and the fact that a Star Wars fansite was part of the network.

This particular CIA tool was intended for short-term use, and was apparently so effective, it was dragged way beyond it’s intended lifespan, right up to the point it was discovered and started getting people killed. And in retrospect, the tradecraft is abysmal. The sites were hosted on a small handful of IP blocks, with the individual domains hosted on sequential IP addresses. Once one foreign intelligence agency discovered one of these sites, the rest were fairly easily identified.
Continue reading “This Week In Security: CIA Star Wars, Git* Prompt Injection And More” →