A WEP és a WPA: teljes biztonság a levegőben? Nem hinném…
Üdvözlök mindenkit az EthicalHacking cikksorozatom 2. részében.
Előzményekért tekerj az oldal aljára.
Mai cikkem tartalma egy kicsit szárazabb anyag: a vezetéknélküli-hálózatok biztonsági megoldásai, valamint ezek hátrányai, hibái.
Tehát: 2 fajta titkosÃtásról beszélhetünk, ha WLAN-ról van szó. MindkettÅ‘ feltörhetÅ‘ (ez mondjuk nem meglepÅ‘, hiszen alapelvünkre emlékeztek: minden feltörhetÅ‘). Az egyiket nagyon egyszerű, a másiknál szerencse is kell. Ezek:
1. A WEP (Wired Equivalent Privacy – Vezetékkel Egyenértékű Biztonság):
Története:
A WEP elÅ‘tt teljes lehetetlenség volt pl. egy cégnél WiFit használni: bárki lehallgathatta a teljes hálózatot, feltűnés nélkül. MÃg, ha vezetékeket használunk, akkor már ugye hozzá kell férni a switchez/routerhez, hogy belépjünk a hálózatba (most az internetrÅ‘l történÅ‘ behatolásokat kihagyom). A WEPet tehát azért alkották meg IEEE 802.11 szabvány tervezÅ‘i, hogy legalább olyan biztonságossá tegyék a WiFit, mint a normális vezetékes hálózatot. Mivel azonban egy switch/router sem nyújt teljes biztonságot, a tervezÅ‘k a WEP-nél sem törekedtek a feltörhetetlenségre, azonban kivételesen még ezt az alacsony lécet is igen hamar leverték. Néhány évvel a WEP megjelenése után már megjelentek az elsÅ‘ feltörésre alkalmas programok. Akkor még nem nagyon vették figyelembe Å‘ket, hiszen a feltörésre még Ãgy is legalább 24-48 óra kellett. De ennek ellenére olyan súlyosak voltak a felvetett problémák, hiányosságok a szabványban, hogy lépett a bizottság: létrehozták a WPA-t (lejjebb).
LeÃrása: működés, hibák, sebezhetÅ‘ségek:
AlapvetÅ‘ fogalmak: AP=AccesPoint-HozzáférésiPont, STA=Station-Ãllomás (a csatlakozni akaró kliens)
A rádiós hálózatokkal kapcsolatban alapvetÅ‘en 2 probléma merülhet fel: valaki lehallgatja az üzeneteket/csomagokat, illetve valaki illegálisan veszi igénybe a hálózatot. A WEP úgy védekezik az elsÅ‘ probléma ellen, hogy titkosÃtja az üzeneteket, a másodikra pedig egyszerű kérés-válasz alapú, 4 lépéses hitelesÃtés nyújtja megoldást. Mindjárt meglátjuk, mennyire eredménytelenül.
A hitelesÃtés 4 lépése: a STA küld egy hitelesÃtési kérelmet (authentication request), amire az AP válaszként küld egy véletlen számsort. Ezt titkosÃtja a STA egy csak általa és az AP által ismert kulccsal, majd ezt visszaküldi. Végül az AP a közös kulccsal kikódolja a STA üzenetét, és ha végül saját üzenetét kapja vissza, dönthet a sikeres/sikertelen hitelesÃtés között (authentication failure/success).
A hitelesÃtés után a STA és az AP titkosÃtva kommunikálnak tovább, ugyanazt a titkos kulcsot használva, mint a hitelesÃtésnél. A titkosÃtás egyik felét az RC4 kulcsfolyam kódoló végzi. Egy kulcsfolyam kódolónak az a lényege, hogy rövid, néhány bájtos kulcsból egy hosszú (ál)véletlen bájtsorozatot alkot, majd ezt hozzá XOR-olja az üzenethez.
(A XOR működése: A XOR függvény két bitet hasonlÃt össze egymással, a következÅ‘ kérdéssel: Ez a két bit egyforma? ha igen, 0-át ad, ha nem 1-et. Lássuk mindezt táblázatban:
További tulajdonsága a XOR-nak, hogy bármely 2 bitből ki tudja számolni a 3.-at.)
Ezekután elméletben a dekódolás Ãgy zajlana le: a vevÅ‘ a titkos kulccsal szintén elkészÃti az RC4 (ál)véletlen sorozatot, majd ha ezt XOR-olja a kapott titkos üzenethez, akkor megkapja az eredeti üzenetet. (Példával szemléltetve: Mondjuk azt, hogy üzenetünk 2 bitbÅ‘l áll: 1-0. Titkos kulcsunk meg RC4 után: 0-0. Ekkor a művelet: 1 XOR 0=1; 0 XOR 0=0. A vevÅ‘ ezt kapja tehát: 0-1 és 0-0 ha ezeket beletesszük újra egy XOR függvénybe: 0 XOR 1=1 és 0 XOR 0=0, tehát visszakaptuk az eredeti üzenetet)
Ez persze nem mehet ilyen egyszerűen: ha mindig ugyanazzal az (ál)véletlen bitsorozattal XOR-olunk, akkor könnyen megfejthető lenne üzenet-statisztika alapján a kulcs.
Ezért a WEP-ben van egy nem állandó érték is, amely üzenetenként változik: az IV-Initialization Vector, amit hozzácsapunk a titkos kulcshoz, és ebbÅ‘l készÃtünk egy (ál)véletlen bájtsorozatot, majd ezt XOR-oljuk az üzenettel.
Ãm még mindig nem teljes a kép: az üzenet sem áll magában: hozzáÃródik még a manipulálás ellen egy ún. ICV érték (Integrity Check Value), ami nem más, mint az üzenet CRC értéke. Önmagában ez nem lenne elég, hiszen egy módosÃtott üzenethez lehet új CRC értéket számolni, de a WEP még az ICV-t is titkosÃtja-hozzáfűzi az üzenethez (ami ugye alapból is titkosÃtásra kerül).
Egyszerűbben: a WEP titkosÃtás működése, összefoglalva:
Üzenetünkre számolunk egy CRC értéket. Nevezzük az üzenet+CRC-érték párost Ü-nek.
Másik ágon: a titkos kulcsot összefűzzük a véletlen IV-vel, és betesszük az RC4 kulcsfolyam kódolóba. Nevezzük az itt kijövő értéket K-nak.
Ezekután: Ãœ XOR K=ÃœK. Végül, a dekódoláshoz szükséges IV-t nyÃltan küldjük át!, tehát a végleges WEP üzenet: ÃœK+IV.
Ezért is tévesek a 128-bites biztonságot nyújtó WEP-rÅ‘l szóló reklámok: mivel az IV 24bites, és nyÃltan kerül átvitelre, a valódi védett bitek száma csak 104.
Az üzenet dekódolása:
A nyÃltan átküldött IV-t összefűzzük a saját titkos kulcsunkkal, majd RC4 (K-t kapjuk). Ezt XOR-oljuk a kapott üzenettel: K XOR ÃœK=Ãœ. Végül a CRC értékeket összehasonlÃtjuk.
Most hogy ismerjük a WEP működését, beszéljünk a támadás szempontjából fontos hibákról:
Lehetséges a rögzÃtett üzenetek visszajátszása, egy késÅ‘bbi idÅ‘pontban. Nemsokára láthatjuk, milyen fontos is ez.
A legfontosabb azonban: az RC4 helytelen használata: léteznek ugyanis ún. gyenge kulcsok, amikbÅ‘l olyan bitsorozatot állÃt elÅ‘ az algoritmus, amiknek elsÅ‘ néhány bájtjából nagy valószÃnűséggel következtetni lehet az eredeti, bevitt értékre, tehát a titkos kulcsra! Ráadásul az állandóan változó IV miatt sokkal nagyobb az esély a gyenge kulcs létrejöttére.
Valójában ezen alapszik a teljes törési eljárás.
Pont olyan, mint az ismert MasterMind játék: minden sorral újabb információ derül ki, és végül meg van a szó. Ezért a WEP-nél nagyjából semmit nem ér a speciális jelszó, mert elÅ‘bb utóbb úgyis kiderül…Próbaképpen ezt a jelszót állÃtottam be: ’!5kJ). Ezt szólistából lehetetlen lenne kipörgetni, de nekem mégis sikerült kiderÃtenem. Hiszen minden csomagból újabb információ derült ki a kulcsról, és végül meg volt az a karaktersor, ami megfelelt az információknak.
A bitszám sem segÃt sokat: 128 bites titkosÃtás esetén már 60 000 csomagból 60-70% a kiderÃtés valószÃnűsége, 100 000 csomagnál 90% a legújabb, PTW technológiával (többet ITT). Persze 64 biten még kevesebb csomag kell, ott már 60 000 csomagból szinte biztosan lehet jelszót kapni.
Viszont 60 000 csomag még mindig nagyon sok: ennyit csak akkor generál egymenetben a felhasználó, ha pl. letölt egy filmet. De ki akar erre várni? Hiszen alapszintű kommunikáció szinte mindig van a levegÅ‘ben. Ha a támadó itt elcsÃp egy alkalmas csomagot (olyan csomagot, amire a routernek válaszolnia kell), és átÃrja a cÃmzett helyére saját magát, majd elkezdi küldeni, folyamatosan visszajátszani? Nyugodtan megteheti, hiszen, mint Ãrtam, a WEP-nél lehetséges csomagok reinjektálása. A router pedig, szerencsétlenül küldi-küldi a válaszcsomagokat, minden egyes csomaggal hozzáadván egy kis információt a nagy MasterMind-hoz…
Egy Intel2200B/G chipsetes kártyával olyan 300 csomag/mp-es sebesség érhető el. Elméletben tehát 200mp szükséges a töréshez. Persze, ha a teljes időt vesszük (megfelelő csomagra kell egy kicsit várni, általában 40-60 mp-et, be kell szerezni KisM*T-tel a megfelelő infókat a hálózatról), úgyhogy összeségében akár 5 percbe is telhet laptop bekapcsolásától a titkos kulcsig.
2. A WPA (WiFi Protected Access-WiFi Védett Hozzáférés)
A WPA-ról sajnos nem találtam ennyi információt, amit tudok, azt dióhéjban összefoglalom:
A WPA sokkal komolyabb titkosÃtást alkalmaz, mint a WEP. Lényeges, hogy több kulccsal dolgozik, és keveri Å‘ket az üzenetek titkosÃtásánál, szóval igazi erÅ‘s titkosÃtás.
Ãm, természetesen ez is feltörhetÅ‘, köszönhetÅ‘en eszes technikáknak. Ugyanis a WPA-nal, és a WPA2-nél is létezik egy olyan alfaj, amikor az SSID-bÅ‘l és a jelszóból készÃt egy hasht az AP, és ezzel titkosÃt. Ezt az ún. WPA-Handshake-et akkor lehet elkapni, ha egy kliens éppen felcsatlakozik a hálózatra. Ha nincs senki a hálózaton, akkor szÃvás van, várni kell. Ha azonban valaki fenn van, akkor megfelelÅ‘ kártyával (Intel pl. nem jó) ledobhatjuk a hálózatról, pontosabban felszólÃthatjuk, hogy újra hitelesÃtse magát (DeAuthentication request). Miközben ezt kiküldtük, folyamatosan sniffeljük az átmenÅ‘ csomagforgalmat, és elcsÃpjük a WPA-Handshake-et.
EbbÅ‘l aztán offline lehet fejteni, tehát be lehet vetni sok gépet összekapcsolva hálózatban, vagy, ami még jobb: a rainbow táblákat. A rainbow táblák lényege az, hogy egy bizonyos művelet végeredményét tartalmazzák, Ãgy azt nem kell újra meg újra elvégeznie a processzornak.
Megpróbálom példával leegyszerűsÃteni: ugye ha van egy szólistánk, és egy handshake-et törünk, mit tesz a processzor: fogja az SSID-t, meg az elsÅ‘ jelszót a listáról, hashet készÃt, majd összehasonlÃtja a lesniffelt hash-sel.
Ezt azonban külön is lehet választani: Vegyük azt, hogy van egy SSID-nk, Handshake-ünk és egy jelszólistánk. Ha létrehozunk egy adatbázist (pl. SQL-ben), amiben 1 oszlopban van csak az SSID, a másikban a jelszavak, majd a 3.-ba beÃrjuk a hasheket, akkor máris egy lépést megtakarÃtottunk. Ãgy, mondjuk egy egymilliós jelszólistát lehashel a proci 30 perc alatt, után viszont ebbÅ‘l az adatbázisból olyan gyorsan tud összehasonlÃtást végezni, mint fentebb Ãrtam. Én egy teszt fájllal kipróbáltam, és 20 196 jelszó/mp-et értem el (P4 2,66GHz, 1GB RAM), de mondom, másoknál ez még magasabb lehet. Persze a kulcs itt egy jó szólista. A weben vannak honlapok, ahol egy adott nyelv leggyakrabban használt szavait lehet megtalálni, de léteznek minden nyelvhez megfelelÅ‘ szólisták.
Ha valaki még a saját adatbázissal sem akar fáradni, neki is van megoldás: srácok összeszedték az 1000 leggyakoribb SSID-t, és elkészÃtették ezek hashét egy nagyon jó szólistával. A végeredmény egy 33GB-os adatbázis szörnyeteg lett: több hálózatba kötött gép 2 napi folyamatos munkájának eredménye. Válalkozó kedvűek ezt is letölthetik, bár hátránya, ha nincs benne a mi SSID-nk, vagy nem angol a jelszavunk, akkor el kell készÃteni a saját adatbázist.
Végül, természetesen, ha a szólista nem segÃt, akkor brute-force-cal is lehet próbálkozni, de persze ez akár évekbe is telhet…
Ennyit a vezetéknélküli-hálózatok biztonsági megoldásiról, és azok hibáiról.
Köszönöm a figyelmet, remélem, nem volt túl „kocka†a tartalom. Ha igen, kérdezz a fórumban, had magyarázzam el.
DOMy
Köszönet a forrásaimnak:
http://www.crysys.hu/publications/files/ButtyanD06ht.pdf
http://www.airscanner.com/pubs/wep.pdf