The $5 PoisonTap quickly, completely hijacks even a locked computer’s internet | Hacker News Reader

The $5 PoisonTap quickly, completely hijacks even a locked computer’s internet

techcrunch.com

37 pointsghosh40 comments

Previously: https://news.ycombinator.com/item?id=12966673

The sad thing for me is that for years on "spy" movies and action movies the hero (or villan) would go into an office or a house or something, plug in a USB device and "boom!" own the machine. I took some comfort that this wasn't really possible, and then this happens.

With badusb and other exploits I've heard security researchers suggest treating usb devices as hypodermic needles and never reuse them and guard your ports like your veins. Almost impossible to actually do, but gives you a sense of just how freaked out the people who know what they're doing are by all this.

It doesn't own the machine though, just MITMs some non-HTTPS websites. It's a weaker attack than what the movie villain could do by replacing your DSL/cable NAT box. (or adding a RPi "bridge" behind it)

Is this prevented by HSTS?

Wow! I'm super impressed by what Samy Kamkar managed to pull off. Let's discuss mitigation on Linux because I don't want to cement the USB ports on my shiny new laptop just yet.

Some suggestions:

* When the GUI is locked, activating new USB devices or even activating a connection via a cable to the ethernet port should be delayed until it is unlocked and (optionally) the user confirms that it's ok.

* New unknown network devices should require confirmation

* A network interface that announces a subnet larger than /24 or /16 (for IPv4) should require a confirmation by the user.

What scripts and hooks are being called whenever there is a change to USB and networking? That would be the place to start. Can there be a /etc/udev/rules.d/ rule that matches all devices?

>* When the GUI is locked, activating new USB devices or even activating a connection via a cable to the ethernet port should be delayed until it is unlocked and (optionally) the user confirms that it's ok.

> * New unknown network devices should require confirmation

These two are the most confusing behavior from current OSes for me - I understand why there is network activity happening while machines are locked for some processes, but I am not entirely sure I understand loading new hardware devices when in a locked state and/or without user interaction of some sort. This suggests an oversight in my mind, and my feeble mind can't think of good reasons why it is this way.

The same issue with new network interfaces - it seems like it's a very intentional action that should be done by the user and not something that should happen automatically, and especially not in a locked state.

Would the same behavior happen on a least privilege account or even a restricted privilege account like something with parental controls enabled? I know that software changes are controlled via this, but hardware changes being allowed seems unusual.

Another solution would be to disable dhcpcd while the laptop is locked.

I think udev is a bit to low level for this. NetworkManager & co. would be the right place IMO. Maybe this could even be considered a security bug with them.

If you put it into a smaller form factor such as USB sticks and drop them in the parking, you'll have a decent chance of getting inside that company. If you could make it very small then it could hide inside a iphone charging cable for example which looks completely harmless from outside.

I think the unique attack vector here is that it's sufficient to just connect the device to the computer for a minute while it's locked. You can then unplug it and the attack persists.

The whole "left behind USB stick" attack is already somewhat known and may catch attention.

The crazy thing is I knew about all of these technologies separately, but never would have guessed that this was possible. I knew my laptop prefers Ethernet. I knew an Ethernet-connected device could serve DHCP. I knew DHCP could provide DNS servers, and that the DNS servers could resolve to whatever they want. I knew if you could pwn DNS you could pretend to be another website, and sideload whatever other sites you want. I knew you could tell a browser via HTTP cache headers to cache something forever.

None of these technologies are remotely new. This has been sitting under everyone's noses for a long, long time. I wonder how long this basic idea has existed in secret.

Bingo

There are better details on this web page for the vulnerability, apparently it affects Mac, Windows, Linux computers with default configs:

https://samy.pl/poisontap/

Is there really a vulnerability in the sense of a security bug here? It's a cool demo of what happens if your computer is connected to an untrusted network, and a good lesson of why you always treat the network as untrusted.

It's doubly surprising that the reporter doesn't recognize that USB is used for wired networking, since Macbook Airs always use USB for that!

Well I think the bug is that even when asleep/locked computers will allow a USB device to connect, and give it a network interface, I can't think of a reason that's a good idea, and even if it was useful, it's too dangerous to allow.

Mainstream OSes and desktop environments (and not just Qubes an people with extra software installed) should really adopt the ask-before-using-USB-devices policy.

If you connected this to a Qubes computer nothing would happen, except a popup behind the lock screen asking for permission. But you could also generally forbid USB network controllers, for example.

It's the same thing with network interfaces, isn't it? If you connect a rogue device to an existing ethernet port I think you could pull off most if not all of the attacks that PoisonTap does.

With an Ethernet tap yes, just on the same switch not necessarily (without causing at least some disruption). For example, a DHCP configured client wouldn't accept a DHCPOFFER he didn't ask for, you'd need to do ARP spoofing which can be detected rather easily AFAIK.

