Aireplay-ng

Aireplay-ng viene utilizzato per iniettare pacchetti.

La funzione principale del software e' generare traffico per poi utilizzare aircrack-ng per crackare chiavi WEP e WPA-PSK. Sono a disposizione differenti tipi di attacchi che possono causare la disconnessione di uno o piu' client (deauthentication) col fine di catturare un handshake WPA, generare una falsa autenticazione (fake authentication), generare un replay (injection) di pacchetti forgiati manualmente (interactive packet replay), iniettare pacchetti ARP request realizzati “a mano” ed effettuare attacchi standard di ARP-request injection. Con il tool packetforge-ng e' possibile realizzare pacchetti arbitrariamente.

La maggior parte driver devono essere patchati per supportare pienamente l'injection. Non dimenticare di leggere la parte di installazione dei driver.

Attualmente il software implementa una vasta varieta' di attacchi:

• Attack 0: Deauthentication
• Attack 1: Fake authentication
• Attack 2: Interactive packet replay
• Attack 3: ARP request replay attack
• Attack 4: KoreK chopchop attack
• Attack 5: Fragmentation attack
• Attack 6: Caffe-latte attack (In arrivo nella prossima release! Non disponibile al momento.)
• Attack 7: Client-oriented fragmentation attack (In arrivo nella prossima release! Non disponibile al momento.)
• Attack 9: Injection test

Questa sezione fornisce una panoramica generale. Non tutte le opzioni sono utilizzabili con tutti gli attacchi. Per informazioni dettagliate, dare uno sguardo alla documentazione specifica per ogni attacco.

Utilizzo:

 aireplay-ng <opzioni> <interfaccia per il replay>

Ad eccezione degli attacchi di deauthentication e fake authentication, e' possibile utilizzare i seguenti filtri per limitare i pacchetti forniti in ingresso ad un particolare attacco. L'opzione di filtraggio piu' comunemente utilizzata e' la “-b”, che serve a selezionare un access point specifico. Per un uso normale, l'opzione “-b” e' l'unica utilizzata.

Opzioni di filtraggio:

• -b bssid : MAC address dell'Access Point
• -d dmac : MAC address destinatario
• -s smac : MAC address sorgente
• -m len : lunghezza minima del pacchetto
• -n len : lunghezza massima del pacchetto
• -u type : frame di controllo, campo tipo
• -v subt : frame di controllo, campo sottotipo
• -t tods : frame di controllo, FromDS
• -f fromds : frame di controllo, ToDS
• -w iswep : frame di controllo, bit WEP

Quando si iniettano pacchetti (replaying), possono essere applicate le seguenti opzioni. Da tener presente che non tutte le opzioni sono pertinenti a tutti gli attacchi. La documentazione dettagliata per ogni attacco fornisce validi esempi di utilizzo di opzioni attinenti.

Opzioni di replay:

• -x nbpps : numero di pacchetti per secondo
• -p fctrl : set frame control word (hex)
• -a bssid : MAC address dell'Access Point
• -c dmac : MAC address destinatario
• -h smac : MAC address sorgente
• -e essid : attacco fakeauth : SSID dell'AP vittima
• -j : arpreplay attack : inject FromDS pkts
• -g value : dimensione del buffer ring (default: 8)
• -k IP : IP destinatario
• -l IP : IP sorgente
• -o npckts : numero di pacchetti per burst (-1)
• -q sec : secondi tra keep-alives (-1)
• -y prga : keystream per un'autenticazione a chiave condivisa

