logo Homepage
Pages: [1]
  Imprimer  
Auteur Fil de discussion: KRACK Attacks : review de la vulnérabilité  (Lu 18960 fois)
the lsd
Administrateur

Profil challenge

Classement : 181/54681

Membre Héroïque
*****
Hors ligne Hors ligne
Messages: 3096

poulping for fun & profit


Voir le profil WWW
« le: 17 Octobre 2017 à 09:11:55 »

Hello tout le monde.

Bon, toute personne ayant suivi un minimum l'actu sécu du jour aura forcément entendu parler de KRACK, la nouvelle vulnérabilité contre le WPA2.

Découverte et rendue publique par Mathy Vanhoef, cette attaque permet en gros, d'exploiter une faiblesse dans l'implémentation de WPA2.
Mais ici, pas de buzzword comme "WPA2 est cassé", "Le protocole WPA n'est plus" ou autre trucs de marketeux.
Nan, ici, on va parler technique et expliquer un peu plus en détail le fonctionnement d'une des attaques. Parce que oui, en fait, il y en a plusieurs. Je vais donc expliquer la méthode la plus basique (en espérant ne pas avoir dit trop de bêtises; si c'est le cas, il ne faut pas hésiter à me corriger )

Pour tout comprendre, il faut déjà garder en tête une des finalités de KRACK : pouvoir faire un "Man In The Middle" (on notera les guillemets, j'expliquerai plus bas pourquoi).
Maintenant, place aux explications :

Le coeur de la faiblesse : le 4 way handshake.

Avant même de parler du 4 way handshake, il faut comprendre le fonctionnement d'un "Nonce" : c'est un message (nombre, lettres, peut importe), qui doit être utilisé une seule et unique fois, afin d'éviter des attaques par rejeu. Par exemple, si un serveur envoie un Nonce de "321583". Le client enverra une réponse contenant "321583". Le serveur doit ensuite considérer que "321583" n'est plus valide et générer un nouveau Nonce. Ainsi, si un attaquant essaie de relancer le message du client (qu'il a obtenu via une écoute du réseau par exemple), le serveur voyant le Nonce de "321583" saura qu'il y a attaque par rejeu et rejettera le paquet.


Bon, maintenant, comment fonctionne exactement une connexion wifi en WPA2 ?
La phase d'authentification s'appelle le 4 Way Handshake, tout simplement parce qu'il y aura un échange de quatre paquets entre le client (le supplicant en VO) et le point d'accès wifi (l'anthenticator en VO).

Lorsqu'un client effectue une demande de connexion, il se passe ces étapes :

 - l'AP (point d'accès) va envoyer un premier message qui contiendra un compteur, et ce qu'on appelle un ANonce (Authenticator Nonce, qui est juste un nombre ici)

 - Grâce à cela, le client va pouvoir calculer une PTK (pour Pairwise Transient Key). Cette PTK est basée sur la clé Wifi, le ANonce, le SNonce (qui est le Supplicant Nonce, généré à la réception du ANonce), et les adresse MAC de l'AP et du client.

 - Une fois la PTK calculée, le client va envoyer un deuxième message, vers le serveur. Ce message contiendra un compteur, et le SNonce.

 - Coté AP, la PTK va être calculée exactement de la même manière que précédemment. Ainsi, le client et l'AP auront la même PTK. A ce point du handshake, même si un attaquant espionne les connexions, il ne pourrait pas casser la connexion, puisqu'elle est basée en partie sur la clé WIFI.

 - Une fois la PTK connue des deux cotés, l'AP envoie dans le troisième message ce qui s'appelle une GTK (Group Transient Key), ainsi que le compteur, incrémenté de 1. La GTK est une clé envoyée de manière chiffrée grâce à la PTK et sert pour envoyer de messages en multicast et broadcast.

 - Le client envoie enfin le 4ème et dernier message, qui est juste un accusé de réception du troisième. Dans le même temps, il valide la PTK et la GTK, qui sont donc considérés comme valides.

 - A la réception de l'accusé, l'AP va de son coté valider la PTK


Voilà pour la partie détaillée. Pour faire plus simple, ça fait quelque chose comme :

"Salut client, on s'authentifie ? Tiens, un message secret : poulpe"
"Coucou AP, ok pour s'authentifier. Voilà mon message secret : epluop"
"OK, tout est correct, voilà une clé chiffrée que tu dois déchiffrer pour discuter en multicast : cbhycr"
"Nickel, j'ai bien reçu ta clé chiffrée."

Une fois que ce 4 way handshake est passé, le client et l'AP peuvent discuter de manière chiffrée.

Pourquoi tout-il-est-cassé ?

En soi, le design est correct. Ce qui pose problème, c'est l'implémentation par les différents constructeurs de ce handshake. L'implémentation dans une utilisation classique est correcte (encore heureux, sinon, on pourrait pas utiliser de WPA2 ^^)

Bon. Imaginons maintenant qu'on puisse se mettre ENTRE le client et l'AP, que pourrait-il se passer ? Juste comme ça, absolument rien : même si on récupère le ANonce et le SNonce, on ne pourrait pas récupérer la PTK, celle ci étant créée grâce à la clé WIFI, et donc pas la GTK non plus, ce qui rendrait impossible le déchiffrement des trames suivantes.

Cela dit, et c'est là que le bas blesse, la méthode de validation de ce 4way handshake est un peu foireuse selon les cas.

L'attaque fonctionne donc ainsi :

Entre le client et l'AP, un rogue AP est créé par l'attaquant. Il sera donc en position de Man In The Middle et pourra voir passer tous les paquets. Lors du 4way handshake, voilà ce qui va se passer :

 - l'AP envoie son ANonce. L'attaquant le laisse passer et le renvoie donc au client
 - le client envoie son SNonce. Comme précédemment, l'attaquant le voie et le laisse passer vers l'AP
 - le serveur va donc envoyer sa GTK, avec son compteur, incrémenté de 1. L'attaquant ne touche à rien et le paquet arrive au client
 - enfin le client envoie son ACK final. C'est ici que tout se joue : l'attaquant bloque ce paquet.

La suite est un peu plus tricky :

  - A ce stage, tout semble OK pour le client, il installe sa PTK et GTK. Sauf que l'AP n'ayant pas reçu le ACK du client, il va renvoyer la GTK, avec un compteur incrémenté encore une fois de 1.
  - le client reçoit ce paquet. Que fait il ? Bêtement, il voie un paquet contenant une GTK, il se dit, "OK je réinstalle ma GTK, ma PTK, et je réinitialise mon compteur"

A ce niveau, que s'est-il passé ? Le serveur à envoyé deux messages contenant la GTK : celui contenant compteur+1, et celui contenant compteur+2.
Le client a envoyé un ACK contenant compteur+1, qui a été bloqué par l'attaquant, puis un autre message, contenant compteur+2.
Sauf que l'AP n'a reçu que celui contenant compteur+2, le message ayant compteur+1 étant tombé aux oubliettes.

Dans un flux "normal", n'importe quel message contenant compteur+1 devrait être rejeté par l'AP. Cependant, la RFC définit ceci :
"On reception of message 4, the Authenticator verifies that the Key Replay Counter field value is one that it used on this 4-way handshake"

Autrement dit, puisque l'AP a envoyé des messages compteur+1 et compteur+2 AVANT de recevoir le ACK du client (contenant compteur+2, tout le monde suit ?), il accepte des messages contenant compteur+1 ET compteur+2.

Enfin, puisque le client a réinitialisé son compteur, il va donc renvoyer un message contenant compteur+1. Ainsi, il fait exactement ce qu'il ne faut pas faire : du Nonce reuse. L'AP considérera ce compteur comme valide, puisqu'envoyé avant réception du ACK final.


Il est possible que certains soient perdus (c'est mon cas par exemple), mais c'est pas encore fini ^^'.


Très bien, on peut effectuer des attaques par rejeu. Cela que peut on en faire ? Selon les protocoles, les résultats sont différents, mais on se base au final sur des attaques connues :

 - sur TKIP, il est possible de déchiffrer et injecter des paquets. Cela est possible car le chiffrement est faible. En gros, le chiffrement des paquets se fait en RC4, avec une clé de 128 bits basé sur la PTK, la MAC de la source et le Nonce. Comme on connait la MAC, et le Nonce, on peut casser facilement le RC4 et donc injecter des paquets. (ce qui ne signifie pas qu'on récupère la clé wifi, juste la clé temporaire.)
 - pour le CCMP, c'est basé sur AES. Donc, c'est un peu poil plus chaud. Mais comme on est aussi basé sur le Nonce, on peut à priori déchiffrer plus facilement.
 - pour le GCMP, le Nonce reuse fait des massacres ici : "If a nonce is ever repeated, it is possible to reconstruct the authentication key used by the GHASH function". Mais pour comprendre ça, il faut lire un autre paper, et il est déjà 23H

On notera que selon les techniques d'attaque, il est possible d'effectuer du rejeu/déchiffrement/injection dans un sens ou l'autre (client vers AP ou l'inverse).


Mais au fait, comment on fait un MITM AP sinon ?

Alors, pour cette partie, c'est plus simple. c'est également une attaque connue, mais c'est rigolo
Le but est donc de créer un Roque AP, et que le client se connecte dessus. Pour cela, va donc falloir créer un AP qui possède le même nom et la même adresse MAC que l'AP original, mais sur un canal différent.
Si le client se connecte directement sur notre AP, il suffit de forwarder les paquets à l'AP réel et tout est bon. Mais il y a aussi des chances pour qu'il tente de se connecter à l'AP d'origine.

Du coup, pour être sur que le client se connecte sur notre AP, on va faire ce qu'on appelle du jamming. En gros, on envoie un max de signaux pourrie à la véritable AP, qui va plus pouvoir répondre. Comme notre AP répond au même nom et à la même MAC que la véritable, le client va tout simplement se connecter sur notre Rogue AP. Juste après ça, on arrête le jam pour pouvoir retransmettre les paquets.

C'est ce qu'on appelle un Channel Attack.



Pour résumer, KRACK, c'est une combinaison de plusieurs attaques :

 - Rogue AP, avec un Channel Attack
 - Une fois en position de MITM, on va sélectionner des paquets à renvoyer ou non vers le client
 - Suite à ça, le client va réinitialiser son compteur
 - le compteur étant utilisé comme Nonce, il sera réutilisé
 - ce qui nous permet de faire des attaques par rejeu
 - et dans certains cas de pouvoir injecter des paquets


Liens :

Paper : https://papers.mathyvanhoef.com/ccs2017.pdf
Site de KRACK Attacks : https://www.krackattacks.com/
AP Jamming : https://people.cs.kuleuven.be/~mathy.vanhoef/papers/acsac2014.pdf et https://www.cs.montana.edu/yang/paper/jamming.pdf
Un POC pour tester, tout frais : https://pastebin.com/aZyyS16w
Une vidéo de vulgarisation : https://www.youtube.com/watch?v=fOgJswt7nAc
Le même article, avec quelques schémas en plus : http://lsdsecdaemon.com/krack-review


Enjoy

The lsd
Journalisée

Newbie Contest Staff :
The lsd - Th3_l5D (IRC)
Statut :
Administrateur
Citation :
Cartésien désabusé : je pense, donc je suis, mais je m'en fous !
lovenunu
Beta testeur

Profil challenge

Classement : 22/54681

Membre Complet
*
Hors ligne Hors ligne
Messages: 172


Voir le profil
« #1 le: 17 Octobre 2017 à 11:15:14 »

Merci beaucoup pour cette explication. Je n'avais même pas vu passer la vuln ^^'.

Une question parce que je ne sais pas si j'ai tout compris. Pour le 4-way handshake, est-ce: un bug de spec, un manque de clareté dans la documentation ou juste les implémentations qui font n'imp ?
Journalisée

Tant pis je remplacerai ma nuit par une sieste.
pixis
Administrateur

Profil challenge

Classement : 17/54681

Membre Héroïque
*****
Hors ligne Hors ligne
Messages: 664


Voir le profil WWW
« #2 le: 17 Octobre 2017 à 12:52:15 »

De ce que j'ai compris, un bug de spec. Si les spec WPA2 sont respectées à la lettre, alors le soucis existe. Si en revanche tu ne respectes pas une ligne des spec, et que l'AP ne renvoie plus le 3ème message s'il n'a pas le ACK du client, alors ya plus le bug, mais tu es hors spec (cf. Windows & iOS)

En effet dans le standard 802.11, on a dans le paragraphe "8.5.3.5 4-Way Handshake implementation considerations" la phrase suivante

Citation
If the Authenticator does not receive a reply to its messages, it shall attempt dottRSNAConfigPairwiseUpdateCount transmits of the message, plus a final timeout

Mais iOS et Windows n'acceptent pas les retransmissions
Journalisée

Newbie Contest Staff :
Pixis
Statut :
Administrateur
Blog :
hackndo
the lsd
Administrateur

Profil challenge

Classement : 181/54681

Membre Héroïque
*****
Hors ligne Hors ligne
Messages: 3096

poulping for fun & profit


Voir le profil WWW
« #3 le: 17 Octobre 2017 à 17:04:21 »

Alors, euhhh, calmons nous. C'est pas siiiii clair que ça je crois.

Pour l'histoire de windows/IOS qui ne sont "pas vulnérables", en fait, ils le sont, mais via d'autres attaques. Donc, au final, ils restent pwned. Le truc, c'est que les deux OS ne respectent pas la RFC (qui autorise bien le renvoi du message 3). Le message est tout simplement droppé par win/ios. Donc, on peut dire que c'est safe dans ce cas, de ne pas respecter les specs ^^ (troll inside). Encore une fois, ça change au final walou puisqu'on peut utiliser d'autres méthodes

Ensuite, d'une manière générale, déterminer si c'est un bug de spec ou d'implem.... J'arrive pas encore trop à le savoir.

La spec définit, pour le message 3 :

"Updates the last-seen value of the Key Replay Counter field.
[...]
Key Replay Counter = n+1"

C'est donc le comportement normal à la réception du message 3 (pour un premier message ou un renvoi).

Sauf que... je n'ai pas réellement trouvé d'informations sur la manière de réagir lorsque ce message est retransmis, et donc ré-analysé par le client. Pas de trace sur le fait de devoir réinitialiser le compteur ni rien.
Je me suis peut être fourvoyé (la doc fait quand même 175 pages), mais en admettant que ce comportement ne soit pas expliqué dans la spec, on considère quoi ? Que c'est un bug de design puisque c'est une absence d'information ? Ou un bug d'implémentation parce que les devs sont en mode yolo ?

Enjoy

The lsd
Journalisée

Newbie Contest Staff :
The lsd - Th3_l5D (IRC)
Statut :
Administrateur
Citation :
Cartésien désabusé : je pense, donc je suis, mais je m'en fous !
ferbos

Profil challenge

Classement : 11/54681

Membre Senior
****
Hors ligne Hors ligne
Messages: 356

The Godfather is back....


Voir le profil WWW
« #4 le: 18 Octobre 2017 à 05:08:46 »

Juste comme ça. Quelqu'un a essayé?
Je demande parce que je suis très nul et que j'adore les exemples.

ferbos
« Dernière édition: 18 Octobre 2017 à 05:12:59 par ferbos » Journalisée

"Les seules limites sont les fautes."
the lsd
Administrateur

Profil challenge

Classement : 181/54681

Membre Héroïque
*****
Hors ligne Hors ligne
Messages: 3096

poulping for fun & profit


Voir le profil WWW
« #5 le: 18 Octobre 2017 à 09:14:22 »

Quoiiiiii ? En plus, je vais devoir faire un tuto vidéo ???? ^^'

(non, j'ai pas testé le script)

Enjoy

The lsd
Journalisée

Newbie Contest Staff :
The lsd - Th3_l5D (IRC)
Statut :
Administrateur
Citation :
Cartésien désabusé : je pense, donc je suis, mais je m'en fous !
pixis
Administrateur

Profil challenge

Classement : 17/54681

Membre Héroïque
*****
Hors ligne Hors ligne
Messages: 664


Voir le profil WWW
« #6 le: 18 Octobre 2017 à 09:49:31 »

EDIT : Mauvais paragraphe. cf. Message suivant avec la bonne citation de la spec

Sauf que... je n'ai pas réellement trouver d'information sur la manière de réagir lorsque ce message est retransmis, et donc ré-analysé par le client.

Dans la spec, on trouve ça :

Citation
On reception of Message 4, the Authenticator verifies that the Key Replay Counter field value is one that it used on this 4-Way Handshake; if it is not, it silently discards the message. Otherwise:
a) The  Authenticator  checks  the  MIC.  If  the  calculated  MIC  does  not  match  the  MIC  that  the Supplicant included in the EAPOL-Key frame, the Authenticator silently discards Message 4.
b) If the MIC is valid, the Authenticator uses the MLME-SETKEYS.request primitive to configure the PTK into the IEEE 802.11 MAC.
c) The Authenticator updates the Key Replay Counter field so that it will use a fresh value if a rekey becomes necessary

Donc sauf sans le cas où le KRC n'est pas valide, il ne doit pas le discard si je comprends bien.
Journalisée

Newbie Contest Staff :
Pixis
Statut :
Administrateur
Blog :
hackndo
the lsd
Administrateur

Profil challenge

Classement : 181/54681

Membre Héroïque
*****
Hors ligne Hors ligne
Messages: 3096

poulping for fun & profit


Voir le profil WWW
« #7 le: 18 Octobre 2017 à 10:04:16 »

On parle pas de la même chose je crois ^^

Ta quote parle de la réception du message 4 par l'AP. Effectivement, il faut que le KRC soit valide pour que le message soit accepté. Donc que le KRC soit déjà passé dans le 4way handshake.

Ce dont je parlais, c'était justement quand le message 4 n'est pas reçu par l'AP, et que l'AP ré-émet le message 3 vers le client, quel doit être la réaction du client lors de la 2ème réception dudit message 3.

Enjoy

The lsd
Journalisée

Newbie Contest Staff :
The lsd - Th3_l5D (IRC)
Statut :
Administrateur
Citation :
Cartésien désabusé : je pense, donc je suis, mais je m'en fous !
pixis
Administrateur

Profil challenge

Classement : 17/54681

Membre Héroïque
*****
Hors ligne Hors ligne
Messages: 664


Voir le profil WWW
« #8 le: 18 Octobre 2017 à 10:26:10 »

My bad, problème de paragraphe :

Citation
On reception of Message 3, the STA_P silently discards the message if the Key Replay Counter field value has already been used or if the INonce value in Message 3 differs form the INonce value in Message 1. Otherwise,
a) The STA_P verifies the Message 3 MIC using SKCK key in SMKSA. If the calculated MIC doesnot match the MIC that the STA_P included in the EAPOL-Key frame, the STA_I silently discards Message 3.
b) If the MIC is valid, the STA_P checks that the RSNIE bit-wise matches that from the 4-Way Handshake Message 2. If these are not exactly the same, STA_P silently discards the message and deletes existing 4-Way Handshake states.
c) If they do match, the STA_P constructs Message 4. It also compares the Key Lifetime value fromKDE with value in its SMKSA. If value in SMKSA is less, it discards the value received in Message 3. Otherwise, it updates the value in SMKSA with value in Message 3.

