ADSL-BC

Si j'en crois l'article, ça craint et je pense qu'on a pas fini d'en parler. Et c'est une équipe principalement belge qui va en faire l'annonce.

https://arstechnica.com/information-tec ... sdropping/

Voilà, c'est public depuis peu:
https://www.krackattacks.com/

Le gros problème c'est qu'il ne s'agit pas d'une faille d'implémentation mais bien de conception, de design du protocole. Ça promet.

Merde, même l'entreprise est concerné ...

Bon reste plus qu'a couper le wifi

... en attendant de tout patcher.

tntuner a écrit :... en attendant de tout patcher.

... ou de n'utiliser que des protocoles chiffrés https, ssh, vpn et autres. Parce-que patcher des centaines de millions d'appareils WiFi, la plupart aux mains d'utilisateurs que ne mettent jamais leur firmware à jour, ça ne va pas se faire du jour au lendemain. Sans doute même jamais. Comment s'assurer, lorsqu'on est connecté en WiFi quelque part que l'AP a été "patché"? Ensuite peut-on même "patcher" un protocole mal conçu sans le dénaturer? Il ne s'agit pas d'une erreur dans un programme mais bien une erreur de conception d'un protocole implémenté par des centaines de fabricants. Ça craint vraiment ce truc.

Les constructeurs "entreprise-grade" ont déjà mis des patch à disposition (Cisco, Juniper, Aruba, Ubiquiti, Mikrotik etc...)

Je sais qu'il y a d'autres utilisateurs Ubiquiti sur ce forum, voici le lien vers le firmware 3.9.3.7537 patché.

Pour mikrotik: la dernière version 6.40.4 est patchée.

À quand une évolution de la norme de chiffrement WIFI???

Je ne sais pas si cela a quelque chose à voir, mais sur dd-dwrt il y a un patch daté de 7 septembre 2017, alors que la version précédente n'avait plus évoluée depuis 2012.

csam a écrit :Je ne sais pas si cela a quelque chose à voir, mais sur dd-dwrt il y a un patch daté de 7 septembre 2017, alors que la version précédente n'avait plus évoluée depuis 2012.

Je ne pense pas. La communauté Open Source a patché hostapd hier seulement. Il te faudra donc télécharger les sources, patcher hostapd et faire un cross-compile. Liens pour les patch:
LEDE/OpenWrt: https://git.lede-project.org/?p=source. ... ec2e82a9a5
DD-Wrt: http://svn.dd-wrt.com/changeset/33525

.. ou bien attendre que les patches trouvent le chemin des précompilés!

Edit:
Je viens de jeter un coup d'oeil dans le patch de LEDE/Open-Wrt et c'est Mathy Vanhoef, un des deux chercheurs belges qui ont découvert la faille, qui a aussi écrit le patch.

Code : Tout sélectionner

+From: Mathy Vanhoef <[email protected]>
+Date: Fri, 29 Sep 2017 04:22:51 +0200
+Subject: [PATCH] Prevent installation of an all-zero TK
+
+Properly track whether a PTK has already been installed to the driver
+and the TK part cleared from memory. This prevents an attacker from
+trying to trick the client into installing an all-zero TK.
+

Les dernières sources de LEDE 17.01.3 sont déjà patchées. Je viens de vérifier après avoir mis à jour les sources LEDE de mon environnement de cross-compilation. Pas besoin de patcher, il suffit de mettre les sources à jour et de recompiler.

Sur Linux Mint j'ai eu un update WPA hier. Peut-être dû à ce problème.

esperlu a écrit :

csam a écrit :Je ne sais pas si cela a quelque chose à voir, mais sur dd-dwrt il y a un patch daté de 7 septembre 2017, alors que la version précédente n'avait plus évoluée depuis 2012.

Je ne pense pas. La communauté Open Source a patché hostapd hier seulement. Il te faudra donc télécharger les sources, patcher hostapd et faire un cross-compile. Liens pour les patch:
LEDE/OpenWrt: https://git.lede-project.org/?p=source. ... ec2e82a9a5
DD-Wrt: http://svn.dd-wrt.com/changeset/33525

.. ou bien attendre que les patches trouvent le chemin des précompilés!

Edit:
Je viens de jeter un coup d'oeil dans le patch de LEDE/Open-Wrt et c'est Mathy Vanhoef, un des deux chercheurs belges qui ont découvert la faille, qui a aussi écrit le patch.

Code : Tout sélectionner

+From: Mathy Vanhoef <[email protected]>
+Date: Fri, 29 Sep 2017 04:22:51 +0200
+Subject: [PATCH] Prevent installation of an all-zero TK
+
+Properly track whether a PTK has already been installed to the driver
+and the TK part cleared from memory. This prevents an attacker from
+trying to trick the client into installing an all-zero TK.
+

Les dernières sources de LEDE 17.01.3 sont déjà patchées. Je viens de vérifier après avoir mis à jour les sources LEDE de mon environnement de cross-compilation. Pas besoin de patcher, il suffit de mettre les sources à jour et de recompiler.

Merci.

CS

Je confirme qu'il y a bien un patch pour Ubuntu et tous ses dérivés.

