KRACK : faille du Wi-Fi WPA2, quels appareils sont touchés ? Comment se protéger ?

C'est bien pire que ce que décrit l'article, car ce qui a été démontré c'est que c'est un type de vulnérabilité qui touche la quasi totalité des implémentations de protocoles d'authentificaton en 4 messages (2 échanges) et quel que soit la sécurité ou la qualité les clés de cryptage utilisées et l'attaque n'est pas non plus une vulnérabiltié des mots de passes ou clés de sécurité elles-mêmes. C'est le système d'authentification qui peut être déjoué. L'auteur dit déjà que WP2 est affecté mais en fait WPA aussi, et WEP, et quelque soit le cryptage (TKIP, AES). Cela va plus loin car ça concerne aussi l'authentification en 4 messages entre n'importe quel couple de systèmes. Cela ne concerne donc pas non plus que le Wifi, mais aussi d'autres comme BlueTooth, les authentifications entre routeurs et passerelles, et entre services internet les plus divers qui utilisent massivement l'authentification en 4 messages qui était réputé et mathématiquement prouvé comme "sûr" mais uniquement concernant la sécurité des clés échangées, mais pas concernant la possibilité de rejouer de façon illimitée la séquence d'authentification sur plus que 4 messages pour forcer la réinitialisation des clés de cryptage. En fait une papier indiquait qu'une fois une clé à usage unique envoyée dans le 3e message, il fallait l'effacer pour ne pas la garder en mémoire. Les implémentations se sont donc contentées de remettre cette mémoire à zéro, mais rien n'empêchait de répéter le 2e message pour forcer à nouveau l'envoi du 3e message contenant la clé nulle et donc de pouvoir ensuite y répondre avec succès avec le 4e message. L'authentification est donc corrompue sans même avoir eu connaissance des mots de passe sensés protéger l'accès, l'accès est authorisé et approuvé en ayant forcé l'utilisation d'une clé nulle. La conséquence c'est toute une série de failles nouvelles dans de nombreux protocoles, et les premier trouvés utilisant ce mécanisme concernaient l'authentification (l'autorisation d'appairage entre appareils). On doit s'attendre aussi à des failles comparables exploitables à distance pour BlueTooth, USB Wireless, l'établissement de VPNs, toute une série de protocoles d'échanges de clé de cryptage (dont Diffie Helman), l'authentifiaction entre routeurs internet sur les backbones, l'authentificaton pour la téléphonie mobile, pour l'accès aux réseaux sociaux, pour les gestionnaires de mot de passe, les systèmes d'archivage à distance, les accès aux clouds privés. Je pense qu'on n'a pas fini de voir toute une série de patches puis de révélation de nouveaux protocoles affectés et déjà la liste des contructeurs et des OS est considérable. On peut être déjà certain que parmi les nombreux protocoles réseau et OS affectés par cette faille dans le système d'échange, un grand nombre sont déjà exploités pour cibler des points précis mais critiques de tout un tas d'architectures réseaux et que la NSA a déjà exploité la faille du système d'échange à 4 messages (et a même pu être à l'origine de celle-ci sous couvert d'une recommandation discrète supposée renforcer le mécanisme, mais qui en fait n'a fait que le rendre extrèmemement fragile et exploitable facilement, et masquer des conditions dans le papier de recherche qui montrait que ce système était "mathématiquement sûr"). KRACK est une catrastrophe, la pire jamais vue et peut être dévastatrice pour tous les réseaux et tous les systèmes. On n'en a pas encore vu toute l'étendue malgré les premières évaluations publiées puisqu'elle casse l'immense majorité des systèmes d'authentification automatique avant même que ceux-ci puissent s'échanger des clés de sécurité et les vérifier. KRACK révèle donc qu'on n'a pas besoin des clés pour les serrures, mais que le système à 4 messages lui-même a été mis en place en même temps qu'une deuxième serrure toujours ouverte (et pour n'importe qui). Le système d'échange de clés est donc lui-même un backdoor, mais il a été largement promu et recommandé au point d'être devenu universel et mis en oeuvre de façon similaire pour un grand nombre de protocoles qui ont suivi à la lettre le document de recommandation de ce système sans se poser de question. A est l'attaquant le cas normal c'est: * message1: A->B (demande d'accès avec nonce choisi par A) * message2: B->A (challenge répondu par B utilisant le nonce de A et incluant un nonce "unique" choisi par B) * message3: A->B (envoi de clé cryptée avec le nonce "unique" choisi par B et le premier nonce de A) * message4: B->A (vérification avec les deux nonce, et confirmation de l'authentification) ici le message3 est répétable mais lors de l'envoi du message2, le nonce "unique" choisi par B a été effacé et perdu mais le messsage2 peut être réenvoyé (et il le sera car les protocoles supposent qu'un paquet peut avoir été non reçu et on peut forcer ce renvoi en provoquant une erreur) mais le message2 sera réémis avec un non nul ou réinitialisé à sa valeur initiale et non plus le nonce unique qui a déjà été effacé. Il suffit de forcer le message 2 a être répété et c'est ultra facile, le message3 sera emis en tenant compte de ce message2 répété mais de contenu désormais connu puisque ne contenant plus le nonce unique mais toujours le même connu. La faille est qu'il n'aurait jamais fallu "effacer" un nonce unique déjà utilisé mais le remplacer par un autre nonce unique, et ne pas permettre de réutiliser le message2 trop souvent (là les protocoles sont corrects qu'ils ils n'autorisent que 3 répétitions et sinon font échouer l'authentification puis ralentir toute nouvelle demande d'authentification par un nouveau message1 venant d'un attaquant). La faille est sur les conditions permettant de valider le message3: cela s'appuie sur le dernier état connu des nonces et non le nonce utilisé la premièrer fois. Les mots de passe et clés de cryptage sont échangées par les messages 2 et 3 puis confirmés de façon "mathématiquement sûre" par le message 4, mais la faille se situe avant, sur le message 3 sans que les clé de cryptage et de signature n'aient encore être certifiées comme correcte.

le contenu du VPN est protégé oui mais pas les appareils aux extrémités s'ils ont des adaptateurs WiFi vulnérables (et notamment les smartphones et nombreux petits appareils Wifi domestiques qu'on a appairé à notre réseau local) Et comme à chaque fois le point faible c'est trop souvent le smartphone qui n'a pas les mises à jour du système (parce que les constructeurs se fichent totalement de garder les firmwares ouverts et vont même maintenant jusqu'à empêcher d'installer des firmwares libres alternatifs, en interdisant le root ou en empêchant de booter sur une image OS alternative qu'ils n'ont pas eux-même compilée et signée et en refusant tout support 6 mois après la fin de vente d'un modèle, histoire de nous obliger sans arrêt à racheter un de leurs trop coûteux appareils). Ceci dit on peut modérer les attaques possibles: on n'est pas obligé de garder le wifi actif partout sur son smartphone, et chez soi les attaques sont malgré tout limité à un voisinage restreint. On devrait cependant pouvoir disposer d'un outil sur PC permettant de détecter des attaques Wifi provenant de voisinages infectés (si son PC a un adaptateur Wifi, ce qui n'est pas toujours le cas quand on est connecté en CPL ou Ethernet, et que le Wifi reste dans la Box dont on n'a pas accès au contenu du firmware et pas moyen d'en faire un réel audit). Les principales attaques concerneront toutefois les hotspots Wifi publics: si sa box émet un hotspot "public", on a intérêt à le couper pour ne garder que la connexion privée et aussi supprimer la diffusion du SSID pour limiter sa détection par des tiers. Mais la box peut être le point faible d'entrée dans le réseau local: un logiciel parefeu local sur chaque PC local s'impose d'onc comme un minimum, de même que la sécurisation et le cryptage des protocoles de partage de fichiers sur le réseau local en cas d'intrusion (désactiver les vieux protocoles mal protégés comme SMB1 sur Windows, augmenter la sécurité avec des clés d'authentification plus longues, sinon on risque de se faire piquer ses données personnelles ou de les voir corrompues et infectées de malwares ou pire encore avec les ransomwares qui pourraient s'installer sur les logiciels qu'on utilise dans nos partages de fichier sur le réseau local, y compris le partage de fichier administratif "C$" activé par défaut sur Windows ou les protocoles de prise de contrôle à distance, ou de registre à distance)

Il est trop deg pour répondre x)

@gUI a tout dit.

Leur tweet dans l'article

Depuis le 16 octobre, tous les LineageOS qui feront une mise à jour seront protégé contre cette faille. https://github.com/LineageOS/android_external_wpa_supplicant_8/commits/cm-14.1 On est le 18 octobre, t'as beau avoir un Pixel, t'as toujours pas reçu le fix.

En principe oui, un VPN ou une connexion en HTTPS devrait protéger le transfert d'information. Il vaudrait mieux se protéger de cette faille toutefois et ne pas prendre de risque.

Bien entendu, mais j'avais mal compris ton commentaire.. Cependant faut bien que l'émetteur et le récepteur soit patché et ça c'est pas gagné. Les Box en fonction des FAI on toutes le même firmware en fonction de leur modèle.. Ils ont juste à déployé un firmware sur leurs modele. Mais un smartphone, plus tôt les smartphones sous Android c'est n'importe quoi.. D'abord le correctif de Google ok, qui lui sera modifié par les constructeurs pour leur téléphone, qui lui même sera modifié par les opérateurs pour leur surcouche.. Un processus qui prendra beaucoup mais beaucoup de temps et vu le marché des smartphone ça fait beaucoup d'appareil vulnérable Trop de fragmention.. Apple(déjà fait d'après les dire), Microsoft (maj déjà déployé). Pour les FAI (Orange, Bouygues, SFR) bah c'est eux même qui tardent à sortir leurs surcouche patché sur Android, donc faut même plus s'étonner.. Bouygues grand champion en la matière?

Si on utilise un VPN, est-ce que l'on est protégé ? Pour ce qui est des terminaux Android qui vont recevoir la mise à jour de sécurité rapidement, il ne faut pas rêver, ils seront sans doute très peu nombreux, et certains ne la recevront jamais.

Si on utilise un VPN, est-ce que l'on est protégé ? Pour ce qui est des terminaux Android qui vont recevoir la mise à jour de sécurité rapidement, il ne faut pas rêver, ils seront sans doute très peu nombreux, et certains ne la recevront jamais.

Je venais juste lire les commentaires pour voir ceux d'Atlas et d'iAndroid. Tout se perd, je suis déçu.

LineageOS qui est en avance sur Google quand même.

me demande si le xiaomi a1 aura le patch c qd même dommage que les patchs de sécurité puisse pas etre installé et récupéré par les utilisateurs...c pas des majs de roms ou de firmwares

ressortez vos cables reseaux @home pour les appareils wifi c pas glop on a la ref du patch Windows 7?

Je parle de ces FAI pour leurs box la ou l'article parle de ça... Free est déjà à jour sur ses box, orange a répondu qu'il se penchait dessus et SFR / Bouygues sont à la traîne et sans réponse !

A titre d'exemple, sur les S7 les dernières MAJ sont : Orange : 1 Septembre 2017 SFR : 1 Aout 2017 Bouygues : 1 Mai 2017

LineageOS aussi ça a du bon :)

Toujours Bouygues et SFR à la traîne...