Aireplay-ng

Tradução e Adaptação em Desenvolvimento: JaymesSmith (12/02/08)
Status: 55% traduzido.
Quando terminada, essas linhas serão apagadas.
When finished, these lines will be erased.

Aireplay-ng é usado para injetar frames.

A função principal é gerar tráfego para uso posterior no aircrack-ng para quebrar chaves WEP e WPA-PSK. Existem ataques diferentes que podem causar desautenticações com o propósito de capturar dados de handshake WPA, autenticações falsas, repetição de pacote interativo, injeção de ARP Request forjados e reinjeção de ARP Request. Com a ferramenta packetforge-ng é possível criar frames arbitrários.

A maioria dos drivers precisam ser de 'patch' para poder realizar injeção de pacotes, não esqueça de ler Instalando drivers.

Atualmente são implementados múltiplos ataques diferentes:

• Ataque 0: Desautenticação
• Ataque 1: Autenticação Falsa
• Ataque 2: Replay (Repetição) de Pacote Interativo
• Ataque 3: Ataque de Replay de ARP Request
• Ataque 4: Ataque KoreK chopchop
• Ataque 5: Ataque de fragmentação
• Ataque 9: Teste de Injeção

Esta seção fornece uma visão geral. Nem todas as opções podem ser usadas em todos os ataques. Veja os detalhes do ataque específico para detalhes relevantes.

Uso:

 aireplay-ng <opções> <replay interface>

Para todos os ataques, com exceção da desautenticação e autenticação falsa, você pode usar os seguintes filtros para limitar quais pacotes serão apresentados no ataque em particular. A opção de filtro mais comumente usada é a “-b” para selecionar um Access Point (AP) específico. Para uso normal, o “-b” é o único que você usa.

Opções de Filtro:

• -b bssid : Endereço MAC, Access Point
• -d dmac : Endereço MAC, Destino
• -s smac : Endereço MAC, Origem
• -m len : tamanho mínimo do pacote
• -n len : tamanho máximo do pacote
• -u type : controle de frame, tipo campo
• -v subt : controle de frame, subtipo campo
• -t tods : controle de frame, Para DS bit
• -f fromds : controle de frame, De DS bit
• -w iswep : controle de frame, WEP bit

Quando repetindo (injetando) pacotes, as opções a seguir podem ser usadas. Tenha em mente que nem todas as opções são relevantes para cada ataque. A documentação do ataque fornece exemplos das opções relevantes.

Opções de Replay:

• -x nbpps : número de pacotes por segundo
• -p fctrl : configurar a palavra do controle de frame (hex)
• -a bssid : configurar o endereço MAC do Access Point
• -c dmac : configurar Destino Endereço MAC
• -h smac : configurar Origem Endereço MAC
• -e essid : ataque de autenticação falsa : configurar SSID do AP alvo
• -j : ataque ARP Replau : injetar pacotes FromDS
• -g value : mudar tamanho do ring buffer (padrão: 8)
• -k IP : configurar o IP de destino em fragmentos
• -l IP : configurar o IP da origem em fragmentos
• -o npckts : número de pacotes por burst/rajada (-1)
• -q sec : segundos entre keep-alives (-1)
• -y prga : fluxo de chave para autenticação de chave compatilhada

