This project contains scripts to test if clients or access points (APs) are affected by the KRACK attack against WPA2. For details behind this attack see our website and the research paper.

Remember that our scripts are not attack scripts! You will need the appropriate network credentials in order to test if an access point or client is affected by the KRACK attack.

Dezembro de 2024: um bug foi corrigido no 7º teste ./krack-test-client.py --gtkinit. Antes dessa correção, era mencionado que (a saída de) este teste não era confiável, mas agora a saída deve ser confiável ao seguir as novas instruções. Ou seja, quando este teste agora indica que o dispositivo é vulnerável, é de fato provável que seja vulnerável.

Janeiro de 2021: os scripts foram tornados compatíveis com Python3 e foram atualizados para suportar melhor as distribuições Linux mais recentes. Se você quiser reverter para a versão antiga, execute git fetch --tags && git checkout v1 após clonar o repositório (e volte para a versão mais recente usando git checkout research).

Pré-requisitos

Nossos scripts foram testados no Kali Linux. Para instalar as dependências necessárias no Kali, execute:

sudo apt update
sudo apt install libnl-3-dev libnl-genl-3-dev pkg-config libssl-dev net-tools git sysfsutils python3-venv iw

Agora compile nossa instância modificada do hostapd e crie um ambiente virtual Python. Isso garante que você esteja usando bibliotecas Python compatíveis (aquelas listadas em krackattack/requirements.txt):

git clone https://github.com/vanhoefm/krackattacks-scripts.git
cd krackattacks-scripts/krackattack
./build.sh
./pysetup.sh

Em seguida, desative a criptografia de hardware para obter resultados ideais:

cd krackattack
sudo ./disable-hwcrypto.sh

Observe que, se necessário, você pode reativar a criptografia de hardware usando o script sudo ./reenable-hwcrypto.sh. É recomendável reiniciar após desativar a criptografia de hardware. Testamos nossos scripts com um Intel Dual Band Wireless-AC 7260 e um TP-Link TL-WN722N v1 no Kali Linux.

Antes de cada uso

Toda vez antes de usar os scripts, você deve desativar o Wi-Fi no seu gerenciador de rede. Em seguida, execute:

sudo rfkill unblock wifi
cd krackattack
sudo su
source venv/bin/activate

Depois de fazer isso, você pode executar os scripts várias vezes, desde que não feche o terminal.

Se você quiser reverter os efeitos do disable-hwcrypto.sh, exclua o arquivo /etc/modprobe.d/nohwcrypt.conf.

Testando Clientes

Primeiro modifique hostapd/hostapd.conf e edite a linha interface= para especificar a interface Wi-Fi que será usada para executar os testes. Observe que, para todos os testes, quando o script estiver em execução, você deve permitir que o dispositivo testado se conecte ao SSID testnetwork usando a senha abcdefgh. Você pode alterar as configurações do AP modificando hostapd/hostapd.conf. Em todos os testes, o cliente deve usar DHCP para obter um IP após se conectar à rede Wi-Fi. Isso ocorre porque alguns testes só começam depois que o cliente solicitou um IP via DHCP!

Você deve agora executar os seguintes testes localizados no diretório krackattacks/:

1. ./krack-test-client.py --replay-broadcast. Este teste verifica se o cliente aceita quadros de broadcast repetidos. Se o cliente aceitar quadros de broadcast repetidos, isso deve ser corrigido primeiro. Se você não corrigir o cliente, nosso script não conseguirá determinar se a chave de grupo está sendo reinstalada (porque, então, o script sempre dirá que a chave de grupo está sendo reinstalada).

2. ./krack-test-client.py --group --gtkinit. Este teste verifica se o cliente instala a chave de grupo no handshake de chave de grupo com o contador de sequência de recepção (RSC) fornecido. Veja a seção 6.4 do nosso artigo de pesquisa complementar para os detalhes por trás dessa vulnerabilidade.

3. ./krack-test-client.py --group. Este teste verifica se o cliente reinstala a chave de grupo no handshake de chave de grupo. Em outras palavras, testa se o cliente é vulnerável ao CVE-2017-13080. O script testa reinstalações da chave de grupo enviando solicitações ARP de broadcast para o cliente usando um número de pacote já usado (repetido) (aqui número de pacote = nonce = IV). Observe que, se o cliente sempre aceitar quadros de broadcast repetidos (veja --replay-broadcast), este teste pode concluir incorretamente que a chave de grupo está sendo reinstalada.

