WIFI 1: Helyi hitelesítő eljárások elleni

Budapesti M˝ uszaki és Gazdaságtudományi Egyetem Villamosmérnöki és Informatikai Kar H´ıradástechnikai Tanszék

M´ er´ esi u ´ tmutat´ oa WIFI 1: Helyi hiteles´ıt˝ o elj´ ar´ asok elleni ” t´ amad´ asok” c´ım˝ u m´ er´ eshez

H´ırközl˝o rendszerek biztonsága szakirány H´ırközl˝o rendszerek biztonsága laboratórium I. (BMEVIHIM220)

A mérést kidolgozták: ´ ´ ra La ´ szlo ´ , Laczko ´ Pe ´ter Buttyan Levente, Do [email protected]

CrySyS – Adatbiztons´ ag Laborat´ orium

2009. október 26.

Tartalomjegyz´ ek 1. M´ er´ es c´ elja

1

2. Elm´ eleti o ¨sszefoglal´ o 2.1. Alapfoglamak . . . . . . . . . . . . . . . . . . . . . . . 2.1.1. Vezeték nélk¨ uli interfész . . . . . . . . . . . . . 2.1.2. Beacon u ¨zenet . . . . . . . . . . . . . . . . . . 2.2. Rejtett SSID . . . . . . . . . . . . . . . . . . . . . . . 2.3. MAC sz˝ urés . . . . . . . . . . . . . . . . . . . . . . . . 2.4. WEP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.1. A WEP m˝ uködése . . . . . . . . . . . . . . . . 2.4.2. A WEP hib´ ai . . . . . . . . . . . . . . . . . . . 2.4.3. Egy komplett támadás WEP ellen . . . . . . . 2.5. WPA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5.1. Ismertet˝o . . . . . . . . . . . . . . . . . . . . . 2.5.2. Helyi hozz´ aférés-védelem és kulcsmenedzsment 2.5.3. WPA gyengeségei . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

2 2 2 2 2 3 3 3 6 7 10 10 11 12

3. M´ er´ esi k¨ ornyezet

13

4. Feladatok 4.1. Csatlakozás rejtett SSID-j˝ u AP-hoz . . . . . . . . . . . . . . . . . . . . . . . . 4.2. WEP elleni támadás . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3. WPA gyengeségei . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14 14 15 15

5. Tov´ abbi inform´ aci´ ok

15

6. Minta beugr´ o k´ erd´ esek

17

1.

M´ er´ es c´ elja

Wi-fi, WLAN, vezetéknélk¨ uli hálózat, IEEE 802.11: Ha nem is mind pontosan ugyanazt fedik le, mégis mindenki számára többnyire ugyanazt jelenti. Adott egy fix eszköz, u ´gynevezett access point (AP) vagy magyarul hozz´ aférési pont, amelyik többnyire vezetéknélk¨ uli kapcsolaton kereszt¨ ul biztos´ıtja az Internet hozz´ aférést az éppen hozz´ a kapcsol´ od´ o mobil állomások (STA) számára. Az egyik legelterjedtebb megoldást az IEEE 1999-ben kezdte szabványos´ıtani 802.11-es kódszám alatt [1]. Ennek a megoldásnak a biztons´ agi vonatkozásait k´ıv´ anjuk megismertetni a hallgat´ oval. Hogy miért pont ezt? Egyrészt, mert ahogy m´ ar mondtuk, az egyik legelterjedtebb megoldás, teh´ at jó eséllyel minden informatikus találkozik vele munk´ aja sor´ an. M´ asrészt pedig, elég régóta elkezd˝ od¨ ott a szabványos´ıt´ as, hogy találjanak benne hib´ at, amib˝ol tanulni lehet. Azt remélj¨ uk, hogy az itt bemutatott támad´ asokat a hallgat´ o által´ anosabban értelmezve megérti a hálózati biztons´ ag komplexitás´ at, és int˝o példaként szolgál a MAC sz˝ urés kijátszhatós´ aga, valamint a WEP tervezése sor´ an elkövetett hib´ ak. A mérés két részre oszlik, az els˝ oben helyi hiteles´ıtésen alapul´ o megoldásokat vizsgálunk, illetve az adatforgalom rejtjelezéssel és integritás-védelemmel kapcsolatos vizsgálatokat végz¨ unk el, m´ıg a m´ asik mérésben a központi hiteles´ıtést járjuk kör¨ ul. Sikeres mérés esetén a hallgat´ o az els˝ o mérés sor´ an 1) l´ athatja, hogy a rejtett SSID és a MAC sz˝ urés valójában mennyi biztons´ agot jelent; 2) visszafejt egy WEP jelszót; 3) megvizsg´ alja a WPA biztons´ agosság´ at, amin kereszt¨ ul betekintést ny´ ujtunk a brute force támadások hatékonyság´ aba is.

1

2.

Elm´ eleti ¨ osszefoglal´ o

Ebben a fejezetben ´ attekintj¨ uk a ma használatos WLAN biztons´ agi megoldásokat, valamint azok gyengeségeit. Mindezt egy r¨ ovid bevezet˝o után, ahol néh´ any fogalmat és m˝ uködési elvet tisztázunk.

2.1. 2.1.1.

Alapfoglamak Vezet´ ek n´ elk¨ uli interf´ esz

Az IEEE 802.11-ben meghat´ arozott teljes frekvenciasávot csatornákra osztották. A jelenlegi hardver többnyire csak egy csatornán való kommunikál´ ast engedélyez. Ezért minden esetben ki kell választani, hogy melyik csatornán akarunk k¨ uldeni vagy hallgatni. Norm´ alis esetben ez automatikusan és észrevétlen¨ ul történik. Normális esetnek tekinthet˝ o az, amikor egy STA egy adott AP-hoz kapcsol´ odik. Ilyenkor az STA beáll´ıtja a megfelel˝ o csatornát és attól kezdve csak egy adott frekvenciatartom´ anyban értelmezi a jeleket. Ráad´ asul, ha nem promiscuous m´ odban van a kártya, akkor azokat a csomagokat, amelyeknek nem mi vagyunk a c´ımzettjei, eldob´ asra ker¨ ulnek. Ezzel szemben promiscuous m´ odban minden olyan csomag megjelenik az interfészen, amelyik attól az AP-t´ ol érkezik, amelyikhez kapcsol´ odott a STA, f¨ uggetlen¨ ul attól, hogy ki a c´ımzett. Még nagyobb szabads´ agot biztos´ıt a monitor m´ od, amelyik nem igényel AP-hoz való kapcsol´ od´ ast, és ennek megfelel˝ oen minden olyan csomagot megjelen´ıt az interfészen, amelyek 802.11 fejléccel rendelkeznek. Itt m´ ar CRC vizsgálat sem történik, teh´ at megjelenhetnek sér¨ ult csomagok is. Mint l´ athat´ o monitor m´ odban a célcsatorna nem egyértelm˝ u, teh´ at azt a felhasználónak kell beáll´ıtani. 2.1.2.

Beacon u ¨ zenet

Az AP periodikusan k¨ uld egy beacon u ¨zenetet minden egyes csatornán, hogy a hatósugarában lév˝ o STA-k számára tudtukra adja jelenlétét. Ezekben az u ¨zenetekben az AP k¨ ul¨ onböz˝o informáci´ okat oszt meg u ´gy, mint a kommunikáci´ ora használt csatorna, támogatott átviteli sebesség, biztons´ agi mechanizmus vagy az SSID. Az SSID (Service Set ID) egy azonos´ıt´ o, ami egy hálózati eszközcsoportot határoz meg. Az STA-k SSID alapján tudj´ ak megk¨ ul¨ onböztetni a vezeték nélk¨ uli hálózatokat. Amikor több AP ugyanahhoz a hálózathoz tartozik, ugyanazt az SSID-t kapják. Ilyenkor a BSSIDvel (Basic SSID) lehet megk¨ ul¨ onböztetni ˝oket, ami egy egyedi azonos´ıt´ o, és többnyire a MAC c´ımmel egyezik meg. Amikor egy STA csatlakozik az AP-hoz, az asszoci´ aci´ os csomagba be kell illeszteni az AP SSID-jét is. Ekkor az AP ellen˝ orzi, hogy a kapott SSID megegyezik-e a saját SSID-jével. Amennyiben nem, az asszoci´ aci´ os kérést visszautas´ıtja.

2.2.

Rejtett SSID

A SSID-t ugyan lehet, de nem kötelez˝ o a beacon u ¨zenetbe beilleszteni. Amennyiben ez nem történik meg, akkor beszél¨ unk rejtett SSID-j˝ u AP-ról. Mivel ilyenkor csak az az eszköz tud csatlakozni, amelyik ismeri a SSID, az SSID tekinthet˝ o megosztott közös titoknak is. Ezt az eljár´ ast szokás biztons´ agi megoldásként használni. Csakhogy csatlakozáskor az SSID-t ny´ıltan k¨ uldi át az azt ismer˝o STA, ezért egy támadó egy asszoci´ aci´ os u ¨zenet lehallgat´ as´ aval az SSID birtok´ aba jut. Ezzel m´ ar a támadó is képes csatlakozni az AP-hoz. Ráad´ asul egy támadó képes k¨ uldeni egy deauthentication u ¨zenetet egy leg´ alis STA nevében. Így a leg´ alis STA leválaszt´ asra ker¨ ul, amelyik nagy valósz´ın˝ uséggel

2

automatikusan visszacsatlakozik. Ezzel ny´ıltan átk¨ uldi az SSID-t, amit a támadó azonnal megszerez.

2.3.

MAC sz˝ ur´ es

