#2 — Dragon blood is still leaking 🇫🇷

Une discussion avec Mohamed Sabt, chercheur en cybersécurité.

Écouter l’épisode

Transcription

Teaser

Mohamed: Notre attaque s’arrête quand on arrive à récupérer suffisamment d’informations pour pouvoir lancer une attaque dictionnaire hors ligne.

Il ne faut pas que le programme qui manipule des données sensibles ait son comportement qui dépende de la valeur du secret.

Intro

François: Bonjour à toutes et à tous et bienvenue dans Post mortem. Je m’appelle François et je serai votre hôte pour ce podcast. Dans Post-mortem, on revient sur des incidents de production, que ce soit des bugs, des cyberattaques ou des projets qui ne se passent pas comme prévu. On essaie de comprendre ce qui s’est passé. Pour cela, j’aurai à mon micro des ingénieurs, des chercheurs qui reviendront sur un événement spécifique qu’ils ou elles ont vécu.

On essaiera de comprendre ce qui s’est passé, ce qu’ils ont mis en place pour essayer d’atténuer les conséquences de cet événement. Et enfin, ils nous partageront les bonnes pratiques pour éviter que ça ne se reproduise.

Aujourd’hui, j’ai la chance de recevoir un docteur et chercheur en cyber sécurité, Mohammed Sabt. Bonjour Mohamed.

Mohamed: Bonjour.

François: Mohamed, vous allez bientôt publier un papier dans lequel vous révélez une attaque sur le protocole Wi-Fi, WPA3. Avant de rentrer dans les détails de ce papier, est-ce que vous pouvez nous parler un peu de vous, de votre équipe et de vos sujets de recherche ?

Mohamed: Tout d’abord, je me présente, je m’appelle, Mohamed Sabt, je suis un maître de conférences à l’université de Rennes 1. J’enseigne la cyber sécurité au sein de Cyber School, qui est une école universitaire de recherche et je suis responsable d’un master international s’appelle l’EIT Digital, aussi dans le domaine de la cyber sécurité.

Actuellement, je travaille dans l’équipe de recherche qui s’appelle EMSEC, dans le laboratoire IRISA à Rennes. On travaille sur des sujets variés. C’est ce qui fait la force de mon équipe. Ça va des sujets très théoriques, sur ce qu’on appelle le chiffrement à base des réseaux euclidiens, ce qu’on appelle le chiffrement quantique, l'analyse formelle des protocoles, les attaques sur les caches, des primitives de sécurité, de cryptanalyse, ce qu’on appelle le chiffrement symétrique et d’autres propriétés de privacy sur des protocoles.

C’est vraiment un spectre assez large dans le domaine de la cyber sécurité. Et moi-même, je travaille sur la sécurité des implémentations. Que ça soit à la fois dans des protocoles de sécurité et aussi dans les smartphones, dans des composants matériels, donc à la fois les cartes à puce et aussi ce qu’on appelle aujourd’hui la trace de zone ou le TEE, de l’anglais, Trusted Execution Environment.

Le sujet de cette attaque s’inscrit dans le cadre de mes recherches concernant la sécurité des protocoles qui sont destinés ou actuellement utilisés dans l’industrie.

Acte 1 — Le contexte de l'attaque

François: Ça marche, merci pour cette introduction, donc au sujet de ce que vous avez rédigé, papier qui sera publié en décembre prochain et qui s’intitule Dragonblood is Still Leaking: Practical Cache-based Side-Channel in the Wild. Je pense que l’on aura l’occasion, au cours de notre discussion, de venir définir ces différents termes Dragonblood, Cache-based et Side-Channel. Puisque ça peut paraître un peu intimidant à première vue, ces mots clés.

Avant de zoomer sur le cœur de cette faille est-ce que vous pouvez nous présenter un petit peu le contexte de cette attaque ?

Mohamed: Bien Sûr. Tout d’abord, j’aimerais bien remercier mes co-auteurs ; mon doctorant Daniel de Almeida Braga et Pierre-Alain Fouque, mon collègue de l’équipe et moi-même. Nous sommes trois co-auteurs de ce papier. C’est un travail qui a commencé au mois de mars (2020) et qui concerne l’étude et l’analyse de sécurité. Ici, quand je dis analyse de sécurité, c’est au niveau de l’implémentation d’un protocole utilisé ou qui sera destiné à être utilisé dans le monde Wi-Fi. Donc WPA-3, c’est un membre de la famille WPA qui veut dire WiFi Protected Access et c’est la version trois de ces protocoles. Donc dire qu'il y a WPA-3, c’est aussi dire qu’il y a version 2, WPA2 et WPA1.

François: D’accord. D’ailleurs à ce sujet ; Est-ce que vous pouvez nous parler un peu de ces différentes versions WPA1, WPA2 et WPA3 ? Qu’est-ce que chacune de ces versions apporte par rapport à la précédente ?

Mohamed: Bien sûr, on va commencer par WPA2 parce que c’est aujourd’hui le système le plus utilisé. Dans cette famille de protocoles, ils ont tous le même objectif; A savoir protéger les communications entre votre ordinateur et l’Access Point, la borne Wi-Fi, parce que tout le monde peut écouter les communications Wi-Fi et il faut les protéger.

