Hello world!

Sissejuhatus

Aireplay-ng`d kasutatakse frame`de sisestamiseks võrguliiklusesse.[1]

Peamine funktsioon on liikluse genereerimine hilisemaks kasutamiseks aircrack-ngs - WEP ja WPA-PSK võtmete lahtimurdmiseks. Erinevad rünnakuviisid võimaldavad tekitada deautentimist WPA handshake pakettide püüdmiseks, võlts deautentimiseks, interaktiivseks pakettie taasmängimiseks ja käsitsi valmistatud ARP päringute sisestamiseks liiklusesse.[1]

Eelteadmised

WEP ja WPA/WPA2 võrkude ründamiseks on vajalikud mõned konkreetsed eelteadmised. Nende teadmine lihtsustab suurel määral võimalike probleemide lahendamist ja annab paremini aimu millega tegu on ja kuidas asjad "backendis" töötavad - ei teki näiteks seda viga et üritatakse replayda paketti kui ühtegi klienti pole APga assotsiaseerunud.

WEP

WEPi ründamiseks on vaja eristada Open Authentication ja Shared Key Authentication süsteemi

Open Authentication

[[1]][5]

Klient saadab autentimis päringu AP'le.[5]
AP autentib kliendi.[5]
- AP laseb selles režiimis kõik kliendid läbi, st. mingit autentimist(sõna otseses mõttes) ei toimu[5]
Klient assotsib AP'ga ja liitub võrguga.[5]
- Selles punktis hakkavad mõlemad osapooled andmeid saatma WEPi krüpteeringuga, st. edasiseks suhtlemiseks on vaja teada salajast võtit. Sellesse punkti jõudes on võimalik assotsitud kliendi MACiga saata AP'le pakke(nõrk koht).[5]

Shared Key Authentication

http://documentation.netgear.com/reference/sve/wireless/images/WEPauthenticationShared.jpg [6]

Klient saadab autentimise päringu AP'le.[6]
AP saadab kliendile random baidiarray(pusle).[6]
Klient kasutab oma 64- vüi 128bitist salajast võtit ning krüptib saadud baidirea ära, ning saadab tagasi AP'le.[6]
AP dekrüptib saadud array ning võrdleb seda esialgu väljasaadetud stringiga, kui need ei kattu, siis saadetakse kliendile negatiivne vastus. Kui kattub siis järelikult on kliendil ja AP'l sama WEP võti, ning AP autentib kliendi ära.[6]
Klient ühendab võrku.[6]

