Názory k článku Odposlouchávání a prolamování Wi-Fi sítí zabezpečených pomocí WPA2
-
MilanK (neregistrovaný)
Kdysi jsem četl, že lze PSK zjistit (menší než hrubou silou) i tím, že přinutíme klienta (STA), aby se připojil na speciální falešné AP (se stejným SSID) - což dnes velmi rád udělá jakýkoliv notebook nebo telefon, když mu "nabídnete" jemu známý SSID.
Z popisu odvození klíče v článku to úplně jasně nevyplývá, ale už to, že se AP a STA "dohodnou" na klíči pouhými dvěma zprávami (sice se tomu říká 4-way, ale jak čtu, tak unicast klíč je známý už po 2 zprávách), je podezřelé. Na podobný problém (PSK -> session klíč) potřebuje IPsec 3 zprávy (a právě při povoleném zrychleném "handshake" ve 2 zprávách jde o známou slabinu IPsec v režimu PSK).
Pro mne tato informace tenkrát znamenala, že WPA2-PSK prostě není bezpečné: podstrčit "rogue" AP je v podstatě stejně těžké, jako pasivně odposlouchávat (ok, to je subjektivní názor, ale aspoň budete souhlasit, že nelze postavit zabezpečení jen na rozdílu obtížnosti mezi pasivním odposlechem a provozem rogue AP).
Může někdo rozvést, jak je těžké prolomit WPA2 PSK pomocí podvrženého AP? V článku jsem o tom při rychlém pročtení nenašel žádnou zmínku.
-
flack (neregistrovaný)
Ano chybne jasne ze vidis. Pretoze ten klient skutocne odosle ale nie heslo, odosle hash ten AP porovna a pretoze nesuhlasi, tak ho oznaci ako pokus s chybnym prihlasenim do site.
Este by ma zaujimalo ake AP spatne z hashu zisti co bolo na zaciatku funkcie. Prosim rozvedte to.
-
FE501 (neregistrovaný)
Hezký článek naštěstí nevysvětluje jak se skutečně prolamuje WPA šifrování, přes slovníky to sice jde, ale je to spíš o štěstí.
Pro příklad:
8 znaků pouze číslice 10^8/1800 = 925 minut
8 znaků malá písmena 26^8/1800 = 1933583 minutPři kombinaci malá velká písmena čísla a i o jeden znak víc je přes slovník pro běžné Frantu hackera nemožná. V každém případě spousta lidí má stále nastaveno datum narození což dobu prolomení značně zrychlí :-)
-
LP (neregistrovaný)
Skrývání SSID je problematické - klienti musí aktivně zjišťovat, zda není v okolí APčko se skrývaným SSID. Jméno SSID vysílají nejen v okolí Vaší sítě, ale všude. A kdokoliv může tyto informace odchytávat a shromažďovat.
Doporučuji k přečtení článek https://blog.nic.cz/2014/10/20/787-618-302-67-18-aneb-statistiky-jednoho-blazniveho-obeda/
-
Petr (neregistrovaný)
To jsem úplně nepochopil. Klient přece neví, která SSID jsou/byla skrytá a která ne, takže na jeho chování, jestli bude do světa troubit názvy konkrétních SSID nebo se dotazovat broadcastem, to nemá vliv, ne?
Takže skryté SSID requesty na konkrétní názvy nijak nezvýší a může to trochu pomoct proti prozrazení SSID před běžnými klienty, kteří by mohli síť uložit do nějaké db, použít název pro pokus o útok atd. Tj. já tam žádnou problematičnost nevidím. -
LP (neregistrovaný)Klient má k dispozici tři způsoby, jak zjistí, ke kterému APčku se může připojit:
- Pasivní poslouchání - APčka každých 100ms posílají informaci, jaká SSID podporují. Skryté sítě se neposílají.
- Aktivní skenování bez SSID (Null Probe Request) - klient vyšle Probe Request s nevyplněným SSID na broadcast adresu. Všechny AP v dosahu mu odpoví, jaká SSID podporují. APčka ani v tomto případě nevrací skrytá SSID.
- Aktivní skenování s vyplněným SSID (Directed Probe Request) - klient na broadcast adresu vyšle Probe Request s vyplněným SSID, odpoví pouze APčka, která podporují toto SSID - včetně skrytých SSID.
Další informace:
CWAP 802.11- Probe Request/Response
Debunking Myths: Is Hiding Your Wireless SSID Really More Secure? -
Sten (neregistrovaný)
Skryté SSID před útoky neochrání.
WPS by hlavně mělo být implementované tak, že je potřeba stisknout tlačítko na AP, aby se na pár sekund zaplo. Pokud útočník nemá fyzický přístup k routeru, tak je to bezpečné. Bohužel mnoho BFU-friendly routerů má zapnuté WPS pořád, a to se (vzhledem ke krátkosti PINu) louská snadno.
-
Rainbow tabulky se používají k výpočtu PSK, nikoliv PTK. Předpočítám si PSK na farmě GPU pro nejpoužívanější SSID a určitá hesla (krátká, slovníková apod.). Dále si vygeneruji PTK a poté budu počítat MIC druhé zprávy 4-way handshaku a porovnávat ho s právě zachyceným MIC.
Výhodou tudíž je, že vyhledání v předpočítáné tabulce je mnohonásobně rychlejší, než počítání 8096 SHA1 hashů pro výpočet jednoho PSK. A právě výpočet PSK pro všechny možné kombinace hesel je nejpomalejší částí algoritmu.
-
s (neregistrovaný)
chcete se tedy vyhnout tem 4k iteracim pri vypoctu PSK? Asi to stale nechapu, protoze rb-lookup bude jiste mnohem narocnejsi nez ty iterace samotne. Musite vypocitat chain, ktery sam o sobe bude mit jiste vic nez 4k prvku, ty pak tridit a hledat v 1TB souboru, ktery se asi do pameti nevleze a nejspis si pri tom sahnete na disk. Kde je uspora?
-
Vy ale v té RB tabulce nevyhledáváte. Pouze jste si předpočítal PSK pro dané SSID a všemožná hesla a následně tuto tabulku procházíte lineárně prvek po prvku. Spočítal jste si to tedy jednou, uložil a následně využil pro prolamování N sítí, kde všechny mají nějaké často používané SSID.
A číst prvek po prvku z nějaké datové struktury je jednoznačně znatelně rychlejší, než počítat 8192 SHA1 hashů.
-
s (neregistrovaný)
Michal Novák: Super! Uz tomu rozumim. Chytre! Rozsiril jste mi obzory, diky!
risototh: vyhledat v 1TB databazi jednoznacne = cteni z disku a to nejspis nebude rychlejsi nez 8000xSHA1 v pameti. Navic, rainbow-table ma k b-tree dost daleko. Doporucuji prostudovat, je to velmi chytra struktura: https://en.wikipedia.org/wiki/Rainbow_table
-
peci1Stříbrný podporovatelHmm, takze me podezreni ohledne "bezpecnosti" verejnych hotspotu s heslem bylo spravne.
Pak tedy vyvstava otazka, proc tu jeste nemame Open WiFi sifrovanou klicem vytvorenym pres Diffie-Hellman vymenu... Uroven bezpecnosti by byla stejna jako u WPA2-PSK, pokud utocnik zna heslo (coz v pripade kavaren atd. neni problem).
S pouzivanim VPN souhlasim a pouzivam, ale stale mi prijde extremne nebezpecne, ze v zadnem znamem OS neni mozne nastavit, aby se pripojil a IHNED pote se spojil pres VPN a do te doby neposilal nikam jinam zadne pakety. Ony jsou ty OS totiz velmi cile v posilani vsemozneho sajrajtu hned, jak zjisti, ze jsou online...
-
s (neregistrovaný)
IMO se to s tou VPN trochu prehani. Vsechny ty gmaily, facebooky, iCloudy jsou na HTTPS. Co konkretne se mi muze stat, kdyz pouziju WiFi v MC Donalds bez VPN? HTTPS nikdo neodposlechne a ty kokotiny na idnes.cz kam obcas kliknu, koho to tankuje? Snad tam nekdo muze podstrcit nejakej malware, ale s notebookem s linuxem se z nejakeho duvodu citim docela bezpecne.
Ostatne VPN jen presouva problem o kousek jinam. Vdycky se ty tvoje pakety nakonec dostanou na nejake draty, kde si je nekdo muze prohlednout. Snad v tom mekaci bude trochu vetsi audience. Ale implementovat novy standard s DH je IMO k nicemu. Zabezpeceni domaci wifi heslem je uplne dostacujici.
-
peci1Stříbrný podporovatel
Ta DH vymena nebyla myslena jako zvyseni zabezpeceni (i kdyz by prakticky asi byla), ale spis jako moznost uplne nekricet do sveta vsechno, co delas, i kdyz se nepouzije sdilene heslo (ktere, jak bylo v clanku ukazano, je prakticky k nicemu).
A k VPN - ty jsi jeste nikde necetl o verejnych hotspotech, ktere ti do webovych stranek pridavaji reklamu? A co kdyz to neni jenom reklama? Nactes si hloupy idnes, a pri trose "stesti" ti muze provozovatel AP ukradnout lecjaka zajimava data z prohlizece...
-
s (neregistrovaný)
Tak ono uz z pouheho faktu, ze WPA2 nepouziva asymetricke sifrovani je jasne, ze kdyz znas heslo, muzes i poslouchat.
Z prohlizece ukradne jen to, co slo po HTTP a to mi je celkem jedno. Ze mi tam ukaze reklamu... hmm... to preziju a dokonce si myslim, ze injectovat reklamu do stranek typu idnes tak, aby to nebylo na prvni pohled podezrele, je docela obtizna zalezitost. A kdyz pojmu podezreni, ze se neco takoveho deje, tak si tu VPN pro jistotu fakt zapnu.
Co mne tak napada, tak utocnik muze jiste zjistit IP kam se pripojuju, na HTTPS snad nekdy i domenu, ale jinak toho zas tak moc nezjisti.
No a taky je nutne dodat, ze ta VPN musi nekam vest. Takze VPN akorat meni audienci, ktera muze poslouchat.
Btw, mam ted v browseru otevreno asi 15 tabu. Vsechny jsou HTTPS a vsechny zelene zamecky. Tam nikdo nic nepodvrhne ani neodposlechne.
-
NULL (neregistrovaný)
"Vsechny jsou HTTPS a vsechny zelene zamecky. Tam nikdo nic nepodvrhne ani neodposlechne."
IMHO zelený rámeček je hezký, ale signalizuje pouze to, že certifikát je podepsán důvěryhodnou autoritou. To že není pro daný web, podvržený, neukáže. Viz. útok na bankovnictví České spořitelny přes výměnu certifikátů v uložišti browseru
-
s (neregistrovaný)
s tim nesouhlasim. Kdyz url sviti zelene, znamena to, ze ten kdo dany www server provozuje, mel moznost menit DNS, poslouchat na portu < 1024, nebo prijimat email na abuse@domena a to v dobe platnosti certifikatu. Proste to, co na seznam.cz nikdo neudela.
To, ze si nekdo poplete URL a misto ceskasporitelna.cz napise abcdwtf.cz, to je problem mezi zidli a klavesnici a nejaka VPN ti nepomuze.
-
NULL (neregistrovaný)
Když ti v browseru někdo vymění cert (třeba té spořitelny) za svůj a unese ti relaci (třeba na tu spořitelnu) MITM, tak ti to bude svítit zeleně. Stačí na to, aby ten jeho byl podepsaný nějakou autoritou kterou uznává tvůj browser - to je to proč je to zelené - jinými slovy, když použiješ LE nebo vlastní cert a nesvítí ti to zeleně, tak je podvrhnutý? Asi ne
-
j (neregistrovaný)
2s: Tudiz nemas ani paru o tom, jak certifikaty fungujou. Tvu browser bude spokojene zelenit pro zcela LIBOVOLNEJ certifikat LIBOVOLNY CA, ze seznamu, kterej ti importuje tvuj browser pripadne system. Takze kdyz budu provozovat CA, ktera bude ve tvym browseru, muzu si vydat cert pro zcela libovolnou domenu zcela kdykoli. Coz je treba zcela bezna vec u firemnich stroju - mas tam firemni CA, a admin si muze vydat cert klidne pro seznam.cz a tvuj browser bude spokojene ukazovat zelenej zamek.
Takze nezvan o veceh o kterych vis naprosto kulovy.
VPN ti pomuze v tom, ze znemoznis provozovateli ty wifi pristup ke svy komunikaci, takze ji dost tezko muze presmerovat na nejakou proxy.
-
NULL (neregistrovaný)
Ano ano, je to tak. Každopádně i VPN login se dá podvrhnout, ale to už je pak úplně jiný vektor a spíše konkrétně cíle ná záležitost. Nejsem si teď akorát jistý tím, že nejprve se musíš přihlásit k AP a pak teprve na VPN, tudíž v podstatě nebezpečný bod - přihlášení k VPN i tak přetrvává. Nehledě na to, že útočník by mohl být i unvitř VPN - třeba VPN vyskoké školy/nějaké větší organizace -> počet uživatelů . . . .
-
peci1Stříbrný podporovatel
Jenze browser bohuzel neni jediny software, ktery v pocitaci bezi. Co kdyz vam AP podvrhne systemovy cas fake timeserverem a pouzije ukradeny a revokovany klic k podvrzeni vaseho slavneho https... AP taky muze zkusit z paketu jinych protokolu (NetBIOS, Avahi...) rozpoznat vas OS a cilene na pocitac zautocit (nikdo totiz netvrdi, ze AP s SSID McDonald je opravdu to, ktere ma McDonald na strope, ale muze si ho vesele provozovat chlapik u vedlejsiho stolu). Takovych moznosti a problemu jsou mraky.
Kdyz se clovek spoji pres VPN, tak i "osklivemu" AP da minimum informaci, ktere muze jakkoli vyuzit (tady by silne pomohlo, co pisu - kdyby systemy umoznovaly VPN vyzadovat od prvniho paketu uspesneho spojeni).
Co se tyce preneseni duvery na "jiny konec dratu" - s tim nemam problem. Svemu domacimu poskytovateli (at uz je to Vodafone, O2, UPC nebo kdokoli jiny) proste musim bezmezne duverovat. A kdyz se pres VPN spojim domu, tak jsem na tom s duverou uplne stejne.
-
peci1Stříbrný podporovatel
Nicmene hostitelsky system bude nadale vesele otevrene komunikovat skrz AP.
-
Bob5 (neregistrovaný)
s- Souhlas.
Ja myslim, ze idealne je mit fyzicky zabezpecene wifi WPA2 silnym heslem doma, u nas asi idelane vyskladanym trochu vic cesky. Specialni znak schovany nekde uprostred prida extra vypocetni cas nutny k prolomeni (si myslim ;-)) proti vsem beznym slovnikum, ktere jsou vetsinou anglicky oriented.
Nejake (vetsinou placene) VPN uz resi bezpecnost na vyssi urovni, kdy clovek nekde na letisti v Syrii muze malicko obejit lokalni pravidla a konecne napsat kamaradovi v UK, ze uz je na ceste, ze. -
arote (neregistrovaný)
HTTPS je tutovka? Za WW2 britové používali rybaření. Zaminovali určitý čtverec a německé minolovky pak posílali zprávy, které britové dokázali mnohem snadněji dešifrovat díky znalosti čtverců, jinými slovy předem známý text. Pokud se připojíte na internetové bankovnictví (a těch tady nejsou milióny), pak pokud útočník má také účet u stejné banky, tak si může nahrát celou svou komunikaci. Ta posléze funguje jako předem známý text pro snadnější určení klíče - záleží na implementaci co, kde a čím se šifruje. Polopatě z předem známé zprávy a metody lze snadno určit šifrovací klíč. Pak asi budete doufat, že vás zachrání sms na mobil, ale v okamžiku, kdy znají pozici vašeho mobilu, jsou schopni odposlechnout i zprávu sms a pak aleluja.
-
vs (neregistrovaný)
No a co mu podstrčit na chvíli fakeAP s ne s WPA2 PSK, ale s nějaký prolomeným algoritmem (WEP), v tu chvíli uživateli naskočí okýnko "zadej heslo k WiFi", což logicky udělá, a v tu chvíli přečíst a dekodovat a shodit fakeAP (aby to nevypadalo podezřele)
A pokud klient nemá penvě nastaveno "JEN WPA2" (což např Win fakt nemají a netuším, zda to jde ovlivnit), tak je heslo doma... -
FLEK. (neregistrovaný)
Většina systémů, pokud vím, pousuzuje sítě se stejným SSID ale různým algoritmem jako oddělené sítě. Tj, pokud budu mít ve vzduchu síť 1) se SSID "abc" a WPA-2(-PSK), 2) se SSID "abc" a WPA-1(-PSK), 3) se SSID "abc" a WEP a 4) se SSID "abc" a otevřenou, tak se mi to zobrazí jako 4 nezávislé sítě a pokud už budu připojen do jedné, tak se systém nebude pokoušet přepojit se do druhé. Tak to má Windows a tak to má i Netvor-Manager.
(Ovšem, jak je to s šifrováním AES vs. TKIP to nevím, pokud si vzpomíním, je možné použít WPA-2 s TKIP a WPA-1 s AES - což ale není standard, ale spousta zařízení to podporuje...)
ČLÁNKY DO MAILU