Donc si le KRP a déjà été used (mais c'est pas le cas parce que l'AP l'incrémente) ou si le nonce diffère du message 1 (ce qui n'est pas le cas non plus), le message doit être discard, sinon, il doit être traité.
Journalisée

Newbie Contest Staff :
Pixis
Statut :
Administrateur
Blog :
hackndo
pitchoule

Profil challenge

Classement : 561/54681

Néophyte
*
Hors ligne Hors ligne
Messages: 16


Voir le profil
« #9 le: 18 Octobre 2017 à 15:00:58 »

Salut à tous,

c'est super instructif tous ça !
Merci à @the lsd pour l'explication 

Par contre je pense que ta CPU chauffe trop @the lsd ca fait 2 fois que tu parles de "handhake" au lieu de "handshake".
Ou c'est moi qui n'est pas tout compris 
Journalisée

P17CH0U13-X
la mort c'est l'arrêt du coeur l'amour c'est la raie du cul !
the lsd
Administrateur

Profil challenge

Classement : 181/54681

Membre Héroïque
*****
Hors ligne Hors ligne
Messages: 3096

poulping for fun & profit


Voir le profil WWW
« #10 le: 18 Octobre 2017 à 16:34:19 »

Je vois pas DU TOUT ce que tu veux dire

Merci de m'avoir prévenu
Journalisée

