vanhoefm/fragattacksTestador automatizado de vulnerabilidades para clientes Wi-Fi e pontos de acesso, que detecta falhas de fragmentação/agregação FragAttacks por meio de injeção de quadros, testes em modo misto e análise de captura de pacotes.
Este repositório contém a ferramenta FragAttacks. Ela pode testar clientes Wi-Fi e pontos de acesso para ataques de fragmentação e agregação. Essas vulnerabilidades afetam todas as redes Wi-Fi protegidas. Para mais informações sobre essas vulnerabilidades, consulte fragattacks.com.
Os seguintes recursos adicionais estão disponíveis:
Consulte o registro de alterações para uma visão geral detalhada das atualizações da ferramenta feitas desde 11 de agosto de 2020. Esse registro de alterações também contém informações sobre em qual versão do hostap a ferramenta FragAttacks se baseia.
Observe que os ataques são idênticos contra WPA2 e WPA3 porque seus cifradores de criptografia CCMP e GCMP são idênticos. Redes WPA mais antigas usam TKIP por padrão para criptografia, e a aplicabilidade dos ataques contra TKIP é discutida no artigo e no site. Para ilustrar que o Wi-Fi é vulnerável desde a sua criação, o artigo e o site também discutem brevemente a aplicabilidade dos ataques contra WEP.
Apenas placas de rede sem fio específicas são suportadas. Isso porque algumas placas de rede podem sobrescrever o número de sequência ou de fragmento de quadros injetados, ou podem reordenar quadros de prioridades diferentes, e isso interfere na ferramenta de teste (ou seja, a ferramenta pode indicar que um dispositivo é seguro quando não é). Eu confirmei que as seguintes placas de rede funcionam corretamente:
As duas últimas colunas significam:
Modo misto: se a placa de rede pode ser usada no modo misto recomendado.
Modo de injeção: se a placa de rede pode ser usada como uma segunda interface para injetar quadros no modo de injeção.
Sim indica que a placa funciona imediatamente no modo indicado. Driver/firmware corrigido significa que a placa é compatível quando usada com drivers e/ou firmware corrigidos. Não significa que esse modo não é suportado pela placa de rede. Recomendo usar a ferramenta de teste no modo misto.
Observe que dispositivos USB podem ser usados dentro de uma máquina virtual, e os drivers e/ou firmware modificados podem ser instalados nessa máquina virtual. No entanto, descobri que o uso de máquinas virtuais pode tornar as placas de rede menos confiáveis e, em vez disso, recomendo o uso de uma imagem USB ao vivo se você não puder instalar os drivers/firmware modificados nativamente.
Minha experiência com as placas de rede acima pode ser encontrada aqui. Resumidamente:
O AWUS036ACM no modo misto parece confiável com nossos drivers mais recentes e é o que eu recomendo. Um dispositivo mais barato, mas quase idêntico, é um com chipset MT7612U. Veja mais informações aqui.
Eu recomendava anteriormente o Technoethical N150 HGA no modo misto. Este dongle é idêntico ao TP-Link TL-WN722N v1.x e exige o uso de drivers e firmware corrigidos. É um dos dongles mais bem testados, mas é difícil de encontrar. Por isso, agora recomendo o AWUS036ACM.
Os Intel 3160 e 8265 são suportados e amplamente testados. Às vezes, o firmware deles travava, mas uma reinicialização torna a placa de rede utilizável novamente. O Intel AX200 não é compatível com a ferramenta de teste.
O WN111v2 parece funcionar bem, embora eu não o tenha testado extensivamente.
O driver para o AWUS036ACH não faz parte do kernel Linux e exige a instalação de um driver separado. No Kali, você pode instalar esse driver pelo gerenciador de pacotes. Esta placa não foi extensivamente testada.
Se você não conseguir encontrar uma das placas de rede acima, pode procurar por placas de rede alternativas que tenham grandes chances de também funcionar. Ao usar uma placa de rede que não é explicitamente suportada, recomendo fortemente executar primeiro os testes de injeção antes de usá-la, e usar a ferramenta contra uma implementação conhecidamente vulnerável para confirmar que a ferramenta funciona corretamente.
A ferramenta de teste foi testada no Ubuntu 20.04 usando o kernel 5.8. Se você usar outra distribuição Linux, observe que apenas versões de kernel iguais ou inferiores a 5.12 são suportadas.
Ao usar o Ubuntu 20.04, você primeiro precisará instalar o kernel 5.8 da seguinte forma. Observe que o seu kernel existente continuará instalado e também continuará sendo usado por padrão:
sudo apt install linux-image-5.8.0-63-generic linux-headers-5.8.0-63-generic linux-hwe-5.8-headers-5.8.0-63 \
linux-modules-5.8.0-63-generic linux-modules-extra-5.8.0-63-generic
Agora reinicie o Ubuntu, segure a tecla Shift durante a inicialização, selecione "Advanced options for Ubuntu" e inicie o kernel 5.8 escolhendo "Ubuntu, with Linux 5.8.0-63-generic". Você pode editar a configuração do GRUB para que o Ubuntu use essa versão do kernel por padrão. Continue as próximas instruções com esse kernel agora em execução.
Instale as dependências necessárias:
sudo apt-get update
sudo apt-get install libnl-3-dev libnl-genl-3-dev libnl-route-3-dev libssl-dev \
libdbus-1-dev git pkg-config build-essential macchanger net-tools python3-venv \
aircrack-ng rfkill firmware-ath9k-htc
# Note: on Kali linux use the package firmware-atheros instead of firmware-ath9k-htc
Agora clone este repositório, compile as ferramentas e configure um ambiente virtual python3:
git clone https://github.com/vanhoefm/fragattacks.git fragattacks
cd fragattacks/research
./build.sh
./pysetup.sh
As instruções acima só precisam ser executadas uma vez. Depois de obter novo código usando git, você
terá que executar ./build.sh e ./pysetup.sh novamente.
Instale os drivers corrigidos usando:
sudo apt-get install bison flex linux-headers-$(uname -r)
git clone https://github.com/vanhoefm/fragattacks-drivers58.git fragattacks-drivers58
cd fragattacks-drivers58
make defconfig-wifi
make -j 4
sudo make install
Isso compila os drivers para a maioria das placas de rede suportadas pelo Linux. Se você quiser compilar
apenas os drivers das placas de rede que testei explicitamente, use make defconfig-experiments.
Você pode obter os seguintes avisos:
make defconfig-wifi, você pode receber avisos relacionados a -Wyacc e -Wformat-overflow.
Você pode ignorar esses avisos, desde que os drivers sejam compilados com sucesso... needs unknown symbol ... Você pode ignorar esses avisos, desde que
eles não contenham o diretório /lib/modules/*/updates/ e os drivers compilados estejam funcionando.SSL error e o comando sign-file. Isso significa que a assinatura digital
dos módulos do kernel falhou. Você geralmente pode ignorar isso.cat /sys/module/mac80211/parameters/fragattack_version
após uma reinicialização. Se esse arquivo existir, os drivers modificados foram instalados com sucesso.Agora instale o firmware corrigido ath9k_htc:
cd research/ath9k-firmware/
./install.sh
# Now reboot
O script ./install.sh assume que as imagens de firmware ath9k_htc estão localizadas no
diretório /lib/firmware/ath9k_htc. Se esse não for o caso no seu sistema, você terá
que copiar manualmente htc_7010.fw e htc_9271.fw para o diretório apropriado.
Após instalar os drivers e firmware corrigidos, você deve desconectar seus dongles Wi-Fi e reiniciar o sistema. As instruções acima devem ser executadas novamente se o seu kernel Linux for atualizado ou se os drivers corrigidos forem atualizados.
Observe que, mesmo quando o seu dispositivo funciona imediatamente, ainda recomendo instalar os drivers modificados, pois isso garante que não haja regressões inesperadas no código do kernel e dos drivers.
Caso você não consiga instalar os drivers/firmware modificados nativamente, você pode baixar uma imagem USB ao vivo que contém os drivers/firmware modificados junto com a nossa ferramenta de teste. Alternativamente, você pode usar uma máquina virtual com placas de rede USB, embora eu tenha descoberto que usar uma máquina virtual é menos confiável na prática.
Toda vez que você quiser usar a ferramenta de teste, primeiro é preciso carregar o ambiente virtual python como root. Isso pode ser feito usando:
cd research
sudo su
source venv/bin/activate
Agora você deve desativar o Wi-Fi no seu gerenciador de rede
para que ele não interfira na ferramenta de teste. Certifique-se também de que nenhum outro serviço de rede esteja causando
tráfego de saída. Você pode garantir isso usando iptables para bloquear o tráfego executando ./droptraffic.sh
(você pode reverter isso reiniciando o sistema). Opcionalmente, use sudo airmon-ng check para ver quais
outros processos podem estar usando a placa de rede sem fio e interferir na nossa ferramenta.
A ferramenta de teste pode testar tanto clientes quanto APs:
Testando APs: configure o AP que você deseja testar editando research/client.conf. Este é um
arquivo de configuração padrão do wpa_supplicant; consulte a documentação do hostap
para uma visão geral de todas as opções que ele suporta.
Testando clientes: você deve executar a ferramenta de teste com o parâmetro --ap (veja abaixo). Isso
instrui a ferramenta a criar um AP com o nome testnetwork e senha abcdefgh. Conecte-se
a essa rede com o cliente que você deseja testar. Por padrão, o cliente deve solicitar um IP
usando DHCP. Para editar propriedades do AP criado, como o canal em que ele é criado, você
pode editar research/hostapd.conf.
Este modo requer apenas uma placa de rede sem fio, mas geralmente exige um driver e/ou firmware corrigido. Consulte Drivers Corrigidos sobre como instalar drivers/firmware corrigidos, e Placas de Rede Suportadas para placas de rede compatíveis. Execute a ferramenta de teste neste modo usando:
./fragattack.py wlan0 [--ap] $COMMAND
Os valores possíveis de $COMMAND estão listados em testes de vulnerabilidades
e testes estendidos de vulnerabilidades.
Uma vantagem desse modo é que ele funciona razoavelmente bem ao testar clientes que podem entrar em estado de suspensão. No entanto, se possível, recomendo desativar a funcionalidade de suspensão do cliente que está sendo testado, consulte Como lidar com o modo de suspensão.
Este modo requer duas placas de rede sem fio: uma atuará como AP ou cliente, e a outra será usada para injetar quadros. A vantagem é que esse modo pode funcionar sem exigir drivers corrigidos. Execute a ferramenta de teste neste modo usando:
./fragattack.py wlan0 --inject wlan1 [--ap] $COMMAND
Aqui, a interface wlan0 atuará como um cliente ou AP legítimo, e wlan1 será usada para injetar quadros. Para wlan0, qualquer placa que suporte o modo normal de cliente ou AP no Linux pode ser usada. Para wlan1, deve ser usada uma placa que suporte o modo de injeção de acordo com Placas de Rede Suportadas.
Ao testar clientes neste modo, os quadros injetados podem ser enviados quando o cliente está em estado de suspensão. Isso faz com que os ataques falhem, então você deve garantir que o cliente não entre em estado de suspensão.
Este modo é experimental e apenas para fins de pesquisa. Consulte detalhes do modo hwsim para mais informações.
Você pode testar dispositivos executando a ferramenta de teste como discutido em modos de interface
e substituindo $COMMAND por um dos comandos na tabela abaixo. Assumimos que os clientes
solicitarão um IP usando DHCP (se não for o caso, consulte configuração de IP estático).
Todos os comandos funcionam tanto contra clientes quanto contra APs, salvo indicação em contrário.
A ferramenta exibe TEST COMPLETED SUCCESSFULLY se o dispositivo for vulnerável ao ataque correspondente
ao $COMMAND fornecido, e exibe Test timed out! Retry to be sure, or manually check result se
o dispositivo não for vulnerável. Após a conclusão do teste, você pode fechar a ferramenta de teste usando CTRL+C.
A maioria dos ataques tem várias variantes leves representadas por diferentes valores de $COMMAND.
Verificar o resultado de alguns testes exige executar tcpdump ou wireshark no dispositivo sob teste (a tabela abaixo indica se o tcpdump deve ser usado). Essa captura de pacotes do tcpdump deve incluir apenas pacotes que passaram pelo processamento das camadas PHY e MAC. Por exemplo, no Linux, essa captura deve ser feita enquanto a interface sem fio está no modo "managed" ou "ap", não no modo monitor, o que significa que a captura conterá apenas pacotes que passaram pelo processamento na camada Wi-Fi. Consulte evitando tcpdump em APs para uma discussão sobre como alguns testes podem, mesmo assim, ser realizados sem ter que executar tcpdump nos APs.
Para verificar sua configuração de teste, o primeiro comando na tabela abaixo executa um ping normal que deve ter sucesso. O segundo comando envia o ping como dois quadros Wi-Fi fragmentados e só deve falhar no raro caso de o dispositivo testado não suportar fragmentação. Caso um desses testes não esteja funcionando, siga as instruções em teste de injeção da placa de rede para garantir que sua placa de rede esteja injetando quadros corretamente. Se o cliente que está sendo testado puder entrar em modo de suspensão, consulte Como lidar com o modo de suspensão.
O terceiro, quarto e quinto comandos não são ataques, mas verificam o comportamento básico de desfragmentação de um dispositivo e são discutidos em mais detalhes abaixo da tabela.
Como os comandos correspondem aos CVEs está listado abaixo. Observe que, para falhas de implementação, listamos um CVE de referência; no entanto, os fornecedores podem usar CVEs diferentes porque uma vulnerabilidade de implementação normalmente recebe um CVE exclusivo para cada base de código afetada. Ainda assim, recomendamos sempre consultar esses CVEs de referência como uma forma de se referir facilmente a cada tipo de falha de implementação descoberta.
ping: Este teste deve sempre ter sucesso. Se falhar, algo está errado com a configuração do teste.- ping I,E,E: Este teste deve ser bem-sucedido contra todos os laptops, smartphones e APs modernos. Se falhar,
algo provavelmente está errado com a configuração do teste. Tente adicionar o parâmetro --icmp-size 100 como correção. Se
funcionar com esse parâmetro extra, você terá que executar todos os outros testes com esse parâmetro extra também.
A única vez em que encontrei esse teste falhando por motivos válidos é quando o dispositivo testado não suporta
receber quadros fragmentados, o que pode ser o caso em dispositivos IoT leves e, por exemplo, OpenBSD.ping I,E,E --delay 5: Este teste é usado para verificar o atraso máximo aceito entre dois fragmentos.
Se este teste não funcionar, tente novamente com --delay 1.5 ou menos. Por exemplo, o Linux remove fragmentos
da memória após 2 segundos, o que significa que um atraso de 1.8 funcionará enquanto 2.2 resultará em nenhuma resposta. Caso o atraso
máximo aceito seja baixo, todos os fragmentos enviados em outros testes devem ser enviados dentro desse atraso máximo aceito.
Caso contrário, os testes falharão trivialmente e você poderá concluir que um dispositivo não é vulnerável a um ataque mesmo
que na verdade seja.
ping-frag-sep: Este teste envia um quadro Wi-Fi fragmentado que é separado por um quadro não relacionado.
Ou seja, ele envia o primeiro fragmento, depois um quadro Wi-Fi não relacionado (normal) e, finalmente, o segundo fragmento.
Caso este teste falhe, o ataque de chave mista (padrão) e o ataque de cache provavelmente também falharão (já que exigem
o envio de outros quadros entre dois fragmentos). Este teste também falhará caso o receptor verifique se os fragmentos
têm números de pacote consecutivos (veja o próximo teste ping-frag-sep --pn-per-qos).
ping-frag-sep --pn-per-qos: Igual ao acima, mas adicionar o parâmetro --pn-per-qos garante que ambos os fragmentos
da solicitação de ping tenham um Número de Pacote (PN) consecutivo. Isso é algo que um receptor deveria estar
verificando para ser seguro. Infelizmente, antes da divulgação de nossos resultados, muitas implementações
não verificam se os PNs são consecutivos. Este teste pode falhar caso o receptor não rastreie o contador
de pacotes mais recente recebido por QoS TID; nesse caso, você pode ignorar outros testes que contenham o parâmetro
--pn-per-qos.
O teste ping I,E --amsdu verifica se uma implementação suporta A-MSDU não-SPP (não verifica se o dispositivo
é vulnerável ao CVE-2020-24588). Para prevenir ataques, idealmente
a rede deve exigir o uso de SPP A-MSDU e descartar todos os A-MSDU não-SPP. No entanto, a maioria dos fornecedores
está atualmente implementando mitigações ad-hoc (veja a Seção 7.2 do artigo). Por isso, você deve usar
os dois testes a seguir para verificar se um dispositivo é vulnerável a ataques de agregação (A-MSDU) (CVE-2020-24588):
amsdu-inject: Este teste simula o ataque de injeção A-MSDU descrito na Seção 3.2 do artigo. Em particular,
ele envia um quadro A-MSDU cujo início também é um cabeçalho LLC/SNAP válido (já que é isso que também acontece em nosso ataque
de referência). Se este teste for bem-sucedido, o dispositivo é vulnerável ao CVE-2020-24588.
amsdu-inject-bad: Alguns dispositivos analisam incorretamente quadros A-MSDU que começam com um cabeçalho LLC/SNAP válido, fazendo o
teste acima falhar. Nesse caso, tente amsdu-inject-bad em seu lugar (veja a Seção 3.6 do artigo). Observe que se este teste
for bem-sucedido, o impacto do ataque é efetivamente idêntico ao de implementações que analisam corretamente tais quadros,
o que significa que o dispositivo é vulnerável ao CVE-2020-24588.
Ao executar o teste de chave mista contra um AP, o AP deve estar configurado para renovar regularmente (por exemplo, a cada minuto)
a chave de sessão (PTK) executando um novo handshake de 4 vias. A ferramenta exibirá
Client cannot force rekey. Waiting on AP to start PTK rekey ao aguardar este handshake de rekey PTK.
Contra um pequeno número de APs, a ferramenta de teste também pode solicitar a renovação do PTK adicionando o parâmetro --rekey-req,
o que significa que não há necessidade de configurar o AP para renovar a chave periodicamente.
Alguns APs não podem ser configurados para renovar regularmente a chave de sessão (PTK). Contra esses APs, você pode, em vez disso, tentar um teste de ataque de cache. Caso o AP seja vulnerável a ataques de cache, então ele provavelmente também é vulnerável a ataques de chave mista (a menos que haja evidências fortes que contradigam isso, por exemplo, uma auditoria de código indique que ataques de chave mista são prevenidos). Se o AP não for vulnerável a ataques de cache, não podemos dizer nada sobre sua suscetibilidade a ataques de chave mista e, nesse caso, recomendo fazer uma auditoria de código.
ping I,F,BE,AE --pn-per-qos: O parâmetro extra --pn-per-qos garante que ambos os fragmentos injetados tenham
números de pacote consecutivos, o que é necessário para que o ataque de chave mista seja bem-sucedido contra certos dispositivos
(por exemplo, contra Linux).
Vários dispositivos implementam o handshake de 4 vias de maneiras diferentes e isso afetará se esses testes serão bem-sucedidos ou não. Caso os testes falhem, é recomendado também executar os testes de ataque de chave mista listados em Testes Estendidos de Vulnerabilidade.
Ao testar um AP, a ferramenta envia um primeiro fragmento, depois tenta reassociar com o AP e, finalmente,
envia o segundo fragmento. No entanto, nem todos os APs suportam adequadamente o processo de reassociação. Nesse caso,
adicione a opção --full-reconnect como mostrado na tabela, o que faz a ferramenta de teste desautenticar
após enviar o primeiro fragmento.
Ao testar um cliente, a ferramenta envia um primeiro fragmento, desassocia o cliente e, assim que o cliente
se reconectar, enviará o segundo fragmento. Idealmente, o cliente se reconectará imediatamente após o envio
do quadro de desassociação. Isso pode exigir desabilitar todas as outras redes no cliente que está sendo testado. Também
descobri que alguns clientes não parecem lidar adequadamente com a desassociação e, nesse caso, você pode adicionar a
opção --full-reconnect como mostrado na tabela para enviar um quadro de desautenticação em seu lugar.
Descobri que é melhor executar cada teste de ataque de cache várias vezes. Às vezes, um teste de ataque de cache pode falhar embora a implementação seja vulnerável. Isso pode ser devido a ruído de fundo, outros dispositivos enviando quadros para o dispositivo testado, etc.
ping I,E,R,AE [--full-recon]: Aqui, o segundo fragmento é enviado imediatamente após se reconectar com o
dispositivo sob teste, o que é importante caso o dispositivo limpe fragmentos da memória após um curto período.
Observe que full-recon é uma abreviação de full-reconnect.
ping I,E,R,E [--full-recon]: Aqui, o segundo fragmento é enviado 1 segundo após se reconectar com o
dispositivo sob teste, o que pode ser útil caso haja um pequeno atraso entre a conclusão do handshake
e a instalação da chave negociada.
Em nossos experimentos, este teste falhou apenas contra Linux e contra dispositivos que não suportam fragmentação.
ping I,E,P e linux-plain: se este teste for bem-sucedido, os ataques resultantes são descritos na Seção 6.3
do artigo. Em resumo, em combinação com a vulnerabilidade A-MSDU ou de cache, pode ser explorado para
injetar pacotes. Quando não combinado com outras vulnerabilidades, o impacto é específico da implementação
(CVE-2020-26147).
ping I,P,E: se este teste for bem-sucedido, é trivial injetar quadros de texto claro em direção ao dispositivo se
a fragmentação estiver sendo usada pela rede (CVE-2020-26147).
ping I,P: se este teste for bem-sucedido, a implementação aceita quadros de texto claro em uma rede Wi-Fi
protegida, permitindo injeção trivial de pacotes (CVE-2020-26140).
ping I,P,P: se este teste for bem-sucedido, a implementação aceita quadros de texto claro fragmentados em uma rede
Wi-Fi protegida, permitindo injeção trivial de pacotes (CVE-2020-26143).
Os dois testes a seguir enviam quadros de broadcast, que não são retransmitidos automaticamente e, portanto, é recomendado executá-los várias vezes. Isso porque o ruído de fundo pode impedir os dispositivos testados de receber o quadro de broadcast injetado. Em meus experimentos, principalmente clientes foram afetados (dos APs testados, apenas os Free/NetBSD foram afetados).
ping I,D,P --bcast-ra: Envia um ping unicast em um 2º fragmento de broadcast em texto claro após conectar. O resultado
dessa variante do ataque é verificado automaticamente pela ferramenta de teste.
ping D,BP --bcast-ra: Aqui, o quadro acima é enviado durante a conexão à rede (ou seja, durante o handshake de 4 vias).
Isso é importante porque vários clientes e APs só são vulneráveis antes de concluir o handshake de 4 vias. Para
confirmar o resultado deste teste, você precisa executar wireshark ou tcpdump na vítima e monitorar se a
solicitação de ping injetada é recebida pela vítima. No tcpdump, você pode usar o filtro icmp e, no wireshark, você
também pode usar o filtro frame contains "test_ping_icmp" para detectar mais facilmente essa solicitação de ping. Em meus experimentos,
principalmente clientes foram afetados.
eapol-amsdu I,P: Este é o teste padrão para a vulnerabilidade específica de implementação discutida na
Seção 6.5 do artigo. Tanto clientes quanto APs podem ser vulneráveis. Seu resultado é verificado automaticamente pela
ferramenta de teste.
Testes que terminam em BP (eapol-amsdu BP e eapol-amsdu-bad BP): Esses testes injetam o quadro malicioso
durante a execução do handshake de 4 vias. Para confirmar o resultado deste teste, você precisa executar wireshark
ou tcpdump na vítima e monitorar se a solicitação de ping injetada é recebida pela vítima. No tcpdump,
você pode usar o filtro icmp e, no wireshark, você também pode usar o filtro frame contains "test_ping_icmp"
para detectar mais facilmente essa solicitação de ping.
Testes que começam com eapol-amsdu-bad (eapol-amsdu-bad BP e eapol-amsdu-bad I,P): Várias implementações
processam incorretamente quadros A-MSDU cujos primeiros 6 bytes também equivalem a um cabeçalho RFC1042 válido para EAPOL. Para testar essas
implementações, você precisa usar a variante de teste eapol-amsdu-bad. Observe que se este teste for bem-sucedido, o impacto
do ataque é idêntico ao de implementações que analisam corretamente tais quadros (para detalhes, veja as Seções 3.6 e
6.6 do artigo).
Caso a ferramenta de teste não pareça estar funcionando, verifique o seguinte:
Verifique se nenhum outro processo está usando a placa de rede (por exemplo, encerre seu gerenciador de rede).
Se tudo funcionou anteriormente, tente desconectar seu adaptador Wi-Fi, reiniciar seu computador ou máquina
virtual e tente novamente. Tente também desabilitar a criptografia de hardware usando o script disable-hwcrypto.sh
(reinicie seu computador após executar este script).
Garanta que o dispositivo testado não entre em estado de suspensão (fazendo com que ele perca quadros injetados). Recomendo executar a ferramenta de teste em modo misto, pois isso lida melhor com clientes que podem entrar em estado de suspensão.
Execute os testes de injeção para garantir que a injeção está funcionando corretamente. Garanta também que um canal de 20 MHz esteja sendo usado; a injeção em outros canais não foi testada.
Verifique se sua máquina não está gerando tráfego de fundo que interfira nos testes. Em particular, desabilite a rede no seu sistema operacional, encerre manualmente seu cliente/servidor DHCP, etc. Veja também Antes de cada uso.
Confirme que você está se conectando à rede correta. Verifique novamente client.conf.
Certifique-se de que o AP testado está usando (AES-)CCMP como algoritmo de criptografia. Outros algoritmos de criptografia, como TKIP ou GCMP, não são suportados.
Se você atualizou o código usando git, execute ./build.sh e ./pysetup.sh novamente (veja Pré-requisitos).
Caso os drivers corrigidos tenham sido atualizados, lembre-se de recompilá-los também.
Se você estiver usando uma máquina virtual, tente executar a ferramenta de teste a partir de uma imagem USB live.
Verifique se o dispositivo testado não bloqueia solicitações de ping ICMP. Caso ele não responda aos pings, você pode executar tcpdump ou wireshark no dispositivo, ou tentar qualquer um dos outros métodos listados em .
Devido a variações de implementação, pode ser difícil confirmar/explorar certas vulnerabilidades, em particular o ataque de chave mista e o ataque de cache podem ser não triviais de confirmar na prática. Portanto, recomendo considerar um dispositivo seguro apenas se houver verificações explícitas no código para prevenir esses ataques. Além disso, se o tempo permitir, também recomendo os seguintes testes mais avançados. Eles têm menor chance de revelar novas vulnerabilidades, mas podem revelar variantes de ataque ou comportamento específico do dispositivo que os testes normais não conseguem detectar.
Se os testes normais em Testes para Vulnerabilidades já confirmaram a presença de uma determinada classe de vulnerabilidade, há pouca necessidade de testar as outras variantes de ataque dessa vulnerabilidade. Todos os comandos funcionam contra clientes e APs, salvo indicação em contrário.
Só é útil executar esses dois testes se o teste principal ping I,E --amsdu falhar e você quiser entender melhor
como o dispositivo testado lida com quadros A-MSDU:
ping I,E --amsdu-fake: Se este teste for bem-sucedido, o receptor trata todos os quadros como quadros normais (ou seja, não
suporta quadros A-MSDU). Esse comportamento não é ideal, embora seja improvável que um atacante possa abusar disso na
prática (veja a Seção 3.5 do artigo).
ping I,E --amsdu-fake --amsdu-spp: Se este teste for bem-sucedido, o receptor autentica o flag A-MSDU de QoS de cada
quadro recebido (ou seja, não o mascarará para zero na recepção), mas depois trata todos os quadros recebidos como quadros normais
(ou seja, não suporta a recepção de quadros A-MSDU reais). Esse comportamento não é ideal, embora seja improvável
que um atacante possa abusar disso na prática (veja a Seção 3.5 do artigo).
A maioria dos dispositivos que testei é vulnerável a ataques de chave mista. Caso os testes normais de ataque de chave mista indiquem
que um dispositivo não é vulnerável, mas o teste ping-frag-sep seja bem-sucedido, é altamente recomendável tentar
esses testes alternativos de ataque de chave mista.Como observação geral, ao testar um AP, você pode adicionar o parâmetro --rekey-req a qualquer um dos testes de ataque de chave mista para solicitar ativamente um handshake de rekey. Um pequeno número de APs realizará então o handshake de rekey. No entanto, a maioria dos APs ignorará essa solicitação e terá que ser explicitamente configurada para renovar regularmente a chave de sessão (PTK).
Algumas notas sobre os testes:
ping I,F,BE,E e ping I,E,F,AE: Estes são testes de ataque de chave mista bastante diretos, onde ambos os fragmentos são
injetados em momentos diferentes.
ping I,E,F,AE --rekey-plain: Alguns drivers (ex.: MediaTek) realizarão o handshake de rekey em texto puro. Para testar
dispositivos que usam esse driver, você deve adicionar o parâmetro --rekey-plain.
ping I,E,F,AE --rekey-plain --rekey-req: Essa combinação específica é útil para testar roteadores que usam um driver
MediaTek. Esses roteadores realizam o handshake de rekey em texto puro, e o cliente pode solicitar ativamente um handshake de rekey.
ping I,E,F,AE --rekey-early-install: Um pequeno número de clientes instala (incorretamente) a chave cedo demais durante
um rekey de sessão pairwise. Para testar esses clientes de forma confiável, adicione o parâmetro --rekey-early-install. Este teste
não é significativo contra APs.
ping I,E,F,E [--rekey-pl] [--rekey-req]: Esta variante de teste é a mesma que os testes anteriores ping I,E,F,AE *,
exceto que o segundo fragmento é enviado 1 segundo após o handshake de 4 vias. Isso pode ser importante porque em um
pequeno número de dispositivos há um pequeno atraso antes que a nova chave seja instalada. Observe que é uma abreviação
de .
Finalmente, caso o teste ping-frag-sep não tenha sucesso, você deve tentar o seguinte teste de ataque de chave mista:
ping I,F,BE,AE --freebsd: Isso essencialmente realiza o handshake de rekey contra uma implementação FreeBSD, ou
um driver que utiliza código do FreeBSD, sem afetar o processo de desfragmentação dos quadros de dados. Consulte
o Apêndice E do artigo para obter detalhes.ping I,E,R,AE --freebsd --full-reconnect: Este teste pode ser usado para verificar se um AP FreeBSD, ou um driver que
utiliza código do FreeBSD, é vulnerável a um ataque de cache. Consulte o Apêndice E do artigo para detalhes sobre como este
teste funciona. Você também deve tentar este teste sem o parâmetro --full-reconnect. O teste também funciona contra
clientes, mas estes provavelmente não serão afetados.
ping I,E,R,AP --freebsd --full-reconnect: Este teste é uma variante contra APs FreeBSD, ou contra um driver que
utiliza código do FreeBSD, onde o segundo fragmento é enviado em texto puro após reconectar com o AP. Contra alguns
dongles no FreeBSD, este teste foi mais confiável e ainda prova que fragmentos antigos permanecem na memória do AP após
a reconexão. Você também deve tentar este teste sem o parâmetro --full-reconnect. O teste também funciona contra
clientes, mas estes provavelmente não serão afetados.
ping I,E,R,AP [--full-reconnect]: Neste teste, o segundo fragmento é enviado em texto puro. Isso pode ser útil se
o dispositivo testado não instalar imediatamente a chave após o handshake de 4 vias. Se este teste for bem-sucedido, isso
mostra que o dispositivo mantém fragmentos na memória após (re)conectar a uma rede, ou seja, é vulnerável a ataques de cache.
Ao contrário dos dois comandos acima, este também é útil para ser executado contra clientes (bem como APs).
ping I,E,E --amsdu: Este teste envia um quadro A-MSDU fragmentado, que nem todos os dispositivos conseguem receber
adequadamente. Ele não testa uma vulnerabilidade. Em vez disso, este teste é útil para determinar a explorabilidade prática
do "ataque misto de texto puro/criptografado". Ou seja, se este teste for bem-sucedido, é mais fácil atacar o dispositivo se o
segundo fragmento puder ser enviado em texto puro (teste ping I,E,P). Consulte a Seção 6.3 do artigo para detalhes.
ping I,E,P,E e linux-plain 3: Se todos os outros testes de ataque misto de texto puro/criptografado não tiverem sucesso, você
também pode tentar esses dois testes extras. Acho bastante improvável que isso revele uma nova vulnerabilidade.
A maioria dos testes a seguir envia quadros de broadcast, que não são retransmitidos automaticamente e, portanto, é recomendado executá-los várias vezes. Isso ocorre porque o ruído de fundo pode impedir que os dispositivos testados recebam o quadro de broadcast injetado. Em meus experimentos, principalmente os clientes foram afetados. A maioria dos clientes só é vulnerável durante a conexão à rede (ou seja, durante a execução do handshake de 4 vias).
ping I,P --bcast-ra: isto envia uma solicitação de ping ICMP unicast dentro de um quadro Wi-Fi de broadcast em texto puro (CVE-2020-26145).
Este teste pode ser realizado tanto contra clientes quanto contra APs.
ping BP --bcast-ra: semelhante ao teste acima ping I,P --bcast-ra, mas o ping é enviado antes que o cliente tenha se
autenticado na rede, ou seja, durante a execução do handshake de 4 vias (CVE-2020-26145). Você deve executar o tcpdump
ou o wireshark para verificar se o cliente aceita o quadro. No tcpdump, você pode usar o filtro icmp e, no wireshark, você
também pode usar o filtro frame contains "test_ping_icmp" para detectar mais facilmente essa solicitação de ping.
ping BP --bcast-ra --bcast-dst: este teste é o mesmo que o anterior, mas é útil se você não puder executar o tcpdump
no AP de destino. Observe que este teste só é significativo contra APs. O parâmetro extra --bcast-dst neste teste
faz com que um AP vulnerável transmita a solicitação de ping injetada para todos os clientes conectados. Em outras palavras, para verificar se um
AP é vulnerável, execute este comando e ouça os quadros Wi-Fi de broadcast em um segundo dispositivo conectado ao
AP usando o filtro icmp ou frame contains "test_ping_icmp".
ping BP [--bcast-dst]: esta é uma variante dos dois testes acima ping BP --bcast-ra [--bcast-dst], exceto que a solicitação de ping
agora é enviada em um quadro unicast em texto puro em vez de um quadro de broadcast (nenhum CVE foi alocado ainda - está relacionado à
CVE-2020-26145). Este teste deve ser realizado tanto contra clientes quanto contra APs. O ping é enviado antes que o cliente tenha se autenticado
na rede (ou seja, durante a execução do handshake de 4 vias), o que significa que você deve executar o tcpdump ou o wireshark para verificar se o
dispositivo aceita este quadro. Alternativamente, ao testar APs, você pode adicionar o parâmetro --bcast-dst semelhante ao teste acima,
e então usar o tcpdump ou o wireshark em um segundo dispositivo conectado ao AP usando o filtro icmp ou
frame contains "test_ping_icmp".
eapfrag BP,BP: esta é uma especialização dos testes de fragmento de broadcast acima, executada antes que o cliente tenha se
autenticado. É um ataque muito experimental baseado na análise de código vazado. Primeiro, envia um fragmento em texto puro
que começa com um cabeçalho EAPOL, que é aceito porque o handshake de 4 vias ainda está em execução. Em seguida, envia um
segundo fragmento de broadcast com o mesmo número de sequência. Com base na análise de código vazado, alguns dispositivos podem agora aceitar
este fragmento (porque o fragmento anterior foi permitido), mas o código subsequente o processará como um quadro normal
(porque o fragmento é transmitido em broadcast). Você deve usar o tcpdump ou o wireshark na vítima para determinar se o quadro
é recebido corretamente, por exemplo, usando o filtro icmp ou frame contains "test_ping_icmp". Uma variante alternativa
é caso a variante normal não funcione.
Este teste pode ser usado caso você queira executar os testes eapol-amsdu[-bad] BP, mas não consiga executar o tcpdump ou o wireshark no
AP. Este teste só é significativo contra APs: o comando eapol-amsdu[-bad] BP --bcast-dst faz com que um AP vulnerável
transmita a solicitação de ping injetada para todos os clientes conectados. Em outras palavras, para verificar se um AP é vulnerável, execute este
comando e ouça os quadros Wi-Fi de broadcast em um segundo dispositivo conectado ao AP usando o filtro icmp ou
frame contains "test_ping_icmp".
eapol-inject 00:11:22:33:44:55: Este teste só é significativo contra APs. Para realizar este teste, você deve conectar-se
à rede usando um segundo dispositivo e substituir o endereço MAC 00:11:22:33:44:55 pelo endereço MAC deste segundo
dispositivo. Antes de ser autenticado, a ferramenta de teste enviará um quadro EAPOL ao AP com este segundo dispositivo
como destino final. Se o AP encaminhar o quadro EAPOL para o segundo dispositivo, o AP é considerado vulnerável. Para confirmar se o AP encaminha
o quadro EAPOL, você deve executar o tcpdump ou o wireshark no segundo dispositivo. Você pode usar o filtro do wireshark frame contains "forwarded_data"
ao monitorar tráfego descriptografado na interface sem fio do segundo dispositivo (ou o filtro do tcpdump ether proto 0x888e
para monitorar todos os quadros EAPOL). Consulte a Seção 6.6 do artigo para obter detalhes e o impacto disso.
eapol-inject-lage 00:11:22:33:44:55: Caso o teste eapol-inject acima seja bem-sucedido, você também pode tentar eapol-inject-large para ver
se essa vulnerabilidade pode ser abusada para forçar a transmissão de fragmentos criptografados. Novamente, você deve usar o tcpdump ou o wireshark
para verificar isso. Use o filtro do wireshark ou tshark (wlan.fc.frag == 1) || (wlan.frag > 0) para detectar quadros fragmentados. Achei
muito raro esse ataque funcionar.
ping I,D,E: Se este teste for bem-sucedido, o cliente ou AP não suporta (des)fragmentação, mas ainda é vulnerável a ataques.
O problema é que o receptor trata o último fragmento como um quadro completo. Consulte a Seção 6.8 do artigo para detalhes e como
isso pode ser explorado.
ping I,E,D: Se este teste for bem-sucedido, o cliente ou AP trata o primeiro fragmento como um quadro completo. Embora esse comportamento
não seja ideal, atualmente não se sabe se isso, por si só, pode ser explorado na prática.
O script test-injection.py pode ser usado para testar se os quadros são injetados corretamente ao usar o modo de injeção:
./test-injection.py wlan0 wlan1
Aqui testamos se a placa de rede wlan0 injeta quadros corretamente e usamos a placa de rede wlan1
para monitorar se os quadros são injetados corretamente. Observe que ambas as interfaces precisam suportar
o modo monitor para que este script de teste funcione.
Caso você não tenha uma segunda placa de rede, pode executar um teste de injeção parcial usando:
./test-injection.py wlan0
Infelizmente, o teste acima só pode verificar se o kernel sobrescreve campos dos quadros injetados; ele não pode verificar se o firmware ou o chip sem fio em si sobrescreve campos.
Para testar se uma placa de rede injeta quadros corretamente no modo misto, que é o modo que eu recomendo usar, você pode executar os dois comandos a seguir:
./fragattack.py wlan0 ping --inject-test wlan1
./fragattack.py wlan0 ping --inject-test wlan1 --ap
Aqui testamos se wlan0 injeta quadros corretamente, monitorando os quadros injetados usando a
segunda placa de rede wlan1. O primeiro comando testa se os quadros são injetados corretamente ao usar
o modo misto enquanto atua como cliente, e o segundo comando ao usar o modo misto enquanto atua
como AP. Para iniciar o teste, o cliente deve ser capaz de se conectar a uma rede, e o
AP espera até que um cliente se conecte antes de iniciar os testes de injeção (consulte Antes de cada uso
para configurar a conexão do cliente e do AP).
Se você também quiser testar o comportamento de retransmissão do wlan0 no modo misto, pode executar:
./fragattack.py wlan0 ping --inject-test-postauth wlan1
./fragattack.py wlan0 ping --inject-test-postauth wlan1 --ap
Caso você não tenha uma segunda placa de rede, pode executar um teste de injeção parcial em modo misto usando:
./fragattack.py wlan0 ping --inject-test[-postauth] self
./fragattack.py wlan0 ping --inject-test[-postauth] self --ap
Infelizmente, os testes acima só podem verificar se o kernel sobrescreve campos dos quadros injetados; eles não podem verificar se o firmware ou o chip sem fio em si sobrescreve campos.
O script de teste fornecerá uma saída detalhada sobre quais testes foram bem-sucedidos ou falharam e concluirá exibindo
ou ==> The most important tests have been passed successfully ou uma mensagem indicando que testes importantes
falharam ou que não foi possível capturar determinados quadros injetados.
Observe que os scripts de injeção testam apenas o comportamento mais importante. A melhor maneira de confirmar que a injeção está funcionando corretamente é executar os testes de vulnerabilidade contra dispositivos conhecidamente vulneráveis e confirmar que a ferramenta identifica corretamente o(s) dispositivo(s) como vulnerável(is).
Quando determinados quadros injetados não puderem ser capturados, isso pode ser devido a ruído de fundo ou porque a
placa de rede testada é incapaz de injetar corretamente determinados quadros (por exemplo, o firmware do Intel AX200 trava
ao injetar quadros fragmentados). Também pode ser que os quadros sejam de fato injetados corretamente, mas que a placa
de rede usada para monitorar se os quadros são injetados corretamente (wlan1 nos exemplos acima) não seja confiável e,
por exemplo, perca a maioria dos quadros devido ao ruído de fundo. Tente executar os testes em um canal diferente também.
Quando os testes de injeção funcionam, mas você tem problemas para executar os testes de ataque de forma confiável, isso pode ser porque os dispositivos que você está testando estão entrando em modo de suspensão. Consulte Como lidar com o modo de suspensão para obter notas adicionais sobre esse problema.
Ao usar o wireshark para inspecionar o comportamento de injeção de um dispositivo, é recomendável usar um segundo dispositivo em modo monitor para ver como os quadros são injetados.
Caso você abra a interface usada para injetar quadros, deverá ver os quadros injetados duas vezes: (1) primeiro você vê o quadro como injetado pela ferramenta que o está enviando e, em seguida, (2) uma segunda vez como o quadro foi injetado pelo driver. Esses dois quadros podem diferir ligeiramente se o kernel sobrescreveu determinados campos. Se você vir um quadro injetado apenas uma vez, ele pode ter sido descartado pelo kernel.
Caso o dispositivo que você está testando não suporte DHCP, você pode especificar manualmente os endereços IP que a ferramenta de teste deve usar. Por exemplo:
./fragattack.py wlan0 [--ap] ping --inject wlan1 --ip 192.168.100.10 --peerip 192.168.100.1
Aqui a ferramenta de teste usará o endereço IP 192.168.100.10 e injetará uma solicitação de ping para o endereço IP do par 192.168.100.1.
Quando um teste envia pacotes IP antes de obter endereços IP usando DHCP, ele usará o endereço IP
padrão 127.0.0.1. Para usar endereços (padrão) diferentes, você também pode usar os parâmetros --ip e -peerip.
A maioria dos testes de ataque funciona enviando solicitações de ping ICMP de maneiras especiais e verificando se recebemos
uma resposta de ping ICMP. Caso o dispositivo testado não suporte pings ICMP, você pode, em vez disso,
usar solicitações ARP adicionando o parâmetro --arp a todos os testes. Caso um teste não suporte o envio
de solicitações ARP, a ferramenta exibirá o erro Cannot override request type of the selected test, caso
em que o teste específico só pode ser executado usando solicitações de ping ICMP.
TODO: Ao atuar como cliente, também podemos injetar solicitações DHCP em vez disso.
Caso você não consiga acesso a uma das placas de rede sem fio recomendadas, uma segunda opção é obter uma placa de rede que use os mesmos drivers no Linux. Em particular, você pode tentar:
Recomendo placas baseadas em ath9k_htc. Nem todas as placas que usam iwlmvm serão compatíveis. Ao
usar uma placa de rede alternativa, recomendo fortemente executar primeiro os testes de injeção
para confirmar que a placa de rede é compatível.
Para usar a ferramenta de teste 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 desabilitados, sem IR ou detecção de radar. Observe que essas
condições podem depender da sua placa de rede, do país atualmente configurado e do AP ao qual você está
conectado. Para obter mais informações, consulte, por exemplo, a documentação do Arch Linux.
Observe que um dispositivo pode usar drivers diferentes para lidar com as bandas de 2,4 e 5 GHz. Como resultado, é importante testar dispositivos em ambas as bandas, pois um dispositivo pode se comportar de maneira diferente dependendo de qual faixa de frequência está sendo usada.
Observe que, no modo misto, o kernel do Linux pode não permitir a injeção de quadros mesmo que seja
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
sob as condições corretas evita esse bug.
Na prática, algumas pessoas descobriram que você deve primeiro definir manualmente a placa de rede sem fio para o canal de 5 GHz em que o AP está operando. Consulte esta issue do GitHub para obter detalhes.
Dispositivos como celulares ou gadgets IoT podem colocar seu rádio Wi-Fi em modo de suspensão para reduzir o consumo de energia. Quando estão em modo de suspensão, esses dispositivos não conseguem receber quadros Wi-Fi, o que pode interferir em nossos testes. Existem algumas opções para tentar mitigar esse problema:
Tente desativar o modo de suspensão no dispositivo testado. Esta é a solução mais confiável, mas infelizmente nem sempre é possível.
Execute a ferramenta de teste no modo misto. A maioria das placas de rede colocará os quadros injetados em fila até que o dispositivo testado esteja acordado novamente.
Tente uma placa de rede diferente para realizar os testes. Descobri que placas de rede diferentes injetam quadros em momentos (ligeiramente) diferentes, e isso pode ser a diferença entre um quadro injetado chegar corretamente ou ser perdido. Por exemplo, contra um Pixel 4 XL, a ferramenta de teste não era confiável ao usar um TL-WN722N, mas funcionava de forma confiável com um Intel 8265.
Atribua IPs estáticos ao dispositivo em teste e deixe a ferramenta de teste usar IPs estáticos (consulte Configuração de IP estático). Com muitos testes, isso pode ser mais confiável porque a ferramenta de teste pode enviar imediatamente o quadro de teste em vez de primeiro ter que usar/esperar o DHCP.
ou seja, quando está executando o handshake de 4 vias. Isso torna mais difícil testá-las automaticamente e normalmente significa que o tcpdump ou similar precisa ser usado no dispositivo em teste. No entanto, os APs podem ser testados sem executar tcpdump neles. Em particular, os testes de ataque de fragmento de broadcast (CVE-2020-26145) e os testes de ataque A-MSDU EAPOL (CVE-2020-26144) podem ser realizados sem executar tcpdump no dispositivo em teste. Em vez disso, o tcpdump precisa ser executado em outro cliente conectado ao AP. Concretamente, os seguintes comandos podem ser usados:
ping I,P --bcast-ra --bcast-dst e ping BP --bcast-ra --bcast-dst
eapol-amsdu BP --bcast-dst e eapol-amsdu-bad BP --bcast-dst
Com esses comandos, você pode monitorar a solicitação de ping em outro cliente conectado ao AP. Caso a solicitação de ping seja recebida nesse cliente independente, o AP em teste está vulnerável. Infelizmente, atualmente parece difícil testar clientes contra essas variantes de ataque sem executar tcpdump no cliente.
Se por algum motivo o Linux não reconhecer automaticamente este dongle, execute sudo modprobe mt76x2u
para carregar o driver manualmente. Este dongle parece confiável com nossos drivers mais recentes. Se o dongle não for confiável,
crie o arquivo /etc/modprobe.d/mt76.conf com o seguinte conteúdo:```
options mt76_usb disable_usb_sg=1
Em seguida, reinicie a sua máquina. Certifique-se também de usar um bom cabo USB com este dongle! Anteriormente, encontrei
comportamento não confiável com este dongle, que foi causado por um cabo USB 3.0 ruim. Portanto, se você tiver problemas,
pode ajudar conectar o dongle diretamente sem usar um cabo.
Ao usar VirtualBox, certifique-se de habilitar USB3.0 para que o dongle seja reconhecido. Consulte
[esta issue](https://github.com/vanhoefm/fragattacks/issues/22) para detalhes.
O AWUS036ACM usa internamente um chipset MT7612U. Agora também existem dongles com chipset MT7612UN que
também são confiáveis com a nossa ferramenta de teste. Um exemplo é o [CSL Wireless Network Adaptor](https://www.amazon.de/dp/B0873BNBD8?tag=modwiffir-20).
### ath9k_htc
O Technoethical N150 HGA, TP-Link TL-WN722N v1.x e Alfa AWUS036NHA usam o driver `ath9k_htc`.
Para mim, estes dispositivos funcionaram razoavelmente bem em uma máquina virtual, embora como todos os dispositivos
sejam mais confiáveis quando usados nativamente. Ao usar uma VM, recomendo configurar a VM para usar um controlador
USB2.0, pois isso pareceu mais estável (pelo menos com VirtualBox).
Em kernels recentes houve uma ([agora corrigida](https://www.spinics.net/lists/linux-wireless/msg200825.html))
regressão com o driver `ath9k_htc` fazendo com que ele não funcionasse. Simplesmente use um kernel atualizado ou os nossos
drivers corrigidos para evitar esse problema.
#### AWUS036ACH
Este dispositivo geralmente não é suportado por padrão na maioria das distribuições Linux e requer instalação
manual dos drivers. No Kali Linux você pode instalar o driver usando `sudo apt install realtek-rtl88xxau-dkms`.
Para instalar o driver em outras distribuições, verifique o seu gerenciador de pacotes ou siga as instruções
de instalação no [GitHub](https://github.com/aircrack-ng/rtl8812au). Antes de conectar o dispositivo,
é recomendado executar `modprobe 88XXau rtw_monitor_retransmit=1`.
Infelizmente, este dispositivo não funciona em modo misto, que é o modo recomendado, e é difícil
de usar em combinação com os nossos drivers modificados. Na prática, você terá que desinstalar os drivers
modificados e então executar a ferramenta de teste usando os parâmetros `--no-drivercheck` e usando `--inject wlan0`
onde wlan0 se refere à placa AWUS036ACH. Devido a essas limitações, este dispositivo não é recomendado.
### Intel AX200
Testei o Intel AX200 e descobri que ele é _não_ compatível com a ferramenta de teste: o firmware dele trava
após injetar um frame com o flag More Fragments definido. Se um desenvolvedor Intel está lendo isto, por favor
atualize o firmware e torne possível injetar frames fragmentados.
### Chips baseados em RT5572
Testei este chipset usando o adaptador [CSL USB 2.0 WLAN Adapter 300Mbit adapter](http://www.amazon.de/dp/B00LLIOT34?tag=modwiffir-20) genérico.
Depois de desabilitar a descriptografia por hardware executando o script `disable-hwcrypto.sh`, consegui realizar
um teste de ping básico (`ping`). Um teste de ping fragmentado (`ping I,E,E`) foi muito não confiável, mas às vezes funcionava.
A conclusão atual é que chips RT5572 _podem_ funcionar com a ferramenta de teste depois de desabilitar a criptografia
por hardware. Mas experimentos extras são necessários para confirmar isso (feedback é bem-vindo).
<a id="id-hwsim-details"></a>
## 9.9. Detalhes do modo Hwsim
**Aviso**: *este é atualmente um modo experimental, use-o apenas para fins de pesquisa.*
Este modo requer apenas uma placa de rede que suporte modo monitor e, ao contrário do modo misto, a
placa de rede não precisa suportar interfaces virtuais. A desvantagem é que neste modo os frames
são processados um pouco mais lentamente, e não é confiável quando a placa de rede não confirma frames:
- Devido ao commit 1672c0e31917 ("mac80211: start auth/assoc timeout on frame status") a autenticação
como cliente expirará instantaneamente, o que significa que não podemos usar o modo hwsim como cliente atualmente.
_TODO: Precisamos corrigir o kernel para evitar esse timeout._
- Se testarmos um cliente que usa o commit 1672c0e31917 ("mac80211: start auth/assoc timeout on frame status")
nós (como AP) devemos confirmar os frames enviados em nossa direção. Caso contrário, o cliente sendo testado será
incapaz de conectar.
_TODO: Testar quais dispositivos confirmam frames em modo monitor e testar `iw set wlanX monitor active`._
- Certos APs também exigirão que frames de autenticação e associação sejam confirmados pelo cliente.
Isso significa que nós (como cliente) devemos novamente confirmar os frames enviados em nossa direção.
_TODO: Testar quais dispositivos confirmam frames em modo monitor e testar `iw set wlanX monitor active`._
- Por alguma razão estranha, o Intel/mvm não consegue receber frames de dados de Android/iPhone/iPad
após o 4-way HS? Este é um bug muito estranho. _TODO: Investigar isso mais a fundo._
Antes de usar este modo, crie duas placas de rede virtuais:
./hwsim.sh
Isso exibirá as duas interfaces "hwsim" virtuais criadas, por exemplo wlan1 e wlan2. Ao testar
um AP neste modo, você deve primeiro procurar pelo canal do AP e colocar a placa de rede real
neste canal:
./scan.sh wlan0
ifconfig wlan0 down
iw wlan0 set type monitor
ifconfig wlan0 up
# Escolha o canal em que o AP está (neste exemplo, 11)
iw wlan0 set channel 11
Aqui wlan0 se refere à placa de rede _real_ (não uma interface criada pelo `hwsim.sh`). Ao testar um
cliente, você não precisa primeiro configurar o canal (ele é obtido do `hostapd.conf`). Agora você pode
iniciar a ferramenta de teste da seguinte forma:
./fragattack.py wlan0 --hwsim wlan1,wlan2 [--ap] $COMMAND
Após a ferramenta ser executada, você pode executá-la novamente diretamente com um novo `$COMMAND`.
<a id="id-wpa3-sae"></a>
## 9.10. Testando dispositivos WPA3 e SAE
Você pode testar um AP WPA3/SAE incluindo as duas linhas a seguir em `client.conf`:
key_mgmt=SAE
ieee80211w=1
Para testar clientes WPA3/SAE, você pode modificar o `hostapd.conf` e definir os parâmetros:
wpa_key_mgmt=SAE
ieee80211w=2
Testamos o acima com um Intel 8265, Intel 3160, Netgear WN111v2 (`carl9170`),
TP-Link TL-WN722N (`ath9k_htc`) e WNDA3200 (`ath9k_htc`). Com esses
dispositivos, consegui conectar ao AP e executar alguns testes. Então parece
que isso deve funcionar com todos os dongles já suportados. Observe que eu
não testei isso em detalhes: minha suposição tem sido que se um
dispositivo está operando em modo WPA2 ou WPA3 não afetará os resultados dos testes.
O `client.conf` fornecido por padrão habilita tanto o método hunting-and-pecking quanto o
método hash-to-element. Para configurar um AP que suporte hash-to-element (e assim
testar os clientes WPA3/SAE mais recentes), você pode modificar o `hostapd.conf` e definir o parâmetro:
sae_pwe=2
Ao definir esse valor, o AP aceitará tanto o método hunting-and-pecking quanto
o método hash-to-element.
<a id="id-live-image"></a>
## 9.11. Imagem USB ao vivo
Baixe a [imagem USB ao vivo](https://people.cs.kuleuven.be/~mathy.vanhoef/fragattacks/ubuntu-20.04.2-fragattacks-1.3.3-amd64.iso)
e grave-a em um USB usando:
# Desmonte caso haja uma partição antiga no USB
sudo umount /dev/sdb*
# Copie a imagem
sudo dd bs=4M if=ubuntu-20.04.2-fragattacks-1.3.3-amd64.iso of=/dev/sdb conv=fdatasync status=progress
O sha256sum da imagem é `4b973452a08b981778285a33accfd4ce58625a91e8e0eab20941facf54904bba`. Substitua `/dev/sdb`
pelo seu pendrive. Se você não estiver usando Linux, pesquise online como gravar uma imagem ISO no seu pendrive.
Ao iniciar a imagem ao vivo, clique em "Try Ubuntu" durante a inicialização. Abra um terminal clicando com o botão direito no
área de trabalho e selecionando "Open in Terminal" e execute:
cd ~/fragattacks/research
sudo su
nmcli radio wifi off
source venv/bin/activate
Agora você pode executar `./fragattacks.py` e seguir as instruções normais neste README.
Lembre-se de desabilitar o Wi-Fi usando `nmcli radio wifi off` como mostrado acima, caso contrário, o
gerenciador de rede do Ubuntu interferirá com a ferramenta de teste. Este README também está presente
na imagem ao vivo em `~/fragattacks/README.md`.
Observe que o airmon-ng pode ser não confiável na imagem ao vivo e é melhor usar [iw](https://github.com/vanhoefm/fragattacks/issues/36).
<a id="id-design-notes"></a>
# 10. Notas de design
Os argumentos dados ao comando ping definem quais ações a ferramenta de teste executará
e quando essas ações são executadas. Cada ação é separada por uma vírgula (`,`). Por padrão,
uma ação é executada após o cliente conectar, e nesse caso uma única letra representa
qual ação é executada. Observe que isso é implementado na
função [`stract2action`](https://github.com/vanhoefm/fragattacks/blob/master/research/fragattack.py#L23).
As ações possíveis são:
- `I`: obter um endereço IP. Por padrão, isso é feito usando DHCP, a menos que um endereço IP seja explicitamente
fornecido usando os argumentos `--ip` e `--peerip`, caso em que nada é feito.
- `E`: injetar um pacote/fragmento criptografado da solicitação de ping.
- `P`: injetar um pacote/fragmento em texto claro da solicitação de ping.
- `F`: renovar a chave de sessão iniciando o 4-way handshake (como um AP) ou aguardando o
4-way handshake (como um cliente).
- `R`: fazer o cliente reconectar à rede.
- `D`: esta é uma "meta ação" especial. Trate-a como um fragmento vazio da solicitação de ping
que não é realmente enviado.
Se houver apenas uma única ação `E` ou `P`, então a solicitação de ping é injetada como um único frame.
Se houver múltiplas ações `E`, `P`, então a solicitação de ping é fragmentada, onde o número
de fragmentos é igual ao número de ações `E` ou `P`. Se houver a ação especial `D`, então
a solicitação de ping é fragmentada sobre as ações `E` ou `P` restantes (veja os exemplos na tabela).
Esse comportamento de fragmentação é implementado na classe [PingTest](https://github.com/vanhoefm/fragattacks/blob/master/research/tests_common.py#L47).
Uma letra pode ser colocada na frente das ações acima para alterar quando a ação deve ser executada:
- `S`: a ação é executada na 1ª ou 2ª mensagem do 4-way handshake.
- `B`: a ação é executada na 3ª ou 4ª mensagem do 4-way handshake.
- `A`: a ação é executada imediatamente após o 4-way handshake ser concluído.
- `C`: a ação é executada 1 segundo após o 4-way handshake ser concluído. A quantidade de segundos
para aguardar pode ser alterada usando o parâmetro `--connected-delay`.
Por exemplo, veja as duas tabelas acima com comandos.
<a id="id-change-log"></a>
# 11. Log de alterações
**Versão 1.3.4 (em andamento):**:
- Sempre criptografe frames EAPOL (Rekey) Request, mesmo quando --rekey-plaintext é usado.
- O cliente agora aceita frames EAPOL repetidos. Isso garante que rekeys funcionem mesmo quando o AP sendo testado
implementa rekeys incorretamente.
- Atualizado o wpa_supplicant para reabilitar a conexão a redes Enterprise que usam MS-CHAPv2. Anteriormente, quando
o SO usa OpenSSL 3.0 ou superior, o MD4 era desabilitado por padrão, o que significa que o MS-CHAPv2 não podia ser usado.
- Adicionado o parâmetro `--pre-test-delay`. Isso adiciona um atraso entre obter um endereço IP e a transmissão
dos primeiros fragmentos/frames. Consulte o [pull request](https://github.com/vanhoefm/fragattacks/pull/44) por
Michael Trimarchi e Angelo Compagnucci.
- Atualizados os drivers modificados para que também compilem no kernel Linux 5.13. Isso é experimental.
- Tornado o teste de injeção mais confiável aguardando mais tempo por frames no teste de reordenação.
- Feitas várias pequenas alterações para tornar o código mais fácil de compilar em plataformas mais antigas (que têm versões mais antigas
de Python e bibliotecas OpenSSL).
- Atualizado o README com um exemplo de como instalar um kernel suportado mais antigo no Ubuntu 20.04. Adicionadas
notas de design. Agora recomendando o AWUS036ACM.
**Versão 1.3.3 (11 de maio de 2021)**:
- Atualizados os drivers modificados para que compilem nos kernels Linux 5.10, 5.11 e 5.12.
- Atualizado o firmware para dispositivos `ath9k_htc` (não deve ter impacto nos testes).
- Reestruturado o repositório para lançamento público. Removidos documentos e slides internos para, em vez disso, referenciar
as versões públicas desses documentos.
- Suporte básico para canais de 40 MHz ao usar o parâmetro `--inject-test[-postauth]` para testar injeção. Em testes
reais de vulnerabilidade, o uso de canais de 40 MHz não foi testado (use `disable_ht40` em `client.conf` se necessário).
**Versão 1.3.2 (8 de março de 2021)**:
- Adicionados [handouts](https://papers.mathyvanhoef.com/fragattacks-slides-2021-03-8.pdf) da apresentação e um
[resumo](https://papers.mathyvanhoef.com/fragattacks-overview.pdf)
da causa raiz e do impacto de cada vulnerabilidade.
- Atualizado este README para [explicar](#id-test-sanity) que o parâmetro `--icmp-size 100` ou similar pode ser adicionado a
todos os testes que enviam frames fragmentados se o dispositivo sob teste só aceitar fragmentos de um determinado tamanho mínimo.
- Corrigidos pequenos erros de digitação neste README.
**Versão 1.3.1 (1 de março de 2021)**:
- Adicionado o teste [`ping BP [--bcast-dst]`](#id-extended-bcast-check-ping-bp) a este README. Ele injeta um ping em texto claro
durante a conexão (ou seja, durante o 4-way handshake). Tanto clientes quanto APs podem ser vulneráveis a esse ataque.
- Atualizada a [visão geral de ataques](#id-paper-clarifications) com novos exemplos de como vulnerabilidades de injeção de pacotes
podem ser abusadas na prática. Isso inclui técnicas para enganar clientes somente IPv4 a usar um servidor DNS malicioso
e técnicas para se comunicar diretamente com dispositivos atrás de um NAT/firewall (por exemplo, para explorar serviços locais).
- Esclarecido que os [testes de fragmento de broadcast](#id-extended-bcast-check) podem ser executados tanto contra clientes quanto contra APs.
- A ferramenta de teste agora verificará se a versão esperada da biblioteca Python Scapy foi carregada.
- Corrigidas algumas referências ao artigo neste README (agora referencia corretamente as seções 6.4, 6.6 e 6.8).
- Atualizado para a versão 3 do rascunho do artigo. Não há mudanças importantes em comparação com a versão 2 do rascunho, apenas pequenos ajustes
textuais e estruturais. Em termos de conteúdo, esta é agora a versão final do artigo.
**Versão 1.3 (20 de janeiro de 2021)**:
- Esta versão é baseada no commit `a337c1d7c` do hostap ("New TWT operations and attributes to TWT Setup and Nudge").
- Adicionada uma [visão geral](https://github.com/vanhoefm/fragattacks/blob/HEAD/attacks.pdf) dos ataques e suas pré-condições e criados [estes slides](https://github.com/vanhoefm/fragattacks/blob/HEAD/amsduattack.pdf)
para ilustrar melhor como o ataque de agregação (CVE-2020-24588) funciona na prática.
- Adicionadas <a href="#id-wpa3-sae">instruções</a> sobre como testar dispositivos WPA3/SAE usando o método hunting-and-pecking
ou hash-to-element. Isso também implica que a Proteção de Frames de Gerenciamento (MFP) é suportada pela ferramenta de teste.
- Adicionado um esclarecimento a este README sobre como usar tcpdump para verificar o resultado de certos testes.
- Adicionado o teste extra `ping BP --bcast-ra --bcast-dst` a este README para poder testar a CVE-2020-26145
contra APs que não podem executar tcpdump (com este teste, o tcpdump deve ser executado em um cliente conectado independente).
- Adicionados os testes extras `ping I,E,F,E [--rekey-pl] [--rekey-req]` a este README para detectar melhor ataques
de chave mista (CVE-2020-24587) em certos dispositivos.
- Corrigida a injeção de frames fragmentados ao usar dongles ath9k_htc em combinação com 802.11n.
- O script `pysetup.sh` foi adicionado para criar o ambiente virtual Python. Este script também corrige
[um bug](https://github.com/secdev/scapy/commit/46fa40fde4049ad7770481f8806c59640df24059) na biblioteca scapy
quando usada com Python 3.9.
- Os drivers corrigidos foram atualizados para compilar corretamente no Linux 5.9.0.
- Corrigido o teste `ping-frag-sep`. Anteriormente, ele se comportava como `ping-frag-sep --pn-per-qos`. Observe que este teste
não é usado para detectar vulnerabilidades, mas apenas para entender melhor as implementações.
**Versão 1.2 (15 de novembro de 2020)**:
- Esta versão (e anteriores) é baseada no commit `1c67a0760` do hostap ("tests: Add basic power saving tests for ap_open").
- A ferramenta sairá automaticamente após um teste ser concluído ou expirar.
- A ferramenta detecta se o 4-way handshake está em loop ou se não há resposta a uma solicitação de rekey (`--rekey-req`).
- Ao usar um servidor DHCP externo, a ferramenta agora sempre enviará frames EAPOL com o endereço de destino
o AP (em vez do servidor DHCP). Isso é importante em testes de chave mista e ataque de cache ao usar um
servidor DHCP externo.
- Ao testar um AP usando `--rekey-req`, a ferramenta agora enviará EAPOL Rekey Request com um Replay Counter de
um em vez de zero.
- A saída de depuração agora mostra a chave (grupo) correta ao criptografar frames de broadcast/multicast. Isso não
influencia nenhum resultado de teste, apenas altera a saída da ferramenta de teste.
- Esclarecido que todos os comandos neste README podem testar tanto clientes quanto APs, salvo indicação em contrário.
- Esclarecidas as descrições dos testes de ataque de cache, fragmento de broadcast e ataque A-MSDU EAPOL neste README.
- Esclarecido que é importante testar tanto a banda de 2,4 quanto a de 5 GHz neste README.
**Versão 1.1 (20 de outubro de 2020)**:
- Corrigido um bug onde o comando `ping I,E,D` enviava uma solicitação de ping criptografada normal. Agora ele envia uma
solicitação de ping criptografada com o flag More Fragments definido no cabeçalho.
- Movidos os comandos `amsdu-inject-[bad]` para a Seção 7 deste README. Eles simulam ataques reais e podem
ser usados para verificar se mitigações temporárias estão funcionando (consulte a Seção 7.2 no artigo).
- Corrigida a grafia de SPPs A-MSDU neste README e na ferramenta de teste. O novo argumento `--amsdu-spp` agora é um
sinônimo do antigo argumento `--amsdu-ssp`.
**Versão 1.0 (11 de agosto de 2020)**:
- Preparado o lançamento inicial para uso durante o embargo.
| Placa de Rede | USB | 5GHz | modo misto | modo de injeção |
|---|
| Technoethical N150 HGA | Sim | Não | driver/firmware corrigido | driver/firmware corrigido |
| TP-Link TL-WN722N v1.x | Sim | Não | driver/firmware corrigido | driver/firmware corrigido |
| Alfa AWUS036NHA | Sim | Não | driver/firmware corrigido | driver/firmware corrigido |
| Intel Wireless-AC 8265 | Não | Sim | driver corrigido | sim |
| Intel Wireless-AC 3160 | Não | Sim | driver corrigido | sim |
| Alfa AWUS036ACM | Sim | Sim | driver corrigido | sim |
| Netgear WN111v2 | Sim | Não | driver corrigido | sim |
| Alfa AWUS036ACH | Sim | Sim | não | sim |
| Command | Short description |
|---|
ping | Envia um ping normal. |
ping I,E,E | Envia um ping fragmentado normal. |
ping I,E,E --delay 5 | Envia um ping fragmentado normal com um atraso de 5 segundos entre os fragmentos. |
ping-frag-sep | Envia um ping fragmentado normal com os fragmentos separados por outro quadro. |
ping-frag-sep --pn-per-qos | Igual ao anterior, mas também funciona se o alvo aceitar apenas PNs consecutivos. |
ping I,E --amsdu | Envia um ping encapsulado em um quadro A-MSDU normal (sem proteção SPP). |
amsdu-inject | Simula ataque: envia um quadro A-MSDU cujo início também é um cabeçalho rfc1042 válido. |
amsdu-inject-bad | Igual ao anterior, mas contra alvos que analisam o quadro incorretamente. |
ping I,F,BE,AE | Injeta dois fragmentos criptografados com uma chave diferente. |
ping I,F,BE,AE --pn-per-qos | Igual ao anterior, mas também funciona se o alvo aceitar apenas PNs consecutivos. |
ping I,E,R,AE | Injeta um fragmento, tenta acionar uma reassociação e injeta o segundo fragmento. |
ping I,E,R,E | Igual ao anterior, mas com um atraso maior antes de enviar o segundo fragmento. |
ping I,E,R,AE --full-recon | Injeta um fragmento, desautentica e reconecta, depois injeta o segundo fragmento. |
ping I,E,R,E --full-recon | Igual ao anterior, mas com um atraso maior antes de enviar o segundo fragmento. |
ping I,E,E --inc-pn 2 | Envia um ping fragmentado com números de pacote não consecutivos. |
ping I,E,P | Envia um ping fragmentado: primeiro fragmento criptografado, segundo fragmento em texto claro. |
ping I,P,E | Envia um ping fragmentado: primeiro fragmento em texto claro, segundo fragmento criptografado. |
ping I,P | Envia um ping em texto claro. |
ping I,P,P | Envia um ping fragmentado: ambos os fragmentos são enviados em texto claro. |
linux-plain | Ataque de fragmentação misto texto claro/criptografado específico do Linux. |
ping I,D,P --bcast-ra | Envia um ping unicast em um 2º fragmento broadcast em texto claro, uma vez conectado. |
ping D,BP --bcast-ra | Igual ao anterior, mas o quadro é enviado durante o handshake de 4 vias (verifique com tcpdump). |
eapol-amsdu I,P | Envia um A-MSDU em texto claro contendo uma solicitação de ping disfarçada como um quadro EAPOL. |
eapol-amsdu BP | Igual ao anterior, mas o quadro é enviado durante o handshake (verifique com tcpdump). |
eapol-amsdu-bad I,P | Envia um A-MSDU em texto claro malformado contendo uma solicitação de ping disfarçada como quadro EAPOL. |
eapol-amsdu-bad BP | Igual ao anterior, mas o quadro é enviado durante a conexão (verifique com tcpdump). |
No geral, pode ser tedioso testar se um dispositivo é vulnerável a ataques de cache. Portanto, também recomendo fazer uma auditoria de código para verificar se os fragmentos permanecem na memória após desassociar ou desautenticar de uma rede ou após reassociar (isso também pode ser verificado dinamicamente usando prints de depuração). Se os fragmentos permanecerem na memória, você deve considerar isso um risco, mesmo que não se saiba se pode ser explorado. Isso é semelhante a saber que uma implementação tem um buffer overflow, mas não (ainda) saber como explorá-lo.
Execute a ferramenta com o parâmetro extra --debug 2 para obter saída de depuração adicional do wpa_supplicant ou
hostapd e da própria ferramenta de teste.
Confirme usando uma segunda interface de monitoramento que nenhum outro quadro seja enviado entre fragmentos. Por exemplo, descobri que meu dispositivo Intel às vezes envia quadros Block Ack Response Action entre fragmentos, e isso interferia no processo de desfragmentação do dispositivo sob teste.
Verifique novamente se você está usando firmware modificado, se necessário para sua placa de rede sem fio. A ferramenta
de teste já verifica isso automaticamente para dispositivos ath9k_htc. A ferramenta de teste também verifica automaticamente
se você está usando drivers modificados, embora possa ser bom verificar manualmente isso na sua
distribuição Linux específica.
Pode ajudar adicionar um atraso entre a obtenção do endereço IP e a transmissão do primeiro fragmento/quadro.
Faça isso usando o parâmetro --pre-test-delay.
| Comando | Descrição curta |
|---|
ping I,E --amsdu-fake | Se este teste for bem-sucedido, o flag A-MSDU é ignorado (§3.5). |
ping I,E --amsdu-fake --amsdu-spp | Verifica se o flag A-MSDU é autenticado, mas depois ignorado (§3.5). |
ping I,F,BE,E | Caso a nova chave seja instalada relativamente tarde. |
ping I,E,F,AE | Variante se nenhum quadro de dados for aceito durante o handshake de rekey. |
ping I,E,F,AE --rekey-plain | Se o dispositivo realizar o handshake de rekey em texto claro. |
ping I,E,F,AE --rekey-plain --rekey-req | Igual ao acima e solicitar ativamente um rekey como cliente. |
ping I,E,F,AE --rekey-early-install | Instalar a nova chave após enviar a mensagem 3 do handshake de 4 vias. |
ping I,E,F,E [--rekey-pl] [--rekey-req] | Igual aos 4 testes acima, mas com atraso maior antes do 2º fragmento. |
ping I,F,BE,AE --freebsd | Ataque de chave mista contra FreeBSD ou implementações semelhantes. |
ping I,E,R,AE --freebsd [--full-reconnect] | Ataque de cache específico para implementações FreeBSD. |
ping I,E,R,AP --freebsd [--full-reconnect] | Ataque de cache específico para implementações FreeBSD. |
ping I,E,R,AP [--full-reconnect] | Teste de ataque de cache em que o 2º fragmento é enviado em texto claro. |
ping I,E,E --amsdu | Envia um ping normal como um quadro A-MSDU fragmentado. |
ping I,E,P,E | Ping com 1º fragmento criptografado, 2º em texto claro, 3º criptografado. |
linux-plain 3 | Igual ao linux-plain, mas o fragmento de chamariz é enviado usando prioridade QoS 3. |
ping I,P --bcast-ra | Ping em um quadro de broadcast em texto claro após o handshake de 4 vias. |
ping BP --bcast-ra [--bcast-dst] | Ping em quadro de broadcast em texto claro durante o handshake de 4 vias (use tcpdump). |
ping BP [--bcast-dst] | Ping em um quadro de texto claro durante o handshake de 4 vias (use tcpdump). |
eapfrag BP,BP | Ataque experimental de fragmento de broadcast (use tcpdump). |
eapol-amsdu[-bad] BP --bcast-dst | Igual ao eapol-amsdu BP, mas mais fácil de verificar contra APs (use tcpdump). |
eapol-inject 00:11:22:33:44:55 | Testa se o AP encaminha quadros EAPOL antes de autenticar (use tcpdump). |
eapol-inject-large 00:11:22:33:44:55 | Faz o AP enviar quadros fragmentados por injeção EAPOL (use tcpdump). |
ping I,D,E | Envia ping dentro de um segundo fragmento criptografado (sem 1º fragmento). |
ping I,E,D | Envia ping dentro de um primeiro fragmento criptografado (sem 2º fragmento). |
--rekey-pl--rekey-plaineapfrag BP,AE