Protéger, c’est ajouter une couche cryptographique. Chiffrement, donc protection de la confidentialité de données et protection de l’intégrité. Mais pour faire ça, on a besoin d’échanger quelques clés secrètes, ce qu’on appelle les clés de session qui sont utilisées par la suite à chiffrer votre communication à un instant T entre votre ordinateur et l’Access Point. Cette phase s’appelle le Handshake et donc en fait une différence principale entre WPA2 et WPA3. C’est dans cette phase de Handshake, une différence notable qui a été ajoutée pour améliorer la sécurité. C’est que dans WPA-3, on va utiliser ce qu’on appelle les PAKE pour Password Authentification Key Exchange qui va utiliser un mot de passe, donc quelque chose qui peut être assez simple finalement, par rapport à une clé cryptographique qui est plutôt aléatoire. Un mot de passe, c’est moins aléatoire qu’une clé. Pour une clé de chiffrement, on attend des propriétés importantes au niveau de l’aléa, de l’entropie et donc WPA-3, on va réussir à transformer des mots de passe dans des clés à forte entropie, quelque chose qui n’existe pas dans WPA-2. Et donc, ce point-là, très fort de WPA-3, quand WPA-3 était défini fin 2018. Ce qu’on appelle le WiFi Alliance a annoncé le début de déploiement de WPA-3.

Ça a été un point qui était soulevé dans les médias comme très positif; Maintenant, WPA-3 va utiliser les PAKEs. Le PAKE implémentait, ce qu’on appelle le Dragonfly, et c’est cette entité importante de WPA-3 qu’on a attaqué dans le papier En fait, le déploiement ou l’annonce de WPA-3 était un peu accélérée par des attaques qui sont sorties contre WPA-2. Qui s’appellent KRACK qui permettent de casser la sécurité de WPA-2 et donc WPA-3 était défini pour résister contre ce genre d’attaques qui était défini récemment contre WPA-2.

François: En résumé, pour comparer WPA-2 et WPA-3, l’initiative derrière WPA-3 est d’avoir des standards de sécurité plus élevés vis à vis des attaques type KRACKs que vous avez mentionné.

Puisqu’en fait, tout ordinateur ou téléphone équipé de fonctionnalités Wi-Fi évoluait selon ces protocoles et était sensible à ces attaques KRACKs. C’est bien ça ?

Mohamed: Ils étaient vulnérables, quand l'attaque fut publiée, il y avait déjà le patch de disponible pour résister contre ce genre d’attaques. Mais fondamentalement, il y avait quelque chose dans WPA-2, qui permettait de faire ce qu’on appelle des attaques dictionnaire hors ligne qui permettent de récupérer le mot de passe de l’utilisateur sans être obligé de se connecter et de faire la communication avec le point d’accès.

François: Vous avez parlé d’attaques dictionnaires et d’attaques hors ligne. Est-ce que vous pouvez nous définir ce qu’est une attaque dictionnaire et une attaque hors ligne ? C’est à dire il y en a des “en ligne”, c’est ça la différence ?

Mohamed: Quand vous utilisez un mot de passe, un mot de passe azerty, par exemple, bien sûr, je ne vous conseille absolument pas d’utiliser ce genre de mot de passe. La première attaque triviale, c’est d’essayer, mot de passe par mot de passe.

Prenons votre compte Google, par exemple. L’attaque la plus simple, c’est ; Je vais sur la page d’authentification Google. Je connais par exemple votre adresse Gmail et là, j’essaye mot de passe par mot de passe. Ici, c’est une attaque en ligne. Parce que je dois être en communication avec le Service Provider. Et c’est le Service Provider qui va vérifier l’authenticité du mot de passe et dire si c’est un bon ou un mauvais mot de passe. Il y a une solution simple contre ce genre d’attaques. C’est qu'au bout de 5 ou 10 tentatives, on va un peu verrouiller le système. On va faire attendre l’attaquant, etc. Donc c’est assez simple en faite de protéger contre ce genre d’attaques. Normalement, les services providers, tous aujourd’hui, fournissent ce genre de contre-mesures.

Une attaque qui devient intéressante quand je peux vérifier votre mot de passe sans communiquer avec votre fournisseur de services. Et là, le nombre de tentatives n’est pas limité. En fait, je peux essayer autant de mots de passe que je le souhaite. Ça c’est pour la partie en ligne et hors ligne.

Pour la partie dictionnaire; Comme je l'ai dit,un mot de passe, c’est un élément finalement peu aléatoire. on dit qu'il est de faible entropie. Quand on définit nos mots de passe nous-mêmes, on va utiliser des patterns qui se ressemblent. Par exemple, le fait de dire azerty ou des mots de passes qui commencent par 1, 2, 3 etc.

Donc, il existe aujourd’hui des dictionnaires qui recensent les mots de passe le les plus fréquent où les patterns les plus probables. Il y a des logiciels qui exploitent ces dictionnaires pour lancer des attaques contre des mots de passe. Bien sûr, hors ligne ici. Pour pouvoir combiner des patterns, anticiper les patterns les plus utilisés, les plus fréquents jusqu’à ce qu’on arrive à match. Et là, on dit bingo, on a réussi à deviner le mot de passe.

Acte 2— L'attaque

François: Maintenant qu’on a présenté le contexte et ces différents standards WPA-2 et l’arrivée de WPA-3 depuis 2018 maintenant. Est-ce que vous pouvez nous parler un peu de l’attaque que vous avez découvert ?

Mohamed: Bien sûr. L’attaque, concerne cette étape de handshake. C’est vraiment ce moment primordial. On va échanger quelques informations sur les configurations, sur les communications à suivre et on va vérifier le mot de passe. Donc on va faire la partie authentification et on va générer durant l’authentification la clé qui va permettre de protéger la sécurité.

François: Quand est-ce que se passe un handshake? C’est à dire, là je suis avec mon téléphone, chez moi. À chaque fois que je désactive-réactive le Wi-Fi, il y a ce processus de handshake de serrage de mains, si je puis dire, qui se passe? Ou c’est lorsqu’on veut enregistrer un appareil sur un nouveau réseau sur lequel il n’a jamais été enregistré? Comment est-ce que ça se passe, à quelle fréquence ce processus a lieu ?