A MAC sz˝ urés tulajdonképpen m´ ar a vezetékes világb´ ol is ismert eljár´ as, és f¨ uggetlen az IEEE 802.11 szabványt´ ol. MAC sz˝ urés esetén az AP fenntart egy listát, hogy mely MAC c´ım˝ u STA-k jogosultak a hálózat használatára. Amennyiben egy olyan STA k¨ uld csomagot, amely nincs a listán, az AP egyszer˝ uen figyelmen k´ıv¨ ul hagyja a csomagot. A MAC c´ım a gyárt´ o ´ altal a hálózati eszközbe beégetett egyedi kód. Azonban ezt a kódot szoftveresen ´ at lehet ´ all´ıtani tetsz˝oleges értékre, ´ıgy akár egy olyan eszközére is, amelyik jogosult az AP-hoz való csatlakozásra. Ha egy támadó sikeresen szerez egy ilyen MAC c´ımet, képes lesz csatlakozni az AP-hoz. Azonban, mivel minden elk¨ uld¨ ott csomagba beker¨ ul forr´ asként vagy célként a csatlakozott STA MAC c´ıme, m´ ar egy csomag elfog´ as´ aval megszerezhet˝o a c´ım. Bizonyos szempontból ez a megoldás annyi biztons´ agot sem ny´ ujt, mint a rejtett SSID, mivel ott legal´ abb csak csatlakozáskor k¨ uldték át ny´ılt form´ aban a közös titkot. Itt azonban minden csomagban megjelenik a c´ım. Fontos megjegyezni viszont, hogy egyszerre két eszköz azonos c´ımmel nem csatlakozhat ´ egy AP-hoz c´ım¨ utk¨ ozés miatt. Eppen ezért a sikeres csatlakozáshoz meg kell várni, hogy a jogosult eszköz lekapcsol´ odjon az AP-ról, vagy hamis deauthentication csomaggal lehet er˝oszakkal leválasztani. Azonban ilyenkor megeshet, hogy az STA megpr´ ob´ al automatikusan visszacsatlakozni.

2.4.

WEP

Az IEEE 802.11 vezeték nélk¨ uli LAN szabvány tervez˝ oi kezdett˝ ol fogva fontosnak tartották a biztons´ agot. Ezért m´ ar a 802.11 korai verziója [1] is tartalmazott biztons´ agi mechanizmusokat, melyek ¨ osszességét WEP-nek (Wired Equivalent Privacy) nevezték el. Ahogy arra a név is utal, a WEP célja az, hogy a vezeték nélk¨ uli hál´ ozatot legalább olyan biztons´ agoss´ a tegye, mint egy - k¨ ul¨ on¨ osebb biztons´ agi kiegész´ıtésekkel nem rendelkez˝ o - vezetékes hálózat. Ha például egy támadó egy vezetékes Ethernet hálózathoz szeretne csatlakozni, akkor hozz´ a kell férnie az Ethernet hub-hoz. Mivel azonban a hálózati eszközök által´ aban fizikailag védve, zárt szobában találhatók, ezért a támadó nehézségekbe u ¨tk¨ ozik. Ezzel szemben egy védelmi mechanizmusokat nélk¨ ul¨ oz˝o vezeték nélk¨ uli LAN-hoz való hozz´ aférés - a rádiós csatorna nyitottsága miatt - trivi´ alis feladat a támadó számára. A WEP ezt a trivi´ alis feladatot hivatott megnehez´ıteni. Fontos azonban megjegyezni, hogy a WEP tervez˝ oi nem törekedtek ”t¨ okéletes” biztons´ agra, mint ahogy a zárt szoba sem jelent tökéletes védelmet egy Ethernet hub számára. A tervez˝ ok teh´ at nem tették t´ ul magasra a lécet, ám a WEP még ezt a korlátozott célt sem érte el. P´ ar évvel a megjelenése után, a kriptogr´ afusok és az IT biztons´ agi szakemberek s´ ulyos biztons´ agi hib´ akat találtak a WEP-ben [2, 3, 4], és nyilv´ anvalóvá vált, hogy a WEP nem ny´ ujt megfelel˝ o védelmet. A felfedezést tett k¨ ovette, és hamarosan megjelentek az Interneten a WEP feltörését automatizáló programok. V´ alaszul, az IEEE u ´j biztons´ agi architekt´ urát dolgozott ki, melyet a 802.11 szabvány i jelzés˝ u kiegész´ıtése tartalmaz [5]. A 802.11i elosztott hiteles´ıtéssel kapcsolatos részét a következ˝ o mérésen, a helyi hiteles´ıtéssel kapcsolatos ter¨ uleteit a következ˝ o fejezetben tárgyaljuk. Ebben a fejezetben a WEP m˝ uködését és hib´ ait tekintj¨ uk ´ at. 2.4.1.

A WEP m˝ uk¨ od´ ese

Vezeték nék¨ uli hálózatok esetében két alapvet˝ o biztons´ agi probléma mer¨ ul fel. Egyrészt a rádiós csatorna jellege miatt a kommunikáci´ o könnyen lehallgathat´ o. M´ asrészt — s ez 3

talán fontosabb — a hálózathoz való csatlakozás nem igényel fizikai hozz´ aférést a hálózati csatlakozóponthoz (Access Point, vagy röviden AP), ezért bárki megpr´ ob´ alhatja a hálózat szolgáltatásait illeg´ alisan igénybe venni. A WEP az els˝ o problémát az u ¨zenetek rejtjelezésvel igyekszik megoldani, a m´ asodik probléma megoldása érdekében pedig megköveteli a csatlakozni k´ıv´ an´ o mobil eszköz (Station, vagy röviden STA) hiteles´ıtését az AP felé. A hiteles´ıtést egy egyszer˝ u kih´ıv´ as-v´ alasz alap´ u protokoll végzi, mely négy u ¨zenet cseréjéb˝ ol áll. Els˝oként a STA jelzi, hogy szeretné hiteles´ıteni magát (authenticate request). V´ alaszul az AP gener´ al egy véletlen számot, s azt kih´ıv´ asként elk¨ uldi a STA-nak (authenticate challenge). A STA rejtjelezi a kih´ıv´ ast, s az eredményt visszak¨ uldi az AP-nak (authenticate response). A STA a rejtjelezést egy olyan titkos kulccsal végzi, melyet csak a STA és az AP ismer. Ezért ha az AP sikeresen dek´ odolja a választ (azaz a dek´ odolás eredményeként visszakapja saját kih´ıv´ as´ at), akkor elhiszi, hogy a választ az adott STA a´ll´ıtotta el˝ o, hiszen csak az ismeri a helyes válasz gener´ alás´ ahoz sz¨ ukséges titkos kulcsot. M´ as szavakkal, a válasz sikeres dek´ odolása esetén az AP hiteles´ıtette a STA-t, és ennek megfelel˝ oen dönthet arr´ ol, hogy a csatlakozást engedélyezi vagy sem. A döntésr˝ol az AP a protokoll negyedik u ¨zenetében tájékoztatja a STA-t (authenticate success vagy failure). Miután a hiteles´ıtés megt¨ ortént, a STA és az AP u ¨zeneteiket rejtjelezve kommunikálnak. A rejtjelezéshez ugyanazt a titkos kulcsot használják, mint a hiteles´ıtéshez. A WEP rejtjelez˝ o algoritmusa az RC4 kulcsfolyam kódoló. A kulcsfolyam kódolók u ´gy m˝ uködnek, hogy egy kis méret˝ u, néh´ any bájtos titkos kulcsból egy hossz´ u álvéletlen bájtsorozatot áll´ıtanak el˝o, és ezen sorozat bájtjait XOR-olj´ ak az u ¨zenet bájtjaihoz. Ez történik a WEP esetében is. Az M u ¨zenet k¨ uld˝ oje (a STA vagy az AP) a titkos kulccsal inizializálja az RC4 kódolót, majd az RC4 által el˝ oa´ll´ıtott K ´ alvéletlen bájtsorozatot XOR-olja az u ¨zenethez. Az M ⊗K rejtjelezett u ¨zenet vev˝ oje ugyanazt teszi mint a k¨ uld˝ o: a titkos kulccsal inicializálja az RC4 algoritmust, amely ´ıgy ugyanazt a K ´ alvéletlen bájtsorozatot áll´ıtja el˝ o, amit a rejtjelezéshez használt a k¨ uld˝ o. Ezt a rejtjelezett u ¨zenethez XOR-olva — az XOR m˝ uvelet tulajdonságai miatt - a vev˝ o az eredeti u ¨zenetet kapja vissza: (M ⊗ K) ⊗ K = M . A fent le´ırtak majdnem megfelelnek a valós´ agnak, van azonban még valami amit a WEP rejtejelezés kapcsán meg kell eml´ıteni. Könnyen l´ athat´ o, hogy ha a rejtjelezés a fent le´ırtak szerint m˝ uködne, akkor minden u ¨zenethez ugyanazt a K álvéletlen bájtsorozatot XORolnánk, hiszen a kódolót minden u ¨zenet elk¨ uldése el˝ ott ugyanazzal a titkos kulccsal inicializáljuk. Ez több szempontból is hiba lenne. Tegy¨ uk fel például, hogy egy támadó lehallgat két rejtjelezett u ¨zenetet, M1 ⊗ K-t és M2 ⊗ K-t. A két rejtjelezett u ¨zenetet XOR-olva, a támadó a két ny´ılt u ¨zenet XOR ¨ osszegét kapja: (M1 ⊗ K) ⊗ (M2 ⊗ K) = M1 ⊗ M2 . Ez olyan, mintha az egyik u ¨zenetet a m´ asik u ¨zenettel, mint kulcsfolyammal rejtjelezt¨ uk volna. ´ Am ebben az esetben M1 és M2 nem álvéletlen bájtsorozatok. Valójában teh´ at M1 ⊗ M2 egy nagyon gyenge rejtjelezés, és a támadó az u ¨zenetek statisztikai tulajdonságait felhasználva könnyen meg tudja fejteni mindkét u ¨zenetet. További példaként tegy¨ uk fel, hogy a támadó lehallgat egy rejtjelezett u ¨zenetet, M ⊗ K-t, ahol M -et teljes egészében, vagy részben ismeri. Ez nem irre´ alis feltételezés, hiszen az M u ¨zenet tartalmazza a fels˝obb szint˝ u protokollok fejléceit, melyeknek mez˝oi többnyire ismertek lehetnek a támadó számára. Az egyszer˝ uség kedvéért most tegy¨ uk fel, hogy a támadó a teljes M u ¨zenetet ismeri. Ekkor a megfigyelt M ⊗ K és az ismert M u ¨zenet XOR összege pont K-t adja: (M ⊗ K) ⊗ M = K. Ennek ismeretében azonban a támadó a további rejtjelezett u ¨zeneteket egyszer˝ uen dek´ odolni tudja. Ha nem a teljes M u ¨zenetet ismeri a támadó, akkor csak K egy részéhez jut hozz´ a, ´ am a további rejtjelezett u ¨zeneteket ekkor is részben dek´ odolni tudja. A fenti problémák elker¨ ulése érdekében, a WEP nem egyszer˝ uen a titkos kulcsot használja a rejtjelezéshez, hanem azt kiegész´ıti egy IV-nek (Initialization Vector) nevezett értékkel, mely u ¨zenetenként változik. A rejtjelezés folyamata teh´ at a következ˝ o: az IV-t és a titkos kulcsot ¨ osszef˝ uzz¨ uk, a kapott értékkel inicializáljuk az RC4 kódolót, mely el˝oa´ll´ıtja az álvéletlen bájtsorozatot, amit az u ¨zenethez XOR-olunk. A dek´ odolás folyamata ezzel analóg.