Sellisel juhul ei ole võimalik autentimisest edasi saada ilma võtmeta, ning seega ei saa ka APle pakke saata. (Lahendus probleemile on #Shared Key Authentication artikli all)

Meetodid

Meetodite ees on "Rünnak x:". x tähistab numbrit mitmes implementeeritud rünnak see on ja seda numbrit aksepteerib aireplay-ng ka vastava käsurea lipu argumendina.

Rünnak 0: Deauthentication

See meetod saab disassotsiaseerumise paketi ühele või rohkemale kliendile kes on parasjagu vastava access pointiga assotsiaseerunud. Klientide dissimisel võib olla mitu eesmärki:[2]

Peidetud ESSID kättesaamine. See on ESSID mida access point ei kuuluta broadcastis.[2]
WPA/WPA2 handshake kinnipüüdmine sundides klienti uuesti autentima.(Ei ole kohustuslik, võib oodata ka kuni klient ise uuesti ühendub)[2]
ARP päringute genereerimine(Windowsi kliendid võivad mõnikord oma ARP cache tühjendada kui ühendus ära kaob)[2]

NB! Arusaadavalt on see rünnak täiesti kasutu kui traadita ühenduspunkti küljes ei ole ühtegi reaalset assotsiaseerunud klienti või võlts autentimist.[2]

Meetodid

Suunatud

Waiting for beacon frame (BSSID: 00:14:6C:7E:40:80) on channel 9
12:35:25  Sending 64 directed DeAuth. STMAC: [00:0F:B5:AE:CE:9D] [ 61|63 ACKs]

BSSID peab olema sihtmärk AP korrektne MAC aadress[2]
kanal peab olema sama millel AP reaalselt räägib[2]
STMAC on rünnatava kliendi korrektne MAC aadress[2]

Sending 64 directed - saadeti välja 64 suunatud deautentimise paketti, st. 64 kliendile ja 64 AP'le.[2]
61 - mitu paketti klient kätte sai[2]
63 - mitu paketti AP kätte sai[2]

Kui 61 ja 63 on arvud mis on suhteliselt stabiilsed ja lähedal 64'le, siis tähendab see seda et mõlemad osapooled on sinu võrgukaardi antennist kuuldekaugusel ja nendega on võimalik infot vahetada. Kui üks neist numbritest on väike, siis tähendab seda et asud vastavast osapoolest liiga kaugel - sellisel juhul see rünnak ei tööta, sul on vaja kas saatja saatevõimet suurendada, või minna osapoolele füüsiliselt lähemale.[2]

Suunatud VS broadcast olukorras on alati soovitav kasutada suunatud varianti, kuna paljud kliendid ignoreerivad broadcastis saadetud disconnect paketti.[2]

Kui sulle kliendi ACK'ide arv on korrektne, aga sulle ikkagi ei tundu et ta ennast lahti ühendaks, siis võib probleem peituda selles et ta ühendub uuesti liiga kiiresti.[2]

Broadcast

Waiting for beacon frame (BSSID: 00:14:6C:7E:40:80) on channel 9
NB: this attack is more effective when targeting
a connected wireless client (-c <client's mac>).
15:49:32  Sending DeAuth to broadcast -- BSSID: [00:14:6C:7E:40:80]

Nagu mainitud, broadcast disconnect on vähem efektiivsem.

Rünnak 1: Fake authentication

Võlts autentimine lubab läbi viia nii Open System kui ka Shared key WEP autentimist, peale selle teeb ta ka assotsiatsiooni access pointiga. See on kasulik ainult siis kui sul on vaja AP'le pakettide saatmiseks assotsiaseeritud klienti, selle puudumisel ei võta AP ühtegi talle saadetud pakki vastu. Kui meil on aga reaalne klient, siis saame tema nimel pakke saata, kui pole, on vaja võlts autentimist. Võlts autentimine ei tekita ARP pakette(seega ei piisa selle üksi kasutamisest) ja ei suuda assotsiaseeruda WPA/WPA2 access pointidega.[3]

Fake authenticationit ei tohi kasutada aktiivse kliendi MACiga, kuna see ajab ruuteri segadusse(?). See on eriti sobilik meetod selliseks juhuks kui olemasolevalt kliendilt on kinni püütud näiteks ARP pakett, ning klient ühendub lahti enne kui suudad piisavalt arp pakette tagasi mängida. Sellisel juhul aitab sama kliendi MACiga fake autentimine ning siis seda kinnipüütud pakki uuesti/edasi mängida.

Meetodid

Open Authentication

Open authentication puhul ei üritata klienti enne assotsiamist autentida, seega saame kerge vaevaga ennast ära assotsida ning hakata AP'ga suhtlema. Selles etapis hakkavad tavakliendid WEP'i(ja seega ka salajast võtit) kasutades rääkima, meie aga saame sisestada juba korrektse võtmega krüptitud(reaalselt kliendilt varem püütud) pakke AP'le saatma, uuesti ja uuesti.[4]

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

Sellisel juhul on assotsiaseerumine õnnestunud ja võib jätkata teiste rünnakutega - AP võtab vastu vastavalt MACilt tulevaid pakke, ja saadab õigetes tingimustes ka vastuseid.[4]

Shared Key Authentication

SKA tähendab seda, et AP ei räägi potensiaalse kliendiga mitte midagi, va. WEP võtmega autentimise protokoll, seega ei ole võimalik meil AP'ga assotsiaseeruda(me ei tea ju salajast võtit millega AP saadetud puzzle ära "lahendada") ning sellest tulenevalt ei saa me ka AP'le mingeid pakke saata.(?)

15:46:53  Sending Authentication Request
15:46:53  AP rejects open-system authentication
Please specify a PRGA-file (-y).

Sellisel juhul on vaja kinni püüda SKA handshake paketid. See toimub automaatselt kui airodump-ng näeb mõnda WEP-SKA handshake'i. Deauthentimise rünnakuga saab seda olemasolevale kliendile sundida.[7]

Kinnipüütud handshake'id salvestatakse "sharedkey-01-00-14-6C-7E-40-80.xor" formaadis faili. See fail tuleb vastavasse AP'sse fake autentimisel/kliendi disconnectimisks anda kaasa "-y" käsurea argumendiga.[7]

NOTE: Kui airodump-ng jookseb ilma aktiivseid rünnakuid AP pihta tegemata, siis on AUTH väli WEP AP taga tühi. Kui airodump-ng näeb mända handshake'i siis tuleb AUTH välja sisse SKA, samal hetkel salvestatakse ka fail.[7]

Rünnak 2: Interactive packet replay

See rünnak lubab valida konkreetse paketti mida taasmängida. Selle meetodiga saab pakette lugeda kahest kohast, võrgust ja failist. Keskendume võrgust püüdmisele. Et interaktiivne uuestimängimine töötaks on tähtis veidi alusteadmisi paketivoo kohta. Iga pakett ei tööta selle rünnakuga. Õnnestumine tähendab seda et AP võtab paki vastu ja genereerib uue IV - WEP ründamiseks on vaja ju koguda palju IV'sid. Väga kasulik on panna peale ka "-m 68 -n 86" filtrid. Need filtreerivad vastavalt minimaalse paki suuruse(68- traadita klientilt) ja maksimaalse(86- traadiga kliendilt). Need on WEP ühenduses ARP pakettide suurused ning õigesti kasutades peaksid tagama vastuse AP poolt.[8]

Naturaalsed paketid

Et seda teha, tuleb meil kas taasmängida originaalpaketti, või paketti veidi manipuleerida. AP'd edastavad(tekitavad uue IV) alati pakkidele mis on suunatud broadcast MACi(FF:FF:FF:FF:FF:FF) vastu. Selline omadus on näiteks ARP pakettidel. Peale selle on vajalik et pakett liiguks traadita kliendist traadiga võrku. Sellisel pakettil on "To DS" lipuke seatud "1" peale. Need filtrid on seadistatavad -b,-d ja -t argumentidega.[8]

Manipuleeritavad pakid

Eesmärk, nagu alati, on panna AP genereerima uusi IV'sid. Ainuke vajalik argument on "-t 1" - see selekteerib ainult pakette mis liiguvad etherneti suunas.

Me ei hooli ka mis lõppunkti MAC aadress on, kuna me saame selle ära muuta. Selleks on "-p 0841" argument, mis muudab paki põhimõtte selliseks nagu ta saadetaks kliendist AP'sse - põmst. muudab "To DS" lipu "1". Vaja on anda ka "-c" väärtuseks broadcast MAC.[8]

Klientideta võrgu ründamine

Sellel meetodil on väga huvitav omadus see, et saab rünnata ka traadita-klientideta AP'd. Jooksuta aireplay-d kõige elementaarsemate argumentidega:

aireplay-ng -2 -b 00:14:6C:7E:40:80 -d FF:FF:FF:FF:FF:FF -t 1 ath0

Nüüd jääb üle vaid oodata kuni mõni pakett broadcasti saadetakse. Pole tähtis milline pakket, sisesta lihtsalt "y" esimesele tulevale pakile ja AP hakkab IV'sid genereerima. Negatiivne külg asjal on tõsiasi et paljud pakid on suhteliselt suured - suured pakid genereerivad IV'sid aeglasemalt. Suur pluss on see et ei ole vaja kinni püüda xor paketistriimi(chopchop või fragmenteeritud rünnakud), ehitada pakki ja käivitada relay rünnakut.[8]

Rünnak 3: ARP request replay attack

Klassikaline ARP päringu taasmängimise rünnak on efektiivseim viis IV'de genereerimiseks, ja ta töötab ka piisavalt stabiilselt. Programm kuulab ARP paketti(tunneb ära kindlate mittekrüptimata väljade järgi ja paki pikkuse järgi) ning hakkab seda AP'le taasmängima. See omakorda põhjustab igale päringu vastusele uue IV genereerimise. Seda rünnakut võib lugeda interaktiivse taasmängimise erijuhuks.[9]

Rünnak 4: KoreK chopchop attack

See rünnak suudab hea õnne korral dekrüptida WEP paketi ilma salajast võtit teadmata. Meetod võib töötada isegi dünaamilise WEP vastu. See rünnak ei tagasta sulle WEP salajast võtit, vaid paketi sisu ja selle paketi krüptimiseks kasutatud keystreami. Mõned AP'd ei ole sellele rünnakule avatud. Kui AP dropib pakke mille pikkus on alla 42 baidi, siis aireplay üritab ülejäänud baidid ära arvata - edukuse tõenäosus oleneb headerite ennustusvõimest. Kui püütakse kinni IP pakett, siis tehakse lisaks veel checksum kontroll peale arvatava lisabaitide juurdelisamist. Rünnakuks on vaja vähemalt ühte WEP paketti.[10]

Teooria

KoreK võttis hästituntud nõrga ICV[link] probleemi ja järeldas sellest, et kui pakki lühendada ühe baidi võrra, siis saab sellest ehitada uue korrektse paki, kuna uus ICV on otseselt seotud puuduva krüptimata baidiga. [11]

Esimene samm on võtta püütud pakett (M) ja eemaldada viimane bait, et saada sõnum M-1. Kuna me ei tea eemaldatud baidi plaintekst väärtust, peame hakkama seda arvama. Õnneks on ainult 256 võimalikku baidiväärtust. Esmaks eeldame siis et eemaldatud bait oli 00 ja paneme saadud sõnumi valemisse(liiga mahukas et siin kirjeldada) et luu abitmask mis üritab muuta ebakorrektset M-1 paketti valiidseks M-1 paketiks. Siis proovime paki korrektsust pritsides selle võrku. Kui AP selle kätte saab, siis kontrollitakse seda ja vastavalt aksepteeritakse või rejectitakse. Iga saadetud pakk baseerub arvatava baidil, niiet tõenäosus õige olla on 1/256. Kui pakett on aga õige, siis AP valideerib selle ja edastab võrku. Eeldades et sa samal ajal kuulad võrku saad näha kui AP seda teeb. Sellisel juhul tead mis on paki viimane bait. Siis on võimalik arvutada PRGA väärtus mida kasutati selle plaintekst baidi krüptimiseks(P XOR M = RC4 PRGA). Ühesõnaga, ründaja saab bait baidi haaval kogu paketi niimoodi ära arvata, boonuseks on ka keystream millega saad oma paki luua.[11]

 .........
 Offset   38 (90% done) | xor = FD | pt = 08 |  229 frames written in   688ms
 Offset   37 (92% done) | xor = 13 | pt = 01 |  232 frames written in   695ms
 Offset   36 (94% done) | xor = 83 | pt = 00 |   19 frames written in    58ms
 Offset   35 (96% done) | xor = 4E | pt = 06 |  230 frames written in   689ms
 Sent 957 packets, current guess: B9...
 
 The AP appears to drop packets shorter than 35 bytes.
 Enabling standard workaround: ARP header re-creation.
 
 Saving plaintext in replay_dec-0201-191706.cap
 Saving keystream in replay_dec-0201-191706.xor
 
 Completed in 21s (2.29 bytes/s)

Jee! Saad kasutada xor faili oma paki injectimiseks või lugeda paki sisu .cap failist. Vaata ainult et paki injectimisel kasutad autentitud source maci, väga väheste ruuterite korral töötab paki sisestamine broadcasti ilma autentimata. Soovitatav on võtta ka lühem pakett kuna deükrptimise aeg on lineaarselt seotud paketi pikkusega.[10]

Rünnak 5: Fragmentation attack

Õnnestumise korral suudab see rünnak tagastada sulle kuni 1500 baiti PRGA'd. See rünnak ei tagasta WEP võtit. Saadud PRGA'ga saab krüptida oma loodud pakette ja neid võrku injectida. Ründamiseks on vaja saada AP'lt vähemalt üks pakett.[12]

Põhimõtteliselt saab proigramm paketist väikese hulga võtmematerjali ning üritab saata ARP või LLC pakette(sisu on teada) AP'le. Kui pakett kajatakse tagasi AP poolt siis saab tagstatud paketi põhjal tuletada suurema hulga PRGA baite. Tsüklit saab korrata kuni saadakse kätte kuni 1500 baiti.[12]

See rünnak nõuab head ühendust AP'ga, kuna ründaja fragmenteerib pakette ja AP peab need kõik kätte saama.[12]

Saving chosen packet in replay_src-0124-161120.cap
 Data packet found!
 Sending fragmented packet
 Got RELAYED packet!!
 Thats our ARP packet!
 Trying to get 384 bytes of a keystream
 Got RELAYED packet!!
 Thats our ARP packet!
 Trying to get 1500 bytes of a keystream
 Got RELAYED packet!!
 Thats our ARP packet!
 Saving keystream in fragment-0124-161129.xor
 Now you can build a packet with packetforge-ng out of that 1500 bytes keystream

Ja meil ongi olemas .xor fail millega saab custom pakette injectida. Muidugi on vajalik assotsitud klienti kelle nimelt pakette injectida.[12]

Rünnak 6: Cafe-latte attack

Iga WEP klient kes saab ARP päringu vastab sellele automaatselt korrektselt krüptitud ARP vastustega - AP ei pea selles etapis tõestama et ta WEP võtit teab. Selle rünnakuga saab kinnipüütud paketis pöörata ümber mõned bitid mille käigus pööratakse kliendi ARP päring ta enda poole tagasi. Saates võltsitud ARP päringut kliendile korduvalt saame kinni püüda suurel hulgal korrektseid krüptitud ARP vastuseid.[13]

See rünnak töötab kuna WEP ei ole nõrk mitte ainult statistilise analüüsi rünnakute vastu, vaid tal puudub ka krüptograafilise tugevusega paki integrity kontroll. Lühidalt öeldes ei suuda osapooled eristada võltsitud/modifitseeritud paketti korrektsest pakist.[13]

Iga WEP pakett kasutab CRC checksumi ülekande vigade tuvastamiseks. Ammu aga teatakse et ründaja saab muuta nii paki sisu kui ka CRC'd et luua uus korrektne pakk. Cafe-latte kasutab neid nõrkusi ja muudab ära saatja MACi ja saatja IP aadressi mis sisalduvad kliendi ARP päringus ning suunavad need kliendi vastu.[13]

Kuna klient ei suuda võltsingut eristada, vastabki ka igale päringule.[13]

Kasutamine

Seda rünnakut saab kasutada reaalsest võrgust eraldatud kliendi puhul. Kliendid teevad tuntud võrkude otsimisel PROBE päringuid, millele saab ründaja siis fake APga vastata. Sellisel juhul peaks kasutama "-D" argumenti et lülitada välja AP otsimine.[14]

Rünnak 7: Client-oriented fragmentation attack

Selle rünnakuga saab kasutada suvalist IP või ARP paketti. See laiendab Cafe-Latte rünnakut lubades kasutada suvalist paketti kliendilt. Sellest paketist peame genereerima ARP päringu. ARPil peab asuma baidipositsioonil 33 target IP ja target MAC peab olema nullbaidi jada.

From this, we need to generate an ARP request. The ARP request must have the target IP (client IP) at byte position 33 and the target MAC should be all zeroes. However the target MAC can really be any value in practice.

The source IP is in the packet received from the client is in a known position - position 23 for ARP or 21 for IP. ARP is assumed if the packet is 68 or 86 bytes in length plus a broadcast destination MAC address. Otherwise it is assumed to be an IP packet.

In order to send a valid ARP request back to the client, we need to move the source IP to position 33. Of course you can't simply move bytes around, that would invalidate the packet. So instead, we use the concept of packet fragmentation to achieve this. The ARP request is sent to the client as two fragments. The first fragment length is selected such that the incoming source IP is moved to position 33 when the fragments are ultimately reassembled by the client. The second fragment is the original packet received from the client.

In the case of an IP packet, a similar technique is used. However due to the more limited amount of PRGA available, there are three fragments plus the original packet used.

In all cases, bit flipping is used to ensure the CRC is correct. Additionally, bit flipping is used to ensure the source MAC of the ARP contained within the fragmented packet is not multicast.