Mohamed: En fait, c'est à chaque connexion. Comme vous l'avez dit, c’est plutôt la première option, si je me permets, à chaque fois que vous initiez des communications avec la borne Wi-Fi.

Ce n’est pas dans l’étape d’enregistrement. L’étape d’enregistrement, c’est le partage de mot de passe. C’est là où il y a un mot de passe secret. Il faut le partager. On fait ça uniquement une seule fois. Ca, c’est juste la partie enregistrement.

Mais le handshake, ça se passe à chaque fois que je commence une communication. Voilà, je fais le handshake. C’est un process assez fréquent dans les communications parce que on devrait communiquer de manière sécurisée en utilisant une clé de chiffrement et cette clé de chiffrement, il est préférable qu'elle change entre les sessions, que ce ne soit pas toujours la même. On ne chiffre pas avec la même clé. On change la clé avec chaque session et on va utiliser ça pour générer une nouvelle clé de session à chaque fois. Tout en faisant l’authentification.

François: D’accord. Donc à chaque fois qu’on instancie une connexion, on est potentiellement exposé à cette attaque ?

Mohamed: Exactement. L’objectif de l’attaque, c’est de deviner votre mot de passe. C’est le handshake, ou serrage de main, si vous voulez, où on va utiliser ce mot de passe. Donc cet élément secret. Et là, on va aller regarder dans le détail; quand est ce qu’on utilise le mot de passe, dans quelles opérations et exploiter quelques failles d’implémentation pour récupérer le mot de passe.

Notre attaque s’arrête quand on arrive à récupérer suffisamment d’informations pour pouvoir lancer une attaque dictionnaire hors ligne.

Après, l’efficacité va dépendre de l’efficacité des attaques par dictionnaire hors ligne.

François: D’ailleurs, au sujet des attaques dictionnaire en ligne. Je pense qu’il est intéressant de citer un chiffre mentionné dans le papier Dragonblood: Analyzing the Dragonfly Handshake of WPA3 and EAP-pwd, papier que vous citez dans votre papier, rédigé par Vanhoef et Ronen, dans lequel les auteurs nous indiquent que: Pour faire une attaque brute force sur un mot de passe en testant avec un dictionnaire de taille 10 puissance 10, donc essayé 10 milliards de mots de passe pour en cracker un. Ça ne coûte que 1 dollar de cloud computing en utilisant des ressources, par exemple, de Amazon et leurs instances EC2.

Mohamed: Voilà, et ce prix-là diminue chaque jour. Bien sûr, comme les ordinateurs deviennent de plus en plus puissants. Et les mots de passe, si on n’utilise pas un générateur aléatoire de mots de passe, vont varier entre 8 et 10 caractères pour les gens les plus avertis en termes de sécurité.

François: Donc au cours de l’attaque, l’objectif est donc d’avoir suffisamment d’informations, même si on n’a pas le mot de passe en tant que tel. Pour pouvoir passer sur un format attaque hors ligne où on va pouvoir enchaîner sur une attaque de type brute force ?

Est-ce que, vous pouvez nous parler un petit peu plus de cette façon dont vous obtenez des informations sur mot de passe sans l’avoir directement ?

Ça peut paraître complexe. Comment est-ce que vous pouvez avoir de l’information sur le mot de passe, sans l’avoir, quelle est l’idée derrière ça?

Mohamed: Dans notre attaque, on va exploiter les architectures matérielles de nos processeurs modernes. Dans WPA-3, ou plus précisément le protocole Dragonfly, utilisé dans WPA-3 pour faire l’authentification et échanger les clés cryptographiques, on ne va pas envoyer le mot de passe comme ça au fournisseur d’accès, à l’Access Point.

On va faire des opérations sur le mot de passe et ces opérations, si le point d’accès et vous-même faites les mêmes opérations sur le même mot de passe. Vous allez arriver au même secret, donc ce secret-là va être utilisé comme une clé de chiffrement, quelque chose qu’on va utiliser pour chiffrer et protéger l’intégrité et la confidentialité des données.

Ce qu’on va faire, on va aller regarder cette opération. En faite, un mot de passe va être transformé, en ce qu’on appelle en un point sur une courbe elliptique — on va faire une opération sensible sur un mot de passe dans une fonction et cette fonction sera exécutée autrement pour chaque mot de passe.

Il y a une exécution unique de cette fonction là en fonction de si votre mot de passe est azerty ou si votre mot de passe est ABC, ça ne va pas prendre le même temps, ça ne va pas suivre le même flow d’exécution.

Je m’explique. Il y a des mots de passe qui seront plus ou moins rapide à convertir en quelque chose de secret.

François: Si je prends mon nom, mon prénom ou si je prends une chaîne de dix caractères aléatoire, ça a un impact sur ce processus-là?

