Security Hacks

1498 Articles

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” →

A coiled black USB-C to USB-C cable is shown on a white background.

An Open-Source Justification For USB Cable Paranoia

June 16, 2025 by 37 Comments

Most people know that they shouldn’t plug strange flash drives into their computers, but what about a USB cable? A cable doesn’t immediately register as an active electronic device to most people, but it’s entirely possible to hide a small, malicious microcontroller inside the shell of one of the plugs. [Joel Serna Moreno] and some collaborators have done just that with their Evil Crow Cable-Wind.

This cable comes in two variants: one USB-A to USB-C, and one with USB-C to USB-C. A tiny circuit board containing an ESP32-S3 hides inside a USB-C plug on each cable, and can carry out a keystroke injection attack. The cable’s firmware is open-source, and has an impressive set of features: a payload syntax checker, payload autocompletion, OS detection, and the ability to impersonate the USB device of your choice.

The cable provides a control interface over WiFi, and it’s possible to edit and deploy live payloads without physical access to the cable (this is where the syntax checker should be particularly useful). The firmware also provides a remote shell for computers without a network connection; the cable opens a shell on the target computer which routes commands and responses through the cable’s WiFi connection (demonstrated in the video below).

The main advantage of the Evil Crow Cable Wind is its price: only about $25, at which point you can afford to lose a few during deployment. We’ve previously seen a malicious cable once before. Of course, these attacks aren’t limited to cables and USB drives; we’ve seen them in USB-C docks, in a gaming mouse, and the fear of them in fans.

Thanks to [rustysun9] for the tip!

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” →

A circuit board is shown on a white background. It has a USB-A port on the front side, and a coiled wire antenna extending from another circuit board mounted above the first one.

A Remote-Controlled USB Rubber Ducky Clone

June 13, 2025 by 17 Comments

Despite the repeated warnings of system administrators, IT personnel, and anyone moderately aware of operational security, there are still quite a few people who will gladly plug a mysterious flash drive into their computers to see what’s on it. Devices which take advantage of this well-known behavioral vulnerability have a long history, the most famous of which is Hak5’s USB Rubber Ducky. That emulates a USB input device to rapidly execute attacker-defined commands on the target computer.

The main disadvantage of these keystroke injection attacks, from the attacker’s point of view, is that they’re not particularly subtle. It’s usually fairly obvious when something starts typing thousands of words per minute on your computer, and the victim’s next move is probably a call to IT. This is where [Krzysztof Witek]’s open-source Rubber Ducky clone has an advantage: it uses a signal detected by a SYN480R1 RF receiver to trigger the deployment of its payload. This does require the penetration tester who uses this to be on the site of the attack, but unlike with an always-on or timer-delayed Rubber Ducky, the attacker can trigger the payload when the victim is distracted or away from the computer.

This project is based around the ATmega16U2, and runs a firmware based on microdevt, a C framework for embedded development which [Krzysztof] also wrote. The project includes a custom compiler for a reduced form of Hak5’s payload programming language, so at least some of the available DuckyScript programs should be compatible with this. All of the project’s files are available on GitHub.

Perhaps due to the simplicity of the underlying concept, we’ve seen a few open source implementations of malicious input devices. One was even built into a USB cable.

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” →

A USB dongle is shown connected to a laptop computer. A text box in the lower right corner says "PECKUS is running in DEBUG mode, it is 3x faster in non-DEBUG mode."

A Presence-sensing Drive For Securely Storing Secrets

May 24, 2025 by 23 Comments

When we hear about flash drives in the context of cybersecurity, we tend to think of them more as threats than as targets. When you’re using flash drives to store encryption keys, however, it makes sense to pay more attention to their security. [Juergen] designed the PECKUS (Presence Enforcing Crypto-Key USB-Storage) with this specifically in mind: a few-kilobyte storage device that only unlocks if the owner’s Bluetooth device is in the vicinity.

[Juergen] needed to store an infrequently-used keyfile on an air-gapped system, and commercial encrypted flash drives were rather expensive and left much to be desired in terms of usability. Instead, he designed a CircuitPython custom firmware for MakerDiary’s nRF52840 micro development kit, which provided a BLE-capable system in the form of a USB dongle.

After flashing the firmware to the board, the user sets it up with a particular Bluetooth device and a file to be stored; after writing the file during setup, it cannot be rewritten. Before reading from the device, the user must pair the previously-set device with the board and press a button on the board, and only then does the device appear to the computer.

The limited amount of storage space means that this device will probably only serve its intended purpose, but in those cases, it’ll be handy to have an open-source and inexpensive protected storage device. [Juergen] notes that attackers could theoretically defeat this system by desoldering the microcontroller from the board and extracting the memory contents from the its storage, but if you have enemies that resourceful, you probably won’t be relying on a $20 board anyways.

We’ve previously seen a few flashdrives cross these pages, including one meant to self-destruct, and one made from a rejected microSD card.