4. ./krack-test-client.py. Este teste verifica reinstalações de chave no handshake de 4 vias enviando repetidamente mensagens 3 criptografadas para o cliente. Em outras palavras, este teste verifica o CVE-2017-13077 (a vulnerabilidade de maior impacto) e o CVE-2017-13078. O script monitora o tráfego enviado pelo cliente para ver se a chave pairwise está sendo reinstalada. Observe que isso efetivamente executa dois testes: se a chave pairwise é reinstalada e se a chave de grupo é reinstalada. Certifique-se de que o cliente solicite um IP usando DHCP para que o teste de reinstalação da chave de grupo comece. Para garantir que o cliente esteja enviando quadros unicast suficientes, você pode, opcionalmente, dar ping no AP: .

	[09:24:11] 02:20:2a:22:a8:30: received a new message 4

Também recomendamos executar este teste em ambientes com pouco ruído de fundo e executá-lo várias vezes.

Algumas observações adicionais:

• O teste mais importante é ./krack-test-client, que verifica reinstalações comuns de chave no handshake de 4 vias.

• Execute estes testes em uma sala com pouca interferência. Uma alta quantidade de perda de pacotes tornará este script menos confiável!

• Opcionalmente, você pode inspecionar manualmente o tráfego de rede para confirmar a saída do script (algumas placas de rede Wi-Fi podem interferir em nossos scripts):

  • Use uma placa de rede Wi-Fi extra em modo monitor para confirmar que nosso script (o AP) envia quadros usando os números de pacote (IVs) adequados. Em particular, verifique se os quadros de broadcast repetidos são de fato enviados usando um número de pacote já usado (IV).

  • Use uma placa de rede Wi-Fi extra em modo monitor para verificar reinstalações da chave pairwise monitorando os IVs dos quadros enviados pelo cliente.

  • Capture o tráfego no cliente para ver se as solicitações ARP de broadcast repetidas são aceitas ou não.

• Se o cliente puder usar vários rádios/placas de rede Wi-Fi, execute o teste usando várias placas de rede Wi-Fi.

• Você pode adicionar o parâmetro --debug para obter mais saída de depuração.

• Todos os parâmetros não reconhecidos são repassados para o hostapd, então você pode incluir algo como -dd -K para fazer o hostapd exibir todas as informações de depuração.

Correspondência com os testes da Wi-Fi Alliance

A Wi-Fi Alliance criou uma ferramenta personalizada de detecção de vulnerabilidades baseada em nossos scripts. No momento em que este texto foi escrito, essa ferramenta é acessível apenas aos membros da Wi-Fi Alliance. As ferramentas deles suportam vários testes diferentes, e esses testes correspondem à funcionalidade do nosso script da seguinte forma:

• 4.1.1 (Retransmissão em texto claro da Mensagem 3 EAPOL). Atualmente, não oferecemos suporte a esse teste. Esse teste não é necessário de qualquer forma. Certifique-se de que o dispositivo testado passe no teste 4.1.3 e, então, ele também passará neste teste.

• 4.1.2 (Retransmissão imediata da EAPOL M3 em texto claro). Atualmente, não oferecemos suporte a esse teste. Novamente, certifique-se de que o dispositivo testado passe no teste 4.1.3 e, então, ele também passará neste teste.

• 4.1.3 (Retransmissão imediata da EAPOL M3 criptografada durante o handshake de rekey pairwise). Isso corresponde a ./krack-test-client.py, exceto que as EAPOL M3 criptografadas são enviadas periodicamente em vez de imediatamente.

• 4.1.5 (Reinstalação de PTK no handshake de 4 vias quando a STA usa construção temporal de PTK, mesmo ANonce). Execute este teste usando ./krack-test-client.py --tptk.

• 4.1.6 (Reinstalação de PTK no handshake de 4 vias quando a STA usa construção temporal de PTK, ANonce aleatório). Execute este teste usando ./krack-test-client.py --tptk-rand.

• 4.2.1 (Teste de vulnerabilidade do handshake de chave de grupo na STA). Execute este teste usando ./krack-test-client.py --group.

