Poignée de main à 4 voies Wireshark WPA

13

De cette page wiki :

WPA et WPA2 utilisent des clés dérivées d'une négociation EAPOL pour crypter le trafic. À moins que les quatre paquets de négociation ne soient présents pour la session que vous essayez de déchiffrer, Wireshark ne sera pas en mesure de déchiffrer le trafic. Vous pouvez utiliser le filtre d'affichage eapol pour localiser les paquets EAPOL dans votre capture.

J'ai remarqué que le déchiffrement fonctionne aussi avec (1, 2, 4), mais pas avec (1, 2, 3). Pour autant que je sache, les deux premiers paquets sont suffisants, du moins pour ce qui concerne le trafic unicast. Quelqu'un peut-il expliquer exactement comment Wireshark gère cela, en d'autres termes pourquoi seule la séquence précédente fonctionne, étant donné que le quatrième paquet n'est qu'un accusé de réception? De plus, est-il garanti que (1, 2, 4) fonctionnera toujours lorsque (1, 2, 3, 4) fonctionnera?

Cas de test

Il s'agit de la poignée de main gzippée (1, 2, 4) et d'un ARPpaquet crypté (SSID :, SSIDmot de passe :) passworddans l' base64encodage:

H4sICEarjU8AA2hhbmRzaGFrZS5jYXAAu3J400ImBhYGGPj / n4GhHkhfXNHr37KQgWEqAwQzMAgx
6HkAKbFWzgUMhxgZGDiYrjIwKGUqcW5g4Ldd3rcFQn5IXbWKGaiso4 + RmSH + H0MngwLUZMarj4Rn
S8vInf5yfO7mgrMyr9g / Jpa9XVbRdaxH58v1fO3vDCQDkCNv7mFgWMsAwXBHMoEceQ3kSMZbDFDn
ITk1gBnJkeX / GDkRjmyccfus4BKl75HC2cnW1eXrjExNf66uYz + VGLl + snrF7j2EnHQy3JjDKPb9
3fOd9zT0TmofYZC4K8YQ8IkR6JaAT0zIJMjxtWaMmCEMdvwNnI5PYEYJYSTHM5EegqhggYbFhgsJ
9gJXy42PMx9JzYKEcFkcG0MJULYE2ZEGrZwHIMnASwc1GSw4mmH1JCCNQYEF7C7tjasVT + 0 / J3LP
gie59HFL + 5RDIdmZ8rGMEldN5s668eb / tp8vQ + 7OrT9jPj / B7425QIGJI3Pft72dLxav8BefvcGU
7 + kfABxJX + SjAgAA

Décoder avec:

$ base64 -d | gunzip > handshake.cap

Exécutez tsharkpour voir s'il déchiffre correctement le ARPpaquet:

$ tshark -r handshake.cap -o wlan.enable_decryption:TRUE -o wlan.wep_key1:wpa-pwd:password:SSID

Il devrait imprimer:

  1 0.000000 D-Link_a7: 8e: b4 -> HonHaiPr_22: 09: b0 Clé EAPOL
  2 0,006997 HonHaiPr_22: 09: b0 -> D-Link_a7: 8e: b4 Clé EAPOL
  3 0,038137 HonHaiPr_22: 09: b0 -> D-Link_a7: 8e: b4 Clé EAPOL
  4 0.376050 ZyxelCom_68: 3a: e4 -> HonHaiPr_22: 09: b0 ARP 192.168.1.1 est à 00: a0: c5: 68: 3a: e4
