>Another critical optimization boiled down to realizing that the response packet allows up to six keycodes to be reported at once. This might have seemed like a straightforward 6x speed gain, but not so: on MacOS, the keystrokes were dequeued not in the order they appeared in the packet, but from the numerically lowest scancode to the highest. This mind-boggling quirk [...]
Reporting multiple keys down in the same packet is meant to be used for when the user actually has those keys down simultaneously, so it's not unusual that MacOS decided to act on them in order of scan code, because the expected effect would be the same.
There are plenty of ways why it might have been added for other purpose. A lot of keyboard APIs provide keyup/keydown events. The most obvious way for implementing that is by having a array or bitmask of all the keys. And once the keystate array is updated from usb packet, the information about order of keys in packet is lost. It also follows the principle of abstracting away low level hardware details. USB isn't only way you could attach a keyboard, there are also PS2 and bluetooth keyboards with different packet structures. Even for USB-HID the standard packet format consisting of bitmask for modifier keys + array of 6 other keys is only the default format guaranteed to work in BIOS. USB HID specification includes standard mechanism for defining the format of packets (report descriptors), which is one of the ways you can achieve more than 6-key rollover .
One plausible (to me) explanation is that the received scancodes are added to a bit vector (a "set"), discarding their original order. Some time later, the bit vector is iterated in numerical order.
Something in the back of my mind is telling me that it's actually spec-compliant to send the 6 scancodes in numerical order. Could very well be misremembering though, and most implementations accept near enough anything from an HID device in my experience
Appendix C: Keyboard Implementation from the Device class definition for HID states "The order of keycodes in array fields has no significance. Order determination is done by the host software comparing the contents of the previous report to the current report. If two or more keys are reported in one report, their order is indeterminate".
It seems pretty scandalous to me that most operating systems still haven't implemented any mitigation for pretend-to-be-a-USB-keyboard attacks.
Fixing it isn't trivial, but it's hardly insurmountable. The solution is fairly simple: Whenever a new keyboard is plugged in or types its first keystroke, lock the screen, and don't accept key input to places other than the login form from a new keyboard until that keyboard has typed the user's login password. (You also need to build a way to authorize legit-fake-keyboard devices like barcode scanners that type the barcodes they scan, but that's not to difficult.)
Given the high prevalence of USB devices with infectable firmwares, and the large number of USB cables of questionable provenance that no one pays much attention to, it doesn't seem okay to leave this vulnerability open.
This isn't very practical as a defense. You can't configure it to ban keyboards, because you still need a keyboard, and you might need to swap keyboards if your original one breaks.
That's not correct, it can block and does block USB keyboards. If your main keyboard was totally dead and you needed to whilelist a replacement keyboard you'd do so by booting into single-user mode.
I think it is a hard problem to solve BUT I think OSs should offer a compromise. That you are notified each time and can grant or deny. This should be an optional setting for those that want to easily add hardening (I think there's no excuse that linux distros don't have a "hardening" setting in their advanced or security settings).
I don't know the answer to this, so I'll ask. Can USB ports be programmed to only output voltage but not data? If so, this seems like a cool way to implement the above as you can have Deny, Access (power), Access (data) as options.
Grant/deny just leads to people clicking accept, you want something where the user has to choose what kind of device the plugged in and if it doesn't match what the device says it is then you reject the device or something.
I was imagining this being in some advanced setting with a "here be dragons" warning. Or even a bit more relaxed like Firefox's strict or custom tracking protection. It comes with warnings and I feel pretty confident to say that most users don't touch these settings.
> On Linux GNOME already has USBGuard support btw.
Yeah I know there are plenty of hardening tools out there, but I was suggesting that they come pre-installed. There's so much bloatware on most systems these days that this seems minor. Or maybe someone could put together a bundling script to make adding all this (e.g. USBGuard + Fail2Ban + Faillock + Firejail + etc) easy to install and configure. I'm not aware of any such tool. But maybe even an Ansible script could go a long way.
> I was imagining this being in some advanced setting ... most users don't touch these settings
That just leaves most users unprotected.
> I was suggesting that they come pre-installed
GNOME's support for USBGuard is installed by default, but USBGuard itself may not be depending on the distro. Agreed that it and other security/safety/robustness (for eg SMART disk warnings need to be supported) stuff (should be enabled by default. GNOME should use Flatpak-style sandboxing for natively installed apps too.
Aren't these users already unprotected? I don't think this is a security concern for most people and turning on by default would frustrate them more. It'd be like shipping Firefox or Chrome with NoScript on my default. Sure, more protection, but it would turn away more people than it would pull in. Better as optional.
Firefox is ratcheting up the tracking protection for normal users and GNOME enabled Thunderbolt protection by default, so there is definitely precedent for protecting regular users too. Also with the rise of stalkerware, normal users are definitely targets too. I think the interface I proposed would be reasonable enough for most people and you could make it easy to turn off with the right UX.
Android already does this but from the other side. I assume iPhone as well. When you plug in a cable it only does power until explicitly allowed to move data as well.
> require the user to type a random combination of keys shown on the screen before enabling a given input device
If you could type it on any device, and you could guarantee that the OS could remember that device, I could see that being workable.
I would also worry about:
Ensuring that the keys shown bit is properly accessible to screen readers/braile devices, etc.
Ensuring that automation could authorise a device, or disable the prompt requirements
Ensuring that the OS actually remembered it. Plugging into different docks at home/work/conference room and having it prompt you to re-authorise your keyboard would drive people up the wall. eg: because during USB Enumeration the port numbers on your dock got switched, or they plugged the dock into the other side of their computer, or the Wireless USB controller is slow at starting up.
How to handle an unauthorised device when there's no other usable input devices. eg I started up my HTPC, and a few seconds later the IR receiver wakes up and is now marked as unauthorised - the device may not have a keyboard but that receiver appears as one. Or maybe I'm trying to fix a laptop and the on-board keyboard is broken, so how do I plug in a USB keyboard to get at the data on it (Maybe I can't reboot)
Some of these things might conflict with having such a lockout.
Pick one of the most popular keyboards used by your target and reuse it. That's how I'd do it. It's not going to get everyone but I think it's a legitimate approach.
The alternative methods looking at the time between keystrokes seems more reliable.
Reading articles like this always causes me to think two things:
1. If this is what a couple of smart guys can do as, essentially, a side project then I can only imagine what nation states with teams of people like this can accomplish.
2. I get why some orgs pour wax into the USB ports of their desktop machines.
That was not a side project from my limited understanding ;) I believe the M$/Alphabet/Meta security teams are probably more advanced or on par with the best state sponsored teams. I could be wrong, plus the state sponsored teams might have infiltrated the FAANG security teams ;)
However, I think the FAANG companies act somewhat more restricted. Three letter agencies don't have qualms about things like "chloroforming security guards" and such.
Also, use USB Data Blocker dongles where possible.
I don't think the NSA pays as well though. You also have large restrictions. Not just stuff like never having smoked weed in your life (we are talking about CS people...) but that once you even have a security clearance (a pain to get in the first place) you have a lot of daily life headaches. You have to carefully watch what you say. International travel has to be reported (and can even be a big hassle). Etc. I'm not sure if the same is true for Google's Red/Blue teams, but I feel pretty confident in saying that they probably get paid more.
Correct, government pay scale is a huge problem for talent acquisition. Your choices are either someone who is so ideologically devoted that they're willing to work for 5-25% of what they're worth or "work for us or you're going to prison for a long time".
Network Cyber Mitigations Engineers and System Vulnerability Analysts analyze vulnerabilities and develop mitigations to strengthen defenses. They produce formal and informal reports, briefings, and guidance to defend against attacks against network infrastructure devices or systems. NSA analysts' competencies run the gamut of data transport possibilities. They work with traditional wired networks, wireless transport, including Wi-Fi and cellular, collaborative platforms such as video teleconferencing, and the hardware and software that support it all.
Correct, government pay scale is a huge problem for talent acquisition. Your choices are either someone who is so ideologically devoted that they're willing to work for 5-25% of what they're worth or "work for us or you're going to prison for a long time"
Or "I'm a covert foreign asset, so I DGAF what I get paid."
> The CTMS [Cybersecurity Talent Management System] salary range has an upper limit of the vice president's salary ($255,800 in 2021), plus an extended range for use in limited circumstances, which has an upper limit of $332,100 in 2021.
All of this is true, but as a government agent, you will be much less likely to go to jail for participating in adversarial activities, which is not nothing.
It's really not hard to realize that organizations whose entire existence is predicated on actually cracking the security of other nation states might garner more investment than a red team focused on checking that your company's security is intact.
> That was not a side project from my limited understanding ;)
First paragraph of the article:
> In episode #3, Daniel Fabian talks about the redteaming efforts - and in particular, about an exercise he and I ran together as a side project back in 2012:
Well, the NSA was diverting shipments of Cisco networking gear to install custom firmware with back doors.
But...this sort of hack is around two decades old and doesn't represent anything new in the field. There are at least a dozen toolkits one can use to implement this on a number of USB-friendly microcontrollers.
I would expect someone working for Google's red team to be able to bang this device out, from scratch, in one day.
Google probably spent more on the voice actor and graphics for the video.
This seems pretty cool. It reminds me of a story I heard recently. Crooks were knocking doorbell cameras off of wifi by an assumed deauth attack. I looked it up and there are “maker watches” that will do deauth “bombs” for you, no soldering required.
A nefarious plasma globe could hide of lot of nasty stuff, you don’t even need to plug it in via USB to cause harm.
The other nifty thing about the plasma globe is that immediately after someone plugs it in, they are likely to be too distracted by the luminous fingers of writhing plasma to notice the shell window popping up briefly on the monitor. Nicely-executed hack on multiple levels.
For the same reason, waiting a few minutes to pop up the shell, as the article says they did, actually seems counterproductive. It might have been better to pop up the window intentionally -- launch the browser to display an ad from the company that made the gadget, maybe, or a 'user's manual', or something like that. Something that would appear innocuous and expected, while providing cover for the payload.
A power user wouldn't (shouldn't) expect a device merely using USB for power to pop up anything on the PC it's plugged into. That would be a dead giveaway that it's doing something it shouldn't be doing.
I’m pretty desensitized to window’s CMD prompts popping up when I install a program or plug in a device. My Razer keyboard even installs borderline malware when you plug it in.
However, if this happened on my Mac I would immediately be skeptical.
> My Razer keyboard even installs borderline malware
What does the software do? I assume it asks for permission and you decline? In a couple of decades of buying USB keyboards I have never let one install software and I have never noticed any problems.
Razer Keyboards and Devices auto-install weird proprietary "drivers" (borderline adware), and the software they auto-install also used to give anyone root/admin privileges (borderline malware) - https://www.engadget.com/razer-mouse-windows-10-security-vul... as an example
Sometimes these crapware "drivers" are actually required for full functionality of the hardware, like assigning keys, macros, profile switching, etc...
Very good point, which is why I never even bothered to check what was advertised. I simply did not want to require anything beyond a driver that would probably go out of date anyway
Plasma globe is also nice because it's so big. It could contain a camera, microphone, storage, LTE radio, GPS (for only turning malicious at the target location) ... a tiny drone that could be ejected at night to fly around the office.
Can you link to one of these watches? If they're being sold with that purpose-build functionality, that's probably a federal crime. You cannot make, possess, or operate a signal jammer in the US.
From what I briefly remember, they aren’t jammers. They’re more akin to a DoS to the access point (I think it has something to do with spamming auth requests?) than jamming any physical signals.
They aren't jammers in the "blast out RF noise" sense, but since they are meant to disrupt legitimate communications, the FCC considers them jammers and has repeatedly fined companies that run deauth attacks to "encourage" people to use their paid networks: https://www.jdsupra.com/legalnews/fcc-issues-another-fine-fo...
As tgsovlerkhgsel said, they're not the classic style of jammer. That kind of thing is called a "smart jammer". And if you built that exact kind of functionality into a device and sold it (vs. just allowing the customer to code it themselves, like they could on any wifi device), you are probably committing a felony by manufacturing and selling a signal jammer.
> The solution proved to be simple: we "borrowed" the USB vendor and product ID sent by an Apple-made keyboard taken from a coworker's desk. Looking at the prototype plasma globe sitting in my "old projects" box, it seems that we picked 05ac:024f.
I'm a bit put out that that worked, although I'm struggling to think of a solution that doesn't involve going full-crypto (including a proper PKI to let vendors sign devices) on all USB devices. But if anyone can set any vendor+product ID, it's not really a useful security measure.
Ah, that was a mistake on my part: I'd initially thought it was. Rereading that screenshot, it's clear that it's not a security measure, just trying to help the user set the keyboard up, in which context it makes sense.
It's got the same functionality as an Accept-Encoding HTTP header. It's meant to provide some information to the far end so that it can drive better behaviour. You can "impersonate" a client that isn't compatible and get junk data and there's no cryptographic protection against that.
Google's actual fix was to install a service that detects if keystrokes are being made too quickly for a human (by default, I believe it's 5 keystrokes per 50 milliseconds), and if so, eject the USB device: https://github.com/google/ukip
Watching the video, they mention that in order for the red team to reach their goal (downloading Google Glass schematics), they had to pivot from the users they compromised with the plasma globe (who were not working on the Glass project) to users on the Glass team. They seemingly did that using an image attached to an email that executed its payload when the email was opened. They didn't elaborate what the payload did, but mentioned that it "captured the user's fingerprint" and enabled them to use that to access the Glass schematics.
Although it sounds much less exciting, this sounds like a much more serious exploit than a compromised USB plasma globe - embedded in an image and requiring minimal user interaction to execute. I wonder whether they identified a novel 0day in a common image parser or something.
I wondered about that too. My guess is that the image was just a trigger loaded off either a remote server or a local server installed by the exploit so they could know when the user was logged in to their Google account rather than a personal account, which would be off-limits for the exercise.
I’m guessing the documentary just glossed over it for brevity.
The author links to UKIP[0], a Linux daemon that they built to try to protect against these kinds of attacks. Did a quick "apt search" on my Debian machine, but nothing came up. Do any major distros package this, and do any install and enable it by default?
I guess it uses heuristics to determine if a device is evil, and that could cause a lot of false positives (which would create spurious bug reports and support cases for distro maintainers), so maybe having something like that installed and running by default isn't a great idea.
It calculates the times between the most recent 5 keystrokes and if they are too fast it carries out a configured action (logs the event or removes the device driver).
Rather than a microphone, measure the plasma globe current consumption. They use more power when they are being played with. At that point the user is probably logged in and distracted.
Bit of a weird opening with the car crash stuff considering that driving is one of the most dangerous actives people do every day, and lots of people still die or are hurt by/from vehicles every day.
I am always amazed when old things we used to do show up again, and again, with minor variation.
We used to be able to make (I think you could buy it too) PS/2 keyboards or dongles/warts/mitm devices that did this. The attacker interface was a bit more cumbersome, but ultimately did the same thing.
It's a really interesting point. I've had to go through quite a bit of trouble to get non-keyboard HID devices (like Yubikeys) "un-Dvoraked" so that they work as expected.
Interesting thought: Keyboard layout should be a setting scoped to the specific hardware gadget, and everyone does that wrong because it's easier to do it wrong.
I'm surprised this works as described (especially with the speed mentioned). If I press CTRL+Alt+T on Ubuntu, I can release it and press T again (by hand!) without it hitting the Terminal window. Reliably, and repeatedly, even with the Terminal app certainly cached, on a modern device with an SSD and low load.
That means an attacker would need to add a wait to risk losing half the payload to the launch animation or whatever causes the delay, and doing it invisibly would be entirely impossible.
Similar to the Mr. Robot episode where Elliot hacks a laptop using a Bluetooth keyboard from a nearby vehicle after an accomplice helps approve a pairing request on the device.
Emulating keyboards pretty old technique. I feel like the rubber ducky stuff and the likes were around earlier. And they are still popular, the flipper zero has a mode of usb payloads but that's more useful if you have physical access.
Yep. Literally a bunch of corporate PR bullshit around a nearly two decade old technique. There's multiple pre-made firmwares for uCs to do this sort of thing.
The fact that they hit the MacOS keyboard wizard shows that apparently nobody on their team had experience with such a basic, ages-old technique.
Reporting multiple keys down in the same packet is meant to be used for when the user actually has those keys down simultaneously, so it's not unusual that MacOS decided to act on them in order of scan code, because the expected effect would be the same.