You might think you understand the concept of BadUSB attacks and know how to defend it, because all you’ve seen is opening a terminal window. Turns out there’s still more attack surface to cover, as [piraija] tells us in their USB-HID-and-run publication. If your system doesn’t do scrupulous HID device filtering, you might just be vulnerable to a kind of BadUSB attack you haven’t seen yet, rumoured to have been the pathway a few ATMs got hacked – simply closing the usual BadUSB routes won’t do.
The culprit is the Consumer Control specification – an obscure part of HID standard that defines media buttons, specifically, the “launch browser” and “open calculator” kinds of buttons you see on some keyboards, that operating systems, surprisingly, tend to support. If the underlying OS you’re using for kiosk purposes isn’t configured to ignore these buttons, they provide any attacker with unexpected pathways to bypass your kiosk environment, and it works astonishingly well.
[piraija] tells us that this attack provides us with plenty of opportunities, having tested it on a number of devices in the wild. For your own tests, the writeup has Arduino example code you can upload onto any USB-enabled microcontroller, and for better equipped hackers out there, we’re even getting a Flipper Zero application you can employ instead. While we’ve seen some doubts that USB devices can be a proper attack vector, modern operating systems are more complex and bloated than even meets the eye, often for hardly any reason – for example, if you’re on Windows 10 or 11, press Ctrl+Shift+Alt+Win+L and behold. And, of course, you can make a hostile USB implant small enough that you can build them into a charger or a USB-C dock.
USB image: Inductiveload, Public domain.
It’s almost as if hardened systems should be designed to specifically allow necessary functions instead of being a swamp of unused functionality. Although that would take skill and cost a (US*) nickle.
*may cost more or less in your locale.
“specifically allow necessary functions instead of being a swamp of unused functionality.”
Mix-n-Match engineering reduces end product costs by reusing already existing chips, modules, etc. Building around low-cost uC’s which are volume produced leaves many internal capabilities un-used.
The same is true of RaspberryPi modules and higher level genetic microprocessor boards.
Few small companies can design at a function only level although FPGA may be considered if expertise exists inhouse.
WiFi and Bluetooth being in the same package even if one or the other isn’t needed.
“If your system doesn’t do scrupulous HID device filtering”…
I still haven’t seen a cheap USB firewall device that could be configured to exclude unwanted features of a USB device. They exist, but afaict only as overpriced forensic tools. Should be straightforward, one would think; a microcontroller with USB protocol analysis and forwarding between two ports…
It’s really not that difficult, even at an OS level, without additional hardware. https://usbguard.github.io/ exists for Linux, and other tools for Windows. Just verify that the VID:PID and USB Device and Report Descriptors match what was approved, before binding drivers to the device.
But then you need to actually consider what is possible with the approved descriptors, which takes a fair amount of knowledge of the various parts of the USB spec. I suspect that this is where the real obstacle lies.
What if it’s not a USB-IF approved device?
that certainly explains why my cat is able to open strange websites that ive never been to before.
Thats what I thought as well
I tell my wife this too….
I’m quite sure there are more ways to bypass the windows keyboard filtering. We already discovered that the filtering only activates after it actually detects a physical keyboard. Why does this matter? Well, there is the on-screen keyboard as well, and these keys get filtered if the filtering is active. But as the filtering is active after it detects a physical keyboard there is the issue that if you manage to open the on-screen keyboard without any physical keyboard attached, you can just bypass the filtering.
How is this different from plugging in a “multimedia” keyboard? If you have an ATM with an exposed USB port, you are already doing something horribly wrong.
As for other kiosk devices with a legitimate use for USB, well, you need to understand what you’re doing. Someone can plug a rogue network card or whatever in there. I certainly wouldn’t use a general purpose consumer OS for such tasks.
Are you talking about actual Kiosk mode in Windows which only allows one app from the Microsofr store to run? Is it vulnerable to this?
Sadly, I do not know as I only have the author’s post to go from and iirc it doesn’t mention specific apps, but I advise you to reread the post and do your own tests with the Arduino/Flipper apps and maybe get in touch with the author!
The “Generic GUI Application Controls” CCBs might well work against the formal Kiosk mode; if the Kiosk application has meaningful responses to them; but, unless something is badly broken, the “Application Launch” ones should just hit a brick wall, since that Kiosk mode is built around explicitly blocking the launch of other applications.
There might be some intermediate cases; where, say, people didn’t properly protect the admin password that allows you to break out of Kiosk mode because they thought that you couldn’t issue a command that would trigger the authentication window; but actually you can. But that wouldn’t really be the fault of Kiosk mode; since it would still be enforcing the security restrictions that it says it does.
“we’re even getting a Flipper Zero application”. Great, now we can look forward to some clueless politician claiming this meanace can be used to hack ATMs as well as steal cars.
They’ve already won if you’d rather cripple a device than give a politician an excuse to show themselves up as a fool?
The “CCBs” seem dangerous in the sense that they are a non-obvious way to get bitten even after you’ve disabled the obvious shortcuts; but seem, if you remember them, like a significant improvement over USB devices just hacking in roughly equivalent functions by sending sequences of keycodes, which is presumably what they’d otherwise do.
Absolutely going to be about a zillion ‘kiosk’ devices that haven’t thought them through and will be vulnerable; but they don’t seem like an inherently insane “this feature cannot be implemented securely what are you thinking?” type thing.
There’s also the compatibility angle: having a “please launch calculator” request can be handled a lot more gracefully across OSes or different user-selected programs than some keyboard vendor having a ‘calculator’ key that just spits “winkey+r calc.exe enter” and calls it good.
Like how we have to have specific buttons on a microwave for “Side Dish” and another for “Dinner” and another for “Lunch/Snack” then somebody is CERTAIN that their college kid needs the OTHER microwave because only IT has a “Breakfast” button, which is the most important meal of the day after all, and before you know it there’s an HID code for “Open chlorine valves” and “Set grid frequency to 60.5 Hz”. But really, this is about consumer choice. It’s about freedom.
You’ve just invented Unicode/emoji