4

üzenet (+ ICV)

IV

xxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxx

titkos kulcs

RC4 kódolás IV üzenet (+ ICV) dekódolás

IV

xxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxx

titkos kulcs

RC4 üzenet (+ ICV)

1. ´ abra. A WEP rejtjelezés folyamata Ebb˝ol következik, hogy a vev˝ onek sz¨ uksége van a kódolásn´ al használt IV-re. Ez a rejtjelezett u ¨zenethez f˝ uzve, ny´ıltan ker¨ ul ´ atvitelre. Ez elvileg nem jelent problémát, mert az u ¨zenet dek´ odolás´ ahoz csupán az IV ismerete nem elegend˝ o, ahhoz a titkos kulcsot is ismerni kell. A méreteket illet˝oen megeml´ıtj¨ uk - s ennek kés˝obb még lesz jelent˝osége - hogy az IV 24 bites, a titkos kulcs pedig (által´ aban) 104 bites1 . A WEP rejtjelezés teljes folyamatát az 1. ábra szemlélteti. Az 1. ´ abra azt is mutatja, hogy a rejtjelezés el˝ ott, a k¨ uld˝ o egy integritás-véd˝ o ellen˝orz˝o összeggel (Integrity Check Value, vagy röviden ICV) egész´ıti ki a ny´ılt u ¨zenetet, melynek célja a szándékos m´ odos´ıt´ asok detekt´ alás´ anak lehet˝ ové tétele a vev˝ o számára. A WEP esetében az ICV nem m´ as mint a ny´ılt u ¨zenetre számolt CRC érték. Mivel azonban a CRC önmagában nem véd a szándékos m´ odos´ıt´ asok ellen (hiszen egy támadó a m´ odos´ıtott u ¨zenethez u ´j CRC értéket tud számolni), ezért a WEP a CRC értéket is rejtjelezi. A m¨ og¨ ottes gondolat az, hogy ´ıgy a támadó nem tudja manipul´ alni az u ¨zeneteket, hiszen a titkos kulcs hi´ anyában nem tudja a m´ odos´ıtott u ¨zenethez tartozó rejtjelezett CRC értéket el˝oa´ll´ıtani. Mint azt alább l´ atni fogjuk, ez a gondolatmenet nem teljesen hibamentes. Végezet¨ ul a WEP kulcsokról szólunk röviden. A szabvány lehet˝ ové teszi, hogy minden STA-nak saját titkos kulcsa legyen, amit csak az AP-vel oszt meg. Ez azonban megnehez´ıti a kulcsmenedzsmentet az AP oldal´ an, mivel ekkor az AP-nek minden STA kulcsát ismernie és gondoznia kell. Ezért a legt¨ obb implementáci´ o nem támogatja ezt a lehet˝ oséget. A szabvány el˝ o´ır egy u ń. default kulcsot is, amit az AP és a hálózathoz tartozó minden STA ismer. Eredetileg ezt a kulcsot azon u ¨zenetek védelmére szánták, melyeket az AP többessz´ or´ assal (broadcast) minden STA-nak el szeretne k¨ uldeni. A legt¨ obb WEP implementáci´ o azonban csak ezt a megoldást támogatja. Így a gyakorlatban, egy adott hálózathoz tartozó eszközök egyetlen közös kulcsot használnak titkos kulcsként. Ezt a kulcsot manuálisan kell telep´ıteni a mobil eszközökben és az AP-ben. Nyilvánvaló, hogy ez a megoldás csak egy k¨ uls˝o támadó ellen biztos´ıtja a kommunikáci´ o biztons´ ag´ at; az eszközök dek´ odolni tudj´ ak egymás u ¨zeneteit. 1

K¨ ul¨ onb¨ oz˝ o marketing anyagokban ezt gyakran u ´ gy interpret´ alj´ ak, hogy a WEP 128 bites biztons´ agot” ” ny´ ujt. Ez természetesen félrevezet˝ o (mint a marketing anyagok ´ altal´ aban), hiszen a 128 bitb˝ ol 24 ny´ıltan ker¨ ul atvitelre ´

5

2.4.2.

A WEP hib´ ai

A WEP tulajdonképpen a rossz protokolltervezés mintapéldája. Az alábbi tömör összefoglal´ ob´ ol l´ athat´ o, hogy lényegében egyetlen kit˝ uz¨ ott biztons´ agi célt sem valós´ıt meg tökéletesen: Hiteles´ıt´ es. A WEP hiteles´ıtési eljár´ as´ anak több problémája is van. Els˝oként mindjárt az, hogy a hiteles´ıtés egyirány´ u, azaz a STA hiteles´ıti magát az AP felé, ám az AP nem hiteles´ıti magát a STA felé. M´ asodszor, a hiteles´ıtés és a rejtjelezés ugyanazzal a titkos kulccsal történik. Ez azért nem k´ıv´ anatos, mert ´ıgy a támadó mind a hiteles´ıtési, mind pedig a rejtjelezési eljár´ as potenciális gyengeségeit kihasználhatja egy, a titkos kulcs megfejtésére ir´ anyuló támadásban. Biztonságosabb lenne, ha minden funkci´ ohoz k¨ ul¨ on kulcs tartozna. A harmadik probléma az, hogy a protokoll csak a hálózathoz történ˝ o csatlakozás pillanatában hiteles´ıti a STA-t. Miután a hiteles´ıtés megt¨ ortént és a STA csatlakozott a ´ hálózathoz, bárki k¨ uldhet a STA nevében u ¨zeneteket annak MAC c´ımét használva. Ugy t˝ unhet, hogy ez annyira nem nagy gond, hiszen a támadó, a titkos kulcs ismeretének hi´ anyában, ´ u ´gysem tud helyes rejtjelezett u ¨zenetet fabrik´ alni, amit az AP elfogad. Am ahogy azt kor´ abban eml´ıtett¨ uk, a gyakorlatban az összes STA egy közös titkos kulcsot használ, s ´ıgy a támadó megteheti azt, hogy egy STA1 által k¨ uld¨ ott - és a támadó által lehallgatott rejtejelezett u ¨zenetet STA2 nevében megismétel az AP felé; ezt az AP el fogja fogadni. A negyedik probléma egy gyöngyszem a protokolltervezési hib´ ak között. Emlékeztet¨ unk arra, hogy a WEP rejtjelezési algoritmusa az RC4 folyamk´ odoló. Nemcsak az u ¨zeneteket kódolják az RC4 seg´ıtségével, hanem a STA ezt használja a hiteles´ıtés sor´ an is az AP által k¨ uld¨ ott kih´ıv´ as rejtjelezésére. Így a támadó a hiteles´ıtés sor´ an k¨ uld¨ ott u ¨zenetek lehallgat´ as´ aval könnyen hozz´ ajut a C kih´ıv´ ashoz és az arra adott R = C ⊗ K válaszhoz, melyb˝ol C ⊗ R = K alapján azonnal megkapja az RC4 algoritmus által gener´ alt K álvéletlen bájtsorozatot. A játéknak ezzel vége, hiszen K seg´ıtségével a támadó bármikor, bármilyen kih´ıv´ asra helyes választ tud gener´ alni a STA nevében (s ezen az IV használata sem seg´ıt, mert az IV-t a rejtjelezett u ¨zenet k¨ uld˝ oje, jelen esetben a támadó választja). S˝ot, mivel a gyakorlatban minden, az adott hálózathoz tartozó eszköz ugyanazt a titkos kulcsot használja, a támadó ezek után bármelyik eszköz nevében csatlakozni tud a hálózathoz. Persze a csatlakozás önmag´ aban még nem elegend˝ o, a támadó haszn´ alni is szeretné a hálózatot. Ehhez olyan u ¨zeneteket kell fabrik´ alnia, amit az AP elfogad. A rejtjelezés követelménye miatt ez nem trivi´ alis feladat (hiszen magához a titkos kulcshoz még nem jutott hozz´ a a támadó), de a WEP hib´ ainak tárh´ aza b˝oven tartogat még lehet˝ oségeket. Integrit´ as-v´ edelem. A WEP-ben az u ¨zenetek integritás´ anak védelmét az u ¨zenetekhez csatolt ellen˝orz˝o ¨ osszeg (ICV) hivatott biztos´ıtani. Az ICV nem m´ as, mint az u ¨zenetre számolt CRC érték, mely az u ¨zenettel egy¨ utt rejtjelezésre ker¨ ul. Formális jelöléseket használva, a rejtjelezett u ¨zenet a következ˝ o m´ odon ´ırhat´ o fel: (M ||CRC(M )) ⊗ K, ahol M a ny´ılt u ¨zenet, K az RC4 ´ altal az IV-b˝ol és a titkos kulcsból el˝ oa´ll´ıtott álvéletlen bájtsorozat, CRC(.) jelöli a CRC f¨ uggvényt, és || jelöli az ¨ osszef˝ uzés m˝ uveletét. Ismeretes, hogy a CRC line´ aris m˝ uvelet az XOR-ra nézve, azaz CRC(X ⊗ Y ) = CRC(X) ⊗ CRC(Y ). Ezt kihasználva, a támadó a rejtjelezett WEP u ¨zenetek bármely bitjét m´ odos´ıtani tudja (át tudja billenteni), bár magát az u ¨zenetet nem l´ atja. Jelölj¨ uk a támadó szándékolt m´ odos´ıt´ asait ∆M -mel. Ekkor a támadó az ((M ⊗ ∆M )||CRC(M ⊗ ∆M )) ⊗ K rejtjelezett u ¨zenetet szeretné el˝oa´ll´ıtani az eredetileg megfigyelt (M ||CRC(M )) ⊗ K rejtjelezett u ¨zenetb˝ ol. Ehhez egyszer˝ uen CRC(∆M )-et kell kiszámolnia, majd a M ||CRC(∆M ) értéket kell az eredeti rejtjelezett u ¨zenethez XOR-olnia. A következ˝ o egyszer˝ u levezetés mutatja, hogy ez miért vezet célra:

6

((M ||CRC(M )) ⊗ K) ⊗ (∆M ||CRC(∆M )) = ((M ⊗ ∆M )||(CRC(M ) ⊗ CRC(∆M ))) ⊗ K = ((M ⊗ ∆M )||CRC(M ⊗ ∆M )) ⊗ K ahol az utolsó lépésben kihasználtuk a CRC linearitás´ at. Mivel CRC(∆M ) kiszámol´ as´ ahoz nincs sz¨ ukség a titkos kulcsra, ezért l´ athat´ oan a támadó könnyen tudja manipul´ alni a WEP u ¨zeneteket, az integritás-védelem és a rejtjelezés ellenére. Az u ¨zenetfolyam integritás´ anak védelme kapcsán szokás eml´ıteni az u ¨zenetvisszajátszás detekt´ alás´ at, mint biztons´ agi követelményt. A WEP esetében ennek vizsgálatával egyszer˝ u dolgunk van, mert a WEP-ben egy´ altal´ an nincs semmilyen mechanizmus mely az u ¨zenetek visszajátszás´ anak detekt´ alás´ at lehet˝ ové tenné. A tervez˝ ok nemes egyszer˝ uséggel err˝ol a biztons´ agi követelményr˝ol megfeledkeztek. A támadó teh´ at bármely eszköz kor´ abban rögz´ıtett u ¨zenetét vissza tudja játszani egy kés˝obbi id˝ opontban, s ezt a WEP nem detekt´ alja. Nyilvánvaló, hogy ez miért gond, ha arra gondolunk, hogy a rögz´ıtett u ¨zenet akár egy bejelentkezési folyamatból is származhat, s például egy felhasználói név/jelszó párt tartalmazhat. Titkos´ıt´ as. Mint azt kor´ abban eml´ıtett¨ uk, folyamk´ odolók használata esetén fontos, hogy minden u ¨zenet m´ as kulccsal legyen rejtjelezve. Ezt a WEP-ben az IV használata biztos´ıtja; sajnos nem teljesen megfelel˝ o m´ odon. A probléma abb´ ol ad´ odik, hogy az IV csak 24 bites, ami azt jelenti, hogy kb. 17 milli´ o lehetséges IV van. Egy WiFi eszköz kb. 500 teljes hossz´ uság´ u keretet tud forgalmazni egy m´ asodperc alatt, ´ıgy a teljes IV teret kb. 7 óra leforg´ asa alatt kimer´ıti. Azaz 7 ´ or´ anként ismétl˝odnek az IV értékek, s ezzel az RC4 által el˝oa´ll´ıtott álvéletlen bájtsorozatok is. A problémát s´ ulyosb´ıtja, hogy a gyakorlatban minden eszköz ugyanazt a titkos kulcsot használja, potenciálisan k¨ ul¨ onböz˝o IV értékekkel, ´ıgy ha egyszerre n eszköz használja a hálózatot, akkor az IV u ¨tk¨ ozés várhat´ o ideje a 7 óra n-ed részére csökken. Egy m´ asik s´ ulyosb´ıt´ o tényez˝ o, hogy sok WEP implementáci´ o az IV-t nem véletlen értékr˝ ol ind´ıtja, hanem nullár´ ol. Ezért beind´ıt´ as után a k¨ ul¨ onböz˝ o eszközök ugyanazt a nullát´ ol induló és egyesével növekv˝o IV sorozatot használják, legt¨ obbször ugyanazzal a közös titkos kulccsal. Azaz, a támadónak várakoznia sem kell, azonnal IV u ¨tk¨ ozésekhez jut. A WEP teljes ¨ osszeomlás´ at az RC4 kódoló nem megfelel˝ o használata okozza. Ismeretes, hogy léteznek u ń. gyenge RC4 kulcsok, melyekre az a jellemz˝o, hogy bel˝ol¨ uk az RC4 algoritmus nem teljesen véletlen bájtsorozatot áll´ıt el˝ o [6]. Ha valaki meg tudja figyelni egy gyenge kulcsból el˝ oa´ll´ıtott bájtsorozat els˝ o néh´ any bájtját, akkor abb´ ol következtetni tud a kulcsra. Ezért a szakemberek azt javasolják, hogy az RC4 a´ltal el˝oa´ll´ıtott bájtsorozat els˝ o 256 bájtját mindig dobjuk el, s csak az utána gener´ alt b´ ajtokat használjuk a rejtjelezéshez. Ezzel a gyenge kulcsok problémáj´ at meg lehetne oldani. Sajnos a WEP nem ´ıgy m˝ uködik. Ráad´ asul a változ´ o IV érték miatt el˝ obb-utóbb biztosan gyenge kulcsot kap a kódoló, s az IV ny´ılt átvitele miatt, err˝ol a támadó is tudom´ ast szerezhet. Ezt kihasználva, néh´ any kriptogr´ afus olyan támadó algoritmust konstru´ alt a WEP ellen, melynek seg´ıtségével a teljes 104 bites titkos kulcs néh´ any milli´ ou ¨zenet lehallgat´ asa után nagy valósz´ın˝ uséggel megfejthet˝ o. A WEP minden kor´ abban le´ırt hib´ aja eltörp¨ ul ezen eredmény mellett, ugyanis ezzel a támadással magához a titkos kulcshoz jut hozz´ a a támadó. Ráad´ asul a támadás könnyen automatizálható, és néh´ any seg´ıt˝ okész” embernek köszönhet˝ oen, az Internetr˝ol letöltött támadó ” programok használatával amat˝or¨ ok által is rutinszer˝ uen végrehajtható. 2.4.3.

Egy komplett t´ amad´ as WEP ellen

Miután a hallgat´ o megismerkedett a WEP m˝ uködésével, és ismeri a f˝obb hib´ ait, itt az ideje egy komplex, gyors és sikeres támadás bemutatás´ anak. Ahogy l´ athat´ o, az eddig bemutatott gyengeségek amellett, hogy kiaknázás´ aval csak részsikereket ér¨ unk el, sokszor olyan 7

