Daily RSS Feed
The Daily Shaarli
Despite the different ways of handling MAC address randomization in each OS, researchers said devices answered with specific packets (control frames) when they performed a specific request.
The novelty in our method is that we are sending RTS frames to IEEE 802.11 client devices, not APs, to extract a CTS response message which we derive the true global MAC address of that device.
The result of sending a RTS frame to the global MAC address of a device performing randomization was that the target device responded with a CTS frame. A CTS frame, having no source MAC address, is confirmed as a response to our attack based on the fact that it was sent to the original, crafted source MAC address
Once the global MAC address is known, that device can be easily tracked just as if randomization were never enabled.
To protect against attacks on MAC address randomization, researchers recommend a stricter policies when handling MAC address randomization operations.
[…] Ils ont étudié cette interception des deux côtés : en observant le trafic chez certains serveurs Web, et en étudiant certaines des boîtes noires qui font cette interception. Côté serveur, pour voir si le trafic est intercepté, ils regardaient surtout s'il y avait une différence entre le User-Agent: HTTP (RFC 7231, section 5.5.3) annoncé et les paramètres TLS. Si un navigateur se présente comme étant Firefox mais annonce l'extension « battement de cœur » du RFC 6520, on est sûr qu'il s'agit d'une interception : Firefox n'a jamais mis en œuvre cette extension. Des tas d'autres heuristiques peuvent être utilisées, comme l'ordre des extensions TLS dans le ClientHello du client.
Leur étude montre que plus de 10 % des sessions HTTPS vers Cloudflare (6 % pour des sites divers de commerce en ligne) sont interceptées, ce qui est assez inquiétant.
Mais il y a bien pire : le système d'interception, on l'a vu, termine la session TLS et en commence une autre avec le serveur. Ce faisant, la totalité des systèmes testés font d'énormes erreurs TLS : ils annoncent des algorithmes de chiffrement abandonnés (RC4, cf. RFC 7465), ou qui n'auraient jamais dû être utilisées (les algorithmes « exportation », délibérement affaiblis), acceptent des certificats expirés, et, parfois, ils ne valident même pas le certificat du serveur ! Ils sont en outre vulnérables à plusieurs attaques TLS connues. Cela est dû au fait que ces boîtes noires utilisent des versions anciennes de bibliothèques TLS, et qu'elles ne les configurent pas proprement. (Ce problème avait déjà été démontré avec les anti-virus.)
NOPE, NOPE, NOPE, NOPE ! On ne désactive pas DNSSEC au moindre problème ! C'est aussi idiot que d'accepter n'importe quel certificat x509 à l'aveugle ou d'enlever la capote avec un-e inconnu-e au motif que "ça gène un peu" ! DNSSEC sera déployé et il faudra faire avec, apprendre le fonctionnement du DNS en sa présence, apprendre à debug en sa présence !
1) Vérifier qu'unbound-anchor est installé. C'est lui qui se charge de créer le fichier root.key (qui contient la clé de signature de la racine DNS, pas la clé du récursif à qui l'on foward) quand la méthode purement DNS normalisée dans le RFC 5011, que le démon unbound applique quand il est configuré avec auto-trust-anchor-file, a échoué (ordi éteint trop longtemps au moment du roulement des clés de la racine, par exemple).
2) Exécuter : sudo unbound-anchor -a /var/lib/unbound/root.key puis redémarrer Unbound (pas obligatoire mais pour être sûr). Ça forcera la génération du fichier. Unbound-anchor est livré avec le matos pour vérifier cryptographiquement que la clé récupérée est la bonne.
3) Comprendre pourquoi le fichier /var/lib/unbound/root.key a disparu ou n'est plus à jour… Parce que la clé de la racine n'a pas changé récemment (et ça n'arrivera pas avant juillet-octobre 2017). Je n'ai pas eu de problème avec la dernière màj Debian de Linux.
