Live data from Hacker News

The Google plasma globe affair of 2012

lcamtuf.coredump.cx

51–60 of 103 posts

Re: The Google plasma globe affair of 2012

#52
post #2

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.

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.

Re: The Google plasma globe affair of 2012

#53

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…

That doesn't stop a keyboard that is actually backdoored to execute payload sometime much later after setup.

Sure, but it's not intended to. It's to prevent a device from pretending to be a keyboard without any user's knowledge.

Re: The Google plasma globe affair of 2012

#54

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…

That doesn't stop a keyboard that is actually backdoored to execute payload sometime much later after setup.

No, but it does stop you from getting pwned by a plasma ball.

Re: The Google plasma globe affair of 2012

#55

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…

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.

Re: The Google plasma globe affair of 2012

#56

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…

For those wondering, there is an easy defense against this on Linux, USBGuard (https://usbguard.github.io/)

RHEL7+ include USBGuard as part of the standard repo [0]

[0] https://access.redhat.com/documentation/en-us/red_hat_enterp...

Re: The Google plasma globe affair of 2012

#57
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.

Re: The Google plasma globe affair of 2012

#58

Earlier quoted context omitted.

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...

Re: The Google plasma globe affair of 2012

#59
post #21
post #19

Earlier quoted context omitted.

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…

NSA’s TAO surely has many orders of magnitude more budget than Google’s red team?

By many accounts they source exploits from the grey market, too.

Re: The Google plasma globe affair of 2012

#60

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…

How do you distinguish between a new keyboard and a bad USB cable that gets wiggled a bit?
Post reply on HN