• 4.3.1 (Reinstalação de GTK e IGTK na STA com suporte ao modo de suspensão WNM). Atualmente, não oferecemos suporte a esse teste (e, na verdade, a Wi-Fi Alliance também não!).

Testando Pontos de Acesso: Detectando um Handshake FT Vulnerável (802.11r)

1. Crie um arquivo de configuração do wpa_supplicant que possa ser usado para se conectar à rede. Um exemplo básico é:

   root@kitploit:~

    ctrl_interface=/var/run/wpa_supplicant
    network={
      ssid="testnet"
      key_mgmt=FT-PSK
      psk="password"
    }
   

   Observe o uso de "FT-PSK". Salve-o como network.conf ou algo semelhante. Para mais informações, veja wpa_supplicant.conf.

2. Tente se conectar à rede usando o wpa_supplicant da sua plataforma. Provavelmente será necessário um comando como:

   root@kitploit:~

    sudo wpa_supplicant -D nl80211 -i wlan0 -c network.conf
   

   Se isso falhar, ou o AP não suporta FT, ou você forneceu as opções de configuração de rede erradas no passo 1. Observe que, se o AP não suporta FT, ele não é afetado por essa vulnerabilidade.

3. Use este script como um wrapper sobre o comando wpa_supplicant anterior:

   root@kitploit:~

    sudo su
    source venv/bin/activate
    ./krack-ft-test.py wpa_supplicant -D nl80211 -i wlan0 -c network.conf
   

   Isso executará o comando wpa_supplicant usando os parâmetros fornecidos e adicionará uma interface de monitor virtual que realizará os testes de ataque. É importante primeiro se tornar root e depois carregar o ambiente virtual Python (veja acima como criar esse ambiente virtual).

4. Use o wpa_cli para fazer roaming para um AP diferente da mesma rede. Por exemplo:

   root@kitploit:~

    wpa_cli -i wlan0
    > status
    bssid=c4:e9:84:db:fb:7b
    ssid=testnet
    ...
    > scan_results 
    bssid / frequency / signal level / flags / ssid
    c4:e9:84:db:fb:7b	2412  -21  [WPA2-PSK+FT/PSK-CCMP][ESS] testnet
    c4:e9:84:1d:a5:bc	2412  -31  [WPA2-PSK+FT/PSK-CCMP][ESS] testnet
    ...
    > roam c4:e9:84:1d:a5:bc
    ...
   

Extra: Descriptografia de Hardware

Para confirmar que a descriptografia de hardware está desativada, execute systool -vm ath9k_htc ou algo semelhante após conectar sua placa de rede Wi-Fi para confirmar que o parâmetro nohwcript/swcrypto/hwcrypto foi definido. Observe que você deve substituir ath9k_htc pelo módulo do kernel da sua placa de rede sem fio.

Extra: 5 GHz não suportado

Não há suporte oficial para testar dispositivos na banda de 5 GHz.

Se você quiser usar a ferramenta em canais de 5 GHz, a placa de rede usada deve permitir a injeção de quadros no canal de 5 GHz. Infelizmente, isso nem sempre é possível devido a restrições regulatórias. Para ver em quais canais você pode injetar quadros, execute iw list e procure em Frequencies por canais que não estejam marcados como disabled, no IR ou radar detection. Observe que essas condições podem depender da sua placa de rede, do país configurado atualmente e do AP ao qual você está conectado. Para mais informações, veja, por exemplo, a documentação do Arch Linux.

Observe que o kernel Linux pode não permitir a injeção de quadros, mesmo quando é permitido enviar quadros normais. Isso ocorre porque, na função ieee80211_monitor_start_xmit, o kernel se recusa a injetar quadros quando cfg80211_reg_can_beacon retorna falso. Como resultado, o Linux pode se recusar a injetar quadros mesmo quando isso é realmente permitido. Fazer cfg80211_reg_can_beacon retornar verdadeiro nas condições corretas (ou em todas) evita esse bug. Portanto, você terá que corrigir os drivers Linux para que cfg80211_reg_can_beacon sempre retorne verdadeiro, por exemplo, corrigindo manualmente o código do driver packport.

Extra: Testes Manuais

Também é possível realizar manualmente testes (mais detalhados) clonando o repositório git do hostap:

git clone git://w1.fi/srv/git/hostap.git

E seguindo as instruções em tests/cipher-and-key-mgmt-testing.txt.