Gli attacchi possono ottenere i pacchetti da iniettare da due fonti. La prima dal flusso dati della scheda wireless. La seconda da un file pcap. Il formato standard Pcap (Packet CAPture, associato con la libreria pcap http://www.tcpdump.org), e' riconosciuto dalla maggior parte dei tool per la cattura e l'analisi del traffico di rete, open-source e commerciali. La lettura da un file e' una caratteristica trascurata di aireplay-ng, che permette di leggere pacchetti ottenuti anche in altre sessioni di cattura. Spesso i vari tipi di attacchi generano dei file pcap dove salvano i pacchetti catturati per permetterne un facile riutilizzo.

Opzioni per la sorgente:

• iface : cattura i pacchetti da questa interfaccia
• -r file : estrae i pacchetti da questo file pcap

Le seguenti sono le opzioni da utilizzare per specificare la modalita' (attacco) con la quale il programma operera'. A seconda della modalita', non tutte le opzioni trattate precedentemente sono utilizzabili.

Modalita' di attacco (possono anche essere specificate mediante i numeri tra parentesi):

• - -deauth count : disconnette 1 o tutti i client associati (-0)
• - -fakeauth delay : effettua una falsa autenticazione con l'AP vittima (-1)
• - -interactive : seleziona da un file un pacchetto da iniettare (-2)
• - -arpreplay : ARP-request replay standard (-3)
• - -chopchop : decifrazione/chopchop di un pacchetto WEP (-4)
• - -fragment : genera validi keystream (-5)
• - -test : test per l'injection (-9)

Di seguito sono riportate le differenze tra l'attacco Fragmentation e l'attacco Chopchop.

Pro:

• Tipicamente ottiene un pacchetto completo (keystream) da XORare di lunghezza pari a 1500 byte. Questo significa che in seguito e' possibile realizzare pacchetti di qualsiasi dimensione. Solitamente la dimensione del pacchetto ottenuta e' sufficiente per forgiare un pacchetto ARP request, anche quando la dimensione risulti inferiore a 1500 byte.
• Puo' funzionare dove chopchop non funziona.
• E' estremamente veloce. In caso di successo, produce il flusso di byte da XORare molto rapidamente.

Contro:

• Necessita di molte informazioni per essere avviato - Ad esempio informazioni sull'indirizzo IP. Molto spesso pero' queste informazioni non si conoscono. Se nulla viene specificato, aireplay-ng di default assume come indirizzo IP sorgente e destinatario 255.255.255.255. Quest'ultimo funzionera' con successo sulla maggior parte, per non dire tutti, degli AP.
• L'attacco dipende molto anche dai driver della periferica. Ad esempio i driver Atheros non generano correttamente i pacchetti, a meno che la scheda wireless non abbia lo stesso MAC address di quello che si sta spoofando.
• Eventualmente i pacchetti venissero persi, e' necessario essere fisicamente piu' vicini all'AP, altrimenti l'attacco fallira'.
• L'attacco fallira' su access point che non gestiscono correttamente pacchetti frammentati.

Pro:

• Puo' funzionare dove il fragmentation non funziona.
• Non necessita di conoscere informazioni sull'indirizzo IP.

Contro:

• Non puo' essere usato contro ogni access point.
• Il numero massimo di bit di xor e' limitato alla lunghezza del pacchetto utilizzato nell'attacco chopchop. Sebbene in teoria si potrebbe ottenere un flusso di 1500 byte da XORare, in pratica cio' e' molto raro, semmai si vedranno 1500 byte di pacchetto wireless.
• Molto piu' lento dell'attacco fragmentation.

L'ottimizzazione della velocita' di injection e' piu' un'arte che scienza. Si puo' provare ad utilizzare il parametro “-x” per variare la velocita' di injection. Sorprendentemente, la riduzione di questo valore può talvolta aumentare il data rate.

Si puo' provare a giocare anche con il valore del data rate: “iwconfig wlan0 rate 11M”. Dipende dal driver e dal modo in cui la scheda e' stata settata in mode monitor, di default e' solitamente 1 o 11 Mbit. Se ci si trova abbastanza vicini e' possibile settare un valore piu' alto, come 54M, che permettera' di ottenere piu' pacchetti al secondo. Se invece si e' molto lontani occorre provare a diminuire il valore a (per esempio) 1M.

Le seguenti verifiche possono essere utilizzate per tutte le modalita' di funzionamento di aireplay-ng.

Assicurarsi che non vi siano altri VAP in esecuzione. Possono esserci problemi infatti quando si crea un nuovo VAP in mode monitor mentre ne esiste un altro in mode managed.

Per prima cosa bisogna arrestare ath0 ed avviare wifi0:

 airmon-ng stop ath0
 airmon-ng start wifi0

o

 wlanconfig ath0 destroy
 wlanconfig ath create wlandev wifi0 wlanmode monitor

Dopo l'esecuzione del software tutto sembra bloccarsi senza restituire alcun output.

Solitamente questo problema e' causato dalla scelta sbagliata del canale di ascolto rispetto a quello dell'access point. Un'altra causa invece potrebbe essere l'uso di un firmware obsoleto su chipset Prism2. Di conseguenza occorre aggiornare il firmware alla versione 1.7.4 o superiore. Per maggiori informazioni vedere schede Prism. Le istruzioni per l'aggiornamento del firmware possono essere trovate qui.

Inoltre, se si e' avviato in background un'altro processo di aireplay-ng, il blocco potrebbe essere causato da un conflitto di opzioni.

Guardare questo thread: Aireplay freezes when injecting

O questo thread: Commenting out RTC

Controllare anche i post precedenti.

Quando si usa un chipset broadcom con il relativo driver a volte si ottiene un errore simile al seguente:

 write failed: Cannot allocate memory wi_write(): Illegal seek

La causa di cio' e' un bug presente nella patch originale del driver bcm43xx. Per ovviare a questo problema basta utilizzare la patch modificata di SuD. Alternativamente si puo' provare ad utilizzare il driver b43 invece del bcm43xx (che pero' richiede aireplay-ng 1.0-beta2 od una release piu' nuova; 1.0 rc1 o svn e' raccomandata.)