feltételezésen alapulnak (pl. ismert ny´ılt szöveg részlet, néh´ any milli´ o elfogott csomag), amelyek jelenlétének felismerése nem könny˝ u feladat, és a WEP-t˝ol teljesen f¨ uggetlen. A hamarosan bemutatásra ker¨ ul˝ o támadás bemutatása sor´ an egy nem mellékes cél, hogy a hallgat´ oval érzékeltess¨ uk, hogy a gyengeségek, melyekre önmagukban vizsgálva talán sokan könnyen legyintenek is, miként ´ allnak össze egy sikeres és nem mellesleg gyors támadáss´ a. A támadás kivitelezéséhez, melyben nem kisebb célt k´ıv´ anunk elérni, mint a WEP-es jelszó visszafejtése, a szerz˝ok vezetékneveinek kezd˝ obet˝ uir˝ ol elnevezett FMS m´ odszert [6] használjuk. Az FMS m´ odszer az RC4 használatáb´ ol ad´ od´ o gyengeségek kihasználása mellett statisztikai eszközöket is bevet. A statisztikai m´ odszereket csak nagy szám´ u mintán lehet alkalmazni, éppen ezért sok k¨ ul¨ onböz˝o IV-hez tartozó rejtjelezett u ¨zenetet kell elfogni. Mindez nagyon hosszadalmas lehet, ha nincs nagy forgalom a hálózaton. Szerencsére” a ” WEP többi gyengesége lehet˝ oséget ad a mesterséges forgalomgenerálásra. Az egyik u ´t a sikeres támadáshoz a következ˝ o lépéseken át vezet. 1) El˝ oször is egy bármilyen IV-hez tartozó 1500 bájtos kulcsfolyamot kell szerezni, hogy általunk gener´ alt u ¨zenetet tudjunk visszainjektálni a hálózatba. 1500 bájt azért elegend˝ o, mert az Interneten a IP csomagokat által´ aban 1500 bájtos darabokban száll´ıtanak tovább (MTU), és ett˝ ol nemigen szoktak eltérni kisebb hálózatok esetén sem. 2) Ezek után egy olyan u ¨zenetet kell gener´ alni, amire tudjuk, hogy mit válaszol az AP, és mivel azt egy m´ asik IV-vel k¨ uldi, ezért megismer¨ unk egy m´ asik IV-hez tartozó kulcsfolyamot. Ennek köszönhet˝ oen u ´jabb u ¨zeneteket tudunk gener´ alni, mik¨ ozben u ´jabb IV-khez tartozó u ¨zeneteket kapunk. A következ˝ okben részletesebben ´ attekintj¨ uk, hogy miként kivitelezhet˝ oek ezek a részt´ amadások. A megértést seg´ıti a 2. ´ abra. További részletekhez a The Final Nail in WEP’s Coffin’ c´ım˝ u cikket [7] ajánlom. Els˝o lépésként egy adott IV-hez tartozó kulcsfolyam els˝ o 8 bájtját kell megszerezni. Ez azért könny˝ u feladat, mert szinte minden 802.11 adatcsomag rejtjelezett részének els˝ o 8 bájtja egy u ´gynevezett LLC/SNAP fejléc. Ennek a fejlécnek köszönhet˝ oen lehet ARP és IP csomagokat k¨ uldeni a WLAN hálózaton kereszt¨ ul. Az els˝ o 7 bájt adott, a 8. pedig kétféle értéket vehet fel: ARP esetén 0x06, IP esetén 0x00. A valós´ agban a csomag méretéb˝ ol következtetni lehet, hogy ARP vagy IP csomaggal van dolgunk, mert az ARP u ¨zenetek mindig fixen 36 bájt hossz´ uak, az IP csomagok pedig ett˝ ol valósz´ın˝ uleg eltér˝oek. Teh´ at az els˝ o 8 bájtot rejtelezett u ¨zenetb˝ ol az ismertnek tekinthet˝ o LLC/SNAP fejléccel egyszer˝ uen XOR-olva megkapjuk a kulcsfolyamk´ odoló els˝ o 8 bájtját. Ez önmagában még nyilv´ anvalóan nem elegend˝ ou ¨zenet k¨ uldésre. Csakhogy a WEP megengedi, hogy adatkapcsolat rétegbeli u ¨zeneteket daraboljunk, u ´gy hogy közben ugyanazt az IV-t használjuk. Erre azonban van egy korlát, legfeljebb 16 azonos IV-j˝ u u ¨zenetet fogad el az AP. Így összesen 4 × 16 = 64 bájtos u ¨zenetet tudunk k¨ uldeni, mivel minden egyes u ¨zenetdarab 8 bájtjáb´ ol az utolsó 4 bájtot elfoglalja a CRC kód. A következ˝ o lépéshez ismerni kell a broadcast u ¨zenetek k¨ uldési mechanizmusát. Amennyiben egy STA0 akar u ¨zenetet k¨ uldeni az AP-hoz kapcsol´ od´ o minden m´ asik STAi -nak, azt csak az AP-n kereszt¨ ul tudja megtenni. Ennek oka, hogy létezhet egy m´ asik olyan STAi , aki STA0 hatósugarán k´ıv¨ ul tartózkodik, de az AP-t mindenketten elérik. Teh´ at az STA0 -tól érkez˝ o broadcast u ¨zenetet csak az AP dolgozza föl, aki viszont u ´jra k¨ uldi azt. Az AP az u ¨zenet k¨ uldésekor az STA0 -t jelöli meg forr´ asként. Ezt azért fontos kiemelni, mert lehallgat´ askor nem lehet megk¨ ul¨ onböztetni az STA0 és az AP által k¨ uld¨ ott csomagokat. A támadás a következ˝ o m´ odon folytathat´ o. A támadó a darabokban elk¨ uld¨ ott 64 bájtban egy broadcast u ¨zenetet k¨ uld (abcdefgh a 2. ábr´ an), amit az AP el˝oször összerak, majd u ´j IV-vel ellátva u ´jrak¨ uldi. A támadó pontosan tudja, hogy mi a k¨ uld¨ ott u ¨zenet teljes tartalma, hiszen ˝o áll´ıtotta ¨ ossze, viszont az AP nem darabolva k¨ uldi, hanem egyben, amihez a 4 bájtos CRC-t hozz´ ateszi, amit viszont most m´ ar a támadó is ki tud számolni. Teh´ at a támadó ´ıgy m´ ar 68 bájtnyi egy m´ asik IV-hez tartozó kulcsfolyamot ismer. A darabolást kihasználó támadás imm´ ar nagyobb u ¨zenetdarabokkal megismételhet˝o (pl.

8

STA

AP

IV0 IV0 a xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

IV0 b xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

...

IV0 h xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

IV1 IV1

abcdefgh

xxxx xxxx xxxxxx xxxx xxxx

abcdefgh abcdefgh

= IV1 IV1

A

IV1

B

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

...

IV1

H

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

IV2 IV2

ABCDEFGH

xxxx xxxx xxxxxx xxxx xxxx

ABCDEFGH

ABCDEFGH

= IV2

IV2

alpha

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

...

xxxx xxxxxx xxxx xxxx xxxx

- Broadcast

2. ´ abra. Egy IV és a hozz´ a tartozó kulcs megszerzésének lépései

9

ABCDEFGH a 2. ´ abr´ an). 16 darab 64 bájtos (CRC elfoglal minden darabban 4 bájtot) u ¨zenet elk¨ uldése után az AP egy 1028 bájtos (64 × 16 + 4) csomagot broadcastol. További két u ¨zenet k¨ uldésével egy komplett 1500 bájtos adott IV-hez tartozó kulcsfolyam áll rendelkezésre. Ezek után könny˝ u további IV-khez tartozó kulcsfolyamokat szerezni, mivel m´ ar tudunk komplett broadcast csomagokat rejtjelezetten k¨ uldeni az AP számára. Fontos megjegyezni, hogy a támadás akkor lehet sikeres, ha az AP u ´j IV-t haszn´ al, amikor u ´jrak¨ uldi a csomagokat. Ez az esetek igen jelent˝os többségében azonban fenn´ all. Miután számos csomagot elfogtunk k¨ ul¨ onböz˝o IV-kkel, az FMS m´ odszerrel a kulcs visszafejthet˝ o. Ahogy kor´ abban m´ ar eml´ıtett¨ uk, az FMS m´ odszer nem determinisztikus m´ odon fejti vissza a kulcsot, mivel sok esetben egy lefutás sor´ an téved, és hib´ as eredményt ad. A támadás megalkot´ oi ezt u ´gy kezelték, hogy sok mintára futtatj´ ak le a visszafejt˝ o algoritmust, és a szerz˝ok bebizony´ıtott´ ak, hogy a jó kulcsot nagyobb valósz´ın˝ uséggel adja vissza az általuk javasolt algoritmus, mint bármely m´ as kulcsot. Az FMS támadásban a kulcsot bájtonként vizsgálják, és minden bájtra több részkulcsjelöltet tartanak fenn, amikhez szavazatokat rendeltek. Egy kulcsjelölt minden egyes bájtja akkor kap egy szavazatot helyiértéknek megfelel˝ oen, ha a visszafejt˝ o algoritmus egy rejtjelezett szövegre azt hozza ki, hogy az a kulcsjelölt lehetett a kulcs. Ezek után az FMS ellen˝orzi a kulcsjelölteket, azaz végignézi, hogy egy adott kulcsjelölttel val´ oban dek´ odolni lehet-e az u ¨zeneteket u ´gy, hogy a CRC kód megfelel˝ o legyen. Az FMS azokat a kulcsjelölteket vizsgálja, amelyek egy bizonyos hányad´ at érték el a legt¨ obbet elér˝ o kulcsjelölt szavazatainak. Ezért minél pontosabb az els˝ odleges kulcsjelölt ann´ al kevesebb kulcsjelöltet kell megvizsg´ alni, és ann´ al gyorsabb az algoritmus. Teh´ at minél több IV-j˝ u csomagot siker¨ ul elfogni, ann´ al gyorsabb a feltör˝ o algoritmus lefutása. Ahhoz, hogy az FMS néh´ any percen bel¨ ul visszafejtsen egy 40 bites WEP kulcsot, 500.000nél több k¨ ul¨ onböz˝o IV-j˝ u csomagot kell összegy˝ ujteni. Azonban az FMS többszöri optimalizálásval, jelenleg 20.000 csomag is elegend˝ onek bizonyul.

2.5. 2.5.1.

WPA Ismertet˝ o

