ANDROID

[ANDROID][bsummary]

FACEBOOK

[FACEBOOK][twocolumns]

NOTÍCIAS

[NOTÍCIAS][bleft]

KALI LINUX

[KALI LINUX][grids]

Código de Prova Conceito para WPA2 Krack Attack foi lançado

WPA2 Krack Attack has been released



Pesquisadores de segurança descobriram várias vulnerabilidades de gerenciamento de chaves no núcleo do protocolo Wi-Fi Protected Access II (WPA2) que poderia permitir que um invasor invadisse sua rede Wi-Fi e espiasse as comunicações da Internet.
O WPA2 é um esquema de autenticação de WiFi de 13 anos, amplamente utilizado para proteger conexões WiFi, mas o padrão foi comprometido, impactando quase todos os dispositivos Wi-Fi - incluindo em nossas casas e empresas, junto com as empresas de rede que as compõem.
Apelidado  Krack - Key reinstalação Ataque -a ataque prova-de-conceito demonstrado por uma equipe de pesquisadores trabalha contra todas as redes modernas protegidas Wi-Fi e pode ser abusado para roubar informações confidenciais, como números de cartão de crédito, senhas, mensagens de chat, e-mails, e fotos.
Uma vez que os pontos fracos residem no próprio padrão Wi-Fi, e não nas implementações ou em qualquer produto individual, qualquer implementação correta do WPA2 provavelmente será afetada.
Segundo os pesquisadores, o ataque recentemente descoberto funciona contra:
  • Tanto WPA1 como WPA2,
  • Redes pessoais e empresariais
  • Cifras WPA-TKIP, AES-CCMP e GCMP

CVE-2017-13082: chave reinstalar em FT Handshake
(802.11r)

Pontos de acesso (APs) podem conter uma implementação vulnerável do aperto de mãos rápidas de Transição BSS (FT). Mais precisamente, uma Solicitação de Reassociação FT retransmitida ou reproduzida pode enganar o AP para reinstalar a chave pairwise. Se o AP não processar solicitações de reassociação FT retransmitidas, ou se não reinstalar a chave pairwise, ela não é vulnerável. Se ele reinstalar a tecla pairwise, o efeito é semelhante ao ataque contra o handshake de 4 vias, exceto que o AP em vez do cliente agora está reinstalando uma chave. Mais precisamente, o AP posteriormente reutilizará os números de pacotes ao enviar quadros protegidos usando TKIP, CCMP ou GCMP. Isso faz com que não seja reutilizado, anulando qualquer segurança que esses esquemas de criptografia devem fornecer. Como o número do pacote também é usado como um contador de repetição para quadros recebidos, os quadros enviados Para  o AP também pode ser reproduzido.
Em contraste com o handshake de 4 vias e o handshake da chave do grupo, isso não é um ataque contra a especificação. Ou seja, se a máquina de estado, como mostrado na Figura 13-15 do padrão 802.11-2016, é fielmente implementada, o AP não reinstalará as chaves pairwise ao receber uma Solicitação de Reassociação FT retransmitida. Contudo, descobrimos que muitos APs processam esse quadro e reinstalam a chave pairwise.

Instruções de uso de scripts

Criamos scripts para determinar se uma implementação é vulnerável a qualquer um dos nossos ataques. Esses scripts foram testados no Kali Linux. Para instalar as dependências necessárias no Kali, execute:
apt-get update
apt-get install libnl-3-dev libnl-genl-3-dev pkg-config libssl-dev net-tools git sysfsutils python-scapy python-pycryptodome
Lembre-se de desativar o Wi-Fi no seu gerenciador de rede antes de usar nossos scripts. Depois de fazer isso, execute  sudo rfkill unblock wifi assim nossos scripts ainda podem usar Wi-Fi.
O script Linux incluído  krack-ft-test.py pode ser usado para determinar se um AP é vulnerável ao nosso ataque. O script contém documentação detalhada sobre como usá-lo:
./krack-ft-test.py --help

Essencialmente, envolve um wpa_supplicant cliente normal  e continuará reproduzindo a Solicitação de Reassociação FT (fazendo o AP reinstalar o PTK). Testamos o script em uma distribuição Kali Linux usando um dongle WiFi USB (um TP-Link WN722N v1).
Lembre-se que este não é um script de ataque! Você precisa de credenciais na rede para testar se um ponto de acesso é afetado pelo ataque.
Esta ferramenta pode dizer incorretamente que um AP é vulnerável a devidas retransmissões benignas de quadros de dados.  No entanto, já lançamos esse código porque o script ficou vazado. Execute esse script em um ambiente com baixo ruído de fundo. As retransmissões benignas podem ser detectadas na saída do script: se dois quadros de dados tiverem o mesmo  seq (número de seqüência), é uma retransmissão benigna. Exemplo de uma retransmissão tão benigna:
[15:48:47] AP transmitted data using IV=5 (seq=4)
[15:48:47] AP transmitted data using IV=5 (seq=4)
[15:48:47] IV reuse detected (IV=5, seq=4). AP is vulnerable!

Aqui houve uma retransmissão benigna de um quadro de dados, porque ambos os quadros usavam o mesmo número de seqüência ( seq). Isso incorretamente foi detectado como reutilização de IV. Há um código para corrigir isso pronto, mas a fusão dessas correções pode levar algum tempo.

Solução sugerida

Se a implementação for vulnerável, a correção sugerida é semelhante à do handshake de 4 vias. Ou seja, um booleano pode ser adicionado de modo que o primeiro FT Reassociation Requests instale as chaves pairwise, mas qualquer retransmissão irá ignorar a instalação da chave. Note que, idealmente, o AP ainda deve enviar uma nova Resposta de Reassociação FT, mesmo que não tenha reinstalado nenhuma chave.

Detalhes de Impacto e Exploração

A exploração dessa vulnerabilidade não requer uma posição do homem no meio! Em vez disso, um adversário simplesmente precisa capturar um aperto de mão rápido Transição BSS e salvar o Pedido de Reassociação FT. Como este quadro não contém um contador de repetição, o adversário pode reproduzi-lo a qualquer momento (e arbitrariamente muitas vezes). Cada vez que o AP vulnerável recebe o quadro reproduzido, a chave pairwise será reinstalada. Este ataque está ilustrado na Figura 9 do artigo.
Um adversário pode desencadear FT handshakes à vontade conforme a seguir. Primeiro, se nenhum outro AP da rede estiver dentro do alcance do cliente, o adversário clona um AP real desta rede ao lado do cliente usando um ataque de minhoca (ou seja, encaminhamos todos os quadros pela internet). O adversário envia um pedido de gerenciamento de transição do BSS para o cliente. Esse pedido ordena ao cliente roaming para outro AP. Como resultado, o cliente executará um aperto de mão FT para roam para o outro AP.
exemplo de rastreamento de rede incluído  - ft.pcapng  é um exemplo do ataque executado contra o hostapd do Linux. Ao usar o filtro wireshark  wlan.sa == 7e:62:5c:7a:cd:47, observe que os pacotes 779 a 1127 usam o valor CCMP IV 1. Isso foi causado por retransmissões maliciosas do pedido de reassociação FT.
0 comentários via Blogger
comentários via Facebook

Nenhum comentário :