Sintomi: l'injection funziona ma molto lentamente, a circa 30 pacchetti al secondo (pps). Ogni volta che si avvia il processo di injection si ottengono i seguenti, o simili, messaggi da parte del kernel:

“rtc: lost some interrupts at 1024Hz”

Questo messaggio inoltre viene ripetuto migliaia di volte. Esistono un paio di soluzioni. La prima e' avviare un secondo processo di aireplay. In questo modo la velocita' d'injection dovrebbe aumentare fino a circa 300 pps. La seconda consiste nell'eseguire i seguenti comandi:

 rmmod rtc
 modprobe genrtc

o se si ha rtc-cmos abilitato nel kernel:

 rmmod rtc
 modprobe rtc-cmos

Non esistono altre soluzioni al merito per il momento. Dare uno sguardo a questo thread.

Essere troppo vicini all'AP puo' ridurre in modo significativo la velocita' di injection. La causa di questo inconveniente potrebbe essere attribuita alla corruzione dei pacchetti e/o al sovraccaricamento dell'AP. Per visualizzare un esempio di malfunzionamento dato dalla troppa vicinanza con l'AP, guardare questo thread.

La causa di quest'errore e' l'elaborazione di due o piu' processi di aireplay-ng contemporaneamente. Il programma continuera' a funzionare normalmente ma i tempi saranno meno precisi..

Dopo aver avviato aireplay-ng con opzioni simili alle seguenti:

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

Si ottiene un errore analogo a:

 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

Questo accade quando, il MAC address sorgente specificato per l'injection (tramite l'opzione -h) e' differente dal MAC address della scheda wireless. Nell'esempio precedente, il MAC address utilizzato per l'injection (00:13:A7:12:3C:5B) non combacia con il MAC address della scheda (06:13:F7:12:23:4A). In alcuni casi, ma non in tutti, questo comportera' un fallimento del processo d'injection. Per evitare cio' si raccomanda di cambiare il MAC address della scheda wireless in modo da farlo coincidere con quello utilizzato per l'injection.

Istruzioni dettagliate sul cambio del MAC address della scheda possono essere trovate nella FAQ: Come cambio il MAC address della mia scheda?.

Molte opzioni di aireplay-ng richiedono la conoscenza dell'SSID. A volte su airodump-ng come SSID sara' visualizzato “<length: ?>”. Questo significa che l'SSID e' nascosto. Il “?” corrisponde alla lunghezza dell'SSID. Ad esempio, se l'SSID fosse stato “test123” allora aireplay-ng avrebbe visualizzato “<length: 7>”, dove 7 e' il numero di caratteri. Quando la lunghezza corrisponde a 0 o 1, significa che l'AP non rivela la lunghezza attuale e di conseguenza quella reale potrebbe essere qualunque.

Per ottenere un SSID nascosto vi sono vari procedimenti:

• Aspettare che un client wireless si associ all'AP. Quando questo avviene, airodump-ng catturera' e visualizzera' l'SSID.
• Disconnettere un client esistente, forzandolo cosi' alla riassociazione.
• Usare un tool come mdk3 per effettuare un bruteforce dell'SSID.

Vedere questa FAQ

Quando si avvia il programma, il sistema si blocca o viene visualizzata una riga con scritto “Waiting for beacon frame” o “No such BSSID available” per poi non accadere piu' nulla.

Ci sono molte possibili cause alla radice di questo problema:

• La scheda wireless e' in ascolto su un canale differente rispetto a quello dell'AP. Soluzione: Usare iwconfig e settare il canale corretto.
• La scheda sta scansionando i canali. Soluzioni: Avviare airodump-ng con il parametro “-c” o “-channel” e specificare lo stesso canale dell'AP.
• L'ESSID e' sbagliato. Soluzione: Inserire il valore corretto. Se contiene spazi o caratteri speciali, racchiuderlo tra virgolette. Per maggiori informazioni, vedere questa FAQ.
• Il BSSID e' sbagliato: Soluzione: Inserire il valore corretto.
• Si e' troppo lontani dall'AP e non si riceve nessun pacchetto beacon. Soluzione: Usare tcpdump e/o airodump-ng per confermare la corretta ricezione dei pacchetti beacon dall'AP. In caso contrario, avvicinarsi fisicamente a quest'ultimo.
• Non si ricevono beacon dall'AP: Soluzione: Usare “tcpdump -n -vvv -e -s0 -i <nome interfaccia>” per confermare la corretta ricezione dei pacchetti di beacon. In caso contrario, supponendo che siano gia' stati affrontati i problemi precedenti, la causa del problema potrebbe essere il settaggio non corretto della scheda in mode monitor da parte del driver o dell'utente.

