Retour sur la vidéo : Explication de KRACK Attacks – A chaud #1

Cela fait une semaine que notre première vidéo Explication de KRACK Attacks – A chaud #1 est sortie. Et pour tout vous dire nous sommes ravis !

Déjà plus plus de 450 vues !

Allez, on prend le temps de faire un premier bilan.

Vos retours

Vous avez été nombreux à nous dire ce que vous avez pensé de notre première vidéo « à chaud ».

MERCIIIII !!! <3

C’est grâce à vous que nous allons progresser.

Nous avons retenu :

« Le son de Tom n’est pas très bon »

Oui, c’est dû au micro et au fait que l’enregistrement se fait via visioconférence sur le PC de Flo.

Pour la prochaine, Tom enregistrera avec son micro cravate le son sur son PC et nous assemblerons le tout au montage.

« Même si je ne m’y connais pas, j’ai tout compris. »

Merci !! <3

Puisque c’est le but de la vulgarisation rien ne peut nous faire plus plaisir !

« C’est vous qui jouez la démo ? »

Non, nous prenons les rôles de l’utilisateur (Tom) et de l’attaquant (Flo) mais nous ne réalisons pas la démonstration. Il s’agît de la vidéo de la démonstration officielle que nous commentons.

« J’aurais aimé un peu plus de détails sur le fonctionnement du truc mais ce serait peut être moins accessible du coup ! »

C’est un peu l’idée 😉

Pour creuser le sujet, l’article publié par le chercheur est à lire : https://www.krackattacks.com

« Il y a beaucoup d’acronymes, serait-il possible d’avoir un glossaire ? »

L’informatique, comme beaucoup de métiers, est bardé d’acronymes. Et les retenir ne se fait effectivement pas du premier coup. Pour pouvoir être « à chaud », nous souhaitons conserver ce format avec le moins de montage possible. Donc pas de glossaire incrusté dans la vidéo. Dans ce format en tout cas, dans les autres vous trouverez beaucoup plus d’aides visuelles (images, schéma, textes, animations etc.).

Qu’est-ce qu’un site « bien configuré » ?

Quelques uns d’entre vous ont pris le temps de nous faire des propositions sur ce que devrait être un site bien configuré pour ne pas laisser la possibilité à l’attaquant de le délivrer en HTTP ou lieu d’HTTPs (<= le s c’est pour secure).

Voici un récap’ :

RewriteHTTPtoHTTPS ?

En somme, la solution proposée est que le serveur force le navigateur de l’utilisateur à utiliser HTTPs même si il lui demande du HTTP.

Comme l’attaquant est en Man in the Middle, SSLStrip permet de détourner le trafic HTTPs en le redirigeant vers du HTTP. Donc du point du vue du serveur, c’est bien du HTTPs et du point de vue du navigateur du HTTP.

Ça ne permet donc pas de parer l’attaque.

HTTP Strict Transport Security ?

HTTP Strict Transport Security (HSTS) est un mécanisme de politique de sécurité proposé pour HTTP, permettant à un serveur web de déclarer à un agent utilisateur (comme un navigateur web), compatible, qu’il doit interagir avec lui en utilisant une connexion sécurisée (comme HTTPS). La politique est donc communiquée à l’agent utilisateur par le serveur via la réponse HTTP, dans le champ d’en-tête nommé « Strict-Transport-Security ». La politique spécifie une période de temps durant laquelle l’agent utilisateur doit accéder au serveur uniquement de façon sécurisée.

Wikipedia FR

Ça c’est une bonne piste ! Bon par contre SSLStrip est capable de passer outre dans deux cas :

  1. C’est la première fois que le navigateur accède à ce site,
  2. La période indiquée par HSTS est dépassée.

HSTS preload ?

On reprend le concept précédent et on ajoute une autorité qui note les sites qui annoncent être délivrés en HTTPs : https://hstspreload.org/

Les navigateurs récents récupèrent constamment cette liste et ils ont donc la possibilité d’interdire à l’utilisateur un site qui ne devrait pas être en HTTP.

Ça nous semble donc être une bonne parade !

Merci beaucoup à Aurélien Labate pour nous avoir fait découvrir cela. 🙂

Et la suite ?

Et bien, cette vidéo n’étant pas prévue, ça a un peu chamboulé notre planning. Mais rien de grave : on va publier la prochaine plus tôt que prévu. 😉

Alors rendez-vous dans quelques jours pour la vidéo de présentation de notre chaîne !

KrackAttacks Quésaco ?

#KrackAttacks concerne le protocole WPA/WPA2. C’est le protocole qui sécurise les échanges en WiFi.

WPA signifie WiFi Protected Access.

En conséquence, KrackAttacks ne concerne pas la 3G, la 4G, le Bluetooth, la radio, les micro-ondes, etc.

KrackAttacks concerne tous les périphériques qui utilisent le WiFi, sous Linux, Windows, Android, MacOS, etc.

… Donc vos objets connectés : votre tablette, votre téléphone portable, votre ordinateur, votre appareil photo, votre caméra de sécurité..

… A condition qu’ils se connectent en WiFi.

Rappel : si vous protégez vos connexions en WEP (Wired Equivalent Privacy), ancêtre du WPA, votre protection est déjà très faible.

KrackAttacks ne permet pas de déchiffrer les informations qui transitent via HTTPs ou VPN.

Par contre ça permet de tenter de les contourner avec d’autres attaques, on va en parler plus bas.

La faille KrackAttacks se situe dans le mécanisme d’initialisation de la sécurisation (du chiffrement) de la connexion.

A ce moment là un utilisateur malveillant a la possibilité de se faire passer pour le point d’accès.

En d’autres termes, KrackAttacks commence par une attaque de type « Man In The Middle ».

L’attaque principale cible donc les clients (votre téléphone, votre pc, etc.)

Néanmoins certaines variantes de l’attaque peuvent aussi compromettre les points d’accès (votre box Internet, votre routeur WiFi, etc.)

Ça signifie que l’attaquant doit être à portée du WiFi. Dans votre immeuble, dans votre rue, dans la voiture garée en bas.

Une fois que l’attaquant en est arrivé là, il peut alors utiliser d’autres techniques pour récupérer vos données (login, mdp, cb, etc.)

Il en existe plein, @Micode en présente une dans une de ses vidéos : https://www.youtube.com/watch?v=pqA5nWenxuE

Que devez-vous faire pour vous prémunir de KrackAttacks ? Faites vos MàJ régulièrement !

D’après les chercheurs derrière cette découverte, c’est corrigeable et la plupart des éditeurs est déjà au courant depuis fin août.

Utilisez https://www.eff.org/https-everywhere pour forcer l’utilisation d’HTTPs.

Vous pouvez aussi vous brancher en filaire, pas de soucis de ce côté là.

Et voilà, fin du thread ! Si on a fait une erreur, si vous avez des questions, dites-le nous 😉

Bonus : vous pouvez trouver tous les détails et une démonstration de l’attaque sur https://www.krackattacks.com/

Édit : Nous avons pris le temps de faire un retour sur cette première vidéo dans lequel on revient sur les critiques constructives que nous avons reçues.


Sources :