Üdvözlöm minden kedves olvasómat EthicalHacking cikksorozatom 8. részében!

Ma a WPA feltöréséről lesz szó...Miről??
Tavaly novemberben két kutató új módszert talált ki arra, hogyan lehet üzenetet küldeni egy WPA hálózatba a jelszó ismerete nélkül. Módszerükkel tehát a kulcsot ugyan nem lehet megszerezni, de üzenetet lehet küldeni. Lássuk, hogyan.

Az itt megjelent írás teljes egészében megtalálható az ethicalhacking.hu weboldalon is. Az aláírás sem véletlen: együtt hoztuk ugyanis össze a leírást.

A tavalyi év végén sokak megrökönyödésére rémisztő cikkek jelentek meg több helyen is:
• „az eddig megfelelő jelszóval törhetetlennek tartott WPA hálózatokban is megtalálták a rést.”

• „ A két kutató, Erik Tews (Darmstadt Egyetem - a PTW eljárás szülőhelye) és Martin Beck (aircrack-ng fejlesztőcsapat) már 15 perc alatt fel tud törni egy WPA hálózatot”

• „nincs menekvés a vezeték-nélküli hálózatok tulajdonosainak”

Ilyen, és ehhez hasonló szalagcímeket olvashattunk. De járjunk utána, mi is az igazság e tekintetben? Ehhez először is tekintsünk be a Wireless LAN kulisszái mögé, majd a megtudott információk fényében térjünk rá a kutatók eredményeire.

A vezetéknélküli hálózatokon már régóta ajánlott a WPA (Wireless Protected Access) használata. Ez a titkosítási mód ugyanis kiküszöböli a WEP eddig megismert összes hiányosságát, ezek közül a legfontosabbat, az ismétlődő Initilization Vectort (mely a kulcsgenerálás során felhasznált „random” érték). Az IV-nek kulcsszerepe van a WEP titkosításban, ennek ellenére egy gyenge algoritmus készíti, emiatt akár néhány percen belül is előfordulhat, hogy két csomagot ugyanaz az IV titkosítja. Ezt a problémát úgy oldotta meg az IEEE bizottság, hogy az eredeti 24 bitesről 48 bitesre növelte az IV hosszát, ezzel gyakorlatilag eltüntette az IV ismétlődést, ez az egyik alapja a WPA-titkosításnak.

Azonban a bizottság nem készíthetett teljesen új titkosítást, hiszen biztosítani kellett a visszafelé való kompatibilitást (a régebbi, csak WEP-re hitelesített eszközöknek is támogatniuk kellett az új rejtjelezést). Ezért nyúltak vissza a WPA megalkotói az 1999-ben kiadott 802.11i szabványhoz, és felhasználták az abban meghatározott TKIP (Temporal Key Integrity Protocol) technikát. Ezzel lett teljes a WPA szabvány. A WPA2 ettől abban különbözik, hogy tartalmazza és megköveteli a TKIP mellett az AES (Advanced Encryption System) titkosítást is.
De térjünk vissza az áldozatra, a WPA-ra, amely még nem követeli meg az AES használatát. A visszafelé való kompatibilitás olyan „jól” sikerült, hogy a kutatók végül is megtalálták egy darabját a WEP-örökségnek, amely benne maradt az utódban is: a régebbi kártyákon is működnie kellett a WPA-nak, ezért megmaradt az RC4 kódoló algoritmus és hibadetektálásként az Integrity Check Value, mely WEP esetében nem más, mint a jó öreg CRC32. Ezek együttesen lehetővé teszik az alábbiakban ismertetett ChopChop-támadás alkalmazását WPA-n is.

A ChopChop támadás általános működése

A WEP-csomag hibátlanságát CRC32-ellenőrzőösszeg állapítja meg. A hálózati forgalomban ugyan mind az adat, mint a CRC titkosítva utazik, de ha módosítunk a titkosított adatokon, a CRC újraírása révén még a megváltoztatott csomagokat is hitelesként fogadja el az AP. Emiatt a titkosítás megfejtése nélkül, vakon felül lehet irkálni a WEP-csomagokat, és addig lehet kalapálni, amíg a titkosított CRC is helyes lesz. (Korek, 2006.)

Ezt a „képességünket” felhasználva lehetőség adódik egy találgatós játékra. Fogunk egy csomagot, kiveszünk belőle egy bájtot. Ez lesz a titok számunkra. Vajon mi volt benne eredetileg? 0-tól 255-ig bármi lehetett. Tegyük fel, hogy amit levágtunk, annak tartalma 42 (mert ez a válasz a világmindenségre meg mindenre). Újraszámítjuk a csonkolt csomag CRC-jét úgy, mint ha tényleg 42-t vágtunk volna le belőle, majd beküldjük őket az AP-nak. Ha a tippünk helyes, a CRC valóban helyes lesz, így a csonka csomagot az AP visszaküldi az éterbe. Ebből tudhatjuk, hogy nyertünk, 42=42! Ha nem, hátravan még 255 próba, és máris megvan az egyik bájt értéke.
Az eljárást megismételjük a csomag többi bájtjára is, így a kulcs ismerete nélkül el tudjuk olvasni a teljes csomagot. De ez még nem minden! Amint megvan egy teljes csomag cleartext változata, ezt össze kell XOR-olni a titkosított változattal, és megkapjuk a WEP kulcsot. Zsír :)

A következő lépés a ChopChop-támadás alkalmazása WPA esetére

Ehhez először lássuk, mit változtattak meg a WPA-ban, hogy nekünk nehezebb dolgunk legyen.
Bevezették az MIC (Message Integrity Check) fogalmát: ez egy 64 bites karaktersorozat, amely kiegészíti a szimpla ICV-t, így nem csak a könnyen megoldható CRC32 áll ellent a támadónak, hanem eme, a Michael-függvénynek nevezett algoritmussal generált összeg is. A másik nagy változás, hogy létrehoztak egy „szekvenciális számolót” és ez vigyáz arra, hogy a csomagok sorrendben érkezzenek a fogadó félhez. A counter működése egyszerű: minden érkező csomag hatására eggyel nagyobb lesz az értéke. Ha aztán később valaki egy rögzített csomagot szeretne visszaküldeni, akkor a nagyobb számlálóérték miatt ez meghiúsul.
A nagyobbik gond azonban az MIC-vel van: ezt nagyon szigorúan veszi a szabvány: ha 2 db MIC hiba fordul elő egy percen belül, akkor leáll a kapcsolat, és egy 60 másodperces szünet után indítja csak el az AP a kapcsolatújrafelvételi-kérelmet a kliens felé – új kulccsal. Ez eléggé behatárolja a támadót.

Ezek után van még valaki, aki elhiszi, hogy sikeres lehet a támadás? Nos, akik igennel válaszolnának, azoknak lett igazuk: igen, még ezek ellenére is véghez lehet vinni. Mi hát a megoldás? A QoS, azaz a Quality of Service WiFi-be integrált megoldása: egy adott csatorna fel van osztva nyolc különböző alcsatornára, így egy eszköz csatornán belül egy másik alcsatornára válthat a kommunikáció folyamán, hogy jobb átviteli minőséget érjen el. „Szerencsére” minden alcsatornához egyedi counter tartozik, valamint a kliensek szinte mindig csak a nullás alcsatornát használják. Ez azt jelenti, hogy szinte mindig találunk egy olyan alcsatornát, ahol alacsonyabb a counter értéke, így a csomagunkat el fogja fogadni az AP! Mehet a ChopChop!

Sőt, szegény MIC hiába próbál védekezni, kompatibilitási okokból úgy építették fel a WPA-t, hogy először az ICV-ellenőrzés fut le, és ha ez rendben, akkor következik a MIC-ellenőrzés! Tehát a ChopChop által használt, hibás ICV-kre épülő találgatás teljes sebességgel rohanhat egy másik alcsatornán. Még mindig zsír :)
Ha az ICV-találgatásunk helyes volt, a feldolgozás végre-valahára eljut a MIC-ig, ami nyilván hibás, mert azt nem tudjuk helyesre pofozni (kapunk egy MIC Failure Reportot). Összegezve: percenkét egy bájtot találhatunk ki, ennyit adott nekünk a szabvány :)

Tetszőleges csomagon 8 perc alatt ki tudjuk találgatni a MIC (8 bájt) titkosítatlan értékét, ami később még jól fog jönni. Kellene még egy plaintext, hogy az egészet beletehessük egy megfordított Michael algoritmusba (mivel a függvényt kétirányúnak tervezték) és megkapjuk a titkosításhoz használt MIC kulcsot. Honnan szedjünk plaintextet?
Most jön a csavar. Ha ARP csomagot használunk fel, ami könnyen felismerhető jellegzetes hosszáról (42 bájt), abban már egy csomó adatot eleve ismerünk, hiszen az ARP-ben IP-címek és MAC Addressek utaznak! A MAC Addresseket tudjuk, mert titkosítatlanul repülnek az Ethernet fejlécben (különben nem ismernék fel a csomagot a hálókártyák), általában az IP-címtartományt is ismerjük. Mindössze két bájtot nem ismerünk belőle: a két IP-cím utolsó bájtját!
A két IP-bájtot két ChopChop-pal kitaláljuk (2 perc), és most már kezünkben tartjuk a teljes clear textjét egy WPA-val titkosított csomagnak!

Szólaljanak meg a harsonák, perdüljenek meg a dobok, és hulljon rá az első rög a WPA koporsójára!

Valóban ez lenne a helyzet? Nem, válaszolhatjuk egyértelműen: a kapott kulcsfolyammal ugyan bekódolhatunk egy csomagot, de a counteren nem változtathatunk, ezért újból a QoS csatornák között kell keresgélnünk, míg meg nem találjuk a megfelelőt, amelyen alacsonyan áll még a counter. A 0-son kommunikál a célkliens, így marad ideális esetben 7 csatornánk a saját gyártmányú csomagok sugárzására. A támadó így már tud kárt okozni, de elolvasni nem tudja az átküldött tartalmat. Ennek ellenére ez így is kellőképpen veszélyes! Az alkalmazható támadások közül az ARP poisoning az első ötlet: úgy állítja át a gépeket a hálózatban, hogy végül minden kommunikáció rajta keresztül menjen végbe.

A támadás működőképességét kutatók bizonyították egy valós hálózaton, sőt megoldást találtak a QoS csatornákat nem támogató AP-k esetére is: ez esetben meg kell akadályozni a kliens-AP kapcsolatot a támadás idejére (így nem nő a counter értéke), pontosan abban a pillanatban, amikor elkaptuk a megfelelő csomagot.
Ha valakinek sikerülne a mindkét irányban érvényes MIC kulcsot megszereznie (ez a támadás ugyanis csak az AP-kliens irány MIC kulcsát fedi fel) és egy valós kulcsfolyamot az egyik QoS csatornára (a counter szempontjából kedvezőre) akkor bármilyen tartalommal bármennyi csomagot küldhet a hálózatnak.

Az AirCrack-csapat már dolgozik a módszer implementálásán.

Védekezés: állítsuk a routeren rekeying intervallt alacsony értékre, pl. 120 másodpercre. Ennyi idő alatt a támadó csak 1, maximum 2 bájtját szerezte meg a MIC-nek, és a kulcsok máris kicserélődnek.

Tomcsányi Domonkos és Fóti Marcell

NetAcademia