☰

Caso de teste

tag-icon • tag-icon wireshark wpa decryption
Caso de teste

Deesta página wiki:

WPA e WPA2 usam chaves derivadas de um handshake EAPOL para criptografar o tráfego. A menos quetodos os quatropacotes de handshake estiverem presentes para a sessão que você está tentando descriptografar, o Wireshark não será capaz de descriptografar o tráfego. Você pode usar o filtro de exibição eapol para localizar pacotes EAPOL em sua captura.

Percebi que a descriptografia também funciona com (1, 2, 4), mas não com (1, 2, 3). Pelo que eu sei, os dois primeiros pacotes são suficientes, pelo menos no que diz respeito ao tráfego unicast. Alguém pode explicar exatamente como o Wireshark lida com isso, em outras palavras, por que apenas a sequência anterior funciona, visto que o quarto pacote é apenas uma confirmação? Além disso, é garantido que (1, 2, 4) sempre funcionará quando (1, 2, 3, 4) funcionar?

Caso de teste

Este é o handshake compactado (1, 2, 4) e um ARPpacote criptografado (SSID:, SSIDsenha password:) na base64codificação:

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

Decodifique com:

$ base64 -d | gunzip > handshake.cap

Execute tsharkpara ver se ele descriptografou corretamente o ARPpacote:

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

Deve imprimir:

  1 0,000000 D-Link_a7:8e:b4 -> HonHaiPr_22:09:b0 Chave EAPOL
  2 0.006997 HonHaiPr_22:09:b0 -> D-Link_a7:8e:b4 Chave EAPOL
  3 0.038137 HonHaiPr_22:09:b0 -> D-Link_a7:8e:b4 Chave EAPOL
  4 0.376050 ZyxelCom_68:3a:e4 -> HonHaiPr_22:09:b0 ARP 192.168.1.1 está em 00:a0:c5:68:3a:e4

Responder1

As trocas EAPOL também são usadas para renovar as chaves temporais. As novas chaves são instaladas no Suplicante após o envio de 4/4, e são instaladas no Autenticador quando ele recebe 4/4[1]. Se o Wireshark precisar lidar com a rechaveamento corretamente, ele só deverá usar as chaves após ler o pacote 4/4 no quadro, pois os pacotes ainda podem estar fluindo durante a rechaveamento (mesmo no caso em que não deveriam, por causa do buffer).

Para os primeiros 4WHS, não esperar por 4/4 é possível, mas é perfeitamente compreensível que eles tenham tido preguiça de implementá-lo. 3/4 ainda é necessário, pois contém chaves de grupo (mesmo que você não esteja interessado nelas, mas saiba que não verá solicitações ARP do AP ou de um cliente para o qual você não possui parte de seu 4WHS) e chaves de gerenciamento. Você pode pular 3/4 também, mas não terá confirmação de que a troca foi bem-sucedida, porque 3/4 é usado para verificar se o Autenticador conhece o PMK.

[1] Observe que com o esquema atual, se a mensagem 4/4 for perdida, o suplicante começará a usar a nova chave e o autenticador ainda usará a chave antiga, e reenviar 3/4 criptografado com a chave antiga não ajudará . Este problema, entre muitos outros com o WPA2, é resolvido no padrão mais recente 802.11 2012, mantendo duas chaves em paralelo.

Responder2

Todas as informações necessárias para construir o PTK são trocadas nas etapas 1 e 2. Isto deve ser suficiente para descriptografar o tráfego unicast.

Sem a etapa 3, você não terá o GTK, portanto, a descriptografia de multicast/broadcast não será possível.

A etapa 4 não é realmente necessária para descriptografar o tráfego de captura, mas se não houver uma etapa 4, o cliente/AP não começará a usar a criptografia. O Wireshark pode desativar isso antes de tentar descriptografar os dados também.

Responder3

Bem, obviamente a documentação do WireShark está errada. :-)

Saindo da documentaçãoaqui:

  • Após EAPOL 1 e 2 ambos os lados conhecem a chave temporal que será usada para descriptografar o tráfego.
  • A terceira mensagem é a prova de que ambos os lados conhecem a chave temporal e indica que oAutenticador(a estação base) está pronta para começar a usar a chave temporal.
  • A quarta mensagem aciona a mudança do PMK configurado antes do EAPOL para a chave temporal derivada do EAPOL

Então, com isso, faz sentido. O WireShark não precisa da mensagem 3 para nada. Ele conhece as chaves após as mensagens 1 e 2, mas espera para começar a usá-las para descriptografar o tráfego até receber a mensagem 4.

Não há garantias para nada na vida, especialmente o comportamento do software livre, mas é uma aposta razoável que não haverá um requisito para a mensagem 3 estar presente para que o WireShark descriptografe a sessão.

Responder4

Isso não explica o porquê, mas citando o airdecap-ngdocumentaçãode qualquer forma,

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.

informação relacionada