Skip to content
KitploitKITPLOIT
FerramentasExploitsBlog
Log in
Enviar
FerramentasExploitsBlog
Enviar

Ferramentas de Hacking, PenTest e Cibersegurança para o seu Arsenal de Segurança!

Kitploit é um diretório de ferramentas de hacking, cibersegurança e pentesting. Descubra as últimas atualizações de projetos para encontrar vulnerabilidades, analisar sistemas, automatizar testes e fortalecer sua segurança.

FeedsContatoPrivacidade© 2026 Kitploit

Diretório de Ferramentas

Categorias

Ver todas as categorias
Loading categories
krackattacks-scripts — Scripts para verificar clientes WPA2 e APs quanto a vulnerabilidades de reinstalação de chave KRACK usando hostapd modificado e replay de quadros em modo monitor. | Kitploit
Ferramentas/GitHubGitHub/vanhoefm/krackattacks-scripts
Auditoria de Wi-FiAnálise de VulnerabilidadesSegurança Sem FioTestes de PenetraçãoTop em Auditoria de Wi-Fi nº10Top em Segurança Sem Fio nº10

Mais Populares

Ver todos →

Descubra as ferramentas mais usadas pela nossa comunidade.

Explore todas as ferramentas

Navegue pela nossa coleção de ferramentas

Ver todas as ferramentas →
Compartilhar
GitHub
vanhoefm/krackattacks-scripts

krackattacks-scripts

Scripts para verificar clientes WPA2 e APs quanto a vulnerabilidades de reinstalação de chave KRACK usando hostapd modificado e replay de quadros em modo monitor.

Ver Repositório
3.5k76666há 1 anoRevisado pelo Kitploit

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: ping 192.168.100.254.

  5. ./krack-test-client.py --tptk. Idêntico ao teste 4, exceto que uma mensagem 1 forjada é injetada antes de enviar a mensagem 3 criptografada. Essa variante do teste é importante porque alguns clientes (por exemplo, wpa_supplicant v2.6) só são vulneráveis a reinstalações da chave pairwise no handshake de 4 vias quando uma mensagem 1 forjada é injetada antes do envio de uma mensagem 3 retransmitida.

  6. ./krack-test-client.py --tptk-rand. Igual ao teste acima, exceto que a mensagem 1 forjada contém um ANonce aleatório.

  7. ./krack-test-client.py --gtkinit. Este teste verifica se o cliente instala a chave de grupo no handshake de 4 vias com o contador de sequência de recepção (RSC) fornecido. Isso é feito retransmitindo Msg3/4 do handshake de 4 vias, cada vez com uma nova chave de grupo e um contador de replay muito alto. Sabemos que é vulnerável se o cliente em teste, depois disso, aceitar quadros de broadcast com um contador de replay mais baixo. Infelizmente, alguns clientes não aceitam Msg3/4 retransmitidas, o que significa que tais clientes não podem ser testados com este comando. Clientes que aceitam uma Msg3/4 retransmitida e, portanto, podem ser testados com este comando, responderão com uma Msg4/4 que pode ser detectada com base na seguinte saída:

	[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.

Baixar ferramenta