Question:
Empêcher les attaques de désauthentification
Tawfik Khalifeh
2012-09-15 03:09:00 UTC
view on stackexchange narkive permalink

Je suis impuissant face à un gamin avec retour en arrière qui utilise à plusieurs reprises aireplay-ng pour désauthentifier les utilisateurs légitimes sur mon réseau de travail Wifi.

J'ai capturé et analysé le trafic réseau sur mon réseau de travail Wifi, et j'ai remarqué une quantité remarquable de paquets de désauthentification 802.11. Je me rends compte qu'il n'est peut-être pas possible de l'attraper, ni même de savoir d'où vient l'attaque. Je veux juste savoir: existe-t-il un moyen d'empêcher une telle attaque?

Comme l'a déclaré @gowenfawr, il n'existe aucun moyen technique pratique pour arrêter une telle attaque. Votre meilleur pari serait de signaler à la police locale et de laisser la loi essayer de le dissuader.
Je ne peux pas garantir que cela fonctionnera, mais j'ai entendu dire que les routeurs de niveau entreprise rejettent maintenant les paquets Deauth de l'extérieur du réseau.Cela vaut peut-être la peine d'acheter si vous vivez dans un appartement ou une maison à proximité d'un script kiddy qui vous dérange vraiment.
@DeepS1X Vous pensez peut-être au support MFP / 802.11w qui authentifie les décès.
C'est vrai - je pensais à Management Frame Protection.Merci!
Pour vérifier d'où elles viennent: Vider les données à l'aide du menu Sniff de l'outil de diagnostic Wi-Fi standard sur Mac (ou airdump-ng si vous avez un appareil avec mode moniteur).Ensuite, vous pouvez voir la force du signal en affichant le fichier de sortie dans Wireshark.Situé trois maisons envoyant les messages de désauthentification de cette façon.
Cinq réponses:
D.W.
2012-09-15 11:02:43 UTC
view on stackexchange narkive permalink

De manière réaliste, vous ne pouvez pas empêcher un malfaiteur d'envoyer des paquets de désauthentification.

Au lieu de cela, vous devriez vous concentrer sur la résistance à une attaque de désauthentification. Assurez-vous que votre réseau est configuré de manière à ce que l'attaque deauth ne permette pas à un attaquant de compromettre votre réseau.

Pour ce faire, vous devez vous assurer que vous utilisez WPA2. Si vous utilisez une clé pré-partagée (une phrase de passe), assurez-vous que la phrase de passe est très longue et forte. Si ce n'est pas déjà fait, changez-le immédiatement! Si vous n'utilisez pas WPA2, corrigez-le immédiatement!

La principale raison pour laquelle les méchants envoient des paquets deauth est que cela les aide à exécuter une attaque par dictionnaire contre votre phrase de passe. Si un méchant capture une copie de la poignée de main initiale, il peut essayer diverses hypothèses sur votre phrase secrète et vérifier si elles sont correctes. L'envoi d'un paquet d'authentification oblige le périphérique ciblé à se déconnecter et à se reconnecter, ce qui permet à un espion de capturer une copie de la prise de contact initiale. Par conséquent, la pratique courante de nombreux attaquants qui pourraient tenter d'attaquer votre réseau sans fil consiste à envoyer des paquets de suppression. Si vous voyez de nombreux paquets Deauth, c'est le signe que quelqu'un essaie peut-être d'attaquer votre réseau sans fil et de deviner votre phrase secrète.

Une fois que l'attaquant a envoyé un paquet Deauth et intercepté la prise de contact initiale, il y a des outils et des services en ligne qui automatisent la tâche d'essayer de récupérer la phrase de passe, en devinant de nombreuses possibilités. (Voir, par exemple, CloudCracker pour un exemple représentatif.)

La défense contre ce type d'attaque est de s'assurer que votre phrase de passe est si longue et forte qu'elle ne peut pas être devinée. Si ce n'est pas déjà long et fort, vous devez le changer tout de suite, car quelqu'un essaie probablement de le deviner au moment où nous parlons.

(L'autre raison pour laquelle un méchant peut envoyer de nouveaux paquets est une gêne . Cependant, comme la plupart des utilisateurs ne le remarqueront probablement même pas, ce n'est pas un ennui très efficace.)

Pour en savoir plus, consultez ces ressources:

Vous avez indiqué que ce n'était pas un ennui très efficace, mais ce repo GitHub indique qu'il peut efficacement éliminer tout le monde du réseau Wifi lorsqu'il est scripté: https://github.com/DanMcInerney/wifijammer - Appelez-moi fou, mais cela semble très ennuyeux. Est-ce que je manque quelque chose?
@DanEsparza, vous avez peut-être raison. J'avais l'impression que les clients se reconnecteraient automatiquement, mais je peux me tromper: je ne l'ai pas testé. Si vous avez trouvé de la documentation qui dit que les clients sont expulsés du réseau et qu'ils ont du personnel, je vous crois.
En fait - je ne sais pas que c'est qu'ils restent automatiquement hors du réseau, c'est juste que l'attaque peut être scriptée de telle manière que les clients sont trop occupés à «ré-authentifier constamment» pour faire quelque chose d'utile.
Si je n'utilise pas du tout WPA / WEP mais un point d'accès ouvert avec un cryptage VPN ou IPSec obligatoire. Puis-je obtenir un WiFi à l'épreuve DeAuth sans perte de sécurité?
@ 比尔 盖子, non. Le VPN garantira la confidentialité et l'intégrité, mais si c'est la voie que vous envisagez, il serait préférable d'utiliser WPA plus votre VPN / IPSec.
Ce n'est plus vrai.Voir 802.11w.
YLearn
2014-08-01 09:04:34 UTC
view on stackexchange narkive permalink

Cisco a été le fer de lance d'une méthode de détection de ces attaques et même de protection de ce type d'attaque si elle est activée et que le périphérique client le prend en charge (prise en charge minimale de CCXv5). La fonction Cisco s'appelle "Management Frame Protection" et tous les détails peuvent être trouvés sur le site Web de Cisco.

En substance, le processus ajoute une valeur de hachage à tous les cadres de gestion qui sont envoyé.

Ce processus a été normalisé avec l'amendement IEEE 802.11w publié en 2009, et est pris en charge par la plupart des distributions Linux / BSD modernes du noyau . Windows 8 a été introduit avec le support 802.11w par défaut (ce qui a causé des problèmes initiaux dans certains environnements). AFAIK, OS X n'a ​​toujours pas le support 802.11w.

Pour référence, 802.11w a été intégré dans la version de maintenance 802.11-2012 de la norme 802.11.

Quelqu'un m'a donné un vote favorable qui a rafraîchi cette réponse dans mon esprit et a pensé que c'était dû à une mise à jour.

La Wi-Fi Alliance (WFA) a rendu obligatoire la prise en charge des cadres de gestion protégés (PMF) pour passer 802.11ac ou Passpoint ( aka HotSpot2.0). Cela a considérablement amélioré la prise en charge du 802.11w et vous pouvez même le trouver dans la plupart des appareils grand public aujourd'hui.

Malheureusement, Apple semble toujours être la cible. Permettez-moi de commencer en disant que j'ai été surpris de constater que Apple n'a pas certifié un seul appareil avec le WFA depuis début 2014. Je sais qu'il s'agit d'un processus volontaire pour les fournisseurs, mais ne pas participer au processus de certification me semble être une mauvaise idée pour un si grand fabricant d'appareils sans fil.

Bien qu'Apple ait ajouté le support 802.11w, il existe sont toujours des problèmes. Plus tôt cette année, je suis tombé sur cet article détaillant les problèmes de connexion d'Apple à un réseau avec authentification 802.11X et 802.11w requis. Les réseaux qui utilisent un PSK (avec 802.11w en option ou requis) semblent fonctionner comme les réseaux 802.1X avec 802.11w en option.

Nous y arrivons, mais il reste encore du chemin à parcourir.

C'est la * bonne * réponse, à long terme. Surtout à la lumière des nouvelles récentes sur les chaînes d'hôtels bloquant le Wi-Fi. Apple doit mettre en œuvre et les fabricants de points d'accès doivent activer des cadres de gestion protégés afin de sécuriser le MAC Wi-Fi.
J'ai récemment été initié à cette attaque (2016) et le gars qui me l'a montrée prétend qu'elle est extrêmement efficace.Cela fait 2 ans depuis votre publication et il ne semble pas que la protection ait vu beaucoup de terrain.
@Shadoninja d'abord, de nombreux environnements 802.11 (en particulier les installations grand public) ne prennent pas en charge le 802.11w aujourd'hui.Soit ils sont trop vieux, soit les fournisseurs n'ont pas ajouté de support.Deuxièmement, les appareils Apple AFAIK ne prennent toujours pas officiellement en charge le 802.11w, mais je peux me tromper (il semble qu'ils n'aient certifié aucun appareil avec Wi-Fi Alliance depuis 2014 et aucun avec aucune certification de sécurité de leur part même alors).Cela conduit de nombreux environnements qui pourraient utiliser 802.11w à ne pas l'exécuter ou à ne l'autoriser qu'en option.Malgré ces problèmes, c'est la solution au problème du PO.
@YLearn, Je n'ai pas nécessairement contesté cette réponse.J'ai trouvé très intéressant qu'un problème de ce calibre existe toujours.
@Shadoninja,, malheureusement, l'échec de (certaines parties de) l'industrie à implémenter des fonctionnalités de sécurité avancées est trop courant, en particulier lorsque les gens ne comprennent pas ces fonctionnalités et pourquoi elles sont nécessaires.
gowenfawr
2012-09-15 03:21:58 UTC
view on stackexchange narkive permalink