Microsoft a publié un patch KB4041676 le 10 octobre (incluant beaucoup d'autres choses) pour Windows 10.
https://support.microsoft.com/en-us/hel ... -kb4041676

Ubuntu est ses variantes ainsi que Fedora sont patchés également.

Ce qu'il faut retenir, c'est qu'il n'est pas nécessaire que les deux bouts de la liaison soient patchés. Aussi, la mise à jour des routeurs n'est pas indispensable.
Pour les répéteurs, c'est différent puisqu'ils sont à la fois émetteurs et récepteurs.

Debian a patché wpasupplicant le 14 octobre.

Code : Tout sélectionner

wpa (2:2.4-1+deb9u1) stretch-security; urgency=high
  * Non-maintainer upload by the Security Team.
  * Fix multiple issues in WPA protocol (CVE-2017-13077, CVE-2017-13078,
    CVE-2017-13079, CVE-2017-13080, CVE-2017-13081, CVE-2017-13082,
    CVE-2017-13086, CVE-2017-13087, CVE-2017-13088):
...
Yves-Alexis Perez <[email protected]>  Sat, 14 Oct 2017 14:18:32 +0200


patrix a écrit :Ce qu'il faut retenir, c'est qu'il n'est pas nécessaire que les deux bouts de la liaison soient patchés. Aussi, la mise à jour des routeurs n'est pas indispensable.
Pour les répéteurs, c'est différent puisqu'ils sont à la fois émetteurs et récepteurs.

D'accord. Mais qu'en est-il alors des milliers de smartphones qui tournent encore sous Android 4 ou supérieur et qui ne sont plus mis à jour?
Il vaut mieux patcher les routeurs tout de même, ceux-ci étant le centre de l'étoile d'un LAN.

tntuner a écrit :

patrix a écrit :Ce qu'il faut retenir, c'est qu'il n'est pas nécessaire que les deux bouts de la liaison soient patchés. Aussi, la mise à jour des routeurs n'est pas indispensable.
Pour les répéteurs, c'est différent puisqu'ils sont à la fois émetteurs et récepteurs.

D'accord. Mais qu'en est-il alors des milliers de smartphones qui tournent encore sous Android 4 ou supérieur et qui ne sont plus mis à jour?
Il vaut mieux patcher les routeurs tout de même, ceux-ci étant le centre de l'étoile d'un LAN.

C'est une attaque principalement client-side. Même avec ton AP patché, si ton smartphone ne l'est pas, tu es vulnérable.

https://avm.de/index.php?id=33369
Pour info, les Fritz!Box en elles-même ne sont pas impactées par la faille.
Néanmoins, AVM prévoit des mises à jour pour ses répéteurs.

SohKa a écrit :C'est une attaque principalement client-side. Même avec ton AP patché, si ton smartphone ne l'est pas, tu es vulnérable.

Ce n'est pas tout à fait ce que les chercheurs qui ont mis la faille au jour écrivent:

No, luckily implementations can be patched in a backwards-compatible manner. This means a patched client can still communicate with an unpatched access point (AP), and vice versa. In other words, a patched client or access point sends exactly the same handshake messages as before, and at exactly the same moment in time. However, the security updates will assure a key is only installed once, preventing our attack. So again, update all your devices once security updates are available. Finally, although an unpatched client can still connect to a patched AP, and vice versa, both the client and AP must be patched to defend against all attacks!

https://www.krackattacks.com/#faq

patrix a écrit :https://avm.de/index.php?id=33369
Pour info, les Fritz!Box en elles-même ne sont pas impactées par la faille.
Néanmoins, AVM prévoit des mises à jour pour ses répéteurs.

Pas sûr. Si AVM a correctement implémenté les spécifications du protocole WPA2, ils sont exposés et doivent patcher. D'autant que, si j'en crois l'article que tu as mis en lien, il n'auraient été informés de la faille que hier, le 16 octobre. Ils critiquent par ailleurs les chercheurs de ne pas avoir appliqué la Responsible Disclosure Procedure ce qui n'est pas exact. Les chercheurs ont tout d'abord contacté les fabricants dont ils ont testé les AP dès le 14 juillet. Devant l'ampleur de la faille ils ont alors chargé le CERT/CC de contacter l'ensemble des acteurs (AP et Clients) le 28 août. Il est assez étrange qu'AVM n'ait pas été mis au courant.

When did you first notify vendors about the vulnerability?

We sent out notifications to vendors whose products we tested ourselves around 14 July 2017. After communicating with these vendors, we realized how widespread the weaknesses we discovered are (only then did I truly convince myself it was indeed a protocol weaknesses and not a set of implementation bugs). At that point, we decided to let CERT/CC help with the disclosure of the vulnerabilities. In turn, CERT/CC sent out a broad notification to vendors on 28 August 2017.

esperlu a écrit :Voilà, c'est public depuis peu:
https://www.krackattacks.com/

Le gros problème c'est qu'il ne s'agit pas d'une faille d'implémentation mais bien de conception, de design du protocole. Ça promet.

Hello,
j'ai rien compris mais j'adore.. respect aux gars .

esperlu a écrit :

SohKa a écrit :C'est une attaque principalement client-side. Même avec ton AP patché, si ton smartphone ne l'est pas, tu es vulnérable.

Ce n'est pas tout à fait ce que les chercheurs qui ont mis la faille au jour écrivent:

No, luckily implementations can be patched in a backwards-compatible manner. This means a patched client can still communicate with an unpatched access point (AP), and vice versa. In other words, a patched client or access point sends exactly the same handshake messages as before, and at exactly the same moment in time. However, the security updates will assure a key is only installed once, preventing our attack. So again, update all your devices once security updates are available. Finally, although an unpatched client can still connect to a patched AP, and vice versa, both the client and AP must be patched to defend against all attacks!

https://www.krackattacks.com/#faq

C'est marrant parce que avec la phrase "both the client and AP must be patched to defend against all attacks", moi, je lis une confirmation de mon précédent message. Ta citation ne fait qu'expliquer que le patch ne crée pas d'incompatibilité opérationnelle après la mise à jour du protocole.

Il faut patcher les clients ET l'AP. Il y a plusieurs attaques, mais celle qui fait particulièrement flipper, c'est celle où l'attaquant fait un MitM et se fait passer pour l'AP auprès du client. Pour réaliser celle-là, peu importe que l'AP soit patché ou pas.