Mellékleteink: HUP | Gamekapocs
Keres
Gyere el a HWSW első IoT meetupjára, június 20-án!

Most egy időre megszűnik a titkosított Wi-Fi

Gálffy Csaba, 2017. október 16. 16:48

Foltozható a meglévő, WPA2-es Wi-Fi titkosítási szabvány, így javítható lesz a nyilvánosságra került új sebezhetőség-sorozat, a KRACK. Ettől függetlenül nehéz hetek-hónapok jönnek, amíg az első frissítések elkezdenek az eszközökre lecsorogni.

hirdetés

Gyakorlatilag védtelenné váltak a Wi-Fi hálózatok - nagyjából így szűrhetjük le egy vadonatúj sebezhetőség következményeit. A Mathy Vanhoef kutató által felfedezett hiba a legjobb Wi-Fi titkosítási eljárást is támadhatóvá teszi. Ismerkedjünk meg a KRACK sebezhetőséggel és gyakorlati következményeivel!

Release the KRACKen

Az első híradások megosztottak voltak abban a tekintetben, hogy az egyes implementációk, vagy maga a protokoll a sebezhető - ezért is várt a HWSW a ma délutánig hivatalos publikációra, hogy a tények birtokában tudjuk tárgyalni a problémát. A kutatók állítása szerint maga a protokoll, vagyis a titkosítási folyamatot leíró szabvány a hibás, emiatt jó eséllyel minden implementáció tartalmazza a sebezhetőséget. Jó hír azonban, hogy nem kell azonnal vadonatúj protokollt írni - ez évekbe is telhetne - a meglévő implementációk foltozhatóak olyan formában, hogy kompatibilisek maradjanak. Egészen pontosan javítható a hiba a hozzáférési pont vagy a kliens oldalán is, hogy ezek továbbra is kommunikálni tudnak majd javítatlan eszközökkel.

handshake

Hogyan is működik a sebezhetőség? Ahogy a kutató írja: "Amikor a kliens csatlakozik a hálózathoz, akkor egy négyes kézfogással egyezik meg a hálózati vezérlővel az új titkosítási kulcsról. Ezt a kulcsot a négy kézfogás harmadik üzeneténél kapja meg és telepíti. Amint a kulcs telepítve van, a kliens ezt használja a sima adatcsomagok titkosítására a titkosítási protokollt használva. Azonban mivel az üzenetek elveszhetnek, az AP újraküldi ezt a harmadik üzenetet, ha nem kap nyugtázó választ a kliens felől. Ennek következménye, hogy a kliens többször is megkaphatja a harmadik üzenetet. Minden alkalommal, amikor ez az üzenet megérkezik, a kliens újratelepíti ugyanazt a titkosítási kulcsot és ezzel alaphelyzetbe állítja a titkosítási protokoll által használt belső számlálót."

És itt a probléma. A titkosítás ugyanis abból a premisszából indul ki, hogy a nonce (számláló) soha nem ismétlődhet - csak ekkor biztonságos. Ha a számláló visszaállítható (és esetünkben az), akkor a titkosítás nem sokat ér. "A kutatás szerint a támadó kikényszerítheti a nonce nullázását e harmadik üzenetek begyűjtésével és újraküldésével. A nonce-újrahasznosítással pedig támadhatóvá válik a titkosítási protokoll, a hálózati csomagok újraküldhetőek, visszafejthetőek és meg is hamisíthatóak. Ez a technika felhasználható a csoportos kulcs, PeerKey, TLDS vagy gyors BSS kézfogások támadására is." - mondja a kutató.

Sajnos tovább is van: a fentieken túl a roppant népszerű és általánosan használt linuxos implementáció, a wpa_supplicant sajátos viselkedése még rátesz egy lapáttal. "A támadás különösen katasztrofális a wpa_supplicant 2.4-es és újabb kiadásai ellen. Itt a kliens egy kinullázott kulcsot telepít az első telepítés után, ahelyett, hogy az eredetit telepítené újra. Ezt valószínűleg a szabványban leírt javaslat okozza, amely szerint a kulcsot az első telepítés után törölni kell a memóriából. Amikor a kliens így újra megkapja a négy üzenetből a harmadikat, akkor a már törölt [kinullázott] kulcsot fogja telepíteni."

A fenti nem csak a változatos Linux-disztribúciókat, hanem az Androidot (amely szintén egy Linux-alapú rendszer) is érinti, 6.0-s és frissebb verziók esetén. Ez az extra hiba azt jelenti, hogy ezen eszközök által Wi-Fi forgalma triviálisan elfogható és manipulálható - jelenleg a mintegy 2 milliárdnyi androidos eszköz 41 százaléka tartozik ebbe a kategóriába, vagyis mintegy 800 millió okostelefon és tablet mostantól nyílt Wi-Fi-vel ekvivalens védettséget élvez.

