This article is more than 1 year old
PoisonTap fools your PC into thinking the whole internet lives in an rPi
DHCP has to be trusted, so this isn't trivial to block
How do you get a sniff of a locked computer? Tell it you're its gateway to the entire Internet IPv4 routing space.
That's the basic principle behind a demo from brainiac cracker Samy Kamkar. Plugged into a victim, his Raspberry Pi Zero-based "PoisonTap" isn't just a network sniffer, it's a backdoor-digger.
MacOS users can breathe a sigh of relief: Kamkar's attack currently only works on Windows and Linux boxen.
The basic bit of trust he exploits is this: operating systems trust DHCP (Dynamic Host Control Protocol) information that routers use to tell them how to get to the Internet. They must, after all.
If a computer – even a locked one – detects the PoisonTap Ethernet emulator plugged into its USB port, it loads it and runs a DHCP request across it.
Instead of providing a legitimate router's response, that the local network covers 192.168.0.xxx-yyy, for example, PoisonTap says it's the whole IPv4 address space (from 0.0.0.0 to 255.255.255.255).
That tricks the OS into treating what should be a “low priority” network interface as more important than the native Ethernet port of the target.
Kamkar writes “if traffic is destined to 1.2.3.4, while normally this traffic would hit the default route/gateway of the primary (non-PoisonTap) network device, PoisonTap actually gets the traffic because the PoisonTap “local” network/subnet supposedly contains 1.2.3.4, and every other IP address in existence”.
Ho hum, a local exploit ...
“So what?” you ask. “It's plugged into the USB port – someone's bound to notice”.
That's where Kamkar's extra code work comes in: while the device is plugged in, with all that traffic crossing PoisonTap it's a cinch to capture cookies and the like.
In the video below, he explains: “As long as a browser is running on the machine and an HTTP request is made automatically – such as through an ad, AJAX request, or other dynamic web content, which happens on most sites, even when the browser is entirely in the background, PoisonTap intercepts the request and responds with attack code that’s interpreted by the browser”.
And some of that's quite nasty: a 2FA session cookie lets an attacker pretend to be opening an already logged-in session.
Kamkar also wrote Web backdoor code so it would produce thousands of iFrames that are “HTML+Javascript backdoors that are cached indefinitely”.
That gives an attacker a persistent backdoor through the user's legitimate router – “a persistent WebSocket out to the attacker’s web server (over the Internet, not on the PoisonTap device)”. That can be exploited, again with new iFrames, so that having a backdoor associated with foobar.com
, the attacker can then redirect their exploit to nastyfoobar.com
.
“Any 'X-Frame-Options', Cross-Origin Resource Sharing, and Same-Origin Policy security on the domain is entirely bypassed as the request will hit the cache that PoisonTap left rather than the true domain”.
Fooling around with what's cached on the victim's host also means PoisonTap can drop a remote access backdoor to any router that's got default or weak credentials.
Protection? If you're running a server, use HTTPS – at the very least for authentication and authenticated content, make sure cookies are marked with the secure flag, add the subresource integrity flag to any remote JavaScript, and use HSTS.
As a desktop user, you can either abandon Thunderbolt or USB ports entirely, close all browser tabs when leaving your machine, or – the most practical suggestion – use an encrypted sleep mode (FileVault2 with “deep sleep”).
If you're interested in Kamkar's previous exploits, you can check out his browser location stalking, which got a reprise in Android; a handy chip-and-pin bypass, or a demo that car-hacking was child's play. ®