A WEP hib´ ait felismerve, az IEEE u ´j biztons´ agi megoldást dolgozott ki, melyet a 802.11i specifik´ aci´ o tartalmaz [5]. A WEP-t˝ol való megk¨ ul¨ onböztetés érdekében, az u ´j koncepci´ ot RSN-nek (Robust Security Network) nevezték el. Az RSN-t k¨ or¨ ultekint˝obben tervezték meg, ´ m´ mint a WEP-et. Uj odszer ker¨ ult bevezetésre a hiteles´ıtés és a hozz´ aférés-védelem biztos´ıt´ as´ ara, mely a 802.1X szabvány által definiált modellre ép¨ ul, az integritás-védelmet és a titkos´ıt´ ast pedig az AES (Advanced Encryption Standard) algoritmusra támaszkodva oldották meg. Sajnos azonban az u ´j RSN koncepci´ ora nem lehet egyik napr´ ol a m´ asikra áttérni. Ennek az az oka, hogy a használatban lev˝o WiFi eszközök az RC4 algoritmust támogat´ o hardver elemekkel vannak felszerelve, és nem támogatják az RSN a´ltal el˝ o´ırt AES algoritmust. Ezen puszt´ an szoftver upgrade-del nem lehet seg´ıteni, u ´j hardverre van sz¨ ukség, s ez kezdetben lass´ıtotta az RSN elterjedésének folyamatát. Ezt a problémát az IEEE is felismerte, és egy olyan opcion´ alis protokollt is hozz´ aadott a 802.11i specifik´ aci´ ohoz, mely továbbra is az RC4 algrotimust használja, és ´ıgy — szoftver upgrade után — futtathat´ o a régi hardveren, de er˝osebb mint a WEP. Ezt a protokollt TKIP-nek (Temporal Key Integrity Protocol) nevezik. A WiFi eszközöket gyárt´ o cégek azonnal adapt´ alták a TKIP protokollt, hiszen annak seg´ıtségével a régi eszközökb˝ol ´ all´ o WEP-es hálózatokat egy csapásra biztons´ agossá lehetett var´ azsolni. Meg sem várt´ ak am´ıg a 802.11i specifik´ aci´ o a lass´ u szabványos´ıt´ asi folyamat sor´ an végleges ´ allapotba ker¨ ul, azonnal kiadt´ ak a WPA (WiFi Protected Access) specifik´ aci´ ot [8], ami a TKIP-re ép¨ ul. A WPA teh´ at egy gyárt´ ok által támogatott specifik´ aci´ o, mely az

10

adat-rejtjelezõ kulcs adat-integritásvédõ kulcs kulcs-rejtjelezõ kulcs kulcs-integritásvédõ kulcs

Kulcsgenerálás

PTK

PMK MACSTA MACAP RandomSTA RandomAP

3. ábra. PTK gener´ alása a PMK-b´ ol, a felek MAC c´ıméb˝ ol, és a véletlensz´ amokb´ ol RSN egy azonnal használható részhalmaz´ at tartalmazza. M´ ara m´ ar elterjedtté vált a WPA2 kifejezés is, mely hivatalosan a komplett IEEE 802.11i-t magában foglalja, de hétköznapi használatban utalhat csupán a CCMP-re is, TKIP nélk¨ ul. A továbbiakban ´ attekintj¨ uk a 802.11i-ben definiált helyi hozz´ aférés-védelmi, és kulcsmenedzsment m´ odszereket, melyek teh´ at megegyeznek az RSN-ben és a WPA-ban. A TKIP és AES-CCMP protokollok m˝ uködésének áttekintését˝ ol most el tekint¨ unk, mivel a mérés sor´ an nem játszik fontos szerepet. Az érdekl˝ od˝ o hallgat´ oknak ajánljuk ennek a le´ır´ asnak egy b˝ov´ıtett kiad´ as´ at [9]. 2.5.2.

Helyi hozz´ af´ er´ es-v´ edelem ´ es kulcsmenedzsment

A helyi hozz´ aférés-védelemet egy u ´gynevezett páronkénti mesterkulcs (pairwise master key, vagy röviden PMK) biztos´ıtja. Az elnevezés jelen esetben némiképp félrevezet˝o, mivel a páronkénti” kifejezés arra utalna, hogy csak az adott STA és az AP ismeri. Ez csak abban ” az esetben igaz, amikor a hiteles´ıtés egy központi szerveren kereszt¨ ul történik, és a PMK valóban egyedi. Azonban, mikor a WEP-es jelszóhoz hasonlóan egyetlen jelszóval biztos´ıtj´ ak a hozz´ aférés védelmét, a PMK egyszer˝ uen a megosztott jelszó lesz. Viszont minden esetben igaz, hogy a PMK mester” kulcs, mert ezt a kulcsot nem használják közvetlen¨ ul rejtje” lezésre, hanem további kulcsokat gener´ alnak bel˝ ole. Egészen pontosan a PMK-b´ ol mind a mobil eszköz, mind pedig az AP négy további kulcsot gener´ al: egy adat-rejtjelez˝o kulcsot, egy adat-integritás-véd˝ o kulcsot, egy kulcs-rejtjelez˝o kulcsot, és egy kulcs-integritás-véd˝ o kulcsot. Ezeket egy¨ uttesen páronkénti ideiglenes kulcsnak (Pairwise Transient Key, vagy röviden PTK) nevezik. Megjegyezz¨ uk, hogy az AES-CCMP protokoll az adatok rejtjelezéséhez és az adatok integritás-védelméhez ugyanazt a kulcsot használja, ezért AES-CCMP használata esetén csak három kulcs gener´ alódik a PMK-b´ ol. A PTK el˝ oa´ll´ıt´ as´ ahoz a PMK-n k´ıv¨ ul felhasználják még a két fél (mobil eszköz és AP) MAC c´ımét, és két véletlensz´ amot, melyet a felek gener´ alnak. Ezt a 3. ´ abra szemlélteti. A véletlensz´ amokat az u ń. négyutas kézfog´ as (four way handshake) protokollt használva juttatj´ ak el egymáshoz a felek. Ennek a protokollnak további fontos feladata az, hogy seg´ıtségével a felek közvetlen¨ ul meggy˝ oz˝odjenek arr´ ol, hogy a m´ asik fél ismeri a PMK-t. A négyutas kézfog´ as protokoll u ¨zeneteit az EAPOL protokoll Key t´ıpus´ u u ¨zeneteiben juttatják el egymáshoz a felek. Az u ¨zenetek tartalma és a protokoll m˝ uködése vázlatosan a 4. ábra alapján a következ˝ o: • Els˝o lépésként az AP elk¨ uldi az általa gener´ alt véletlensz´ amot (AN once) a mobil eszköznek. Mikor a mobil eszköz ezt megkapja, rendelkezésére áll minden informáci´ oa PTK el˝ oa´ll´ıt´ as´ ahoz. A mobil eszköz teh´ at kiszámolja az ideiglenes kulcsokat. • A mobil eszköz is elk¨ uldi az ´ altala gener´ alt véletlensz´ amot (SN once) az AP-nek. Ez az u ¨zenet kriptogr´ afiai integritás-ellen˝orz˝o összeggel (Message Integrity Code, vagy röviden MIC) van ellátva, amit a mobil eszköz a frissen kiszámolt kulcs-integritás-véd˝ o kulcs (KCK) seg´ıtségével ´ all´ıt el˝ o, ami a PTK része. Az u ¨zenet vétele után az AP-nek is rendelkezésére ´ all minden informáci´ o a PTK kiszám´ıt´ as´ ahoz. Kiszámolja az ideiglenes kulcsokat, majd a KCK seg´ıtségével ellen˝orzi a MIC-et. Ha az ellen˝orzés sikeres, akkor elhiszi, hogy a mobil eszköz ismeri a PMK-t. 11

STA

AP ANonce generálása ANonce

SNonce generálása PTK kiszámítása (KCK) SNonce, MICKCK PTK kiszámítása (KCK) ANonce, MIC'KCK MIC"KCK

4. ´ abra. Négy-utas kézfog´ as lépései • Az AP is k¨ uld egy MIC-et (M IC ′ ) tartalmazó u ¨zenetet a mobil eszköznek, melyben tájékoztatja a mobil eszközt arr´ ol, hogy a kulcsokat sikeresen telep´ıtette, és készen ´ all a további adatforgalom rejtjelezésre. Az u ¨zenet vétele után a mobil eszköz a KCK kulccsal ellen˝ orzi a M IC ′ -et, és ha az ellen˝orzés sikeres, akkor elhiszi, hogy az AP ismeri a PMK-t. • Veg¨ ul a mobil eszköz nyugtázza az AP el˝ oz˝o u ¨zenetét, mely egyben azt is jelenti, hogy a mobil eszköz is készen ´ all a további adatforgalom rejtjelezésére. A továbbiakban a mobil eszköz és az AP az adat-integritás-véd˝ o és az adat-rejtjelez˝o kulccsal védik egymásnak k¨ uld¨ ott u ¨zeneteiket. Sz¨ ukség van azonban még olyan kulcsokra is, melyek seg´ıtségével az AP többessz´ or´ assal k¨ uldhet u ¨zeneteket biztons´ agosan minden mobil ´ eszköz számára. Ertelemszer˝ uen, ezeket a kulcsokat az összes mobil eszk¨ oznek és az AP-nek is ismernie kell, ezért ezeket egy¨ uttesen ideiglenes csoportkulcsnak (Group Transient Key, vagy röviden GTK) nevezik. A GTK egy rejtjelez˝ o és egy integritás-véd˝ o kulcsot tartalmaz. AES-CCMP esetén a két kulcs ugyanaz, ezért csak egy kulcsból áll a GTK. A GTK-t az AP gener´ alja, és a négyutas kézfog´ as sor´ an létrehozott kulcs-rejtjelez˝o kulcsok seg´ıtségével titkos´ıtva juttatja el minden mobil eszközhöz k¨ ul¨ on-k¨ ul¨ on. 2.5.3.

