An enthusiast, hacker, and just a good computer security expert, Sami Kamar, has shared a new way to hack macOS and Windows computers. For this purpose, he developed a device called Poisontap, which consists of the increasingly popular Raspberry Pi mini-PC. If you connect the gadget to your computer, it is detected as an Ethernet device that allows you to redirect all network traffic to itself.
Poisontap first downloads all cookies from the computer, which are known to be stored in the browser cache, and then intercepts control of the Wi-Fi router, which makes it possible to send any code to the victim device via the Internet. Moreover, after disconnecting the hacker’s gadget from the computer, the backdoor remains on it. Thus, the solution allows to fool antiviruses and lock screens.
If you want to know more about it, Samy reveals its details in full on his website: samy.pl/poisontap/
There are a number of tips to protect against this kind of attack, from sealing the USB ports of your computer with cement or glue, to following the not very reassuring and impractical Microsoft advice “Don’t leave your laptops and computers unattended”.
Before we get to the functionality, I will tell you how to install Raspbian and Poisontap.
Part 1. Installing Raspbian
We need an sd-card of 16-32 gigabytes, a card reader (or you can do with an adapter) and a system image.
Download the system image you prefer from https://www.raspberrypi.org/downloads/raspbian/ (I chose full version with preinstalled software – Raspbian Full Buster). Then burn it to flash drive through Win32DiskImager (link: https://sourceforge.net/projects/win32diskimager/files/latest/download)
This is what Win32DiskImager looks like:
In Device we select our flash drive and in Image File – OS image, then press Write, when the process is finished you can insert the flash drive into our Malina and start, then there will be a simple setup, where you will need to select the system language and so on, I see no point in showing this.
Part 2. Configuring Services and Installing Poisontap
Once the system is installed, you can configure the basic services.
First, open the console and write sudo raspi-config
Next, in the window that appears, choose everything that is shown in the gif:
When we have done everything, reboot the Malinka and after the reboot in the console write sudo apt-get update.
In the console we write:
sudo apt-get install git npm
sudo npm install websocket
curl -sL https://deb.nodesource.com/setup_7.x | sudo -E bash –
sudo apt-get install nodejs
git clone https://github.com/samyk/poisontap
sudo node backend_server.js &
Next, we need to create a bash script – sudo nano install.sh.
When you press Enter you will open a text editor, where you have to put the following:
Instructions adjusted from https://gist.github.com/gbaman/50b6cca61dd1c3f88f41
echo -e “\nauto usb0\nallow-hotplug usb0\niface usb0 inet static\n\taddress 188.8.131.52\n\tnetmask 0.0.0.0” >> /etc/network/interfaces
echo “dtoverlay=dwc2” >> /boot/config.txt
echo -e “dwc2\ng_ether” >> /etc/modules
sudo sed –in-place “/exit 0/d” /etc/rc.local
echo “/bin/sh /home/pi/poisontap/pi_startup.sh” >> /etc/rc.local
chown -R pi /home/pi/poisontap
apt-get -y install isc-dhcp-server dsniff screen nodejs
It should come out something like this:
Press CTRL + X, Y and Enter
Write in the console sudo chmod +x install.sh and now you can run our script.
As you can see I had to write an exit for the script to go further, so keep that in mind.
If the script stops, use exit again.
Now we need to edit the rc.local file, but before doing so we will backup it to the desktop:
sudo cp /etc/rc.local /home/pi/Desktop/
sudo nano /etc/rc.local
Remove all lines from the file, so that it looks like this:
Do almost the same with dhcpd.conf:
sudo cp /etc/dhcp/dhcpd.conf /home/pi/Desktop/
sudo cp dhcpd.conf /etc/dhcp/dhcpd.conf
This completes the installation, you can connect our rpi0 to your computer, but before you do it, check the file /etc/network/interfaces, it should contain the following lines:
iface usb0 inet static
Also in /etc/default/isc-dhcp-server file you should add the following line:
Part 3. Poisontap Functionality
When PoisonTap is connected to a computer, it:
- Emulates Ethernet device via USB (or Thunderbolt);
- Captures all Internet traffic from your computer (even though it is a low-priority/unknown network interface);
- Pumps and stores HTTP cookies and sessions from the browser for top 1,000,000 Alexa sites;
- Provides an internal router to the attacker, making it available remotely through outbound WebSocket and DNS connections;
- Allows an attacker to remotely force a user to create HTTP requests and proxy responses (GET & POST) using the user’s cookies in any domain that has a backdoor;
- Backdoors and remote access are retained even after the device is removed and the attack is over.
What else can Poisontap do?
PoisonTap emulates an Ethernet device (such as Ethernet over USB/Thunderbolt) – by default, Windows, OS X and Linux recognize an ethernet device, automatically load it as a low priority network device and query through it, even if the machine is locked or password protected.
PoisonTap responds to the DHCP request and gives the machine an IP address, however, the DHCP response is designed to tell the machine that the external IPv4 space (0.0.0.0 – 255.255.255.255) is part of the PoisonTap local network, not a small subnet (such as 192.168.0.0 – 192.168.0.255)
- Usually it does not matter if a secondary network device is connected to the machine, because it will be given a lower priority than the existing (trusted) network device, and it will not replace the gateway for Internet traffic, but .
- Any routing table / gateway priority / network interface service security order is easily bypassed due to the priority of “LAN traffic” over “Internet traffic”.
- PoisonTap uses this network access even as a low priority network device because the subnet
- Low priority network device has a higher priority than the gateway (default route) of the device with the highest priority.
- This means that if the traffic is destined for 184.108.40.206, whereas normally this traffic would go to the default route/gateway of the primary (not PoisonTap) network device, PoisonTap actually receives the traffic because the PoisonTap LAN/subnet is supposed to contain 220.127.116.11, and every other IP address that exists.
- Due to the above reasons, all internet traffic goes through PoisonTap, even if the machine is connected to another network device with a higher priority and proper gateway (true wifi, ethernet,etc.)
How does cookie pumping work?
- As long as the background is running in the web browser, one of the open pages will probably perform an HTTP request in the background (e.g. downloading new ads, sending data to an analytics platform, or just continuing to track your web activity) via AJAX or dynamic script/iframe tags
- You can see this for yourself, just go into your devtools / inspector (usually Cmd + Shift + I or Ctrl + Shift + I), go to the most visited website, click on the Network tab and observe how remote resources continue to be accessible even if you do not take any action on the page.
- On this HTTP request, as all traffic goes out to the PoisonTap device, the PoisonTap DNS quickly returns its address, thus forcing the HTTP request to go to the PoisonTap server (Node.js).
- If the DNS server points to an internal IP (LAN) that PoisonTap cannot access, the attack continues to function because the internal DNS server will generate public IP addresses for the various domains under attack, and these are the public IP addresses that PoisonTap has already hijacked.
- Once the internal DNS server responds, the browser hits the public IP address, eventually reaching the PoisonTap web server (Node.js) in either scenario.
- The HTML/JS-agnostic page then produces multiple hidden iframes, one iframe for each Alexa-top-1-million domain
- Any “X-Frame-Options” security on the domain is now easily bypassed, since PoisonTap is now an HTTP server and chooses which headers to send to the client itself.
As every iframe HTTP request to the site is made (e.g. ), HTTP cookies are sent from the browser to a “public IP” already stolen by PoisonTap, which quickly logs the cookie and authentication information, writing tens of thousands of user cookies to PoisonTap
- Any Cross-Origin Resource Sharing or Same-Origin Policy security is also bypassed, because the way in which the domain is accessed seems quite legitimate/legitimate to the browser
- All of this happens because we intercept cookies, not credentials, and so any 2FA/MFA implemented on the site is very easy to circumvent when an attacker uses a login cookie. This is due to the fact that we are not actually performing a login function, but rather continuing an existing session that does not trigger two-factor authentication.
- If the server uses HTTPS, but the cookie is not explicitly set to Secure cookie, the HTTPS protection is bypassed without issue and the cookie is sent to PoisonTap.
Remotely accessible web backdoors
- Because PoisonTap force-caches these backdoors in each domain, the backdoor is tied to that domain, allowing the attacker to use the domain cookie and run requests from the same source in the future, even if the user is not currently logged in.
- For example, when http://nfl.com/PoisonTap iframe is loaded, PoisonTap accepts rejected internet traffic and responds to HTTP requests via the Node web server.
- Added additional HTTP headers to cache the page as undefined.
- The WebSocket remains open, allowing the attacker, at any moment in the future, to connect to the machine with the backdoor and to perform a request to any source where this backdoor is implemented (Alexa top 1,000,000 sites – see below)
- If the backdoor is open on a site (e.g. nfl.com), but the user wants to perform an attack against another domain (e.g. pinterest.com), the attacker can load an iframe from nfl.com into the pinterest.com backdoor (http://pinterest.com/PoisonTap)
- Again, please note that any “X-Frame-Options”, Cross-Origin Resource Sharing, and Same-Origin Policy security on the domain is completely bypassed because the request will go into the cache from which PoisonTap came, not into the genuine domain.
Router backdoor and remote access
- There is one network that PoisonTap can’t hack, and that network is the actual LAN subnet of the actual network interface (e.g. if the user’s wifi subnet is 192.168.0.x, then that network will remain unaffected), but…
- PoisonTap force – caches the backdoor on a special host, specifically the IP address of the target router added to “.ip.samy.pl”, e.g. 192.168.0.1.ip.samy.pl, essentially performing a permanent DNS restart attack.
- When using PoisonTap as a DNS server (the victim uses a public DNS server), PoisonTap temporarily responds with a special PoisonTap IP (18.104.22.168), implying that any request at this point will hit the PoisonTap web server.
- If the DNS server is instead set to an internal network (like 192.168.0.x), an additional specially crafted request goes to 22.214.171.124.pin.ip.samy.pl, which tells my DNS server (on the public Internet) to temporarily respond to any [ip.address].ip.samy.pl address with an “attached” address (126.96.36.199) for a few seconds
- PoisonTap then quickly sets the backdoor to http://192.168.0.1.ip.samy.pl/PoisonTap, which currently points to the PoisonTap device at 188.8.131.52, allowing you to access the backdoor and cache from the PoisonTap device
- DNS pinning and DNS re-binding protection is easily bypassed due to depletion of the DNS pinning table
- Due to hundreds of thousands of previously requested requests, and re-binding should not occur in the future, making this attack resilient over long periods of time (thanks to Matt Austin for sharing this attack with me!)
- Now, when the backdoor is forcibly cached at http://192.168.0.1.ip.samy.pl/PoisonTap, any future requests to 192.168.0.1.ip.samy.pl will address the unsecured IP address, running 192.168. 0.1 and pointing directly to the router.
- This means that if you load host 192.168.0.1.ip.samy.pl/PoisonTap in an iframe remotely via a backdoor, you can now perform AJAX GET/POSTs on any other page on the internal router, completely remotely, thus allowing remote access to the internal router.
- This can lead to other attacks on the router that the attacker might not have access to at all, such as using the default administrator credentials to overwrite DNS servers, or exposing authentication vulnerabilities.
Never use the methods described in the article. This article is written for informational purposes only. The author is not responsible for the application of the skills. Otherwise, you are breaking the law.