Security Hacks

1528 Articles

A screenshot of the software in action is shown. A sidebar on the left shows an icon of a skull-shaped drone above the text “DAMN VULNERABLE DRONE.” Below this, it lists controls for the simulator, and resources for using the software. In the rest of the screen, a rendered scene is shown. A rendered computer monitor showing “DRONE HACKER” is at the bottom of the scene. Above this is a hovering drone, and behind it is a table labeled “Ground Control Station” with a man sitting at it.

A Vulnerable Simulator For Drone Penetration Testing

July 18, 2025 by 7 Comments

The old saying that the best way to learn is by doing holds as true for penetration testing as for anything else, which is why intentionally vulnerable systems like the Damn Vulnerable Web Application are so useful. Until now, however, there hasn’t been a practice system for penetration testing with drones.

The Damn Vulnerable Drone (DVD, a slightly confusing acronym) simulates a drone which flies in a virtual environment under the command of of an Ardupilot flight controller. A companion computer on the drone gives directions to the flight controller and communicates with a simulated ground station over its own WiFi network using the Mavlink protocol. The companion computer, in addition to running WiFi, also streams video to the ground station, sends telemetry information, and manages autonomous navigation, all of which means that the penetration tester has a broad yet realistic attack surface.

The Damn Vulnerable Drone uses Docker for virtualization. The drone’s virtual environment relies on the Gazebo robotics simulation software, which provides a full 3D environment complete with a physics engine, but does make the system requirements fairly hefty. The system can simulate a full flight routine, from motor startup through a full flight, all the way to post-flight data analysis. The video below shows one such flight, without any interference by an attacker. The DVD currently provides 39 different hacking exercises categorized by type, from reconnaissance to firmware attacks. Each exercise has a detailed guide and walk-through available (hidden by default, so as not to spoil the challenge).

This seems to be the first educational tool for drone hacking we’ve seen, but we have seen several vulnerabilities found in drones. Of course, it goes both ways, and we’ve also seen drones used as flying security attack platforms.

Continue reading “A Vulnerable Simulator For Drone Penetration Testing” →

This SSD Will Self Destruct In Ten Seconds…

July 16, 2025 by 16 Comments

In case you can’t wait for your flash memory to die from write cycling, TeamGroup now has a drive that, via software or hardware, can destroy its own flash chips with a surge of voltage. If you wonder why you might want this, there are military applications where how you destroy a piece of equipment is right up there in the manual with how to use it.

They have obviously put a lot of thought into it, as you can see in the video below. Apparently, if you are in the middle of blowing up the flash and power cuts out, the chip will resume frying itself when you restore power.

Continue reading “This SSD Will Self Destruct In Ten Seconds…” →

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

Video Cable Becomes Transmitter With TEMPEST-LoRa

July 4, 2025 by 10 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 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 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.