61

I just heard of PoisonTap today. Here is a short description from a TechCrunch article:

PoisonTap connects to the USB port and announces itself not as a USB device, but an Ethernet interface. The computer, glad to switch over from battery-sucking Wi-Fi, sends a DHCP request, asking to be assigned an IP. PoisonTap responds, but in doing so makes it appear that a huge range of IPs are not in fact out there on servers but locally connected on the LAN, through this faux wired connection.

And

you don’t even have to be there: pre-loaded items like analytics and ads will be active, and as soon as one of them sends an HTTP request — BAM, 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.

This sounds quite worrisome, yet I did not hear too much about it yet. So my main question is:

How vulnerable are people to the PoisonTap hack?

It seems like the following points would be relevant:

  1. Is the general population at risk, or only a very specific subset (OS, browser?)
  2. What exactly is at risk, your data, your gmail account ...?
  3. Is it something that most people can pull off, or does it depend on specific hardware and a high level of skill?
  4. Is there something that one can do easily, without closing all browsers or turning off the PC each time when you walk to a different room to ask a short question. (Is locking it sufficient?)

And of course, if it is as bad as it seems: can we expect updates soon that would make it safer to go to the toilet again?

Community
  • 1
Dennis Jaheruddin
  • 1,715
  • 11
  • 17
  • Note that the publisher makes claims about most of these points, but that I would be very happy with someone who could comment from a more objective perspective. – Dennis Jaheruddin Nov 17 '16 at 13:16
  • I agree, it would be nice to hear an objective perspective. For the sake of having everything in one place [here is the link to Samy's post on the subject](https://samy.pl/poisontap/) – INV3NT3D Nov 17 '16 at 14:22
  • 6
    Isn't this the same as impersonating a public access point (i.e. Starbucks, airport, etc) to get people to connect to you so you can do a man in the middle attack? So the standard [MitM mitigations](http://destroyadware.com/articles/security/3-effective-ways-defend-man-middle-attack-mitm/) would apply? (i.e. make sure all of your traffic is encrypted before it leaves your machine) – Johnny Nov 17 '16 at 17:04
  • 1
    @Johnny except impersonating a public access point doesn't require the bad actor to physically approach your machine and plug something into it that remains plugged in while you surf. – Doktor J Nov 17 '16 at 17:55
  • @Johnny I am not sure about what one can do when impersonating a public access point. What I understand is that this hack goes for many cookies that are not even being used. Is that the same in a standard MITM attack? – Dennis Jaheruddin Nov 17 '16 at 19:48
  • 2
    I do not understand why anyone would use PoisonTap instead of just a USB stick that installs malicious drivers via Plug-n-Play. If PnP is disabled, then neither would PoisonTap work. Yet a malicious driver is free to do **anything**, much better than PoisonTap. The solution is to disable PnP. – user21820 Nov 18 '16 at 04:55
  • A lot of hype for nothing. This is no different than plugging in a malicious device via Ethernet or impersonating a Wi-Fi AP. – André Borie Nov 18 '16 at 10:53
  • 2
    @user21820: I don't think you understand how PnP installs drivers. It doesn't download a driver from the device being plugged in, it uses identifying information (for USB, this involves USB enumeration and the string descriptors) to search its own driver database. Getting drivers added to that database may require administrator action (such as editing `/etc/modules.conf` on Linux) and/or passing signature verification (such as Windows Update). Loading arbitrary code is not a feature of PnP. – Ben Voigt Nov 18 '16 at 16:20
  • @BenVoigt: It doesn't require administrator rights on Windows, at least with the default local policy settings. Secondly, all the USB stick needs to do is to pretend to be a removable disk drive, invoke auto-play and it can install its own drivers. The safest way is still to disable PnP and auto-play via local policy and install whatever devices you want using admin rights. No? – user21820 Nov 18 '16 at 18:27
  • @user21820: What "it" doesn't require admin rights? Loading a driver already installed on the machine? True, but not an entrypoint for malicious code. Loading a driver distributed with the Windows install and signed by Microsoft? True, but not an entrypoint for malicious code. Downloading a new driver from Windows Update cross-signed by Microsoft? Depends on system configuration, the default is to prompt before searching online. Copying an unsigned driver off removeable media and loading it? Definitely DOES require admin rights. – Ben Voigt Nov 18 '16 at 21:10
  • @user21820: Also, AutoPlay hasn't executed code off the removable disk for 6 Windows versions now (XP, Vista, 7, 8, 8.1, 10). A preinstalled driver consisting of Microsoft code loads to support the removable disk, not your malicious payload. Attackers normally instead use the HID profile for automated attacks, but those won't work against a locked machine. Every comment you leave just proves what I already said: You don't understand the driver install process. – Ben Voigt Nov 18 '16 at 21:13
  • @BenVoigt: Okay what I said used to be true a few years ago, even of Windows 7 (which was claimed to be patched in 2011). And you trust Microsoft to be 100% clean every time you connect to it? (I wonder whether you like Cortana and Edge ads...) – user21820 Nov 19 '16 at 09:31

4 Answers4

62

First the attacker needs to have physical access to the machine in order to plug the device into the USB port. This means any kind of full remote exploit is not possible. It does work though if the computer screen is locked with a password or similar. Note that the physical access does not need to be direct, i.e. it can also be some gullible user plugging a donated USB stick into the system.

Then the device announces itself as a USB ethernet device. This means that the computer will try to add PoisonTap as a network device to the system and get an IP address from it using DHCP. The DHCP response will return an IP address with a /1 subnet so that most IPv4 traffic is sent to the device. From then on the attacker has the same access to the device like a router: in fact the device works as a router for the attacked computer. This means that any traffic can be easily sniffed and modified but that encrypted connections are still protected against decryption and modifications get detected. This means for example that access of gmail over https (the usual way) will not be compromised.

At the end it is just another way for a local attacker. The impact of the attack is comparable to redirecting someone's traffic via ARP or DHCP spoofing, hijacking the local router or a rogue access point. Not more can be done as with these attacks but also nothing less. It looks like that the software comes with some nice attacks which modify unencrypted HTTP connections to access different sites in order to poison the browsers cache with heavily used scripts (like a poisoned google analytics etc). Since many sites include such third party code and such code gets access to the full page a poisoned code can extract lots of useful information. But again, this works only for HTTP not HTTPS.

Is the general population at risk, or only a very specific subset (os,browser?)

Most current systems are at risk but the attacker needs physical access.

What exactly is at risk, your data, your gmail account ...?

Sniffing and modification of unencrypted connections. Gmail usually is encrypted and thus not affected.

Is it something that most people can pull off, or does it depend on specific hardware and a high level of skill?

It needs special hardware and software but the hardware is cheap and the software released. It needs about the same level of experience as attacks like ARP or DHCP spoofing, i.e. script kiddies could do it.

Is there something that one can do easily, without closing all browsers or turning off the pc each time when you walk to a different room to ask a short question. (Is locking it sufficient?)

The usual protections against other USB based attacks still work, i.e. disable USB or restrict the kind of devices. But note that if the device has an ethernet port you could mount a similar attack through this since any kind of wired connections is preferred to wireless by most systems.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • Comments are not for extended discussion; this conversation has been [moved to chat](http://chat.stackexchange.com/rooms/48819/discussion-on-answer-by-steffen-ullrich-how-worried-should-i-be-about-getting-ha). – Rory Alsop Nov 20 '16 at 10:17
  • "First the attacker needs to have physical access to the machine in order to plug the device into the USB port." Not really. The attacker could be a (member of a) company that mass produces USB sticks; they "just" have to sneak their code into the firmware of the stick. You as user put the stick into your PC. I believe that's the most devious part of this attack. As a comparison, TomTom, for its current range of auto navigation hardware, does exactly this. For whatever perverse reason, their devices communicatie with the PC software by registering a new interface/IP and then TCP/IP over that. – AnoE Nov 20 '16 at 10:19
  • @AnoE: If you consider attacks by the manufacture or distributor of the USB stick you should also include malicious firmware of builtin NIC, malicious OS, malicious BIOS/UEFI, malicious routers and switches, malicious ISP, malicious system administrators etc. While all of these are possible attack vectors I think all these are out of the context of this question. – Steffen Ullrich Nov 20 '16 at 10:22
  • There's still a big difference between an ubiquitous USB stick, which can be picked up for 1€ at every super market checkout, and builtin devices that 99% of consumers have no idea actually exist, much less are able to replace. On the other hand, it is quite usual that e.g. business people exchange USB sticks and so on. My point is not that the attacker must necessarily be the vendor, but that physical access of the attacker is not necessary. – AnoE Nov 20 '16 at 10:28
  • @AnoE: You are right that the attacker does not need to have direct physical access but indirect physical access is sufficient, i.e. with the unintentional help of some other person. But as far as I know one usually only cares if an attack needs physical access or not (vs. remote attack), no matter if this is direct or indirect. – Steffen Ullrich Nov 20 '16 at 10:35
  • My point is that this is exactly what is potentially different for PoisonTap. A malicious, say, lecturer at a large prestigious conference could potentially bring dozens of prepared USB sticks containing his lecture notes. If it is not a security conference ;), he will at least have *some* success. – AnoE Nov 20 '16 at 10:45
  • @AnoE: I don't think that there is much of a difference if this is an USB stick with infected documents, BadUSB or PoisonTap on it. In all cases someone trusts an USB stick received from a potential untrusted source which might harm the system in a non-obvious way. And in all these cases the attacker uses indirect physical access with the unintentional help of a gullible user. – Steffen Ullrich Nov 20 '16 at 10:56
  • Let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/48820/discussion-between-steffen-ullrich-and-anoe). – Steffen Ullrich Nov 20 '16 at 11:01