Newbie Contest Staff :
The lsd - Th3_l5D (IRC)
Statut :
Administrateur
Citation :
Cartésien désabusé : je pense, donc je suis, mais je m'en fous !
pixis
Administrateur

Profil challenge

Classement : 17/54681

Membre Héroïque
*****
Hors ligne Hors ligne
Messages: 664


Voir le profil WWW
« #11 le: 19 Octobre 2017 à 12:28:41 »

Bon du coup comme ce sujet m'a beaucoup intéressé, et que j'y ai passé pas mal de temps, je me suis également fendu d'une analyse technique.

http://beta.hackndo.com/krack/
Journalisée

Newbie Contest Staff :
Pixis
Statut :
Administrateur
Blog :
hackndo
the lsd
Administrateur

Profil challenge

Classement : 181/54681

Membre Héroïque
*****
Hors ligne Hors ligne
Messages: 3096

poulping for fun & profit


Voir le profil WWW
« #12 le: 19 Octobre 2017 à 13:25:55 »

Je comprend mieux pourquoi tu me posais plein de questions hier :p
Et tu m'as même pas mis dans les remerciements de l'article pour t'avoir aidé quoi ! ^^

Pas encore pris le temps de lire, mais ça a l'air propre en tout cas, t'as fait des magnifiques schémas et tout !

Enjoy

The lsd
Journalisée

Newbie Contest Staff :
The lsd - Th3_l5D (IRC)
Statut :
Administrateur
Citation :
Cartésien désabusé : je pense, donc je suis, mais je m'en fous !
pixis
Administrateur

Profil challenge

Classement : 17/54681

Membre Héroïque
*****
Hors ligne Hors ligne
Messages: 664


Voir le profil WWW
« #13 le: 19 Octobre 2017 à 14:11:39 »

Grave erreur et oubli de ma part. C'est fixed !
Journalisée

Newbie Contest Staff :
Pixis
Statut :
Administrateur
Blog :
hackndo
Pages: [1]
  Imprimer  
 
Aller à: