Perché non abbiamo bisogno di un handshake WPA su un attacco MiTM spoofing ARP?

2

Sulla rete wireless in esecuzione con protocollo WPA2, la comunicazione tra un client e l'AP è crittografata usando una chiave di sessione (chiamandola così, ma se c'è un termine più preciso sarei felice per modificarlo) che viene scambiato tra di loro durante l'Handshake a 4 vie (che controlla se tale client è in possesso del PSK).

Questa chiave di sessione è univoca per ogni client connesso all'AP. Sto assumendo questa affermazione dal momento che quando un utente malintenzionato sta annusando una rete, deve avere la stretta di mano del client ogni se desidera decrittografare la comunicazione di ogni client con l'AP. Quindi, anche se sei connesso a detta rete, non sarai in grado di decifrare le comunicazioni di qualcun altro con l'AP, dato che la tua chiave di sessione è diversa (a meno che non capiti di catturare il 4- way handshake dell'altro cliente).

Durante un attacco MiTM usando lo spoofing ARP, sei già connesso all'AP, ma non hai gli tasti di sessione degli altri client. Una volta avvelenato la loro cache ARP, inizieranno a inviare i pacchetti destinati ad essere inviati all'AP al tuo computer. La domanda è, dal momento che credono ancora che stiano parlando con l'AP, non cripteranno i pacchetti usando la chiave di sessione che hanno scambiato con l'AP durante la connessione?

Lo chiedo perché sperimentando (sulla mia rete) non avevo bisogno dell'handshake a 4 vie per vedere il traffico decrittografato sulla macchina attaccante, che credevo di aver bisogno. Mi chiedevo se la chiave di sessione è allegata all'indirizzo MAC, quindi una volta che la vittima inizia a parlare con il tuo MAC, anche se crede che tu sia il gateway, non crittograferà il traffico con il tasto di sessione che utilizzava in precedenza.

    
posta murphsghost 22.08.2016 - 01:13
fonte

3 risposte

0

Questa non è una risposta definitiva, ma credo che potrebbe essere nella giusta direzione.

Ho trovato un file PCAP di uno dei miei esperimenti, che non riesco a condividere a causa delle dimensioni del file (oltre 40.000 pacchetti) e della presenza di potenziali dati sensibili. Lungo le cose che ho notato, il seguente sembra molto pertinente alla discussione:

Anche se l'acquisizione inizia prima di collegarmi all'access point fino alla fine dell'attacco di spoofing ARP, l'unico presente 4WHS era il mio. La vittima non ha ripetuto il 4WHS durante l'intero attacco. Tuttavia il traffico era completamente non criptato.

L'illustrazione sotto rappresenta lo scenario di attacco (ignorando il fatto che l'AP è un Range Extender WiFi). Le linee nere sono il normale flusso del traffico e le linee rosse sono il risultato dell'attacco MiTM:

Unavoltachel'hostA(attaccante)sicollegaall'APriceveunachiavetransitoriapairwise(PKT1).LostessoaccadequandoHostB(vittima)siconnette(PTK2,cheèunachiavediversa).QuestechiavivengonoutilizzatepercrittografareiltrafficotraHostAeAP,HostBeAP.CredocheilPTKsiaassociatoall'indirizzoMAC,quindiHostAsacheènecessarioutilizzarePTK1percrittografareidaticonMACCC:CC:CC:CC:CC:CCcomedestinazioneel'APsacheènecessarioutilizzarePTK1percrittografareidaticonMACAA:AA:AA:AA:AA:AAcomedestinazione.LostessovaleperlacomunicazioneHostB-AP(utilizzandoPTK2).

UnavoltachelatabellaARPvieneavvelenata,iltrafficodaHostBa"AP" non passa a MAC CC: CC: CC: CC: CC , quindi non utilizza il PTK2 per crittografarlo. Lo stesso accade con il traffico proveniente da AP reali verso la macchina degli attaccanti: Poiché il MAC non è BB: BB: BB: BB: BB l'AP non usa PTK2 per crittografare i messaggi.

Questo thread del forum di backtrack ( ARP-Poisoning MIT su WPA2 ) sembra anche non è necessario disporre delle informazioni WPA2 4WHS per intercettare il traffico decrittografato su tale attacco.

Ho intenzione di leggere ulteriormente l'intera RFC WPA2 per vedere se trovo qualche informazione concreta su questo, ma finora questa è la mia teoria su cosa sta succedendo.

Ho scelto la risposta di @dotproi come accettata, dal momento che è andato un po 'oltre cercando di capire cosa stava succedendo.

Se qualcuno ha una fonte che può confermare la mia teoria (o confermare che non è corretta), per favore condividi!

    
risposta data 23.08.2016 - 21:17
fonte
4

In primo luogo, per fare l'avvelenamento ARP devi essere connesso alla rete wireless su cui avveleni le risposte. Potresti già saperlo, ma la tua domanda non indica che sai che è un requisito, quindi volevo assicurarmi che fosse chiaro. Per quanto riguarda la tua risposta:

In parole povere, l'avvelenamento ARP funziona perché l'ARP funziona. L'unica cosa che cambia è che il valore delle risposte inviate dalla macchina attaccante è falso. Le risposte ARP sono implicitamente attendibili e, poiché scadono, devono essere aggiornate periodicamente. Gli aggressori sfruttano questa fiducia implicita per inviare risposte false. Se i dettagli del 4WHS fossero necessari per ARP, nessuno (reale o aggressore) sarebbe in grado di comunicare le risposte ARP.

    
risposta data 22.08.2016 - 06:19
fonte
3

Tramite l'avvelenamento ARP potresti essere in grado di instradare i pacchetti attraverso la tua macchina e metterti nel mezzo. Tuttavia, è necessario acquisire un 4wh per poter decifrare il PSK e decrittografarlo. Hai ragione nel dichiarare che la crittografia avviene in una porzione inferiore del livello. Di conseguenza, senza un 4wh, sarà in grado di vedere solo il traffico crittografato tra il client della vittima e l'AP.

Nel tuo scenario ci sono due possibilità.

Attendi , assicurandoti di iniettare periodicamente i pacchetti ARP contraffatti nella rete per aggirare eventuali timeout della cache ARP nella speranza di catturare un'altra stretta di mano quando la vittima si riconnette.

Forza l'estinzione automatica

Invio disassociare i pacchetti al client della vittima per forzare un altro handshake WPA che è potenzialmente possibile acquisire.

Dai un'occhiata alla questa voce nei documenti aircrack.

aireplay-ng -0 [# of deauths] -a [AP MAC] -c [Client MAC] [interface]

Questo post precedente è rilevante anche per questa discussione.

Modifica

Dopo aver riscritto la domanda, il tuo scenario è più chiaro per me.

La forzatura brutale di una sessione WPA non è comoda o banale. Tuttavia, ci sono strumenti che hanno moduli per automatizzare il processo di cracking (alcuni forse dietro le quinte?). Oltre allo schema di autenticazione sopra menzionato, non sono a conoscenza di altri componenti vulnerabili di WPA2 che potresti aver sfruttato "passando".

Con le informazioni disponibili, la spiegazione più probabile è una svista sulla tua parte. Cioè, hai effettivamente eseguito l'attacco e perso il ricordo, o forse hai scambiato la sessione in questione con un'altra.

Se hai le prove per rivedere la sessione e / o replicare, torna a trovarci.

Spero che questo aiuti.

    
risposta data 22.08.2016 - 08:46
fonte

Leggi altre domande sui tag