WPA gyenges´ egei

Ahogy m´ ar kor´ abban eml´ıtett¨ uk a WPA-t m´ ar jóval kör¨ ultekint˝obben tervezték meg, mint ´ azok köz¨ a WEP-et. Ennek megfelel˝ oen a b˝ unlajstroma jóval rövidebb. Es ul is csak a gyakorlati szempontból legfontosabbakat emelj¨ uk ki. Ugyan form´ alisan m´ ar bebizony´ıtott´ ak, hogy a négyutas kézfog´ as teljes´ıti a t˝ole elvártakat bizonyos feltételek figyelembevételével. Mégis itt található néh´ any apr´ os´ ag. El˝ oször is nem volt és nem is lehetett elvár´ as helyi hozz´ aférés-védelem mellett valódi hiteles´ıtés nélk¨ ul, hogy ismert jelszó (PMK) mellett ne lehessen dek´ odolni m´ asok u ¨zeneteit. Ahogy kor´ abban m´ ar le´ırtuk, a PTK-t számol´ o f¨ uggvény öt bemenetéb˝ ol (emlékeztet˝ ou ¨l PMK, AP és STA MAC c´ıme, valamint AP és STA által gener´ alt véletlen számok) mindegyik ismert a négyutas kézfog´ as lehallgat´ asa után, melyben a véletlen számok ker¨ ulnek kicserélésre. A PTK ismeretében az u ¨zenetek dek´ odolhatóak. Ráad´ asul a négyutas kézfog´ as lehallgat´ as´ aval egy kulcs jelölt off-line m´ odon ellen˝orizhet˝ové válik, hiszen a kulcs-integritásvéd˝ o kulcsot felhasználják a MIC-ek kiszám´ıt´ as´ an´ al. Amennyiben egy kulcsjelölt azonos MIC-et eredményez, mint a lehallgatott u ¨zenetben, a kulcsjelölt nagy valósz´ın˝ uséggel a PMK. Azonban ´ıgy is csak a szót´ aras támadás a leghatékonyabb PMK visszafejt˝ o eljár´ as jelenleg. 12

Hivatkoz´ asok [1] IEEE Std 802.11TM . part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications, 1999. [2] Jesse R. Walker, Submission Page Jesse Walker, and Intel Corporation. Unsafe at any key size; an analysis of the wep encapsulation. IEEE 802.11-00/362, 2000. [3] Nikita Borisov, Ian Goldberg, and David Wagner. Intercepting mobile communications: the insecurity of 802.11. In MobiCom ’01: Proceedings of the 7th annual international conference on Mobile computing and networking, pages 180–189, New York, NY, USA, 2001. ACM. [4] W. Arbaugh, N. Shankar, J. Wan, and K. Zhang. Your 802.11 network has no clothes. IEEE Wireless Communications Magazine, 9(6):44–51, 2002. [5] IEEE Std 802.11iTM . Medium Access Control (MAC) security enhancements, amendment 6 to IEEE Standard for local and metropolitan area networks part 11: Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications, July 2004. [6] Scott R. Fluhrer, Itsik Mantin, and Adi Shamir. Weaknesses in the key scheduling algorithm of rc4. In SAC ’01: Revised Papers from the 8th Annual International Workshop on Selected Areas in Cryptography, pages 1–24, London, UK, 2001. Springer-Verlag. [7] Andrea Bittau, Mark Handley, and Joshua Lackey. The final nail in wep?s coffin. Security and Privacy, IEEE Symposium on, 0:386–400, 2006. [8] Wi-Fi Alliance. Wi-Fi Protected Access. [9] Levente Buttyán and L´ aszl´ o D´ ora. H´ırad´ astechnika, May 2006.

3.

WiFi biztons´ ag - A jó, a rossz, és a cs´ uf.

M´ er´ esi k¨ ornyezet

A méréshez minden mér˝ocsoport számára egy Linksys WRT54GL t´ıpus´ u AP-t helyezt¨ unk u ¨zembe. Ezen AP-k képesek az OpenWRT beágyazott Linux futtat´ as´ ara, mely lehet˝ ové teszi az AP-k dinamikus konfigur´ alás´ at annak megfelel˝ oen, hogy az egyes mér˝ocsoportok mely feladatokat végezték el, és melyek vannak hátra. A k¨ ul¨ onböz˝o AP-k k¨ ul¨ onböz˝o csatornán m˝ uködnek u ´gy, hogy a lehet˝ o legkevesbbé zavarj´ ak egymás kommunikáci´ oját. A feladatok elvégzéséhez sz¨ ukséges forgalmat egy automatikusan m˝ uköd˝ o kliens gener´ alja. Ez szintén egy Linksys WRT54GL t´ıpus´ u eszköz OpenWRT operáci´ os rendszerrel. Az automatikus kliens sorban minden mér˝ocsoport AP-j´ ahoz csatlakozik, és lekér egy weblapot, melyet az AP helyben kiszolgál. A méréscsoportok a feladatokat egy Atheros AR2413 (802.11bg) t´ıpus´ u vezeték nélk¨ uli hálózati kártyával ellátott PC-n hajtj´ ak végre. A kártya olyan szempontból k¨ ul¨ onleges, hogy szemben az ´ atlagos kártyákkal, támogatja az egyedileg összeáll´ıtott csomagok visszainjekt´ alás´ at. Erre egyébként az ¨ osszes Madwifi driverrel vezérelhet˝o vezeték nélk¨ uli kártya képes. A mér˝ogépeken a mérés alatt Live CD fut (BackTrack), melyen megtalálhatóak az méréshez sz¨ ukséges alkalmazások. Mivel kikapcsol´ askor minden adat és m´ odos´ıt´ as elveszik, amit a CDn található rendszeren hajtottunk végre, ker¨ ulj¨ uk a feleseleges u ´jraind´ıt´ asokat, illetve u ¨gyelni kell arra, hogy minden sz¨ ukséges adatot, amire sz¨ ukség lehet a mérés sor´ an olyan tárol´ on helyezz¨ unk el, ahol kikapcsol´ as után is megmarad.

13

A mérési jegyz˝okönyvet a mérés sor´ an folyamatosan kell kitölteni, és mérés végén a mérésvezet˝o számára véglegese ´ allapot´ aban elérhet˝ové kell tenni. A kitöltést a Google Docs seg´ıtségével lehet elvégezni, ami egy online dokumentumtároló és szövegszerkezt˝o szolgáltatás. Ez több okból is sz¨ ukséges és el˝ onyös is. Egyrészt a BackTrack nem rendelkezik el˝ore telep´ıtett szövegszerkeszt˝ ovel. M´ asrészt a Live CD u ´jraind´ıt´ asa esetén is (amit okozhat egy esetleges áramsz¨ unet) biztosan megmarad a kitöltött jegyz˝okönyv. Harmadrészt pedig a mérésvezet˝o számára is r¨ ogt¨ on elérhet˝ové válik a elkész¨ ult mérési jegyz˝okönyv. A Google Docs bejelentkezést igényel, ahol mérés el˝ ott m´ ar elérhet˝o lesz a jegyz˝okönyv egy kitöltetlen példánya. A http://docs.google.com-on a wifimeres<m´ er} ohely>@crysys.hu felhasználónévvel lehet belépni. A jelszavat a mér˝ocsoportok a mérés elején kapják meg, ami a mérés végeztével megváltozik. AP be´ all´ıt´ as. Mindegyik AP-n található egy u ´gynevezett SES (Secure Easy Setup) gomb. A SES gombbal ´ all´ıthatjuk, hogy melyik feladathoz tartozó biztons´ agi beáll´ıt´ as legyen érvényes. Az aktuális ´ allapotr´ ol a SES sz´ıne és egy WLAN felirat´ u LED ad visszajelzést. Bekapcsol´ askor, alapértelmezésként a WLAN nincs bekapcsolva, és ilyenkor a WLAN felirat alatti LED nem világ´ıt, minden m´ as esetben igen. A SES gomb visszajelzését az 1. táblázat ´ırja le. 1. táblázat. SES gomb sz´ınének jelentése SES DMZ Biztons´ agi be´ all´ıt´ as Nem világ´ıt Nem világ´ıt Wi-fi kikapcsolva Fehér Nem világ´ıt MAC sz˝ urés és rejtett SSID Narancssárga Nem világ´ıt 40 bites WEP Fehér Vil´ ag´ıt WPA (TKIP vagy CCMP) Narancssárga Vil´ ag´ıt RADIUS (Wifi 2. mérés) A csatornák frekvencia-átlapolód´ asa miatt akkor is elveszhetnek csomagok, ha az AP-k k¨ ul¨ onböz˝o csatornán m˝ uködnek. Ez k¨ ul¨ on¨ osen a WEP-es rész mérésénél jelenthet problémát, mivel az ott elvégzett támadások hatalmas forgalommal járnak. Ezért a feladatokat nem csak térben” (frekvencia), hanem id˝ oben is szét kell osztani. A mérésvezet˝o a mérés elején ” kiosztja, hogy melyik csoport mikor dolgozhat a WEP-es mérésen. Feladat Hiteles´ıt˝ o K´ od. Minden egyes AP-n fut egy mini webkiszolg´ aló. Az automata kliens minden csatlakozás után innen kér le egy weblapot, amihez elk¨ uld egy felhasználónevet és egy jelszót. A válasz egy kód, ami az aktuális id˝ ot˝ ol, a felhasználó nevét˝ ol és az AP sorsz´ amát´ ol f¨ ugg, és SHA-1-et használó HMAC-b˝ ol számolja az AP. Ezt a kódot Feladat Hiteles´ıt˝ o Kódnak nevezz¨ uk. A végs˝o cél minden feladat esetén egy érvényes Feladat Hiteles´ıt˝ o Kód megszerzése. Ehhez a következ˝ o lépéseket biztosan el kell végezni: 1) meg kell szerezni a jelszót, amit az automata kliens k¨ uld minden kérés esetén (WEP és WPA esetén ez rejtjelezetten ker¨ ul átvitelre), 2) hozz´ a kell kapcsol´ odni az AP-hoz (minden esetben valamilyen fok´ u védelmet kell kijátszani), 3) le kell kérni a Feladat Hiteles´ıt˝ o Kódot. Ez utóbbihoz m´ as felhasználónevet kell használni, mint az automata kliensnek: ‘M’ és a mér˝ohely száma (pl. ‘M4’).

