Slo-Tech - Raziskovalec Mohammad Sohail Ahmad iz podjetja AirTight je odkril ranljivost v protokolu WPA2, ki jo je poimenoval Luknja 196. Ime je dobila po zaporedni številki strani v standardu IEEE 802.11 (revizija iz leta 2007), kjer se skriva ozadje zanjo. Napaka omogoča avtoriziranemu uporabniku omrežja prestrezanje in dešifriranje podatkov drugih uporabnikov na istem omrežju z MITM-napadom. Podrobnosti bodo predstavljene na konferencah Black Hat Arsenal in DEF CON 18, ki bosta potekali prihodnji teden v Las Vegasu.
Zlomljen ni šifrirni algoritem AES, iz katerega je izpeljan WPA2, marveč je zlorabljena pomanjkljivost v implementaciji, ki omogoča prejem prometa z dostopne točke (AP) s skupnim deljenim ključem vsem odjemalcem. WPA2 namreč uporablja dve vrsti ključev: PTK (pairwise transient key), ki je unikaten za vsakega odjemalca, in GTK (group temporal key) za zaščito poslanih podatkov več odjemalcem v omrežju. S PTK je moč zaznati ponarejanje (spoofing) in poneverbo podatkov (data forgery), z GTK pač ne.
Tako lahko odjemalec zlorabi GTK za tvorbo posebnega broadcast paketka, na katerega se drugi odjemalci odzovejo s pošiljanjem svojih zasebnih ključev. Kot pravi Ahmed, potrebuje približno deset vrstic kode v odprtokodnem gonilniku MadWiFi in standardno mrežno kartico, da se lahko s ponarejanjem MAC-naslova pretvarja, da je njegov računalnik AP. Ostale tako pretenta, da je prehod (gateway), tako da se odzovejo s svojimi PTK. Napad lahko izvedejo le že avtorizirani uporabniki omrežja.
Novice » Varnost » Odkrita ranljivost v WPA2
RejZoR ::
To je vbistvu dost bedasta in neuporabna "ranljivost". Mislim, če moraš bit že avtoriziran pomeni, da si itaq že v omrežju. Edina uporabna stvar tukaj je potem, da se pač logiraš s podatki nekoga drugega in potem delaš kakšne nečednosti in s tem prikažeš, kot da je to delala neka druga oseba. Pri domačih wireless omrežjih pa je običajno tako ali tako samo 1 geslo, tko da si gor al pa nisi. In če nisi je WPA2 še vedno zelo varen.
Razen če je z "avtoriziran uporabnik" bilo mišljeno kaj drugega kot oseba, ki je že loginana v omrežje s svojim geslom.
Razen če je z "avtoriziran uporabnik" bilo mišljeno kaj drugega kot oseba, ki je že loginana v omrežje s svojim geslom.
Angry Sheep Blog @ www.rejzor.com
MrStein ::
Ostale tako pretenta, da je prehod (gateway),
gateway/prehod je nekaj čist drugega.
Torej normalno en STA ne vidi prometa drugih STA v WPA(1/2)-PSK omrežju?
Me vedno zanimalo, pa nikoli nisem vprašal...
Motiti se je človeško.
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!
Zgodovina sprememb…
- spremenil: MrStein ()
r_DTgl ::
RejZoR se enkrat preberi novico, v obeh primerih avtorizacije ki si ti jih opisal pa nikakor ni bedasta in neuporabna ranljivost. Eden izmed lepsih hackov v zadnjem casu.
MrStein ::
Bom zlorabil temo, ker ravno urejam en WLAN:
Kaka je razlika med WPA-AES in WPA2-AES? (oboje PSK).
Ker ruter je star in podpira baje le WPA-AES, pa me zanima kak je z varnostjo in kompatibilnostjo (sicer 99% bodo novi klienti delali, ampak pametni vprašajo
Kaka je razlika med WPA-AES in WPA2-AES? (oboje PSK).
Ker ruter je star in podpira baje le WPA-AES, pa me zanima kak je z varnostjo in kompatibilnostjo (sicer 99% bodo novi klienti delali, ampak pametni vprašajo
Motiti se je človeško.
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!
Zgodovina sprememb…
- spremenil: MrStein ()
Jst ::
Pomoje ni mislil na protokol sam, ampak na implementacije na raznih napravicah, like iPod Touch, ki je bil znan po tem, da je imel neke težave oz. ranljivosti pri WPA2 prijavi v omrežje.
Islam is not about "I'm right, you're wrong," but "I'm right, you're dead!"
-Wole Soyinka, Literature Nobelist
|-|-|-|-|Proton decay is a tax on existence.|-|-|-|-|
-Wole Soyinka, Literature Nobelist
|-|-|-|-|Proton decay is a tax on existence.|-|-|-|-|
denial ::
Bom zlorabil temo, ker ravno urejam en WLAN:
Kaka je razlika med WPA-AES in WPA2-AES? (oboje PSK).
Z vidika varnosti IMO ni bistvene razlike. Če se hočeš sam prepričati se malce poglobi v linke: KLIK, KLOK in KLAK.
Sniffanje prometa med authenticated userji naj ne bi bilo mogoče zaradi unikatnih PTK-jev, kar je "Hole 196" sedaj itak postavil na glavo. Me prav zanima, če tale bug deluje tudi pri uporabi L2-isoloation.
Zakaj "Hole 196"? Ker je bug baje objavljen na strani 196 IEEE 802.11 Standarda (Revizija, 2007): KLIK
SELECT finger FROM hand WHERE id=3;
Zgodovina sprememb…
- spremenil: denial ()
fiction ::
Bom zlorabil temo, ker ravno urejam en WLAN:Kaka je razlika med WPA-AES in WPA2-AES? (oboje PSK).Dobro vprašanje. AFAIK je WPA, WPA2 itd. itak samo "certifikat", ki ga dobi naprava po testiranju s strani Wi-Fi Alliance, ne pa nekaj kar bi označevalo encryption protokol. Po WPA2 mora naprava obvezno implementirati AES CCMP, medtem ko pri WPA to ni obvezno.
Jaz bi rekel, da je oboje isto, samo da se pri enem testu uporabi eno pri drugem pa drugo. Se pravi, če izbereš WPA-AES je zadeva teoretično lahko broken, ker tega nihče ni šel "preverjati" pri WPA2-AES so pa stvar toliko sprobali, da je dobila "štemepel". Ampak če naprava podpira oboje, verjetno niso šli delati dveh različnih implementacij istega protokola.
Kar se tiče napake zgleda precej kritična. Ni vse samo v tem, da lahko en uporabnik neavtorizirano dostopa do omrežja. No free internet, no bug
Tudi to, da lahko, ko si prijavljen, prestrezaš promet od drugih uporabnikov je problematično. Mogoče so se ljudje le malo preveč navadili na to, ker se to da tako enostavno v odprtem omrežju ali pa pri WEP. fiction ::
Zakaj "Hole 196"? Ker je bug baje objavljen na strani 196 IEEE 802.11 Standarda (Revizija, 2007): KLIKVprašanje zdaj je samo, katera stran je dejansko 196-ta? Mislim, ker je še cover in par stvari, ne zato ker ne bi znal štet. Je to stran z: 8.4.10 RSNA security association termination?
fiction ::
Sicer se mi zdi pa zanimivo, kako je to sploh kdaj delalo. Ti načeloma poveš samo SSID in BSSID od AP-ja (MAC naslov), nikjer pa ne public keya ali kaj takega. Ključ je samo en shared secret (PSK), ki ga vsi poznajo. Vsi vse slišjo in vsi se lahko poljubno pretvarjajo kaj so. Kako potem zagotoviš, da nekdo ne faka AP-ja in tako ne prestreza vsega prometa?
Poldi112 ::
Ne moreš - lastnik AP-ja itak vedno lahko posluša. Zato, če hočeš varnost na tujem AP-ju, uporabiš vpn.
Where all think alike, no one thinks very much.
Walter Lippmann, leta 1922, o predpogoju za demokracijo.
Walter Lippmann, leta 1922, o predpogoju za demokracijo.
denial ::
@fiction:
IMO je tole (stran 196, zadnji stavek):
Če je res to in je zadeva dokumentirana, pol s tehničnega vidika ne gre za bug, temveč za design flaw in zlorabo funkcionalnosti.
IMO je tole (stran 196, zadnji stavek):
If an attacker creates an MPDU with the spoofed TA, then the decapsulation procedure at the receiver will generate an error. GTKs do not have this property.
Če je res to in je zadeva dokumentirana, pol s tehničnega vidika ne gre za bug, temveč za design flaw in zlorabo funkcionalnosti.
SELECT finger FROM hand WHERE id=3;
fiction ::
Ne moreš - lastnik AP-ja itak vedno lahko posluša. Zato, če hočeš varnost na tujem AP-ju, uporabiš vpn.No ja to itak. Če ne drugega lahko potem, ko gre naprej od AP-ja po žici vse posniffa lastnik omrežja. Ampak tukaj je govora o tem, da se nekdo drug predstavlja kot rogue AP in potem lepo res pošlje stvari na pravi AP naprej. In tudi to se je pomoje dalo že prej.
Spock83 ::
No malo bolj resnim access pointom lahko določiš rouge AP. Za domačo uporabo pa je itak brez veze. Kdo pa ti bo šaril...
fiction ::
@fiction:Ja, ampak to še ni bug. Če imajo vsi isti GTK potem lahko nekdo nekaj pošlje v imenu nekoga drugega pa tega ne moreš odkriti. Se pravi za broadcast in multicast ne moreš biti prepičan glede izvora. V standardu je samo opisano to dejstvo. Ampak kot piše v novici je fora v tem, da se ti zdaj delaš, da si AP in nekaj broadcastaš pa dobiš nazaj PTK - ključ med določenim vozliščom in AP-jem. Tega prej nisi mel.
IMO je tole (stran 196, zadnji stavek):If an attacker creates an MPDU with the spoofed TA, then the decapsulation procedure at the receiver will generate an error. GTKs do not have this property.
Če je res to in je zadeva dokumentirana, pol s tehničnega vidika ne gre za bug, temveč za design flaw in zlorabo funkcionalnosti.
Pomoje gre za spoofan ARP request. Nazaj dobiš unicast ARP reply.
Oz. AP ga, ampak ti tisto tudi slišiš. In točno veš kako tisti paket izgleda, tako da lahko na podlagi tega dobiš PTK (known plaintext attack).
fiction ::
Hm očitno tale napad potem pomeni enostavno pasivno sniffanje ostalih uporabnikov na WLAN omrežju. Pri drugih napadih si se moral aktivno
boriti za to, da so odjemalci izbrali tebe kot AP in ne ta pravega.
Pa potem si moral posredovati promet naprej...
Ta mentaliteta eh, kdo ima pa čas, da se bo s tem ukvarjal je pomoje napačna. Po tej logiki lahko tudi na parkirišču pustiš odklenjen avto. Komu se bo pa dalo stikati.
boriti za to, da so odjemalci izbrali tebe kot AP in ne ta pravega.
Pa potem si moral posredovati promet naprej...
No malo bolj resnim access pointom lahko določiš rouge AP. Za domačo uporabo pa je itak brez veze. Kdo pa ti bo šaril...Hm? Zloben AP ti napadalec podtakne.
Ta mentaliteta eh, kdo ima pa čas, da se bo s tem ukvarjal je pomoje napačna. Po tej logiki lahko tudi na parkirišču pustiš odklenjen avto. Komu se bo pa dalo stikati.
denial ::
Ampak kot piše v novici je fora v tem, da se ti zdaj delaš, da si AP in nekaj broadcastaš pa dobiš nazaj PTK - ključ med določenim vozliščom in AP-jem. Tega prej nisi mel.
Poudarek je na "nekaj broadcastaš" kajti tisti nekaj bi lahko bil čisto legitimen request. Če ti sedaj pošiljaš GTK requeste, potem valda dobivaš PTK-je klientov. To je dokumentiran ferature.
SELECT finger FROM hand WHERE id=3;
Zgodovina sprememb…
- spremenil: denial ()
fiction ::
Jah, to da je v paketu, ki ga ti pošlješ source MAC naslov od access pointa ni ravno legitimno.Ampak kot piše v novici je fora v tem, da se ti zdaj delaš, da si AP in nekaj broadcastaš pa dobiš nazaj PTK - ključ med določenim vozliščom in AP-jem. Tega prej nisi mel.
Poudarek je na "nekaj broadcastaš" kajti tisti nekaj bi lahko bil čisto legitimen request.
Če ti sedaj pošiljaš GTK requeste, potem valda dobivaš PTK-je klientov. To je dokumentirano.V to se sicer nisem poglabljal, ampak a ni PTK vedno med parom entitet? Če ti komuniciraš z enim WLAN clientom bosta ti in on uporabila za komunikacijo med seboj en PTK. Ampak za komunikacijo z AP-jem boš pa ti imel en drug PTK npr. PTK1, on pa čisto tretjega - PTK2. Pri čemer AP oba pozna. Ti pa hočeš zdej dobiti PTK2 za dešifriranje tistega kar gre od njega na AP.
denial ::
Jah, to da je v paketu, ki ga ti pošlješ source MAC naslov od access pointa ni ravno legitimno.
Seveda ni. Vendar počakajmo razplet. Lahko se namreč zgodi, da bomo na koncu razočarani nad inovativnostjo "buga" :D
V to se sicer nisem poglabljal, ampak a ni PTK vedno med parom entitet? Če ti komuniciraš z enim WLAN clientom bosta ti in on uporabila za komunikacijo med seboj en PTK. Ampak za komunikacijo z AP-jem boš pa ti imel en drug PTK npr. PTK1, on pa čisto tretjega - PTK2. Pri čemer AP oba pozna. Ti pa hočeš zdej dobiti PTK2 za dešifriranje tistega kar gre od njega na AP.
Glede PTK in parom entitet bo verjetno držalo. Nisem preveril, zato ne bom trdil, vendar je ta način logičen. Sam vprašanja pa nisem razumel. Če se ti predstavljaš kot AP, torej pošiljaš spoofane GTK paketke, pol boš od klienta1 prejel PTK1, od klienta2 PTK2, itd.
SELECT finger FROM hand WHERE id=3;
Zgodovina sprememb…
- spremenil: denial ()
fiction ::
Pustimo se presenetiti.Jah, to da je v paketu, ki ga ti pošlješ source MAC naslov od access pointa ni ravno legitimno.Seveda ni. Vendar počakajmo razplet. Lahko se namreč zgodi, da bomo na koncu razočarani nad inovativnostjo "buga" :D
Sam vprašanja pa nisem razumel. Če se ti predstavljaš kot AP, torej pošiljaš spoofane GTK paketke, pol boš od klienta1 prejel PTK1, od klienta2 PTK2, itd.Ja, to je pomoje "običajen" napad, ki nima veze s tem nedavno odkritim. Gre za tekmovanje - ti moraš biti močnejši, prej prisoten etc. v primerjavi s pravim AP-jem, tako da se uporabniki povežejo raje s tabo. Po tem aktivno sprejemaš njihov promet, če ga ne pošlješ pravilno naprej (npr. pravemu AP-ju) gre v /dev/null.
Na to je letelo eno vprašanje prej. Od predpostavki, da se uporablja WPA-PSK in napadalec pozna passphrase: a lahko
ugotoviš ali komuniciraš s pravim AP-jem ali pa z zlobnim AP-jem?
Pri novem napadu je pa, vsaj kolikor jaz razumem, fora v tem, da ti ni treba tekmovati z AP-jem. Handshake se je že zgodil.
Clienti poznajo pravi AP, vse je kul. Če zdaj ti prideš, "jo, jaz sem AP, handshake with me" te vsi nekam pošljejo.
Ti ponarediš samo ARP request oz. nekaj kar se broadcasta in na kar ti ostali clienti odgovorijo. Bug oz. feature, ki je dokumentiran, je zdaj, da ker gre za broadcast izvor ni nujno pravi. To pa clienti ne upoštevajo in lepo veselo pošljejo nazaj AP-ju kriptiran unicast promet. Pravi AP bo tisto jasno sprejel, ampak ignoriral. Ker gre za radijsko omrežje ti tudi tisto slišiš, ampak načeloma tega ne moreš razumeti, ker je šifrirano. Point je pa zdaj v tem, da ker gre za odgvor na tisto kar si ti zahteval obstaja velika verjetnost, da točno veš kaj bi moral biti posamezen bajt v paketu.
Torej poznaš plain-text in slišiš cipher-text. Iz tega potem najbrž lahko izračunaš PTK med AP in tistim clientom.
In tako naprej za vsakega, ki odgovori. Zdaj lahko pasivno poslušaš, ni treba več tekmovati, vse skupaj je precej bolj stealth...
denial ::
Na to je letelo eno vprašanje prej. Od predpostavki, da se uporablja WPA-PSK in napadalec pozna passphrase: a lahko ugotoviš ali komuniciraš s pravim AP-jem ali pa z zlobnim AP-jem?
Hm, če lahko odkriješ ARP spoofing/rogue DHCP potem da, sicer pač ne. PSK ne zagotavlja "individualne zasebnosti" zato je nujna uporaba dodatnih mehanizmov (VPN, L2-isolation).
Mogoče pa ni treba spoofat GTK, temveč ga zgolj uporabiš:
"Now let me decode that paragraph for you. What it says is that pairwise (individual) keys used in 802.1X with both TKIP and AES encryption have a check in place to determine if the source (TA) is being spoofed or not. So, if an attacker pretends to be an AP and sends traffic, the wireless client will know. However, broadcast and mulitcast traffic sent using group keys (GTK) do not have a spoofing check. That means an attacker could use the group key and send a broadcast to other clients, posing as an AP and those clients won't know the difference." (Vir: KLIK)
SELECT finger FROM hand WHERE id=3;
Zgodovina sprememb…
- spremenil: denial ()
fiction ::
Mogoče pa ni treba spoofat GTK, temveč ga zgolj uporabiš:Ja, spoofas samo source, GTK je isti za vse v omrezju in ga kot je napisano samo uporabis. Tako lahko posiljas stvari kot da si AP
in broadcastas. Samo se zmeraj je trik v tem kaj lahko s tem dosezes. Ce hoces direktno videti odgovor mora
tudi cilj nazaj broadcastati, kar pa sigurno ne. No cisto mogoce, da lahko tako sprozis kaksen rekeying ali pa zahtevas shranjen kljuc. Ampak bolj verjeten je tisti scenarij, ki sem ga prej opisal.
To se sklada tudi z
Tako lahko odjemalec zlorabi GTK za tvorbo posebnega broadcast paketka, na katerega se drugi odjemalci odzovejo s pošiljanjem svojih zasebnih ključev..
Samo to, da direktno posljejo svoje zasebne kljuce se mi zdi malo neverjetno. Mogoce le izgleda kot da, ker jih je simpel ugotoviti.
denial ::
Nice example of design flaw abuse:
http://file.si/public/viewset/27422
L2|client|AP-isolation prevents it.
http://file.si/public/viewset/27422
L2|client|AP-isolation prevents it.
SELECT finger FROM hand WHERE id=3;
Vredno ogleda ...
| Tema | Ogledi | Zadnje sporočilo | |
|---|---|---|---|
| Tema | Ogledi | Zadnje sporočilo | |
| » | Huda ranljivost v vseh napravah z Wi-Fi (strani: 1 2 )Oddelek: Novice / Varnost | 25475 (20440) | SeMiNeSanja |
| » | Kdo visi na mojmu ruterju?Oddelek: Pomoč in nasveti | 1526 (1055) | mihec87 |
| » | Odkrita ranljivost v WPA2Oddelek: Novice / Varnost | 10055 (8376) | denial |
| » | Zaščita RouterjaOddelek: Omrežja in internet | 4989 (3924) | blackbfm |
| » | Wifi in prijavljanje v winXPOddelek: Omrežja in internet | 2112 (1784) | bluefish |