fkasler/cuddlephishBrowser-in-the-Middle (BitM) armé pour les testeurs de pénétration
Navigateur-dans-le-milieu (BitM) multi-utilisateur armé pour les testeurs d'intrusion. Cette attaque peut être utilisée pour contourner l'authentification multi-facteurs sur de nombreuses applications Web à haute valeur ajoutée. Elle fonctionne même pour les applications qui n'utilisent pas de jetons de session et qui ne seraient donc pas exploitables via des attaques traditionnelles de vol de jetons. Il s'agit d'un outil d'ingénierie sociale et n'exploite aucune faille technique dans le service cible.
Cet outil est un serveur Web spécialisé. Il est conçu pour fonctionner sur un serveur Linux Debian 11 (Bullseye) et repose sur les informations d'adresse IP publique pour protéger les fonctionnalités d'administration. Ne vous attendez pas à pouvoir le tester localement sans passer par des contraintes importantes.
Attention : Chromium n'est pas pris en charge sur ARM. Bien qu'il soit techniquement possible de forcer l'utilisation d'un binaire Chromium ARM, vous perdrez toutes les fonctionnalités/protections supplémentaires de puppeteer-extra.
Cet exemple de configuration utilise Caddy pour gérer TLS, SNI et ajouter quelques en-têtes personnalisés comme 'X-Real-IP' à chaque requête. Vous n'êtes pas obligé d'utiliser Caddy avec Cuddlephish, car le même proxy inverse peut être configuré avec Nginx, Apache, etc. J'aime Caddy car il est facile à installer avec Docker et dispose de plugins pour gérer les certificats Letsencrypt pour la plupart des registraires de domaines. Le fichier Caddyfile d'exemple montre comment le configurer pour Gandi. Consultez la documentation de votre registraire.
Installez Docker, Node, XVFB et d'autres dépendances :
git clone https://github.com/fkasler/cuddlephish
cd cuddlephish
sudo bash install_deps.sh
Vous pouvez ensuite utiliser Docker pour construire Caddy avec un plugin de certificat wildcard pour votre registraire. L'exemple est pour Gandi. Consultez la documentation ici et la liste des modules de fournisseurs DNS ici. Vous pouvez modifier le Dockerfile pour votre registraire avant la construction :
sudo docker build -t caddy .
Maintenant, modifiez le fichier Caddyfile pour échanger votre domaine et votre clé API Gandi (ou autre registraire), puis démarrez Caddy. Je recommande de le lancer dans une fenêtre screen ou tmux afin de pouvoir exécuter le serveur Node dans une autre fenêtre dans un instant :
sudo docker run -p 80:80 -p 443:443 -p 2019:2019 -v $PWD/Caddyfile:/etc/caddy/Caddyfile --network=host caddy:latest
Avec Caddy qui gère le trafic pour nous sur les ports 80 et 443, nous pouvons enfin exécuter l'outil !
Installez les dépendances Node :
npm install
Quelques ajustements de configuration : ÉTAPE CRITIQUE : Assurez-vous de modifier le fichier config.json d'exemple pour ajouter votre/vos adresse(s) IP publique(s) approuvée(s) pour l'accès administrateur. Cette liste blanche d'IP est ce qui détermine l'accès à l'interface Web "/admin". Vous devez également changer la clé de socket par défaut pour quelque chose de plus sécurisé.
L'outil n'est pas configuré pour cibler des connexions par défaut, vous devrez donc en ajouter. Il existe un script 'add_target.js' pour faciliter cette étape. Exécutez simplement le script et collez l'URL du portail de connexion que vous souhaitez cibler lorsque vous y êtes invité :
node add_target.js
Cela récupérera le nom du service, le titre de l'onglet et le favicon pour vous, et ajoutera une entrée à 'targets.json'. Vous pouvez exécuter ce script plusieurs fois et il ajoutera vos nouvelles cibles. Le script nommera chaque service en fonction du domaine, sans le niveau supérieur. Ainsi, pour 'https://www.example.com/login.php', le service serait simplement 'example' lorsque vous spécifiez votre cible lorsque vous...
Exécutez-le !
node index.js example
Après quelques secondes, vous devriez voir un message dans la console lorsque votre première instance Chrome automatisée se connecte via websockets. Désormais, les visiteurs de votre site de phishing devraient voir ce qui semble être la page de connexion cible mais qui est en réalité un flux vidéo de votre instance de navigateur automatisée. Ils peuvent également interagir avec votre instance de navigateur et se connecter pour vous.
Si vous avez correctement configuré votre/vos IP(s) d'administration dans config.json, vous devriez pouvoir consulter une interface Web spéciale '/admin' pour suivre les utilisateurs, consulter les journaux de frappe, prendre le contrôle des instances de navigateur connectées, voler des cookies et supprimer les instances de navigateur indésirables.
Remarque : Vous ne verrez rien dans la page d'administration tant que vous n'aurez pas de victimes. Une fois que vous avez une victime, son instance de navigateur devrait apparaître dans l'interface administrateur.
Plusieurs personnes ont ouvert des problèmes concernant une "Page blanche", ce qui est plutôt un symptôme de nombreux problèmes possibles, et non un problème en soi. Veuillez ne pas ouvrir de problèmes sous des noms de symptômes vagues. Au lieu de cela, si vous avez une page blanche côté utilisateur, essayez d'abord d'examiner les points suivants :
À un niveau élevé, si vous voyez simplement une page blanche côté front-end, cela signifie qu'il y a une rupture dans la chaîne de flux de données de "Démarrer WebRTC" > "Sélectionner l'onglet à diffuser" > "Négocier ICE avec le navigateur de la victime" > "Diffuser la vidéo". Les étapes de dépannage ci-dessus sont destinées à vous aider à suivre les données tout au long de ce processus. Lorsque cela fonctionne correctement, vous devriez voir un flux de journaux sur le serveur similaire à ceci :
J'espère que cela vous aidera avec tout problème, et comme toujours, des informations suffisantes pour reproduire un problème de manière cohérente sont un prérequis pour soumettre des problèmes en vue d'une enquête plus approfondie.
Déclenchez manuellement le téléchargement d'une charge utile vers le système de la victime via JavaScript. Chaque cible commence avec 'payload.txt' comme charge utile de test. Remplacez simplement l'emplacement du fichier dans targets.json pour envoyer une charge utile personnalisée.
Envoie un changement de window.location à la victime pour la rediriger vers le vrai portail de connexion. Il semblera simplement qu'elle est obligée de se réauthentifier, ce qui l'empêchera de vous voir prendre les commandes. Si vous modifiez le code, vous pouvez faire d'autres choses intéressantes avec cette technique générale ;)
Vous permet d'intervenir et de prendre le contrôle d'une instance de navigateur directement depuis le portail d'administration. Pour arrêter de contrôler l'instance, appuyez sur la touche ÉCHAP. Notez que cela enlèvera le contrôle à la victime du phishing et elle pourra observer vos mouvements si vous ne l'éjectez pas d'abord. Vous êtes prévenu.
Vous permet de redonner manuellement le contrôle de l'instance de navigateur automatisée à l'utilisateur. Cela peut être utile dans certains scénarios d'ingénierie sociale lors de l'usurpation d'identité du service informatique. Vous pouvez dire à l'utilisateur que vous démarrez une session d'assistance, prendre le contrôle et naviguer vers le service cible, rendre le contrôle et lui demander de se connecter, reprendre le contrôle, etc.
Extrait tous les éléments de cookie et de stockage local de l'instance de navigateur et les télécharge sous forme de fichier JSON. Pour injecter ce matériel d'identification dans une instance de navigateur exécutée sur votre système local, il existe un script appelé 'stealer.js' dans le projet. Il est destiné à être exécuté depuis votre machine, pas depuis le serveur, donc pour l'utiliser, vous devrez également installer les composants Node du projet sur votre système.
node stealer.js ~/Downloads/cuddle_asdf1234.json
Tue une instance de navigateur lorsque vous n'en avez pas besoin. Parfois, les utilisateurs ne vous connectent pas complètement. Parfois, la connexion WebRTC échoue. Parfois, une session expire avant que vous puissiez l'utiliser. Dans ces cas, ce bouton peut vous aider à nettoyer les instances de navigateur inutiles via le portail d'administration.
Chaque navigateur est généré avec son propre "identifiant de navigateur" aléatoire et un répertoire de données utilisateur correspondant dans le dossier "user_data" du projet. Dans certains cas où 'stealer.js' ne fonctionne pas, vous devrez peut-être également répliquer les données utilisateur de cette instance. Cela peut être utile dans les cas ciblant des services avec une fonctionnalité "se souvenir de ce navigateur" en fonction de la façon dont cette fonctionnalité est implémentée.
Il y a également un fichier keylog.txt dans chaque répertoire de données utilisateur contenant un journal complet des frappes de l'utilisateur victime. Le journal général des frappes dans le portail d'administration essaie de prendre en compte des éléments comme les touches de retour arrière, alors que ce keylog.txt contiendra toutes les frappes enregistrées.
Exemple de pm.json :
{
"tacking_id": "id",
"logging_endpoint": "https://www.phishmongerserver.com/create_event",
"admin_cookie": "admin_cookie=s3cret",
"post_url_search": "ppsecure"
}
Cet outil fonctionne en associant les visiteurs du site de phishing à un navigateur Chrome automatisé, exécuté sur le serveur de phishing. Un flux vidéo de l'instance Chrome contrôlée par l'attaquant est ensuite diffusé à la victime du phishing via WebRTC, et tous les mouvements de souris et frappes clavier fournis par l'utilisateur sont transmis du navigateur de la victime à son instance Chrome associée. Le serveur utilise des websockets pour suivre les victimes, les associer à des navigateurs, négocier les flux vidéo WebRTC et intercepter les entrées utilisateur. Pour chaque nouveau visiteur, le serveur génère une nouvelle instance Chrome. Comme nous utilisons le protocole Chrome Devtools (CDP) pour piloter chaque instance Chrome, nous pouvons utiliser des API comme "Storage.getCookie" pour extraire les cookies de session pour les sites cibles une fois que l'utilisateur s'est connecté pour nous. Nous pouvons également intervenir à tout moment et piloter directement chaque instance Chrome, en exploitant la même méthode que nous utilisons pour donner le contrôle à distance aux victimes en premier lieu.
Le serveur Node effectue les opérations suivantes :
Il est de ma connaissance que cette technique a été théorisée et même armée depuis plusieurs années maintenant (voir les remerciements). Ainsi, bien que les acteurs malveillants puissent exploiter cette technique, et l'ont probablement fait depuis un certain temps, les professionnels de la sécurité offensive n'ont pas eu de moyen facile de reproduire cette technique et peuvent même ignorer son existence. Mon intention en publiant cet outil est de permettre aux testeurs d'intrusion et aux red teamers d'utiliser BitM lors d'opérations pour démontrer son impact potentiel et aider les défenseurs de réseaux à se préparer aux menaces réelles.
Tout d'abord, comprenez que cette attaque repose sur l'ingénierie sociale pour amener un utilisateur à visiter un site Web malveillant. La mise sur liste blanche des domaines irait loin pour prévenir ce type d'attaque ainsi que d'autres formes d'ingénierie sociale. Si nous comptons sur les utilisateurs pour gérer 100 % des données d'identification (mot de passe, OTP, SMS, PhoneFactor, notification push, etc.) pour un service Web, nous sommes potentiellement vulnérables à cette attaque. Par conséquent, pour contrecarrer cette attaque, nous devons exploiter des données d'identification que les utilisateurs ne gèrent pas. Par exemple, les certificats TLS client peuvent être délivrés aux appareils clients et ne seront valides que pour le véritable service Web. Le certificat est géré par le navigateur et le système d'exploitation, et il n'y a aucun moyen pour le serveur de l'attaquant d'obtenir une copie du certificat TLS de la victime. Une autre option consiste à utiliser U2F ou FIDO2 avec du matériel comme un YubiKey pour gérer une partie des données d'identification requises. Il n'y a aucun moyen pour un site Web de pirate d'interagir avec un YubiKey branché sur l'ordinateur d'une victime.
Je ne suis pas encore un expert Docker. Si vous pouvez proposer une configuration simple avec Docker, j'adorerais recevoir une pull request.
C'est un jeu de mots sur Cuttlefish (seiche), une créature marine badass qui peut se fondre dans son environnement, Phishing, car cela nécessite de l'ingénierie sociale pour réaliser l'attaque, et intentionnellement mal orthographié pour être unique, ludique et absurde. Cela me rend heureux de penser que ce nom d'outil amusant sera mentionné aux côtés de résultats de tests d'intrusion à haut risque.
Bien que j'aie développé cette technique et cette implémentation de manière indépendante, j'ai depuis appris que quelques autres chercheurs m'ont précédé dans la découverte. Chacun a adopté une approche utilisant des clients VNC basés sur le Web pour obtenir un résultat similaire. C'est une approche intuitive et pourrait être applicable pour effectuer des attaques MitM contre d'autres logiciels, pas seulement les navigateurs (VPN-dans-le-navigateur peut-être ?). Cela vaut vraiment la peine d'être vérifié :
Franco Tommasi, Christian Catalano & Ivan Taurino https://link.springer.com/article/10.1007/s10207-021-00548-5
@mrd0x https://mrd0x.com/bypass-2fa-using-novnc/
Aussi :
Remerciements à Daniel Aaron @majordmg pour son aide dans les premières étapes de la preuve de concept WebRTC.
Un grand merci à RJ Stallkamp @Z3rO-C00L pour avoir corrigé et stylisé l'interface d'administration, ainsi que pour le nouveau super logo.