This Week in Security

267 Articles

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

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

This Week In Security: Signal DRM, Modern Phone Phreaking, And The Impossible SSH RCE

May 23, 2025 by No comments

Digital Rights Management (DRM) has been the bane of users since it was first introduced. Who remembers the battle it was getting Netflix running on Linux machines, or the literal legal fight over the DVD DRM decryption key? So the news from Signal, that DRM is finally being put to use to protect users is ironic.

The reason for this is Microsoft Recall — the AI powered feature that takes a snapshot of everything on the user’s desktop every few seconds. For whatever reason, you might want to exempt some windows from Recall’s memory window. It doesn’t speak well for Microsoft’s implementation that the easiest way for an application to opt out of the feature is to mark its window as containing DRM content. Signal, the private communications platform, is using this to hide from Recall and other screenshotting applications.

The Signal blogs warns that this may be just the start of agentic AI being rolled out with insufficient controls and permissions. The issue here isn’t the singularity or AI reaching sentience, it’s the same old security and privacy problems we’ve always had: Too much information being collected, data being shared without permission, and an untrusted actor having access to way more than it should. Continue reading “This Week In Security: Signal DRM, Modern Phone Phreaking, And The Impossible SSH RCE” →

This Week In Security: Lingering Spectre, Deep Fakes, And CoreAudio

May 16, 2025 by 5 Comments

Spectre lives. We’ve got two separate pieces of research, each finding new processor primitives that allow Spectre-style memory leaks. Before we dive into the details of the new techniques, let’s quickly remind ourselves what Spectre is. Modern CPUs use a variety of clever tricks to execute code faster, and one of the stumbling blocks is memory latency. When a program reaches a branch in execution, the program will proceed in one of two possible directions, and it’s often a value from memory that determines which branch is taken. Rather than wait for the memory to be fetched, modern CPUs will predict which branch execution will take, and speculatively execute the code down that branch. Once the memory is fetched and the branch is properly evaluated, the speculatively executed code is rewound if the guess was wrong, or made authoritative if the guess was correct. Spectre is the realization that incorrect branch prediction can change the contents of the CPU cache, and those changes can be detected through cache timing measurements. The end result is that arbitrary system memory can be leaked from a low privileged or even sandboxed user process.

In response to Spectre, OS developers and CPU designers have added domain isolation protections, that prevent branch prediction poisoning in an attack process from affecting the branch prediction in the kernel or another process. Training Solo is the clever idea from VUSec that branch prediction poisoning could just be done from within the kernel space, and avoid any domain switching at all. That can be done through cBPF, the classic Berkeley Packet Filter (BPF) kernel VM. By default, all users on a Linux system can run cBPF code, throwing the doors back open for Spectre shenanigans. There’s also an address collision attack where an unrelated branch can be used to train a target branch. Researchers also discovered a pair of CVEs in Intel’s CPUs, where prediction training was broken in specific cases, allowing for a wild 17 kB/sec memory leak.

Continue reading “This Week In Security: Lingering Spectre, Deep Fakes, And CoreAudio” →