14

The scope of what "PoisonTap" can do is equivalent to what can already be done with a malicious local network or wifi access point you plug in/connect to. In either case, there are all sorts of serious dangers if you're using unencrypted (e.g. plain-http) connections for anything that matters (providing login credentials, browsing sensitive content, downloading executable code or data files that could contain malformed data intended to exploit a bug in the application using them, etc.) but there is negligible risk to encrypted connections. And setting up a fake access point is a much lower risk to the attacker than plugging something into the victim's laptop, so I don't see why a competent attacker would choose the PoisonTap approach.

R.. GitHub STOP HELPING ICE
  • 7,813
  • 1
  • 23
  • 34
  • 1
    My impression is that this is intended to be a device that works in the traditional corporate desktop situation where you have a fixed box in an office connected to a wired Ethernet LAN, ie., where the machine either doesn't have wifi or it isn't used. (Or, I suppose, where you have a machine that is securely configured to only connect via wifi to a given mutual-authentication RADIUS network.) With that said, I would agree with the general idea that this seems like an interesting refinement to existing methods that is being overhyped by some as game-changing. – mostlyinformed Nov 18 '16 at 03:34
  • 1
    @halfinformed: Because of course you can't unplug an ethernet cable and plug it into a malicious device... – R.. GitHub STOP HELPING ICE Nov 18 '16 at 05:03