cYrus
la source
Il ne peut pas .. il doit être déchiffré parce qu'il a les quatre, ou vous êtes connecté au réseau wifi et qui déchiffre les paquets
Paul
Je parle (évidemment) des paquets capturés en mode RFMON.
cYrus
@ Paul: J'ai édité la question; pouvez-vous répondre?
cYrus
SI seulement je pouvais. Si vous suivez la séquence EAPOL, le client n'a le PTK qu'après le premier paquet (l'anonce est passée). L'AP connaît le PTK après le deuxième paquet (snonce). Si vous observez ces deux et connaissez les MAC, ce que vous faites bien sûr, et le ssid + psk, alors cela devrait être tout ce dont vous avez besoin. Le troisième paquet est juste GTK pour la diffusion et la multidiffusion, et le quatrième est juste un ACK. Si vous déchiffrez unicast (qui est la réponse arp), les deux premiers paquets devraient suffire. Je ne peux pas m'empêcher de penser que je manque quelque chose car tout indique que vous avez besoin des quatre.
Paul
Avez-vous approfondi cela?
Paul

Réponses:

1

Les échanges EAPOL sont également utilisés pour renouveler les clés temporelles. Les nouvelles clés sont installées sur le Supplicant après l'envoi de 4/4 et sont installées sur l'Authenticator lorsqu'il reçoit 4/4 [1]. Si Wireshark doit gérer correctement la recomposition, il ne doit utiliser les clés qu'après avoir lu le paquet 4/4 dans le cadre, car les paquets peuvent toujours circuler pendant la recomposition (même s'ils ne le devraient pas, en raison de la mise en mémoire tampon)

Pour le premier 4WHS, il n'est pas possible d'attendre le 4/4, mais il est parfaitement compréhensible qu'ils étaient juste paresseux pour le mettre en œuvre. 3/4 est toujours nécessaire car il contient des clés de groupe (même si cela ne vous intéresse pas, mais sachez que vous ne verrez pas les demandes ARP de l'AP ou d'un client pour lequel vous n'avez aucune partie de ses 4WHS) et des clés de gestion. Vous pouvez également ignorer 3/4, mais vous n'avez aucune confirmation que l'échange a réussi, car 3/4 est utilisé pour vérifier que l'authentificateur connaît le PMK.

[1] Notez qu'avec le schéma actuel, si le message 4/4 est perdu, alors le demandeur a commencé à utiliser la nouvelle clé, et l'authentificateur utilise toujours l'ancienne clé, et renvoyer 3/4 crypté avec l'ancienne clé n'aidera pas . Ce problème, parmi tant d'autres avec WPA2, est résolu dans la dernière norme 802.11 2012 en gardant deux clés en parallèle.

BatchyX
la source
1

Toutes les informations nécessaires à la construction du PTK sont échangées aux étapes 1 et 2. Cela devrait être suffisant pour décrypter le trafic unicast.

Sans l'étape 3, vous n'aurez pas le GTK, donc le décryptage multicast / broadcast ne sera pas possible.

L'étape 4 n'est pas vraiment nécessaire pour déchiffrer le trafic de capture, mais s'il n'y a pas d'étape 4, le client / AP ne commencera pas à utiliser le chiffrement. Wireshark peut également désactiver cette fonctionnalité avant d'essayer de décrypter les données.

YLearn
la source
0

Eh bien, évidemment, la documentation de WireShark est erronée. :-)

En sortant de la documentation ici :

  • Après EAPOL 1 et 2, les deux parties connaissent la clé temporelle qui sera utilisée pour déchiffrer le trafic.
  • Le troisième message est la preuve que les deux parties connaissent la clé temporelle et indique que l' authentificateur (la station de base) est prêt à commencer à utiliser la clé temporelle.
  • Le quatrième message déclenche le passage du PMK configuré avant l'EAPOL à la clé temporelle dérivée dans l'EAPOL

Donc avec ça, ça a du sens. WireShark n'a besoin du message 3 pour rien. Il connaît les clés après les messages 1 et 2, mais il attend de commencer à les utiliser pour déchiffrer le trafic jusqu'à ce qu'il reçoive le message 4.

Il n'y a aucune garantie à quoi que ce soit dans la vie, en particulier le comportement des logiciels libres, mais il y a fort à parier qu'il ne sera pas nécessaire que le message 3 soit présent pour que WireShark déchiffre la session.

Old Pro
la source
Il me semble que le paquet 4 n'est pas nécessaire non plus - il est juste conçu pour l'attendre.
Paul
@Paul, c'est un peu comme dire que "reprendre" n'est pas nécessaire après une "pause".
Old Pro
@OldPro, je ne suis pas sûr qu'attendre 4 ° soit une bonne idée, les paquets capturés ont tendance à se perdre surtout lorsqu'ils voyagent dans les airs.
cYrus
@cYrus, attendre 4 est essentiel, car les clés de chiffrement doivent être changées simultanément des deux côtés. Si le client ne reçoit pas 4, il ne sait pas que la base en a reçu 3. Si le client ne reçoit pas 4, il envoie à nouveau 3 (ce qui déclenche un renvoi de 4) jusqu'à ce qu'il reçoive 4 ou renonce à essayer pour créer la connexion.
Old Pro
@OldPro: Je ne parle pas du protocole. Les deux côtés peuvent recevoir tous les paquets, mais ils peuvent être supprimés ou non capturés par l'entité qui capture passivement le trafic.
cYrus
0

Cela n'explique pas pourquoi, mais en citant de toute façon la documentation airdecap-ng ,

WPA/WPA2 Requirements

The capture file must contain a valid four-way handshake. For this purpose having (packets 2 and 3) or (packets 3 and 4) will work correctly. In fact, you don't truly need all four handshake packets. 
sybind
la source