
PoisonTap – Exploits locked computers over USB - el_duderino
https://github.com/samyk/poisontap
======
niftich
Another fine exploit by Samy [1]. At the risk of sounding like a killjoy, once
the attacker has physical access to a machine, let alone plugs in their own
device, you can usually abandon all security hope [2]. But that entirely
notwithstanding, the techniques presented in this exploit are actually quite
clever, and they conspire to make for a nasty set of scenarios. Kudos to him
for raising awareness once again!

[1]
[https://en.wikipedia.org/wiki/Samy_Kamkar](https://en.wikipedia.org/wiki/Samy_Kamkar)
[2]
[https://hn.algolia.com/?query=tptacek%20"physical%20access"&...](https://hn.algolia.com/?query=tptacek%20"physical%20access"&type=comment)

~~~
nine_k
A powered-down machine with full disk encryption is reasonably safe against
physical access, I still hope?

~~~
pulse7
Unless USB keylogger is present which will log the disk encryption password
when user is unaware of it...

~~~
goda90
I've already seen lockable boxes around computer ports on some older model
workstations. Combine that with some tamper proofing on the keyboard, and
you've probably bought yourself a little more security against any intruder
who has limited time with physical access.

------
micaksica
You have a few mitigations that aren't listed here, but it's really moot
because physical access is still game over.

First, the GRSecurity patchset contains a kernel-level USB whitelist, so you
can whitelist only known USB devices. A targeted attacker could attempt to
spoof an existing/whitelisted USB device, but it does significantly harden the
USB attack surface:

1\.
[https://wiki.gentoo.org/wiki/Allow_only_known_usb_devices](https://wiki.gentoo.org/wiki/Allow_only_known_usb_devices)

Clearly this only helps Linux people. For those using Linux/BSD/macOS, There's
also _usbkill_ , a Python-based antiforensic tool that just kills the computer
if a device is inserted/removed that isn't on its whitelist:
[https://github.com/hephaest0s/usbkill](https://github.com/hephaest0s/usbkill)

While this won't stop Samy's box from starting to do its thing, it will at
least shut the computer off and mitigate some of the potential damage.
_usbkill_ is in the Homebrew repositories for macOS as well. If you have fully
encrypted disks and strong passphrases, this is still going to ruin somebody's
day trying to use this device.

~~~
stebalien
> First, the GRSecurity patchset contains a kernel-level USB whitelist, so you
> can whitelist only known USB devices. A targeted attacker could attempt to
> spoof an existing/whitelisted USB device, but it does significantly harden
> the USB attack surface:

Actually, the GRSecurity patchset includes a toggle to disable _all_ new usb
devices after boot. The whitelist mechanism you're referring to relies only on
udev (no kernel patching needed). You can even whitelist by driver to, e.g.,
allow all usb storage devices by default.

------
captainmuon
The takeaway for me is that you can program a Raspberry Pi Zero to be a USB
device (not just host). I wonder if it can do both at the same time...

I sometimes think about building a "USB Condom". There already exist devices
that only pass through the power lines, if you want to charge a phone from a
dubious plug. However, I would go a step further and try to support data. For
example, I would emulate a USB pen drive (with a FAT32 file system), and then
mirror the contents of an attached drive. If the attached drive is malicious,
it cannot easily attack the host.

~~~
blauditore
Hm, this sounds like a software-based solution right? But if you have software
only letting certain data pass, couldn't the same software just be run by the
main device instead of an intermediate one?

~~~
wongarsu
Two reasons speak for a separate hardware for that purpose:

1: conventional computers have no mechanism to indicate what you expect from a
USB device, and you can't ask for confirmation that the user wanted to plug in
a keyboard, because the user might need that keyboard to confirm hits
intention

2: the USB software stack can be attacked at many layers, including firmware,
generic OS code and the OS-chosen driver. That software stack varies depending
on OS, motherboard, BIOS version, installed drivers etc. A hardware device can
provide protection invariant from those factors

------
zeta0134
I wonder if a viable method for securing USB devices would be a pairing step,
similar to how bluetooth keyboards work. Most input devices are USB-based,
which means we can't require confirmation for _every_ device, but we could
require OS confirmation for most of them, and do a pairing step for input
devices. Like click these visual targets / type in this key sequence.

This wouldn't fully solve this problem, but it _might_ just help protect me
from people plugging devices into my machine while it's locked, and could even
alert me that the device I thought was just charging has reported itself as a
keyboard, despite looking nothing like one.

------
caf
It seems like another mitigation missing from their list is "modify your DHCP
client to reject over-broad subnet masks" where the cutoff is probably
something like /20.

Additionally you could reject any DHCP lease for a subnet that purports to
overlap with the address range of any other directly connected network.

~~~
jtokoph
Couldn't the USB device identify itself as multiple devices over the same
port? Similar to a hub. It could then give a /20 to each device.

~~~
caf
It could, there's a limit of 127 USB devices though so it couldn't cover a
large percentage of the address space that way. It might be enough to still
cover some major sites of interest.

------
brazzledazzle
I don't have a Pi to test with but I imagine keeping the associated kernel
module(s) (assuming I have the right ones) unloaded would mitigate this
entirely:

kextunload /System/Library/Extensions/AppleUSBEthernet.kext

and maybe this one. I don't know if this would impact using your phone as a
usb hotspot but it might so keep that in mind:

kextunload /System/Library/Extensions/AppleUSBNetworking.kext

and this one but I'm pretty sure it is in fact required for usb tethering so
keep that in mind if you use that:

kextunload /System/Library/Extensions/AppleUSBEthernetHost.kext

I don't remember if they reload on reboot or not but if needed you can reload
them with kextload.

Edit: This is for OS X/macOS by the way. And I wish I had a Pi to test with
because this is very cool. We owe people that release stuff like this a big
thanks because they took it from an idea to implementation and then the big
step of creating a usable, shareable project which goes a long way toward
increasing awareness.

------
canada_dry
It's long past time that USB security is taken seriously.

By default anything stuck into a USB port should be sandboxed and various
integrity checks need to be performed before access is allowed.

~~~
JshWright
> It's long past time that USB security is taken seriously.

You mean, before we started using USB for charging...?

It wouldn't be hard at all to make a convincing looking power adapter with
something like PoisonTap baked in.

~~~
niftich
You can protect both devices from each other with a USB condom [1] which only
connects the power pins. This should be the solution for trying to charge from
untrusted slots, or for when an untrusted device wants to charge from you.

[1] [http://syncstop.com/#faq-original](http://syncstop.com/#faq-original)

~~~
greggman
Know of any USB condoms that can filter for device types? Given BAD USB type
of exploits there really no easy way for me to know that when I stuck my USB
stick in the printer at the library it wasn't reprogrammed to be a keyboard or
something else and when I then go plug it into my computer it now powns my
computer

------
jlgaddis
I remember the "good ol' days" when you could reasonably build a monolithic
Linux kernel with support for loadable modules disabled. Just compile in
whatever you needed for your hardware and leave out the other 90% that you
didn't need.

It was a decent (but not very popular) defense against rootkits and attackers
being able to dynamically load kernel modules and would also prevent something
like this (unless you had the necessary drivers compiled in).

~~~
pmlnr
This could be done: we need a common git repo with a config for each kernel
version per laptop; eg. config-4.4.30 for ThinkPad X200, which only includes
the required drivers for the laptop itself.

~~~
collyw
That sounds great but I remember installing Linux on a Mac and even then it
wasn't consistent exactly which drivers should have been used as there were
variations depending on the date of purchase. Macs are probably a lot more
consistent than the majority of laptops.

------
qwertyuiop924
That is impressive. And scary.

But if your box's physical security has been compromised, you're already
screwed in any case.

~~~
fny
> But if your box's physical security has been compromised, you're already
> screwed in any case.

There's a gradient to the screwage, however.

For example, I've encrypted my disk, so someone would need to steal my
computer and then try bruteforcing it with some new-fangled graphics card.

With this insanity, I risk someone stealing my unencrypted traffic with a
plug-and-play device any time I get up from my desk to pee. Then again, they
can already do that with Wireshark.

~~~
dgoldstein0
not just unencrypted - traffic for any website that doesn't use HSTS. All they
need to do is intercept a single HTTP page and then they can modify it to
contain iframes to their favorite sites over http, and any site without HSTS
can then be owned.

~~~
dgoldstein0
Hopefully though everyone sets the secure flag on important cookies... I
wouldn't bet on it, but I suspect it may be more common than HSTS.

------
jlgaddis
I wonder if this could be combined with some of the (relatively) recent issues
w/ LastPass and/or 1Password, where the application and password credentials
were accessible via 127.0.0.1 (which is apparently required for the browser
extensions to work)?

If so -- assuming the user is logged in to {1Password|LastPass} -- just plug
this in to their PC after they walked away from their desk and wait for all of
their saved credentials to be stolen!

------
msimpson
This attack can be mitigated in Windows using group policy:
[https://technet.microsoft.com/en-
us/library/cc731387(WS.10)....](https://technet.microsoft.com/en-
us/library/cc731387\(WS.10\).aspx)

------
stillAbnormal
A hardware-oriented attack vector that completely unravels the carefully
conceived schemes of the application layer's software-oriented security that
sits on top of it.

And USB at the heart of it. My old friend, USB.

Why am I not surprised?

------
thinkling
Previously:

"PoisonTap, a $5 tool that invades password-protected computers"

[https://news.ycombinator.com/item?id=12966673](https://news.ycombinator.com/item?id=12966673)

------
sidarape
Almost everything said on that page is already feasible with basic network
spoofing. Sure, the hardware hack is cool and allows a bit more but nothing
extraordinary.

------
thinkling
So is clearing your browser cache sufficient to be sure that any possible
PoisonTap infection has been removed?

~~~
dgoldstein0
sounds like it, but given usb plug-n-play I'm sure you could make a more
persistent version.

And also clearing your cache won't invalidate all your web sessions that they
could have stolen. You'll want to find every site you were logged into, and
explicitly log out. Otherwise those stolen cookies will still be valid, unless
the website does some sort of channel-id thing to bind cookies to the
particular computer (which I'm not sure is possible beyond experimental
browser features, and certainly is not common practice)

------
midgetjones
It's not often you see exploits that reference RuPaul's Drag Race. I, for one,
am all for it.

------
wilg
Does using SRI ([https://developer.mozilla.org/en-
US/docs/Web/Security/Subres...](https://developer.mozilla.org/en-
US/docs/Web/Security/Subresource_Integrity)) defeat a portion of this attack?

~~~
minitech
A small portion. (It’s listed in the mitigations.) Use HTTPS anyway, though.

------
dgoldstein0
so thinking about the attack: would it be feasible for OSes to only allow USB
input devices to be attached while the computer is locked? It seems like it
should be unnecessary to install usb network devices while the computer is
locked.

------
alexpoulsen
FileVault plus running 'pmset destroyfvkeyonstandby' in Terminal should
prevent this. Destroying the FileVault key should encrypt the disk, likely
stopping things from running while asleep. I haven't tested this though.

------
X-Istence
On OS X when I plug in a new USB based Ethernet device, the first thing it
does is pop up a dialog asking me if I want to enable/configure the device...
is the device already configured at that time?

~~~
greggman
Does it ask for a password to enable it? If not the device and also emulate a
keyboard to press enter to confirm the dialog.

Any idea where is the list of approved devices is. I'd like to clear my list
and then plugin some devices and see if it asks.

~~~
X-Istence
I run as a non-administrator account, so this may be different if the user has
administrator privileges.

But here is what happens:

1\. I plug in the new device

2\. Dialog box pops up letting me know a new network interface was detected
(and to open network preferences to configure the device). The device does
show up as en6, it is disabled and there is no network activity.

3\. I can click Cancel or open Network Preferences

4\. Click to open Network Preferences

5\. I have to click the lock, and authenticate as an administrative user

6\. I have to click the +

7\. I have to select the new network interface by name from the drop-down

8\. I have to click OK

9\. I have to click Apply

At that point the network interface is brought "up", and it does a DHCP
request, and I can use it.

So there are 8 steps to take AFTER plugging in the device before it can start
siphoning off any and all of my data. It's not as plug and go as it is made
out to be.

\----

After adding a device, you can remove it from the list of devices in Network
Preferences, and that resets that dialog box letting you know there is a new
device.

------
jlebrech
shouldn't the OS pause the running of programs when you've locked your
computer, and when you log in say something like "hey you've plugged a new
device in while you were locked out, are you sure you want to resume all you
programs"

