Wireshark WPA handshake de 4 vias


13

A partir desta página wiki :

O WPA e o WPA2 usam chaves derivadas de um handshake EAPOL para criptografar o tráfego. A menos que todos os quatro pacotes de handshake estejam presentes na sessão que você está tentando descriptografar, o Wireshark não poderá descriptografar o tráfego. Você pode usar o eapol do filtro de exibição para localizar pacotes EAPOL em sua captura.

Notei que a descriptografia funciona com (1, 2, 4) também, mas não com (1, 2, 3). Tanto quanto sei, os dois primeiros pacotes são suficientes, pelo menos para o 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, dado que o quarto pacote é apenas um reconhecimento? Além disso, é garantido que o (1, 2, 4) funcionará sempre quando (1, 2, 3, 4) funcionar?

Caso de teste

Este é o handshake compactado com gzip (1, 2, 4) e um ARPpacote criptografado (SSID :, SSIDsenha :) passwordna 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 verificar 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 O ARP 192.168.1.1 está em 00: a0: c5: 68: 3a: e4

Ele pode não .. ele deve ser descriptografar porque tem todos os quatro, ou você está conectado à rede Wi-Fi e que é descriptografar os pacotes
Paul

Estou (obviamente) falando sobre pacotes capturados no modo RFMON.
precisa

@ Paul: eu editei a pergunta; Você pode responder?
precisa

Eu queria poder. Se você seguir a sequência EAPOL, o cliente terá o PTK após apenas o primeiro pacote (o anonce é passado). O AP conhece o PTK após o segundo pacote (snonce). Se você observar esses dois e conhecer os MACs, é claro que você faz, e o ssid + psk, isso deve ser tudo o que você precisa. O terceiro pacote é apenas GTK para transmissão e multicast, e o quarto é apenas um ACK. Se você estiver descriptografando o unicast (que é a resposta arp), os dois primeiros pacotes deverão ser suficientes. Não posso deixar de pensar que estou perdendo algo, pois tudo diz que você precisa dos quatro.
Paul

Você chegou mais longe com isso?
Paul

Respostas:


1

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 instaladas no autenticador quando ele recebe 4/4 [1]. Se o Wireshark precisar manipular o rekeying corretamente, ele deverá usar as chaves somente após a leitura do pacote 4/4 no quadro, pois os pacotes ainda poderão estar fluindo durante o rekeying (mesmo no caso em que não devem, por causa do buffer)

Para o primeiro 4WHS, não é possível esperar por 4/4, mas é perfeitamente compreensível que eles tenham sido preguiçosos em 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 de ARP do AP ou de um cliente para o qual você não faz parte do seu 4WHS) e chaves de gerenciamento. Você também pode pular 3/4, mas não tem confirmação de que a troca foi bem-sucedida, pois 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. O reenvio de 3/4 criptografado com a chave antiga não ajudará. . Esse problema, entre muitos outros com o WPA2, é solucionado no mais recente padrão 802.11 2012, mantendo duas chaves em paralelo.


1

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

Sem a etapa 3, você não terá o GTK, portanto, descriptografar 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 / ponto de acesso não começará a usar a criptografia. O Wireshark pode desativar isso antes de tentar descriptografar os dados também.


0

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

Saindo da documentação aqui :

  • Após o EAPOL 1 e 2, os dois lados conhecem a chave temporal que será usada para descriptografar o tráfego.
  • A terceira mensagem é prova de que os dois lados conhecem a chave temporal e indica que o autenticador (a estação base) está pronto para começar a usar a chave temporal.
  • A quarta mensagem aciona a troca do PMK configurado antes do EAPOL para a chave temporal derivada no 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 aguarda para começar a usá-las para descriptografar o tráfego até depois de 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 que a mensagem 3 esteja presente para o WireShark descriptografar a sessão.


Parece-me que o pacote 4 também não é necessário - ele foi projetado apenas para aguardar.
Paul

@Paul, é como dizer que "currículo" não é necessário após uma "pausa".
Old Pro

@ OldPro, não tenho certeza de que esperar 4 ° é uma boa idéia, os pacotes capturados tendem a se perder, especialmente quando viajam pelo ar.
CYrus

@cYrus, a espera de 4 é essencial, pois as chaves de criptografia precisam ser alteradas simultaneamente nos dois lados. Se o cliente não receber 4, ele não saberá que a base recebeu 3. Se o cliente não receber 4, enviará 3 novamente (o que desencadeia um reenvio de 4) até receber 4 ou desistir de tentar para criar a conexão.
Old Pro

@ OldPro: Eu não estou falando sobre o protocolo. Ambos os lados podem receber todos os pacotes, mas podem ser descartados ou não capturados pela entidade que captura passivamente o tráfego.
CYrus

0

Isso não explica por que, mas citando o-ng airdecap documentação de qualquer maneira,

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. 
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.