There is an old adage in cybersecurity: “If a bad guy has unrestricted physical access to your computer, it’s not your computer anymore.”
Often, people assume this means taking apart the laptop to dump memory or soldering wires to the motherboard. But sometimes, it’s as simple as plugging in a USB drive for ten seconds while the target gets a coffee.
In this project, I wanted to explore the modern state of HID (Human Interface Device) Attacks. I combined low-cost hardware (a Raspberry Pi Pico acting as a “BadUSB”) with a very recent Linux vulnerability, CVE-2025-6019, to create a “Plug-and-Pwn” device that elevates from physical access to a root shell almost instantly.
The Concept: Beyond the Rubber Ducky #
Classic HID attacks (like the famous USB Rubber Ducky) usually work by emulating a keyboard and typing furiously. They open a terminal, type a long wget command to download a payload, and run it.
This works, but it has drawbacks:
- It’s noisy: A terminal window flashing on the screen is obvious to the user.
- It requires internet: The target needs to reach your C2 server to download the stage 2 payload.
I wanted something cleaner, faster, and more self-contained. My goal was a device that acts as both a keyboard and mass storage simultaneously to deliver the exploit locally.
The Vulnerability: CVE-2025-6019 #
The core of this attack isn’t just typing fast; it’s weaponizing a specific flaw in how modern Linux desktop environments handle removable media.
CVE-2025-6019 relates to a local privilege escalation vulnerability involving libblockdev and udisks2. In simple terms, modern desktops try to be helpful. When a user is physically present at the machine, services like PolicyKit often allow them to mount USB drives without asking for a root password (via the allow_active directive).
The critical flaw is that under certain conditions, the system fails to enforce security restrictions like nosuid (No Set User ID) on these user-mounted partitions.
If I can mount a partition containing a binary with the SUID bit set owned by root, and the system doesn’t strip that bit during mounting, executing that binary gives me root privileges.
The Attack Chain #
My implementation uses a microcontroller (like a Pi Pico or an Arduino-compatible board) programmed to present itself as two devices: Let’s call it the “Two-Faced USB”.
1. The Trojan Horse (Mass Storage) #
One part of the USB device acts as a standard storage drive. Before the attack, I prepare a specially crafted, tiny filesystem image on it.
The preparation script (C2-attack.sh in my repo) does the heavy lifting:
# Create a small container file
dd if=/dev/zero of=./payload.img bs=1M count=50
# Format it as XFS (or ext4)
mkfs.xfs ./payload.img
# Mount it temporarily to inject the payload
mkdir -p ./mnt_point
mount -o loop ./payload.img ./mnt_point
# Copy a shell binary (like bash or sh)
cp /bin/bash ./mnt_point/sys_shell
# THE CRITICAL STEP: Set the SUID bit
# 4755 means root owner, readable/executable by all,
# but runs with the permissions of the owner (root)
chown root:root ./mnt_point/sys_shell
chmod 4755 ./mnt_point/sys_shell
# Unmount. The image is now primed.
umount ./mnt_pointThis image now contains a “poisoned” bash shell.
2. The Trigger (HID Keyboard) #
When the USB is plugged in, the OS detects the storage partition. The HID keyboard component then immediately sends a pre-programmed sequence of keystrokes.
Instead of typing a long download command, it simply triggers the mounting of the poisoned partition. Because of CVE-2025-6019, the desktop environment mounts it without nosuid.
The keyboard then navigates to the mount point and executes the poisoned shell:
$ /media/user/USB_NAME/sys_shell -p
Because the SUID bit is active, this shell spawns with effective UID 0 (root). Game over.
Automation and “Quality of Life” #
To make this a viable Red Team tool, I automated the payload generation. I wrote Python scripts that detect the attacker’s local IP and embed it into the necessary files before generating the final image.
This ensures that once root is achieved on the victim machine, it knows exactly where to send the reverse shell back to the attacker, making the attack highly portable.
Conclusion & Mitigation #
This project was a fascinating dive into the intersection of hardware and software security. It highlights that even if your network perimeter is flawless, a ten-dollar USB stick and a localized OS vulnerability can bypass everything.
How to defend against this?
For system administrators, the mitigation involves hardening PolicyKit rules to ensure physical users cannot mount arbitrary filesystems without strict nosuid and noexec options enforced by the kernel.
For everyone else: Don’t plug strange USB drives into your computer. Seriously.
You can find the proof-of-concept code for this project on the repository.