Modérateurs : Diamond, watch, Barbapapa
tntuner a écrit :... en attendant de tout patcher.
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.
+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.
+
Merci.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.
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.
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.
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.
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.
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.
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
Retour vers Discussion générale
Utilisateur(s) parcourant ce forum : Aucun utilisateur inscrit