Per maggiori dettagli, avviare airodump-ng e leggere i relativi file di testo, i quali dovrebbero fornire tutte le informazioni necessarie per rimediare ai vari problemi.

Assicurarsi inoltre che:

• Eccetto che per la deauthenticaion, injection test e fake authentication, le altre modalita' di aireplay-ng richiedono un MAC address associato con l'access point vittima. Occorre quindi effettuare un attacco di fake authentication per associare il MAC address della propria scheda con l'AP o utilizzare il MAC address di un client gia' associato. Nel caso in cui non si utilizzi un MAC address associato, l'access point scartera' automaticamente i pacchetti. Messaggi di disconnessione durante l'injection denotano la non associazione con l'access point. aireplay-ng in genere visualizza questi messaggi, che possono essere visualizzati in ogni caso mediante l'ausilio di tcpdump: “tcpdump -n -e -s0 -vvv -i <nome interfaccia>”. E' possibile filtrarli inserendo delle pipeline in ingresso a grep come di seguito: `tcpdump -n -e -s0 -vvv -i ath0 | grep -E “DeAuth|assoc”'.
• La scheda wireless sia correttamente patchata ed installata. Usare l'injection test per confermare la compatibilita' della scheda.
• Assicurarsi si essere fisicamente abbastanza vicini all'access point. E' possibile confermare la distanza dialogando con l'AP seguendo queste istruzioni.
• Un altro metodo per confermare la corretta comunicazione con l'AP e' assicurarsi di ricevere i pacchetti ACK per ogni pacchetto trasmesso. In una comunicazione wireless, il ricevente deve confermare ogni pacchetto ricevuto con un pacchetto “ACK”. E' una parte del protocollo di comunicazione wireless. Sniffando senza filtri sul canale wireless, potrebbe essere possibile ottenere pacchetti “ACK”. Rivisualizzare una sessione di cattura con wireshark o tcpdump. Alternativamente e' possibile farlo in real time con “tcpdump -n -vvv -e -s0 -i <nome interfaccia>”. Una mancata ricezione dei pacchetti ACK da parte dell'AP significa che quest'ultimo non riesce a captare i segnali inviati dalla scheda wireless. Questo problema e' dato dalla troppa lontananza dall'AP.
• La scheda wireless sia settata in mode monitor. Utilizzare “iwconfig” per confermarlo.
• La scheda wireless sia in ascolto sullo stesso canale utilizzato dall'access point. Usare “iwconfig” per confermarlo.
• Assicurarsi di utilizzare un MAC address valido. Vedere la conversazione sul settaggio del MAC address).
• Alcuni access point sono programmati per ricevere solo connessioni da MAC address specifici. In questo caso occorre ottenere un MAC address valido tramite airodump-ng. Inutile si rivela in questo caso effettuare un attacco di fake authentication. Le liste di controllo accessi MAC non riconoscono un attacco di deauthentication. Vedere i suggerimenti per la risoluzione dei problemi dovuti al controllo accessi MAC.
• Il BSSID e l'ESSID (opzioni -a/-e) siano corretti.
• In caso di chipset Prism2, assicurarsi di avere aggiornato il firmware.
• Assicurarsi di usare la versione di software al momento stabile (stable). Alcune opzioni non sono disponibili nelle vecchie versioni del programma. Inoltre la versione stabile contiene molti bug corretti.
• Non e' una cattiva idea verificare il GitHub per vedere se il problema e' attualmente conosciuto come bug nella versione stabile. Molte volte la versione in fase di sviluppo contiene molti bug corretti riscontrati nella versione stabile.

Questa sezione si riferisce solo all'ultima versione SVN e ad alcune release candidate come prossime della suite di aircrack-ng. Una volta che queste verranno rilasciate come stabili, la documentazione soprastante verrà aggiornata.

Cambiamenti:

• “-e <ESSID>” non necessario, a condizione che l'ESSID non sia nascosto. (Si applica al fake auth e test)
• “-B” o “–bittest” e' un test del bit rate (Si applica al test)
• “-F” o “–fast” e' un test veloce (Si applica al test)
• “-D” disabilita il rilevamento dell'AP. Alcune modalita' non procedono se non viene ricevuto un pacchetto beacon dall'AP. Questa opzione disabilita' questa funzionalita'.
• “-F” sceglie il primo pacchetto corrispondente.
• “-R” disabilita l'utilizzo di /dev/rtc. Alcuni sistemi hanno problemi con l'RTC. Questa opzione ne disabilita l'ultilizzo.