7

The attack is only feasible with local access and only on systems that automatically dhcp-enable randomly-connected network hardware. Sadly, the three major OSes do so, but some other ones more concerned with security (such as OpenBSD and friends) do not. One can predict that as a result of this attack, maybe Windows, MacOS and Linux will change their behaviour to favor security over convenience. But only in this one area, until somebody finds another way to exploit their stance in the convenience-over-security tradeoff in a different area.

idarwin
  • 171
  • 1
  • 2
    One also starts thinking that consumer OS DHCP client should reject a DHCPOFFER where the netmask results in a subnet broader than /16 (after all, these TCP/IP stacks cannot hope to manage such a large ARP table) – Ben Voigt Nov 17 '16 at 21:11
  • @BenVoigt, there are probably some class A networks still floating around out there. Set your OS to reject anything larger than a /16, and you might risk compatibility problems with one of your major customers. – Mark Nov 17 '16 at 22:15
  • 1
    @Mark: There are class A allocations, sure, but are any of them operated as a single subnet? Like I said, a consumer-grade TCP/IP stack is already in trouble if it connects to one, due to the sheer size of the ARP table that will be required. – Ben Voigt Nov 17 '16 at 22:16
  • 1
    Why does it need a /0 subnet instead of being the gateway? – JDługosz Nov 18 '16 at 01:26
  • 1
    @BenVoigt That won't accomplish anything because the USB device is the default gateway. They're only doing proxy arp because they are lazy. – Navin Nov 18 '16 at 10:11
  • 1
    @Navin: No, it's not the default gateway. Read the description of the attack. In order to become default gateway it would have to win an interface metric comparison, by using netmask of `0.0.0.0` they manage to ignore the metric on most OSes. – Ben Voigt Nov 18 '16 at 16:14
  • 1
    @JDługosz: If the computer already has a default gateway, the one suggested by the DHCPOFFER coming from the USB device often won't supercede the existing one, causing the attack to fail. – Ben Voigt Nov 18 '16 at 16:15
  • 2
    @BenVoigt That's neat but aren't there other ways to influence metric like presenting a 100G interface? – Navin Nov 18 '16 at 18:23
0

Is there something that one can do easily, without closing all browsers or turning off the pc each time when you walk to a different room to ask a short question. (Is locking it sufficient?)

My solution right now is disable USB port(s) before lock screen by handcraft batch script which may looks like this:

@echo off

:: Disable USB port(s)
REG ADD HKLM\SYSTEM\CurrentControlSet\services\USBSTOR /v Start /t REG_DWORD /d 0x4 /F

:: Lock screen
tsdiscon
Pandora
  • 167
  • 5