Os ataques podem obter pacotes para repetir (replay) de duas origens. A primeira sendo um fluxo ativo de pacotes da sua placa wireless. A segunda sendo de um arquivo pcap. Formato Pcap padrão (Packet CAPture ou CAPtura de Pacote, associado à biblioteca libpcap http://www.tcpdump.org), é reconhecida pela maioria das ferramentas open-source e comerciais de análise e captura de tráfego. Leitura de arquivo é geralmente uma característica despercebida do arieplay-ng. Isso permite que você leia pacotes de outras sessões de captura ou, quase sempre, vários ataques geram arquivos pcap para fácil reutilização.

Opções da Origem:

• -i iface : captura pacotes desta interface
• -r file : extrai pacotes deste arquivo pcap

Isso é como você especifica em qual modo (ataque) o programa irá operar. Dependendo do modo nem todas as opções acima são aplicáveis.

Modos de Ataque (Números ainda podem ser usados):

• - -deauth count : desautenticar 1 ou todas as estações (-0)
• - -fakeauth delay : autenticação falsa com AP (-1)
• - -interactive : seleção de frame interativo (-2)
• - -arpreplay : replay de ARP Request padrão (-3)
• - -chopchop : decifrar/fatiar(chopchop) pacote WEP (-4)
• - -fragment : gera fluxo de chaves válido (-5)
• - -test : teste de injeção (-9)

Aqui estão as diferenças entre ataques de fragmentação e chopchop (fatiamento):

A Favor:

• Normalmente obtém o tamanho do pacote completo de 1500 bytes xor. Isso significa que você pode muito bem criar subsequentemente qualquer tamanho de pacote. Mesmo em casos onde menos de 1500 bytes são coletados, há espaço suficiente para criar ARP Requests.
• Pode vir a funcionar onde chopchop não funciona.
• É extremamente rápido. Ele marca a fluxo xor extremamente rápido quando bem sucedido.

Contra:

• Precisa de mais informações para execução - dados do endereço IP IE. Em geral isso pode ser adivinhado. Melhor ainda, aireplay-ng assume os IPs de destino e origem como 255.255.255.255 se nada for especificado. Isso funcionará com êxito na maioria, senão todos, os APs. Então este é um contra bem limitado.
• Configuração para executar o ataque está mais sujeito aos drivers do dispositivo. Por exemplo, Atheros não gera os pacotes corretos, a menos que a placa wireless seja configurada para o endereço MAC que você está fazendo o spoofing.
• Você precisa estar fisicamente perto do Access Point, já que se algum pacote se perder o ataque falha.
• O ataque irá falhar em Access Points que não gerenciam devidamente pacotes fragmentados.

A Favor:

• Pode funcionar onde a fragmentação não funcionar.
• Você não precisa saber qualquer informação de IP.

Contra:

• Não pode ser usado contra cada Access Point.
• Os bits xor máximos estão limitados ao tamanho do pacote com o qual você está fatiando contra. Embora, teoricamente, você poderia obter 1500 bytes do fluxo xor, na prática você raramente vê 1500 bytes de pacotes wireless.
• Mais lento em relação ao ataque de fragmentação.

Otimização de velocidade de injeção é mais arte do que ciência. First, try using to tools “as is”. You can try using the “-x” parameter to vary the injection speed. Surprisingly, lowering this value can sometimes increase your overall rate.

You may try to playing with the rate “iwconfig wlan0 rate 11M”. Depending on the driver and how you started the card in monitor mode, it is typically 1 or 11MBit by default. If you are close enough set it up to a higher value, like 54M, this way you'll get more packets per second. If you are too far away and the packets don't travel that far, try to lowering it to (for example) 1M.

These items apply to all modes of aireplay-ng.

Make sure there are no other VAPs running. There can be issues when creating a new VAP in monitor mode and there was an existing VAP in managed mode.

You should first stop ath0 then start wifi0:

 airmon-ng stop ath0
 airmon-ng start wifi0

or

 wlanconfig ath0 destroy
 wlanconfig ath create wlandev wifi0 wlanmode monitor

You enter the command and the command appears to hang and there is no output.

This is typically caused by being on the wrong channel compared to the access point. Another potential cause of this problem is when you are using an old version of firmware on prism2 chipset. Be sure you are running firmware 1.7.4 or above to resolve this. See Prism card for more details. Firmware upgrade instruction can be found here.

As well, if you have another instance of aireplay-ng running in background mode, this can cause the second to hang if the options conflict.

See this thread: Aireplay freezes when injecting

Also check the previous entry.

Symptoms: The injection works but very slowly, at around 30 packets per second (pps). Whenever you start injecting packets, you get the following or similar kernel message:

“rtc: lost some interrupts at 1024Hz”

This message is then repeated thousands of times. If you start a second instance of aireplay, then the injection would increases to around 300 pps.

There is no solution at this point in time, just the workaround to start a second instance. See this forum thread.

Being too close to the AP can dramatically reduce the injection rate. This is caused by packet corruption and/or overloading the the AP. See this thread for an example of the impact of being too close to the AP.

This is caused by having two or more instances of aireplay-ng running at the same time. The program will still work but the timing will be less accurate.

After entering an aireplay-ng command similar to:

 aireplay-ng -1 0 -e horcer -a 00:50:18:4C:A5:02 -h 00:13:A7:12:3C:5B ath0

You get a message similar to:

 The interface MAC (06:13:F7:12:23:4A) doesn't match the specified MAC (-h).
      ifconfig ath1 hw ether 00:13:A7:12:3C:5B

This occurs when the source MAC address for injection (specified by -h) is different then your card MAC address. In the case above, the injection MACof 00:13:A7:12:3C:5B does not match the card MAC of 06:13:F7:12:23:4A. In some cases, but not all, this will cause injection to fail. That is why it gives you this warning. So it is always recommended that your injection MAC match the card MAC address.

Detailed instructions on changing the card MAC address can be found in the FAQ: How do I change my card's MAC address ?.

Many aireplay-ng commands require knowing the SSID. You will sometimes see “<length: ?>” as the SSID on the airodump-ng display. This means the SSID is hidden. The “?” is normally the length of the SSID. For example, if the SSID was “test123” then it would show up as “<length: 7>” where 7 is the number of characters. When the length is 0 or 1, it means the AP does not reveal the actual length and the real length could be any value.

To obtain the hidden SSID there are a few options:

• Wait for a wireless client to associate with the AP. When this happens, airodump-ng will capture and display the SSID.
• Deauthenticate an existing wireless client to force it to associate again. The point above will apply.
• Use a tool like mdk3 to bruteforce the SSID.

See this FAQ entry

Also make sure that:

• Most modes of aireplay-ng require that your MAC address be associated with the access point. The exception being client disassociation, injection test and fake authentication modes. You must either do a fake authentication to associate your MAC address with the access point or use the MAC address of a client already associated with the AP. Failure to do this means that the access point will not accept your packets. Look for deauthentication or disassociation messages during injection which indicate you are not associated with the access point. aireplay-ng will typically indicate this or it can be done using tcpdump: “tcpdump -n -e -s0 -vvv -i <interface name>”. You can filter it by piping it to grep with something like `tcpdump -n -e -s0 -vvv -i ath0 | grep -E “DeAuth|assoc”'.
• The wireless card driver is properly patched and installed. Use the injection test to confirm your card can inject.
• You are physically close enough to the access point. You can confirm that you can communicate with the specific AP by following these instructions.
• The wireless card is in monitor mode. Use “iwconfig” to confirm this.
• The card is configured on the same channel as the access point. Use “iwconfig” to confirm this.
• Make sure you are using a real MAC address. See discussion in setting MAC address).
• Some access points are programmed to only accept connections from specific MAC addresses. In this case you will need to obtain a valid MAC address by observation using airodump-ng and use that particular MAC address. Do not do a fake authentication for a specific MAC address if the client is active on the AP. MAC access control lists do not apply to deauthentication. See the MAC access control troubleshooting tip here.
• The BSSID and ESSID (-a / -e options) are correct.
• If Prism2, make sure the firmware was updated.
• Ensure your are running the current stable version. Some options are not available in older versions of the program. As well, the current stable version contains many bug fixes.
• It does not hurt to check GitHub to see if your “problem” is actually a known bug in the current stable version. Many times the current development version has fixes to bugs within the current stable version.