Mohamed: Non non, pas du tout. Les éléments qui sont importants, sont les adresses MAC, donc l’adresse Mac de la source, l’adresse MAC de la destination. Donc les identifiants de l’Access Point et vous-même et le mot de passe. Et ici l’exécution de cette fonction, le temps d’exécution va varier. Parce qu'il y a des mots de passe qui seront plus ou moins faciles à convertir. Et ça, ça concerne donc la première attaque qui était annoncée contre WPA-3 DragonBlood, qui exploitait cette faille en disant “Finalement, il y a quelque chose qui ne va pas parce que voilà; si je mesure juste le temps d’exécution. Je peux connaître que vous n’utilisez pas le mot de passe azerty, par exemple, mais vous pouvez utiliser d’autres mots de passe qui seront plus faciles à convertir parce que ça prend moins de temps.” Et donc là, le standard a évolué suite à l’attaque DragonBlood. Et finalement, le temps d’exécution va être maximisée. On va convertir le mot de passe. Si on réussit à convertir très vite, on va faire des opérations inutiles. On va faire par exemple 40 opérations. Si on fait deux opérations, et on arrive à convertir (le mot de passe). Ce n’est pas grave, on va faire 38 (autres opérations), mais on ne va pas utiliser les résultats (de ces 38 autres opérations). C’est juste qu’on va récupérer le résultat après la seconde fois parce que c’est là où on a réussi à convertir. Et c’est là où notre attaque arrive. En fait, on arrive à distinguer le cas où on dit “ah en fait, Maintenant, j’ai réussi à convertir mon mot de passe, je vais faire des opérations inutiles et je ne vais pas utiliser les résultats de ces opérations inutiles.” Donc, on arrive à observer ce comportement là et finalement, à savoir quand est-ce que le mot de passe, on a réussi à convertir en élément sensible, secret. Et là, on va lancer notre attaque contre un dictionnaire, donc en fixant les adresses et tous les autres paramètres. Et on va dire, par exemple “mot de passe 1, on peut le convertir après deux opérations. Mot de passe 2, on peut le convertir après trois opérations” et on va éliminer tous les mots de passe dont le nombre d’opérations n’est pas identique au mot de passe de la victime.

François: Pour résumer très grossièrement, votre attaque se base sur, un petit peu surveiller ce qui se passe au niveau du processeur, les instructions chargées afin de pouvoir dériver de l’information sur “Ah! On est arrivé dans telle branche. Par exemple, un if ou un else et donc c’est probablement tel comportement qui s’est passé. Autrement dit, je peux en déduire des informations sur le mot de passe potentiel.

Mohamed: Exactement. Comme je l’ai dit, l’exécution va être différente selon chaque mot de passe. Quand on réussit à convertir le mot de passe, on va entrer dans un branchement particulier. Donc, on va exécuter quelques instructions uniquement quand on arrive à convertir le mot de passe. Et c’est là où on va écouter les instructions, exécuter et savoir exactement quand est ce que ce scénario arrive. Et c’est là, en fait l’information qu’on souhaite avoir. C’est vraiment quand est-ce que le mot de passe a été converti ; après une tentative, une deuxième tentative, ou le dixième tentative.

François: D’accord, d’ailleurs, est-ce que vous pouvez nous en dire un peu plus à ce sujet? Comment est-ce que vous surveillez si tel branchement a été choisi ou non, parce que, en lisant le papier je trouvais ça absolument passionnant la façon dont, en étudiant ce qui se passe au niveau du processeur, des instructions chargées en cache. Vous arrivez à déduire de l’information. Comment est-ce que vous avez d’une part, eu l'idée de recourir à cette technique et, à haut niveau, comment est-ce que ça marche ? De surveiller les instructions exécutées par le processeur ?

Mohamed: Pour surveiller les instructions exécutées par le processeur, On a utilisé des attaques basées sur le cache.

Tout d’abord, on n’a pas inventé ce genre d’attaque. Ce sont des attaques qui existent depuis un certain temps. Par exemple, les fameuses attaques Spectre et Meltdown utilisent et exploitent ce genre de fuites d’informations sur un processeur. Ici, bien sûr, on étudie les processeurs Intel, les processeurs les plus utilisés dans un ordinateur.

Si un process spy (processus espion) qui aimerait bien écouter des informations sur autre process. Normalement, un système d’exploitation ne permet pas, par défaut, de faire ce genre d’écoutes illégales. Parce que les mémoires ne sont pas les mêmes, etc.

Ce qui est assez intriguant dans la conception des processeurs modernes aujourd’hui, c’est que le cache, donc le cache c’est une partie de mémoire qui permet d’augmenter la performance de l’exécution d’un programme. Parce qu’accéder à la mémoire, ça coûte beaucoup plus cher qu’accéder à un cache et permet d’exécuter les instructions, enfin avoir un accès rapide aux instructions que l’on utilise le plus souvent et les données qu’on a accès plus rapidement.

François: D’ailleurs, à ce sujet-là, excusez-moi de vous interrompre. Est-ce que vous avez un ordre de grandeur à nous donner pour accéder à une information sur le disque — Bon, aujourd’hui, est ce qu’on parle de différence entre disque dur ou SSD — Ensuite, mémoire en RAM et ensuite aux différents niveaux de cache jusqu’aux registres ?

Mohamed: Il y a cinq ordres de grandeur différence entre l’accès à un disque dur et l’accès au RAM. Donc l’accès au RAM on va le compter en plus tôt nanosecondes. A peu près 50 nanosecondes. L’accès au disque dur, ça va être plutôt, dans l’ordre de millisecondes. Bien sûr, ça va être plus rapide dans le cas de SSD. Et dans le cas d’un cache, je n’ai pas le chiffre exact, mais c’est beaucoup plus rapide que d’avoir un accès dans un RAM. Il n’y a pas cette étape d’aller accéder à une adresse, de charger l’adresse dans un registre. Ça, ça prend beaucoup plus de temps que juste avoir directement accès aux caches. Et donc, le problème de la conception en tout cas de cache actuel par design, est qu’ils sont partagés avec tout le monde. En fait, on a le même cache pour tout le monde. Si un process spy arrive à contrôler son cache. À mettre des informations précises dans tel et tel endroit de cache et écouter le temps d’exécution de l’autre process, il va pouvoir deviner que cette partie de cache contient telle et telle valeur.

