[HN Gopher] The Google plasma globe affair of 2012
___________________________________________________________________
The Google plasma globe affair of 2012
Author : true_squirrel
Score : 190 points
Date : 2022-10-10 15:48 UTC (7 hours ago)
(HTM) web link (lcamtuf.coredump.cx)
(TXT) w3m dump (lcamtuf.coredump.cx)
| nijave wrote:
| 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.
| g_sch wrote:
| 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.
| NegativeLatency wrote:
| 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.
|
| https://www.cdc.gov/vitalsigns/motor-vehicle-safety/index.ht...
| carry_bit wrote:
| I wonder if it flopped for anyone because they had a different
| keyboard layout (like Dvorak) set.
| partdavid wrote:
| 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.
| alexpotato wrote:
| 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.
| golem14 wrote:
| 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.
| theptip wrote:
| NSA's TAO surely has many orders of magnitude more budget
| than Google's red team?
| cbsmith wrote:
| 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.
| tapland wrote:
| Probably. It's way handier if the keylogger is embedded
| into the cable from your usb-x monitor right when you open
| the fresh package.
|
| But budget limited ingenuity is fun too!
| godelski wrote:
| 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.
| Arainach wrote:
| 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".
|
| Citations:
|
| https://apply.intelligencecareers.gov/job-
| description/119486...
|
| Cyber Mitigations Analyst/System Vulnerability Analyst -
| Entry to Expert Level (Maryland)
|
| 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.
|
| Pay Plan: GG, Grade: 07/1 to 15/10
|
| https://www.opm.gov/policy-data-oversight/pay-
| leave/salaries...
|
| In a very high cost of living area, that means that entry
| level is $31K and the absolute top for expert level is
| $176,300.
|
| Compare that to what FAMG are paying new college grads.
| [deleted]
| jonas21 wrote:
| It's certainly something someone _could_ do as a side
| project, even if that wasn 't strictly the case here.
| telotortium wrote:
| 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
| yjftsjthsd-h wrote:
| > 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.
| jaywalk wrote:
| You have to realize that it was never meant to be a security
| measure. It's only there to identify the device to the host
| system.
| anamexis wrote:
| Indeed, and the Keyboard Setup Assistant was never meant to
| be a security measure, either.
| yjftsjthsd-h wrote:
| 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.
| renewiltord wrote:
| 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.
| Arnavion wrote:
| >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.
| ryan-c wrote:
| That seems like behavior that had to be actively added though,
| and I am extremely curious why.
| Karliss wrote:
| 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 .
| valleyer wrote:
| 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.
| dpatterbee wrote:
| 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
| Karliss wrote:
| 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".
| wil421 wrote:
| 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.
| CamperBob2 wrote:
| 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.
| jaywalk wrote:
| 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.
| CamperBob2 wrote:
| I think that train left the station when they plugged a
| 50,000-volt EMI generator into a USB jack. :)
| wil421 wrote:
| 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.
| [deleted]
| LtWorf wrote:
| They make me pretty nervous on windows too... but it's
| windows so I don't know enough to presume for sure I'm
| infected or it's just windows.
| tomcam wrote:
| > 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.
| maxsilver wrote:
| 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
| tellmemore145 wrote:
| 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.
| EthicalSimilar wrote:
| 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.
| tomcam wrote:
| Equally as interesting from the technical and social engineering
| sides.
| w-ll wrote:
| 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.
| kelnos wrote:
| 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.
|
| [0] https://github.com/google/ukip
| maxerickson wrote:
| 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).
| hdjjhhvvhga wrote:
| Google was lucky to have Zalewski.
| [deleted]
| jimrandomh wrote:
| 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.
| godelski wrote:
| 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.
| pitaj wrote:
| That's actually a really good idea, but I think it could cause
| problems for things like external numpads.
|
| Maybe require the user to type a random combination of keys
| shown on the screen before enabling a given input device,
| instead of their own password?
| paranoidrobot wrote:
| > 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.
| dzhiurgis wrote:
| That doesn't stop a keyboard that is actually backdoored to
| execute payload sometime much later after setup.
| skybrian wrote:
| Sure, but it's not intended to. It's to prevent a device from
| pretending to be a keyboard without any user's knowledge.
| anamexis wrote:
| No, but it does stop you from getting pwned by a plasma ball.
| Scalene2 wrote:
| This could be improved by adding a microphone to help determine a
| good time to execute.
| Cerium wrote:
| 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.
| Scalene2 wrote:
| Ohh that's good!
| Waterluvian wrote:
| I wonder if it might be reasonable to break up the attack over
| time.
|
| Slowly populate a script with contents so that instead of writing
| a lot of characters that a user might see, just populate a few.
___________________________________________________________________
(page generated 2022-10-10 23:00 UTC)