dougives/wispKit de script et de matériel pour désauthentifier automatiquement les clients 802.11 en masse. Capture des paquets pour des actions malveillantes ultérieures.
Script pour désauthentifier automatiquement les clients 802.11 en masse. Capture des paquets pour des usages ultérieurs. Excellent pour démarrer une conversation dans votre café local.
Ce script a été conçu pour fonctionner sur un Raspberry Pi 3 ou supérieur. Il fonctionnera également sur du matériel similaire avec des capacités équivalentes ou supérieures, bien sûr.
Un certain nombre d'accessoires supplémentaires sont nécessaires pour utiliser le script efficacement. Vous aurez également besoin de :
Pour une efficacité maximale, vous devriez également avoir :
Personnellement, j'utilise ConnectBot avec Hacker's Keyboard sur mon téléphone portable pour contrôler ce genre de kits via SSH. C'est ce qui attire le moins l'attention et tient dans la poche.
Je suggère que l'appareil soit configuré pour se connecter automatiquement à un VPN que vous hébergez, afin d'éviter tout problème de routage/NAT. Configurer OpenVPN sur un hébergeur cloud est le moyen le plus simple d'y parvenir. Assurez-vous d'utiliser la directive de configuration serveur client-to-client d'OpenVPN, ou de configurer le forwarding autrement.
Vous aurez évidemment besoin d'une autre méthode que le wifi pour connecter l'appareil à Internet. L'accès cellulaire est la solution la plus simple. À moins que vous ne souhaitiez récupérer les captures de paquets à distance, très peu de bande passante (<100Kib/s) est nécessaire. Vous pouvez vous contenter d'un forfait de données "illimité" bon marché qui restreint votre vitesse après une certaine quantité de données utilisées.
J'ai eu des problèmes de MTU lors de l'utilisation d'OpenVPN sur le réseau cellulaire. Le remède le plus simple est de définir votre MTU à 1200 avec ip link set dev tunX mtu 1200, où tunX est votre périphérique tun. Vous devrez peut-être utiliser un MTU différent selon votre réseau.
Selon votre configuration spécifique, les périphériques USB connectés peuvent consommer plus d'énergie que le Raspberry Pi ne peut en fournir par ses moyens habituels. L'utilisation d'un hub USB alimenté comme celui mentionné ci-dessus vous permettra d'alimenter les radios via un autre port USB de la batterie. Certains hubs USB bon marché "rétro-alimentent" le hub sur le Raspberry Pi. C'est acceptable tant que vous utilisez une batterie de bonne qualité, et même utile.
Une autre solution consiste à fournir une alimentation supplémentaire au hub USB à l'aide d'un répartiteur comme celui-ci. Cela fonctionne, mais je ne le recommande pas. C'est une chose de plus qui pourrait se déconnecter accidentellement, et c'est compliqué à organiser.
Si vous assurez le contrôle à distance via un téléphone portable connecté par câble, vous devez vous assurer que la batterie est complètement chargée au démarrage du kit, si possible. Certains appareils bon marché peuvent ne pas tirer suffisamment de courant pour suivre la consommation d'énergie d'une connexion de données constante.
La combinaison de plusieurs radios, du Raspberry Pi et du modem cellulaire va chauffer sérieusement. Les Panda PAU06 chauffent particulièrement. Si la chaleur ne vous dérange pas, vous vous retrouverez avec des radios fondues ou pire. Effectuez un essai avec le sac/enceinte que vous avez choisi à température ambiante au préalable, pour vous assurer qu'il offre une dissipation thermique adéquate. Si vous devez utiliser le kit dans un environnement chaud, comme à l'intérieur d'un véhicule par une journée chaude, prenez des mesures supplémentaires pour éviter la surchauffe. Dans le cas d'un véhicule, régler la climatisation et démarrer le véhicule à distance par intermittence suffira.
Certains téléphones portables bon marché sont sujets à la surchauffe en raison de la combinaison de l'équipement supplémentaire et de la nécessité de transmettre régulièrement des données. Ils peuvent s'éteindre dans ces conditions, empêchant le contrôle à distance. Placer le téléphone dans un compartiment séparé du reste du kit aidera, mais il est préférable d'utiliser un autre appareil.
Si vous avez l'intention d'utiliser le kit de manière discrète, gardez à l'esprit que la chaleur peut attirer l'attention de manière inattendue. S'il est laissé sur le tableau de bord d'un véhicule pendant une journée enneigée, il fera fondre la neige et la glace. Il y aura un espace rond et clair sur le pare-brise, centrant le kit en vue, alors que tout le reste est couvert de neige !
Les instructions d'installation de Wisp sont détaillées dans rpi-install.md. Les étapes devraient être similaires pour les systèmes non-raspian. Wisp dépend de aireplay-ng d'aircrack-ng pour transmettre les trames de désauthentification. Notamment, vous devrez construire Python-3.7.1 pour l'appareil, ce qui est également décrit dans le fichier rpi-install.md.
Wisp dépend d'un autre petit programme C appelé dream. Le code source est inclus dans dream.c. Dream dépend de libpcap.
Compilez dream pour votre appareil avec la commande gcc -O3 dream.c -lpcap.
Dream est un outil pour surveiller le trafic 802.11 avec une sortie filtrable par ligne (grep). Il enregistre également le trafic capturé dans des fichiers au format pcap standard. Wisp appelle dream pour chaque radio de monitoring et analyse la sortie pour le trafic client. Voici ses arguments :
--a : Signaler uniquement le trafic des clients associés. (Tous les paquets sont toujours enregistrés sur le disque si --d est activé.)--d (fichier) : Enregistrer les paquets dans le fichier spécifié.-[b][c][d][f][s][t] : Spécifie les champs à afficher par ligne, notamment :
b : BSSc : Numéro de canal.d : Nom du périphérique qui a reçu le paquet.f : Fréquence.s : Station (STA).t : Horodatage pcap.Ces champs sont toujours affichés dans le même ordre, quel que soit l'ordre spécifié. (C'est-à-dire que -bcst est équivalent à -sctb.)
Wisp lit un fichier au format JSON nommé wisp.json pour la configuration. Voici une description des clés :
monitors : Contient une liste de périphériques à configurer comme moniteurs. Chaque périphérique contient des sous-clés décrivant sa configuration spécifique :
channel : Le canal sur lequel le périphérique doit monitorer.injector : Le périphérique à configurer pour injecter les trames de désauthentification.timing : Liste plusieurs paramètres de temporisation, tous donnés en millisecondes :
delay : Le délai entre l'envoi des paquets de désauthentification, par client.jitter : Module le délai par une valeur aléatoire, dans la plage donnée.stale : Durée pendant laquelle un client non vu est conservé dans la liste des délais. A peu d'effet pratique sauf si elle est proche de la plage de temps du délai.Tous les paramètres sont chargés depuis wisp.json, donc wisp est invoqué simplement : python3 ./wisp.py
Wisp configurera automatiquement les radios comme décrit dans wisp.json. Il désactivera également rfkill et tuera tout processus interférant, comme le fait airmon-ng.
Wisp renomme les périphériques spécifiés avec le format wispX où X est le numéro associé au phy. Il les renommera à leurs noms d'origine lors de la fermeture.
Wisp affiche un . pour chaque désauthentification envoyée. C'est un moyen simple et efficace de vérifier que tout fonctionne comme prévu.
Wisp (via dream) génère des fichiers pcap préfixés par le nom de la radio (phy) qui a capturé les paquets, avec une chaîne hexadécimale aléatoire, se terminant par .cap. Par exemple, quelque chose comme phy0-8cf9ec5ca146943f.cap. Vous pouvez ensuite inspecter, analyser et manipuler ces fichiers avec les outils habituels pour les fichiers pcap.