François: Ensuite, vous récupérez cette information. Sous quelle forme est-elle ? Vous avez des temps, et c’est à partir d’un temps d’exécution, que vous arrivez à vous dire “Ah d’accord. Donc là, on a tant de nanosecondes par exemple, ça correspond probablement à un mot de passe, de tant de caractères.” Est-ce que c’est comme ça que vous fonctionnez ?

Mohamed: Non. Ici on ne va pas regarder la partie donnée, mais on regarde la partie instructions. On peut vraiment regarder quels branchements, quelles instructions sont actuellement en train d’être exécutées sur le logiciel qui est en train de faire le serrage de mains, le handshake de WPA-3. Quand on arrive à observer, via ce mécanisme de cache, on est en train de regarder le cache, vouloir vider le contenu de cache. De temps en temps, si les valeurs ne correspondent pas, on va recharger les valeurs à nouveau donc on recharge les valeurs, c’est là où ça prend du temps. Donc, on sait que voilà les valeurs, c’était comme ça et donc en fait, quand je parle ici des valeurs. Je parle plutôt des instructions, les instructions sont comme ça. Donc on va deviner les instructions qui sont en train d’être exécutées par le logiciel qui est en train de faire le serrage de main. Et c’est à ce moment-là, quand on arrive à deviner, ici de manière probabiliste, parce que ce ne sont pas des attaques exactes. Parfois, on arrive à deviner exactement l’opération dans laquelle le mot de passe a été converti avec succès ou pas. Et donc, quand on arrive à faire ça avec succès et on connaît, voilà l’opération. Et c’est là qu’on va lancer une deuxième phase d’attaque pour essayer ce qu’on appelle, réduire le dictionnaire en testant vraiment refaire le même protocole et voir si un mot de passe dans le dictionnaire, on peut le convertir avec 3, 4, 5 opérations. Si ce n’est pas égal à ce qu’on vient d’observer avec les caches, on va juste éliminer de dictionnaire et donc c’est là on va voir petit à petit des dictionnaires plus petits. Donc on part d’un dictionnaire très important et là, on va réussir à réduire la taille du dictionnaire avec cette information qu’on vient de récupérer.

François: Avec ce que vous venez de mentionner, il me semble intéressant de parler du modèle de menace envisagé parce qu’on parle tout de même de monitorer l’accès au code qui est exécuté par le client, donc ça suppose qu’on ait un attaquant qui ait déjà accès à la machine cible.

Mohamed: En fait le modèle d’attaquant. C’est juste un attaquant qui peut installer un logiciel, un process sans privilèges particuliers.

L’attaquant a juste besoin que la victime exécute une sorte de spyware. Mais ce spyware n’a pas de privilèges particuliers. Il a juste les privilèges par défaut. Il tourne et voilà. Il va réussir à lancer les attaques par cache, expliquées dans le papier. L’attaquant a besoin uniquement de ça. Finalement, ce n’est pas un modèle si fort que ça, des chevaux de Troie aujourd’hui ou des applications, par exemple des jeux, des applications gratuites qu’on utilise aujourd’hui. Il n’est pas improbable d’avoir une application avec un comportement souhaité, comme un jeu, qui peut avoir des comportements cachés, comme espionner d’autres process.

François: Donc là, je pense que c’est intéressant de revenir sur le titre du papier puisque à travers la discussion on a déjà permis de définir un petit peu quelques termes. Donc Dragon Blood, c’est en rapport avec ce protocole Dragonfly de handshake et la partie cache-based, cache-based pourquoi, puisque vous vous basez sur des informations autour du cache du processeur pour dériver de l’information sur les mots de passe ?

Mohamed: Exactement. C’est Ça.

François: Et il y a un autre mot clé qui m’avait interloqué en lisant le titre, c’est Side Chanel. On n’en a pas trop parlé jusqu’alors. Est-ce que vous pouvez définir cette notion ? Et qu’est-ce qu’une attaque Side Chanel ?

Mohamed: Le side channel ici, est lié aux attaques par cache. On essaye de récupérer de l’information indirectement. Une implémentation WPA-3 classique, je donne un mot de passe, il y a des choses qui se passent à l’intérieur. Je n’ai pas accès. Et à la fin, j’ai un secret partagé avec le point d’accès.

Ici le Side Channel signifie que, en exploitant un canal de communication qui n’est pas considéré dans le modèle d’exécution. On va pouvoir récupérer de l’information. Et ce canal, c’est le cache du processeur.

François: D’accord, en fait, ça pourrait par exemple aussi monitorer la consommation électrique pour se dire que “Là il y a plus de consommation au niveau du processeur, donc peut-être y a-t-il une action plus complexe en train d’être réalisé sur ce créneau. Donc on est dans telle branche d’instruction” ?

Mohamed: Exactement, il y avait pas mal d’attaques contre les cartes à puce, par exemple. Que ça consomme plus de ressources si on utilise une clé secrète qui est égale à ça et pas à ça. Le temps d’exécution, comme vous l’avez indiqué, etc. Aujourd'hui les attaques par cache deviennent de plus en plus récurrentes dans le domaine de la cyber sécurité. Bien sûr, c’est un problème matériel qui vient de la conception même de nos processeurs. Donc, ce n’est pas très simple de corriger ce genre d’attaques. En tout cas l’origine des attaques. C’est vraiment ce modèle de caches qui permettent de récupérer de l’information. Mais aujourd’hui, on peut corriger les failles au cas par cas. Chaque programme peut corriger des failles liées aux fuites par cache. Et ça, ça demande un style de programmation assez particulier. Et la vérification de plusieurs propriétés dans le code.

François: Je suppose qu’à ce niveau-là, ça nécessite d’avoir des ingénieurs qui développent des systèmes qui soient vraiment très au fait des mécanismes de mémoire, d’accès aux caches pour pouvoir jouer avec ces phénomènes là et être sûr de faire fuiter le moins d’informations possible.

Mohamed: Voilà si on veut vraiment descendre très, très bas. Néanmoins, il y a des solutions plus simples. C’est ce qu’on appelle programmer en temps constant. Un algorithme et un programme va être exécuté toujours de la même façon, quelle que soit l’entrée, quel que soit le secret. Imaginons dans notre cas d’usage, il n’y a pas ce branchement qui révèle si le mot de passe est converti avec succès. Je fais ça et ça et ça. Après, je fais des opérations inutiles. On a réussi à écouter ce branchement là. Si on n’a pas ça, si on exécute juste des instructions. Avoir des informations via le cache serait très, très difficile. Et finalement, quand on a proposé des corrections aux implémentations de WPA-3, les implémentations vulnérables concernées, on a proposé des implémentations en temps constant.

Acte 3 — Leçons tirées

François: Je pense que c’est un bon moment pour passer à la partie atténuation de l’attaque ou quelles sont les observations que vous avez faites avec cette attaque qui vous permettent de donner des conseils, au moins des directives pour solutionner ces problèmes.

Mohamed: Premier conseil si vous ne connaissez pas les propriétés de sécurité nécessaires, ou exigée un dans un protocole. N’essayez pas de l’implémenter.

Aujourd’hui, implémenter des parties cryptographiques sensibles, ça demande beaucoup de sensibilité sur pas mal d’attaques. Ici, on a exploité le fait qu’il y avait une partie de programme qui n’ait pas été faite en temps constant.

Deuxième conseil, donc, lié au temps constant. Il ne faut pas que le programme qui manipule des données sensibles, ait son comportement qui dépende de la valeur de secret.

Je prends un exemple simple vérification de PIN. Si votre programme de vérification vérifie le premier chiffre, si c’est correct, je vérifie le deuxième chiffre. Si c’est correct, je vais vérifier le 3 chiffre. Ici, on voit clairement qu’on peut faire fuiter quelques informations, via le temps d’exécution.

Si le premier chiffre n’était pas correct, on va s’arrêter tout de suite, si le quatrième chiffre n’était pas correct. On va exécuter jusqu’à vérifier le quatrième chiffre. Et bien sûr, la différence de temps d’exécution est ici minime. Mais aujourd’hui, on peut observer ce genre de différence d’exécution. C’est observable.

Il n’y a pas que le temps d’exécution qui est concerné. Aujourd’hui, on arrive aussi à pouvoir récupérer de l’information, même si dans votre programme, il y a des cas qui disent si la valeur secret est égale à ça, on va exécuter telle partie du programme. Sinon, on va exécuter telle partie du programme, même si le temps d’exécution sera identique.

Via les attaques par cache, on va pouvoir distinguer que là, dans votre programme, vous avez exécuté la partie “if” et pas la partie “else”. Et c’est là qu’on va pouvoir récupérer un peu d’informations sur les secrets. Finalement, c’est assez compliqué de bien implémenter les protocoles qui sont utilisés aujourd’hui par tout le monde. Bien sûr, il y a l’aspect efficacité et l’aspect que ça tourne sur pas mal de machines, à la fois sur ordinateur, mobile, etc. Qui rend finalement aussi la programmation assez compliquée assez complexe. Finalement, il se peut que quelques aspects de sécurité peuvent sauter. Ça, ça demande beaucoup de temps et beaucoup de revues de code. Et l’utilisation d’outils spécialisés pour dire “voilà, Votre code d’aujourd’hui ne fuit pas de données par la cache”, par exemple.

François: Aujourd’hui, quasiment tout le monde passe par des points d’accès Wi-Fi sécurisés pour se connecter à Internet; Est-ce qu’il y a quelque chose que l’on peut faire pour limiter son exposition à de telles attaques?

Mohamed: En tant qu’utilisateur final, il faut juste mettre à jour, son logiciel. Quand il y a une mise à jour disponible et ça concerne la sécurité, il faut la faire.

Mais en faite, dans l’attaque que l’on a exposé, non, l’utilisateur ne peut rien. C’est vraiment au niveau de l’exécution de la bibliothèque de code qui fait le WPA-3. Il faut utiliser les librairies où le code est bien regardé par d’autres experts de sécurité qui ont pris en considération ce genre d’attaques.

François: Vous avez maintenant rédigé un papier à ce sujet là. Papier qui sera publié fin décembre. En avez-vous déjà parlé avec des éditeurs, des constructeurs de processeurs, par exemple Intel ou avec la WiFi Alliance pour remonter ces problèmes et faire en sorte que des bonnes pratiques, par exemple, d’exécution en temps constant soient implémentées dans les standards?

Mohamed: En fait, on était plus terre à terre. Aujourd’hui, les attaques par caches sont exploitées, donc liées aux conceptions d’Intel, elles sont utilisées par plusieurs familles d’attaques. Il y a des gens qui ont déjà communiqué avec Intel. Donc on n’a pas souhaité entrer dans la complexité de communication avec Intel. Intel qui devra prendre des décisions. C’est difficile, hein? Parce que, un processeur aujourd’hui est là, qu’est ce qu’on en fait? Est-ce qu’on doit dire à tout le monde, “En fait, il faut rendre les machines, on va changer vos processeurs avec un nouveau modèle de cache”.