4.

Feladatok

4.1.

Csatlakoz´ as rejtett SSID-j˝ u AP-hoz

1. Fedje fel a rejtett SSID-t! 2. Csatlakozzon a rejtett SSID-j˝ u AP-hoz! Ha nem ny´ılt az AP, a további lépésekhez kérjen jelszót a mérésvezet˝ot˝ ol. 14

3. Der´ıtse ki, hogy ki csatlakozik a MAC sz˝ uréssel ellátott AP-hoz! 4. Csatlakozzon a rejtett SSID-j˝ u AP-hoz a megfelel˝ o MAC c´ımet hamis´ıtva! 5. Szerezze meg a méréshelyhez tartozó Feladat Hiteles´ıt˝ o Kódot!

4.2.

WEP elleni t´ amad´ as

1. Der´ıtse ki a megt´ amadandó AP adatait! El˝ otte egyeztessen a mérésvezet˝ovel, hogy rendelkezésre ´ alljon szabad (m´ asok által nem támadott), WEP-pel védett AP! 2. Ind´ıtson el egy lehallgat´ ast kizár´ olag az adott AP-ra sz˝ urve! 3. Végezzen el ´ alhiteles´ıtést az AP-n´ al! 4. Szerezzen meg egy IV-hez tartozó 1500 bájt hossz´ u kulcsfolyamot! 5. Kész´ıtsen egy visszainjekt´ alható szabályos csomagot! 6. Kényszer´ıtse az AP-t k¨ ul¨ onböz˝o IV csomagok k¨ uldésére! 7. A WEP kulcs kiszám´ıt´ asa 8. Csatlakozzon az WEP-pel védett AP-hez, és kérje le a Feladat Hiteles´ıt˝ o Kódot!

4.3.

WPA gyenges´ egei

1. Fejtse vissza a WPA jelszót szót´ aras támadással! Ha az alapszót´ ar használatával nem jár sikerrel, egész´ıtse ki a szavakat egy számmal! 2. Fejtse vissza az idegen eszköz kommunikáci´ oj´ at! 3. Csatlakozzon az WPA-val védett AP-hez, és kérje le a Feladat Hiteles´ıt˝ o Kódot!

5.

Tov´ abbi inform´ aci´ ok

Monitor m´ od. A mérés fontos részét képezi a lehallgat´ as. Ehhez sok esetben monitor m´ odba kell ´ all´ıtani a kártyát. Azonban, amikor csatlakozni kell egy AP-hoz, akkor vissza kell áll´ıtani kliens vagy station m´ odba. Ehhez a wlanconfig parancs ad seg´ıtséget madwifi driver esetén. Akár station, akár monitor m´ odban használjuk a kártyán egy virtuális interfészt kell definiálni a következ˝ o paranccsal: wlanconfig create wlandev wlanmode sta|monitor Virtuális interfészt a következ˝ o paranccsal lehet tör¨ olni: wlanconfig destroy Néh´ any hibalehet˝oséget kizárhatunk azzal, ha a air*-ng parancsok futtat´ as´ ahoz a monitor m´ od váltás´ at r´ ab´ızzuk egy beép´ıtett eljár´ asra az airmon-ng start|stop parancs seg´ıtségével.

15

Lehallgat´ as. Lehallgat´ ast számos program megvalós´ıt, ezek köz¨ ul a következ˝ o kett˝ ot használatát javasoljuk: ‘airodump-ng’ és ‘Wireshark’. Mindkét alkalmazás kezelni tudja az elterjedt PCAP (packet capture) form´ atumot, mely lehet˝ ové teszi az alkalmazások közötti átjár´ as. Az el˝ obbi program k¨ ul¨ onlegessége, hogy támogatja a rejtjelezett csomagok lementését is megfelel˝o paraméterezés mellet. Az airodump parancs futtat´ asa után megjelen´ıt minden fontosabb informáci´ ot az AP-kr´ ol (SSID, BSSID, csatorna, biztons´ agi beáll´ıt´ asok), valamint megjelen´ıti az AP-khoz csatlakozó STA-k MAC c´ımét is. Az airodump-ng a következ˝ o minta szerint paraméterezhet˝ o (A mérést könny´ıt˝ o kapcsol´ okat a 2. táblázatban soroljuk fel): airodump-ng

2. táblázat. airodump-ng kapcsol´ oi Kapcsol´ o Le´ır´ as --bssid <mac> Kizár´ olag a <mac> MAC c´ımhez kapcsol´ od´ o kommunikáci´ ot hallgatja le, egyébként minden elfogott csomagot kezel --channel Kizár´ olag a csatornán lév˝ o kommunikáci´ ot hallgatja le, egyébként ciklikusan váltogat -w fájlba menti a lehallgatott kommunikáci´ ot A Wireshark a grafikus interfésznek köszönhet˝ oen megk¨ onny´ıti a csomagok kezelését. A Wireshark képes dek´ odolni a rejtjelezett csomagokat, amennyiben megadjuk a hozz´ a tartozó jelszót. Ezt a ‘File → preferences → Protocols → IEEE 802.11’ men¨ uben a ‘Enable decryption’ beikszelésével és az alatt található mez˝o(k) kitöltésével tudjuk elérni. Csatlakoz´ as. Az access pointhoz való csatlakozást többféleképp is el lehet végezni: 1) user interfésszel rendelkezik a ‘Wireless assistant’, 2) kézzel kell konfigur´ alni a ‘wpa supplicant’-ot. MAC c´ım v´ altoztat´ as. MAC c´ım változtat´ as´ ara sz¨ ukség van, amikor MAC c´ımre is sz˝ ur az AP. Itt is több lehet˝ oség köz¨ ul választhatunk: ifconfig hw ether <´ uj mac c´ ım> vagy macchanger --mac=<´ uj mac c´ ım> Visszaj´ atsz´ as. A csomagok megfelel˝ o visszajátszás´ at az ‘aireplay-ng’ programcsomaggal lehet elvégezni. K¨ ul¨ onböz˝o kapcsol´ okkal k¨ ul¨ onböz˝o támadásokat lehet végrehajtani. A 3. táblázatban ¨ osszeszedt¨ uk a mérés sor´ an használatosakat. További kapcsol´ okhoz ajánljuk a manual-t. ¨ Uzenet gener´ al´ as. A ‘packetforge-ng’ egy a WEP törésére használható program, mely egy adott IV és kulcsfolyam ismeretében gener´ al egy visszainjekt´ alható broadcast u ¨zenetet. A kimenet egy PCAP form´ atum´ u fájl, mely az azt kezel˝ o alkalmazásokkal feldolgozható és felhasználható.

16

3. táblázat. Aireplay-ng f˝obb kapcsol´ oi Kapcsol´ o R¨ ov. kapcs. T´ amad´ as --deauth= -0 Deauthentikál egy megadott STA-t -szor ´ ıtést végez el <delay> ms --fake-auth=<delay> -1 <delay> Alhiteles´ m´ ulva a további kapcsol´ okkal megadott AP-hoz --interactive -2 Visszainjekt´ alható broadcast u ¨zenettel forgalmat gener´ al a megadott AP-n´ al ¨ --fragment -5 Uzenet darabolási eljár´ assal valamelyik IV-hez megszerez 1500 bájtnyi kulcsfolyamot --test -9 Leteszteli, hogy támogatja-e a kiválasztott kártya a csomagok visszainjekt´ alás´ at WEP ´ es WPA t¨ or´ es. A ‘aircrack-ng’ WEP és WPA jelszó visszafejtésre/felt¨ orésre használható program. WEP esetén a kor´ abban m´ ar eml´ıtett FMS eljár´ ast implementálja kiegész´ıtve számos optimalizáló eljár´ assal. WPA esetén egyszer˝ uen szót´ aras támadást hajt végre elfogott négyutas kézfog´ as seg´ıtségével.

6.

Minta beugr´ o k´ erd´ esek • Hogyan fedne fel egy rejtett SSID-t? • Mi az a beacon u ¨zenet? • Hogyan lehet csatlakozni egy AP-hoz, amelyikben csupán MAC sz˝ uréssel védekeznek? • Két k¨ ul¨ onböz˝o WEP-pel védett csomagok esetén hogyan állap´ıthat´ o meg, hogy azonos kulcsfolyammal lett a két u ¨zenet kódolva? • Nevezzen meg három WEP gyengeséget! • Írja le a WEP-es támadás f˝obb lépéseit! • Mi sz¨ ukséges m´ as mobil ´ allomás u ¨zeneteinek visszafejtéséhez WPA esetén ismert jelszó mellett? • Mi a négyutas kézfog´ as célja? • Mi a leghatékonyabb ismert támadás WPA jelszó visszafejtésre?

17

WIFI 1: Helyi hitelesítő eljárások elleni

Recommend Documents