IPv6 is another story though, it seems like IPv6 RA (which can also contain DNS configuration) are accepted by default by all OSes. My observation so far suggested that these overrule DHCPv6 as well.

This is interesting, though, looks a bit like "attacker might replace explorer.exe" type of vulnerability: if you can physically access a device, you're already in; just like you need to be admin or root to replace system binaries, meaning pwnage long before executables are replaced.

The difference is that this attack requires only one minute, no tampering with hardware and thus it will also work against tamper proof devices.

Also it will be not immediately obvious that your device got hacked while you left for a minute because it will not have been rebooted.

This seems like it would be noticed quickly if access to the internet stops working. Can it proxy intercepted traffic to the real internet? Does the raspberry pi need its own internet connection in order to act as a proxy, or can it get a real internet connection via the host device somehow?

PoisonTap responds with a barrage of data-caching malicious iframes for the top million Alexa sites. And those iframes, equipped with back doors, stick around until someone clears them out.

It sounds like this is the default response to any HTTP request, so I'm guessing these top million iframes are stored locally on the device. The TechCrunch photo shows a 32GB card - how many iframes could that store, alongside a tiny Linux-based OS?

And it's not that attacks can only happen while the PoisonTap is connected - it's that connecting the PoisonTap for just 60 seconds or so will likely have it install itself and respond to at least 1 request, seeding the laptop, desktop, or server with 1 million backdoor'd iframes, likely in some background AJAX process that you don't even know is happening in your browser, or when some process like Windows Update or Chrome or Firefox or Safari or Spotify or Skype or Hangouts or Dropbox tries to phone home. Or anywhere.

Then, once the PoisonTap is disconnected, those 1 million iframes are free to route through the same wifi or other connection the device used prior to the attack, to the general internet, for whatever secondary steps the attackers choose to perform.

What may be even more worrisome would be something like this, but with wifi capabilities. It could pose as a free wifi hotspot, possibly even bridging other free / easily hackable / commonly-known wifi hotspots - while replacing ad banners with the same malicious barrage. Or even filtering ads completely, for a "Knight in Shining Armor" solution.

It generates the response to the 1 million Alexa sites on the fly, no need to actually store them on the Pi Zero.

If you add a wifi module, you could potentially configure it to connect to the hotspot, then act as a network bridge for the laptop.

Something like this: http://www.glennklockwood.com/sysadmin-howtos/rpi-wifi-islan...

just use https and you will be safe.

Not sure why all the downvotes, this seems to be mostly true - although this is more advice for site/domain admins rather than users themselves.

There may be some caveats, such as an otherwise secure site using https, except for using regular-http redirects (which the PosionTap device could intercept) without using strict transport security with preloading.

Not if the tap is pretending to be a keyboard and injecting keystrokes into your input stream. Make it a compound device, keyboard, mouse, and network port and you're kind of off to the races.

For certain values of safe.

Poisoning the DNS subsystem of your computer is not safe. At the very least it could record which requests you made indefinitely. This does need to be fixed.

> Poisoning the DNS subsystem of your computer is not safe. At the very least it could record which requests you made indefinitely. This does need to be fixed.

I'm assuming that if a domain used DNSSEC this would protect the user against this type of attack?

If your upstream DNS server and your OS support DNSSEC, it might require small changes to the attack (spoofing IP addresses instead of DNS names).

There really is no substitute for end-to-end crypto in networking.

You could accomplish the same thing by plugging in an Ethernet cable that ran traffic through a malicious reverse proxy. The difference here is that the USB device presents itself as an Ethernet device.

I'm staring at my MAC now and wondering if my Little Snitch will prevent this type of hijacking. I expect the firewall to ask me how to treat a new interface before sending packets there.

No, the rules aren't per interface and there's no authentication of a new network device.

It appears you are mistaken: a properly configured little snitch will protect you. You can configure APS (automatic profile switching) to pause and ask every time your mac connects to an unknown network -- not a device, as I imagined, but a network.

Here is a detailed post: https://blog.obdev.at/automatic-profile-switching/

Seems like an even worse problem for the new Mac Book Pro's, all Thunderbolt/USB-C ports. You could probably spoof any type of input.

Most types of [input] devices (mouse, keyboard, storage) would not be successful against a locked computer, only network devices.

How is this different from just using a WiFi Hotspot? It also "contains the whole internet" but does not need physical access.

How do you reliably force a laptop to connect to your hotspot? You have to guess a network it's willing to automatically connect to and that you can impersonate, hope that WLAN is actually on, ...

It's often a valid strategy, but the PoisonTap covers different scenarios (and vice versa)

The fix is to upgrade to the new Macbook. No more USB ports!

Your attempt at sarcasm fails.

Reply on news.ycombinator.com