On n’est pas entré dans des communications avec Intel, enfin on est entré en communication avec Intel mais via un autre aspect. On n’est pas entré en communication avec le WiFi Alliance, non plus. Parce que ce n’est pas un problème qui est lié au Standard lui même. C’est vraiment un problème lié aux implémentations. Le Standard définissait des opérations difficile à implémenter, mais dont une implémentation sécurisée peut exister. Mais voilà, des opérations naturellement pas faciles à implémenter en temps constant. On n’a pas non plus souhaité que WiFi Alliance change le standard. Le standard est déjà là. J’imagine que des constructeurs, des fabricants de points d’accès sont déjà en train d’implémenter, ont déjà implémenté WPA-3 donc changer le standard ça va être difficile.

On a plutôt privilégié de regarder les bibliothèques qui implémente WPA-3 et on lance notre attaque. Si on arrive à l’exécuter avec succès, on va parler avec les développeurs de ces librairies. Bien sûr, si c’est open source parce que c’est plus facile. Donc on va en parler avec les gens et on va proposer directement un patch du code vulnérable. Et on va accompagner les développeurs pour tester le patch, tester à la fois le patch en fonctionnel, et ce que ça change le comportement de WPA-3 ou de la bibliothèque concerné. Est-ce que ça rend la bibliothèque moins efficace. Est-ce que ça passe leurs tests unitaires, etc. On a vraiment été dans l’accompagnement des développeurs de telles bibliothèques et bien sûr, on a revérifier si notre attaque fonctionne une fois que le code a été patché.

François: Merci pour ces précisions. Est-ce qu’il y a quelque chose d’autre, que vous souhaiteriez mentionner au sujet de cette attaque?

Mohamed: Je souhaite juste mentionner que notre travail concerne deux implémentations open source. La première est Free Radius, donc Free Radius aujourd’hui est utilisé un peu partout. D’après leur site, il est utilisé par des millions d’utilisateurs. C’est assez populaire Free Radius. Et la deuxième implémentation c’est IWD, pour iNet Wireless Deamon. En fait, c’est un projet commencé par Intel pour faire un démon WiFi léger qui est aujourd’hui utilisé par Arch Linux, par exemple. Quand on a exploité l’attaque, on est entré en communication avec les développeurs. C’était au mois de juin (2020). Ça a pris, un peu plus d’un mois et demi d’entrer en communication avec les gens, recevoir les réponses. Essayer de convaincre les développeurs que c’est une attaque qui marche en fournissant un POC (proof of concept, une preuve de concept) complet. À partir d’une bibliothèque compilé qui tourne sur une machine. Pour dire, voilà, “On arrive à faire ça et ça et ça.” Après, il y a beaucoup d’allers et retours avec “On vous propose ça, qu’est ce que vous pensez?” Et en retour, en disant “En faite, ça ça ne correspond pas à notre style de programmation. Parce que on a tel et tel problème, il y a telle et telle dépendance dans la bibliothèque.” Donc, c’est un travail qui était fait par Daniel, le doctorant. Et je pense que autre l’aspect scientifique, qu’on a appris dans l’attaque. Qu’il y avait aussi tout un aspect pratique, comment convaincre des gens à prendre en compte son patch, qui était aussi très formateur pour nous qui ont travaillé sur sur ce papier là.

François: C’est vrai que c’est quelque chose auquel on ne pense pas au premier abord, mais vous avez toute une partie conduite du changement. Apporter auprès de la communauté open source, cette faille que vous avez relevée. En discuter, prendre contact avec la communauté, leur montrer concrètement qu’il y a un risque avec cette attaque. Et proposer une façon de l’atténuer. Je pense que ça doit représenter un gros travail pour vous, d’amener cette information sans être sur un ton de défiance, mais plutôt “Voilà, on a repéré une faille. On pense qu’elle est assez critique. Il faudrait l’adresser rapidement” Je suppose que ça ne doit pas être évident d’apporter cette information ?

Mohamed: Exactement. On a dit dès le début quand on est en communication, qu’on ne souhaite pas créer un buzz, ou partir avec l’attaque. Pour nous le plus important, c’est que l’attaque soit corrigée. Je pense que le fait qu’on ait fourni un POC complet, qui était accessible pour les développeurs pour qu’ils puissent aller voir comment l’attaque était implémentée, pour pouvoir jouer aussi un peu avec. Qui a réussi à convaincre les gens qui gèrent ces bibliothèques de prendre notre attaque en compte. Puisque j’imagine — Je ne maintiens pas un projet open source aussi important, qui est utilisé par des millions d’utilisateurs. — Mais j’imagine que ces gens là reçoivent peut-être tous les jours des alertes en disant “Regardez ici, on peut attaquer cette partie là, regardez là, on peut attaquer cette partie là.” Ça peut être juste des fausses alertes et finalement, je pense que c’est assez difficile comme travail de discerner une fausse d’une bonne alerte. En tout cas, heureusement, dans notre cas, on a réussi à les convaincre. Avant l’attaque un mois et demi, ça me semblait trop long. Il y a quand même une faille, ça prend un mois et demi pour la corriger. Maintenant, j’ai fait l’expérience. Finalement, un mois et demi, ce n’était pas évident de cocher toutes les cases et tout vérifier et fournir le bon patch qui marche et qui passe les tests.

François: Merci Mohamed pour avoir partagé votre expérience au micro de Post Mortem. Avant de conclure l’épisode, est-ce qu’il y a des ressources que vous souhaiteriez recommander à nos auditeurs et à nos auditrices pour qu’ils et elles puissent approfondir ce sujet là?