Le seul moyen d'empêcher une telle attaque est de bloquer la capacité de l'attaquant à envoyer des transmissions sans fil qui atteindront vos utilisateurs légitimes. Ce n'est pas une solution pratique pour plusieurs raisons (mais des points supplémentaires si vous pouvez convaincre vos employés de s'asseoir dans une cage de Faraday).

Cette page de blog ici cite une partie de la norme WiFi pertinente, notamment:

La désauthentification n'est pas une demande; c'est une notification. La désauthentification ne sera refusée par aucune des parties.

Donc, non, il n'y a pas vraiment de moyen d'empêcher une telle attaque.

Bummer - cette URL est morte et n'est archivée sur aucun des principaux sites. Votre réponse implique qu'il faut suivre la norme pertinente.Mais ce n'est qu'un document.Nous sommes libres de l'ignorer.Il y a des conséquences, mais ce n'est sûrement pas illégal, et je me demande ce qui, en pratique, pourrait mal tourner IRL si toutes les implémentations ignoraient tous les paquets de désauthentification.
@MatthewElvey, à peu près la même chose que si tous les automobilistes ignoraient les panneaux d'arrêt.Le réseau se bloquait avec des locuteurs qui parlaient et leurs paquets s'écraseraient contre des cartes qui n'écouteraient pas (l'expéditeur de deauth n'écouterait plus jamais cette conversation).
@gowenfawr Vous faites référence à [Évitement de collision] (https://en.wikipedia.org/wiki/Collision_avoidance_%28networking%29) mais les paquets de désauthentification ne sont même pas mentionnés parmi les nombreuses méthodes (planification préalable des intervalles de temps, détection de porteuseschémas, temps d'accès aléatoires et délai exponentiel après détection de collision) mentionnés ici.Je vois donc un confiture comme improbable.D'après ce que je peux dire, les paquets de désauthentification sont pour des choses comme une valeur de vérification d'intégrité de message incorrecte (MIC) est détectée, ou pour un arrêt ordonné d'un point d'accès.https://goo.gl/JBVDR7
nandoP
2014-10-06 21:04:32 UTC
view on stackexchange narkive permalink

La norme 802.11 actuelle définit les types de "trame" à utiliser dans la gestion et le contrôle des liaisons sans fil. IEEE 802.11w est la norme des cadres de gestion protégés pour la famille de normes IEEE 802.11. TGw travaille sur l'amélioration de la couche de contrôle d'accès moyen IEEE 802.11. L'objectif est d'augmenter la sécurité en assurant la confidentialité des données des trames de gestion, des mécanismes qui permettent l'intégrité des données, l'authenticité de l'origine des données et la protection contre la relecture.

==> http://en.wikipedia.org/wiki/IEEE_802.11w-2009

Il semble que la protection contre le deauth et la relecture soit déjà dans le noyau bsd / linux:

La norme 802.11w est implémentée sous Linux et BSD dans le cadre de la base de code du pilote 80211mac qui est utilisée par plusieurs interfaces de pilote sans fil, à savoir ath9k. La fonctionnalité est facilement activée dans les noyaux les plus récents et les systèmes d'exploitation Linux en utilisant ces combinaisons. Openwrt en particulier fournit une bascule facile dans le cadre de la distribution de base.

user36773
2014-01-07 22:17:29 UTC
view on stackexchange narkive permalink

Si possible, demandez à tout le monde de se connecter à un réseau filaire pendant une semaine et éteignez votre Wi-Fi. Après une semaine, rallumez-le et j'espère que l'attaquant aura abandonné d'ici là. J'essaierais également de mettre tout le monde sur liste blanche sur votre réseau afin que seules ces adresses IP puissent se connecter. Si vous pensez qu'ils vont continuer à vous attaquer quel que soit l'effort que cela va leur causer, alors je suis d'accord avec Terry, contactez les forces de l'ordre locales et laissez-les s'en occuper.

La liste blanche n'aurait aucun effet sur le type d'attaque décrit par le PO. L'attaquant usurpe l'identité L2 de l'AP ou du client et serait autorisé par l'entrée de la liste blanche. De plus, puisqu'il s'agit d'une attaque L2, les adresses IP ne sont pas utilisées.


ⓘ
Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 3.0 sous laquelle il est distribué.
Loading...