Lássuk a következményeket

Első kör: a támadási felület fizikai. Jelentős különbség a "szokásos" sebezhetőségek túlnyomó részéhez képest, hogy ez hálózaton keresztül távolról (például interneten át) nem használható ki, a támadónak fizikai hozzáférést kell szereznie, magyarán a támadni kívánt hálózat vagy célpont közelében kell lennie, rádiós hatósugáron belül.

integration

Meglehetősen pontos illusztrációja a problémának.

A másik: a legfontosabb, legérzékenyebb pontokon ma már a hálózati kommunikációt védi egy második titkosítási réteg is (HTTPS vagy épp VPN). Ugyan a kutatók felhívják a figyelmet, hogy ez a védelem nem száz százalékos, a HTTPS rendszeresen el szokott esni (nem-böngészős implementációknál) és a VPN-megoldások között is akad bőven, amely nem tartalmaz beépített titkosítást.

A harmadik: ugyan a támadási forma lehetővé teszi a titkosítási kulcsok visszafejtését bizonyos körülmények között, de magát a hozzáférési jelszót nem lehet ezzel megszerezni. Így nincs szükség a jelszavak azonnali vagy későbbi cseréjére, azok (hacsak másképp ki nem szivárogtak) akkor biztonságban vannak. Ugyanígy ha a hálózat friss kulcsot küld ki, akkor a régi visszafejtése ebben nem segít, a támadónak újra meg kell azt fejtenie.

A FUD-ot nagyjából kizártuk, akkor lássuk a valódi veszélyeket! A legnagyobb probléma, hogy a WPA2-vel védett hálózatokon a sima, titkosítatlan HTTP-kapcsolat támadhatóvá válik. A kapcsolaton kicserélt adatok a támadó számára visszafejthetőek lesznek, akár jelszavak és a cookie-k tartalma is. Ez egy ragyogó ok arra, hogy a HTTPS-t még nem használó oldalak (itthon ilyen az Index, az Origo vagy a 24.hu is) sürgősen vezessék be a titkosítást. Ennél gonoszabb, hogy a HTTP forgalom meg is hamisítható bizonyos Wi-Fi protokollok esetén (WPA-TKIP és GCMP), vagyis például az oldalak kinézete módosítható, elemek szúrhatóak abba bele - mindent úgy, hogy a kliens meg van győződve arról, hogy az eredeti oldalt látja.

A sebezhetőség több módszerrel felhasználható malware terjesztésére is. Például az említett esetben (TKIP vagy GCMP használata esetén) a támadó potenciálisan rá tudja venni a klienst malware telepítésére is. Ehhez nem elegendő a WPA2 sebezhetősége, kell a kliensoldalon is biztonsági rés

További olvasnivaló

Ahogy ilyenkor mindig, szakembereknek, Wi-Fi hálózatok üzemeltetőinek és haladó felhasználóknak érdemes a forrást fellapozniuk. Vanhoef itt írt egy tömörebb összefoglalót a sebezhetőségről (nagyjából ennek alapján született a cikk is), itt pedig maga a kutatási jelentés érhető el. Ebből olyan izgalmas elemek derülnek ki, hogy a Windows és az iOS (feltételezhetően a 802.11-es szabvány helytelen implementációjából kifolyólag) nem fogadja az ismételt 3. üzenetet, de sajnos a támadás másik formája, a csoportos kulcs-kézfogás ellen ez sem véd. Pehelykönnyű olvasmány lefekvés előtt. Ha ez nem lenne elég, akkor érdemes hozzácsapni Matthew D. Green, a Johns Hopkins tekintélyes kriptográfia-professzorának cikkét is, akinek van néhány keresetlen szava az iparághoz.

Frissítés: a Microsoft közzétette saját bejegyzését, eszerint a KRACK sebezhetőséget a cég javította minden támogatott operációs rendszerén az októberi patch kedden kiadott csomaggal. Erre volt lehetősége a cégnek, a hibát megtaláló kutató még májusban értesítette az amerikai CERT-et a hibáról, így rengeteg szereplő készen állt már a javítással a mai határidőre.

Facebook

Mit gondolsz? Mondd el!

Adatvédelmi okokból az adott hír megosztása előtt mindig aktiválnod kell a gombot! Ezzel a megoldással harmadik fél nem tudja nyomon követni a tevékenységedet a HWSW-n, ez pedig közös érdekünk.
Hiánypótló Android fejlesztői képzés Kotlin alapokon június 26-án! Online és tanteremben is. 30 órában, gyakorlatorientáltan. Focivébé barát időpontokban. + Június 19-én bemelegítő Android/Kotlin meetup!