Mohamed: Si le sujet des WPA-3 vous intéresse, et vous souhaitiez lire tout de suite, vous familiariser avec les attaques par cache, contre ce genre de protocole. Vous pouvez commencer par lire le papier DragonBlood. Parce que si on a intitulé notre papier DragonBlood is still leaking, c’est parce qu’il y a déjà une première attaque qui s’appelait Dragon Blood et on amélioré beaucoup plus son efficacité, sa précision. Et finalement, l’appliquer à d’autres bibliothèques. Il y a même un site web lié au papier d’origine, à l’attaque d’origine. Je trouve que lire au moins la partie introductif de ce papier là, dans leur site Web est une source d’information qui permet de familiariser les gens sur WPA-3, sur les attaques par cache, etc. C’est quelque chose qu’on aimerait bien développer au sein de notre équipe. Cet aspect de vulgarisation de nos travaux de recherche et je trouve super qu’il y ait des gens qui fassent des attaques et prennent le temps de faire un petit site web, vulgariser et ne pas avoir que le format papier académique.

En tout cas, ce n’est pas encore prêt pour notre attaque actuelle ou pour des attaques que l’on est en train d’effectuer, mais c’est un point sur lequel on aimerait beaucoup s’améliorer. Faire des travaux de recherches et mieux communiquer nos travaux de recherches, surtout s’il s’agit d’attaque qui peuvent concerner tout le monde.

François: Ça marche, je mettrais dans les notes de l’épisode le lien vers le papier d’origine, écrit par Mathy Vanhoef et Eyal Ronen. Également, je mettrai le lien vers le site web qu’ils ont conçu pour définir et présenter l’attaque DragonBlood. Auriez-vous un petit mot pour la fin ? Un message à faire passer à nos auditeurs en particulier.

Mohamed: J’ai juste un dernier mot pour dire: N’ayez pas peur, continuez à utiliser WPA-3. En tout cas, c’est corrigé dans les bibliothèques que l’on a étudiées. À choisir entre WPA-2 et WPA-3, WPA-3 reste plus sûr, plus sécurisé et va vous donner plus de sécurité. Donc utilisez WPA-3 si vous avez l’opportunité.

François: Merci beaucoup Mohamed pour votre temps et cette présentation de l’attaque DragonBlood is still leaking.

Mohamed: Je vous en prie et je vous remercie pour cette invitation. Ça m’a fait plaisir de présenter notre travail au sein de ce podcast. Bien sûr, un grand remerciement pour mes co-auteurs Daniel, qui a effectué l’essentiel du travail et Perre-Alain Fouque.

François: J’espère que ce deuxième épisode de Post-mortem vous a plu. Si c’est le cas, n’hésitez pas à le partager avec un ou une amie. Quelque chose qui aide énormément à nous faire connaître, c’est de laisser une note et un commentaire sur Apple Podcasts. Si vous souhaitez proposer un retour d’expérience dans un épisode, n’hésitez pas à me contacter directement sur les réseaux, Instagram et Twitter. Vous ne trouverez sous le tag PodcastMortem. Vous pouvez aussi me contacter par email francois@postmortem.media et je serais ravi d’en discuter avec vous. A une prochaine fois, Bye.

Épisode enregistré en septembre 2020

Notes de l'épisode

Wi-Fi Protected Access 3 (WPA3) est destiné à remplacer WPA 2 — en service depuis 2004 — en rendant presque impossible de craquer le mot de passe d’un réseau.

Problème, des chercheurs ont révélé qu’un attaquant peut exploiter des failles dans les implémentations existantes de WPA 3 pour récupérer le mot de passe de la victime.

Dans cet épisode, Mohamed Sabt, maître de conférence à l’université de Rennes 1 enseignant la cybersécurité et chercheur au sein de l’équipe “Sécurité et Cryptographie Embarquées” (EMSEC) nous révèle une toute nouvelle cyberattaque sur le wifi et en particulier sur la certification WPA3.

On se concentre sur le moment du serrage de main, le handshake, au cours de l’initialisation de la connexion entre un appareil et le point d’accès wifi. C’est à ce moment que plusieurs implémentations du handshake Dragonfly de WPA 3 présentent des failles.

En analysant les instructions chargées dans le cache de processeurs Intel ainsi que les temps d’exécutions, Mohamed et son équipe ont réussi à déterminer quelles instructions sont exécutées ce qui permet de réduire considérablement la taille des dictionnaires à utiliser pour enchaîner sur une attaque brute force.

Mohamed nous raconte ensuite comment ils ont travaillé avec la communauté open source qui maintient ces implémentations afin de patcher ces vulnérabilités et les leçons qu’il en a tiré d’un point de vue académique et organisationnel, par exemple; Comment remonter une faille de sécurité à un projet open source?

Points clés;

1. Le temps d’exécution d’une fonction de cryptage ne doit pas dépendre de la valeur du secret. Pensez aux implémentations en temps constant.
2. Si vous ne maîtrisez pas un standard de sécurité, n’essayez pas de l’implémenter vous- même.
3. Pour convaincre une équipe open source de la criticité d’une faille, arriver avec une preuve de concept (Proof of Concept, POC) complète qui montre l’attaque permet de gagner en crédibilité auprès de la communauté.
4. Pour les utilisateurs finaux, pensez à effectuer les mises à jour de sécurité.

Références

Mohamed remercie ses co-auteurs, Daniel De Almeida Braga et Pierre-Alain Fouque et nous invite à consulter le papier d’origine au sujet de Dragonblood et le superbe site web réalisé par les auteurs pour vulgariser leur travail de recherche.

• Dragonblood — Analysing WPA3’s Dragonfly Handshake, site web
• Dragonblood: Analyzing the Dragonfly Handshake of WPA3 and EAP-pwd, archive, un papier écrit par Mathy Vanhoef et Eyal Ronen.