SSHv2 i TLS (což je realizace toho S v HTTPS) ověřují obě strany pokud vím, takže ano, přesně MITM na WiFi nebo kabelu řeší v návrhu. Ideje SSH i HTTPS je, že právě i přes nezabezpečené médium poskytují rozumnou míru důvěry (tedy za předpokladu, že neznáte nějaký efektivní algorithmus pro rozklad velkých čísel na prvočísla nebo diskrétní logaritmus atp.). https://en.wikipedia.org/wiki/Computational_hardness_assumption
@Filip Jirsák
Jenomže certy bank máš v browseru. Existují weby, jejihž certifikáty nemáš v browseru a dokonce umožňují i přihlášení nebo dotazy http/https, tedy MITM se ti klasicky někdo tváří jak HTTPS a sám to přeposílá jako HTTP. Já ostatně netvrdil, že to funguje vždy a všude.
https://stackoverflow.com/questions/14907581/ssl-and-man-in-the-middle-misunderstanding
"Technologie HSTS dokáže odstranit problémy se SSL-stripping man-in-the-middle útokem, který byl poprvé publikován Moxie Marlinspikem v roce 2009 na BlackHat Federal talk pod názvem „New Tricks For Defeating SSL In Practice“.[8] SSL-stripping útoky (na SSL a TLS) transparentně převádějí zabezpečený HTTPS připojení na nezabezpečené ...."
[https://cs.wikipedia.org/wiki/HTTP_Strict_Transport_Security]
To už jsou s OWASPEM a https://www.krackattacks.com/ další 2 kteří to mají špatně, tedy nevylučují že HTTPS lze MITM zneužít ....
Jenomže certy bank máš v browseru.
Ne, já certifikát žádné banky v prohlížeči nemám. V prohlížeči mám certifikáty uznávaných certifikačních autorit, občas tam mám certifikát nějaké své testovací certifikační autority, mám tam i několik certifikátů webových serverů, ale to nejsou weby bank – protože všechny banky, které mne zajímají, mají certifikát od nějaké důvěryhodné autority.
tedy MITM se ti klasicky někdo tváří jak HTTPS a sám to přeposílá jako HTTP
No, to už jste se zase dostal úplně mimo oblast, o které byste něco tušil, a je to čiré básnictví.
To už jsou s OWASPEM a https://www.krackattacks.com/ další 2 kteří to mají špatně, tedy nevylučují že HTTPS lze MITM zneužít
Nic nemají špatně, to akorát vy tomu textu nerozumíte.
HTTPS není žádná neprůstřelná technologie, má nějaké předpoklady, za kterých funguje, a když předpoklady nejsou splněné, např. je uživatel ignorant, technologie to nezachrání. Ale to nijak nesouvisí s tou dírou ve WPA2. Ta díra ve WPA2 znamená jenom to, že někdo může Wi-Fi komunikaci nabourat stejným způsobem, jako ji může nabourat když jste připojený drátem a útočník vytáhne drát na druhém konci ze switche a připojí ho do svého switche, nebo prostě jen ovládá nějaký router po cestě.
Z hlediska internetové komunikace to zkrátka není nic nebezpečného, protože na internetu se předpokládá, že útočník může komunikaci sledovat i s ní manipulovat, takže bezpečnostně důležitá komunikace je šifrovaná, například zmíněným HTTPS. Větší průšvih je to v místních sítích, protože tam se to často bere, že místní síť je bezpečná. Což teda v případě SOHO sítí málokdy platí, Wi-Fi síť by mne teprve nenapadlo považovat za bezpečnou, ale jsou lidé, kteří té bezpečnosti věřili. Tam to může být problém, třeba pokud někdo prohlašoval, „to je intranet, to je v bezpečné síti, tam není potřeba HTTPS“.
Jo Jirsáku, poslouchat se dá i po kabelu, ale nemůže to u mě a ISP + trasa jen tak udělat nějaké sousedovo 13leté dítě jako potenciálně nyní s dírou ve WPA2. Byť nejspí jako scriptkiddie. Já je ale nepodceňuji ....
To, že HTTPS je 100% ochrana proti MITM jsi tvrdil ty a to jsem ti vyvrátil. To že to tak bylo navrženo je hezké, ale to je tak všechno. Samozřejmě není a linky na to máš. Tak nepindej.
Jo, pravda, chytil jsi mě za slovíčko, v browserech jsou certy CA které dále vystavují certy bankám a pod. To ví každé malé děcko, netušil jsem že i to ti budu muset potvrdit .... No, nedá se, občas zapomenu co jsi zač ...
"
tedy MITM se ti klasicky někdo tváří jak HTTPS a sám to přeposílá jako HTTP
No, to už jste se zase dostal úplně mimo oblast, o které byste něco tušil, a je to čiré básnictví.
"
SSL-Stripping kdyby tě to zajímalo ... je to popsané v jednom z těch linků. Mohl ses podívat ...
Filip Jirsák Dnes 13:08
protokoly HTTPS nebo SSH byly navržené právě proto, aby znemožnily tento typ útoků MitM, tedy případy, kdy útočník má pod kontrolou síť. Proti těmto typům útoků chrání perfektně, na 100 procent.
Filip Jirsák Dnes 18:36
"HTTPS není žádná neprůstřelná technologie, má nějaké předpoklady, za kterých funguje"
Vida, aspoň trochu ses poučil ....
V TLS je ověření klienta volitelné a třeba u HTTPS se používá velmi málo. Serveru je obvykle jedno, s jakým klientem komunikuje, nebo si ho ověří jinak, než přes TLS (třeba přihlášením jménem a heslem). Klient potřebuje server ověřit vždy – bez toho by si nemohl být jist, že nekomunikuje s útočníkem, který mu podvrhne falešné informace nebo získá důvěrná data.
A hele, jirsakovo blabolivy kolecko zas v akci, hele jirsak, ukaz mi JEDINEJ browser, kterej overuje (nebo vubec umoznuje overit) server. Zadnej takovej neexistuje co? Spokoji se s libovolnym klicem libovolny CA kterou mu podobnej mamlas jako TY predhodi ze? Takze kdyz mu ten CA cert predhodim rebas ja, tak bude pekne drzet hubu a bez problemu mi na proxy posilat data ze? Prave proto, ze bezpecnost https je presne zadna.
Jo, vono by to sice slo do jisty miry vylepsit, trebas za pouziti DANE, ale misto toho se vymysli ubersmirovaci technika ... budem posilat dorazy na otisk kazdyho jednoho klice do nejaky guugli databaze ... to aby guugl presne vedel nejen na kerej web se leze, ale i zcela konkretni stranku ...
Prohlížeče ověřují, zda jméno na certifikátu souhlasí s požadovaným jménem webu, ověřují, že je certifikát platný, ověřují, že ho vydala důvěryhodná certifikační autorita. Důvěryhodné certifikační autority dávají vydané certifikáty do Certificate Transparency listu. Takže platí, co jste napsal – že když prohlížeči předhodíte falešný certifikát vydaný důvěryhodnou certifikační autoritou, prohlížeč ho bude akceptovat. Zapomněl jste ovšem dodat jeden „drobný“ detail – že takový certifikát nezískáte, ani kdybyste se na uši stavěl. Což ještě vůbec nic neznamená, ale oni ten falešný certifikát nezískají ani ti, kteří tomu opravdu rozumí. (Pro pomaleji chápající rovnou vysvětluji, že předchozí věty neznamenají, že to nejde.) Vaše tvrzení je tedy asi na takové úrovni, že bankovní trezor je úplně k ničemu, protože když znáte kombinaci, dovnitř se pohodlně dostanete.
Takze presne jak sem rek, jirsak opet blaboli ...
Cert s libovolny jmenem si vygeneruje kdo chce. Browseru je uplne JEDNO, kdo ten cert podepsal. Jestli je cert revokovanej nebo neni je mu taky uplne JEDNO, protoze kdyz se mu nepovede pripojit tam kde to ma overit, tak to povazuje za OK.
A takovych certifikatu se po netu povalujou desitky tisic, a pravidelne se to minimalne jednou rocne nekde proflakne. Coz jirsak samo naprosto ignoruje.
Mimochodem jirsak, ziskat "duveryhodny" certifikat podepsany trebas Le je zcela trivialne primitivni. To ty samo nemuzes pri svym IQ houpaci zidle tusit, protoze bohate staci, kdyz si nekde cestou lehce forwardnu traffic a "neco" vystavym na "svym" webu. A voiala, razem mam "duveryhodnej" a zcela platnej certifikat. Zazrak co? Mimochodem jirsak, jak myslis ze "vyrabi" ty Leckovy certifikaty libovolnej hosting.
Jéčko, při své nekonečné genialitě jste poněkud přehlédlo skutečnost, že vymyslet, jak rozhodnout, kdo z nás dvou blábolí, může i někdo s IQ houpací židle.
Takže předpokládám, že tady do zítřka do oběda bude certifikát vystavený na doménu root.cz, který bude akceptovat aktuální Chrome nebo Firefox ve výchozí konfiguraci, spolu s nějakým důkazem, že držíte privátní klíč od toho certifikátu (např. jím něco podepíšete). Pokud by se snad přihodilo, že by tu takový certifikát nebyl, nezbyde než to považovat za důkaz, že Jéčko je obyčejný tlučhuba, který si vymýšlí až se mu od klávesnice práší.
Nikoli, šifrované protokoly se používají právě proto, aby nezáleželo na tom, jakým komunikačním kanálem data putují. Pokud má někdo možnost manipulovat s daty WiFi spojení, může vám HTTPS nebo SSH spojení zrušit, ale nemůže do něj vložit svá data ani nemůže odposlechnout obsah spojení. Samozřejmě pokud bylo spojení bezpečně navázáno – ale k tomu slouží ověřování certifikátů protistrany při navazování spojení.
O https bych spíš prohlásil že byl navržen proto, aby poskytl iluzi bezpečí a zamnaskova a zjednodušil MitM útok pro vyvolené subjekty (každý, kdo má přístup k důvěryhodné CA, tj. zejména všechy trojpísmenkové organizace). MitM útok na https (a další protokoly založené na stromu důvěry) je běžnou funkcionalitou korporátních firewalů.
Jenže tohle se nedá dělat ve velkém, protože by se na to velmi rychle přišlo. Například EFF má projekt SSL Observatory, který sbírá platné certifikáty nalezené na internetu. A již velmi brzy bude nutné, aby byl certifikát zveřejněný v otevřeném registru, aby byl platný. Takže jen tak někomu neprojde, aby si nechal pomocí pistole/zákona vystavit certifikát na libovolnou doménu. Legitimní majitel si toho všimne.
2Petr Krčmář
"A již velmi brzy bude nutné, aby byl certifikát zveřejněný v otevřeném registru, aby byl platný"
Jo to urcite, kazdej bude nadsene posilat nejaky interni certifikaty do nejakych pekel horoucich aby mu neco vevnitr fungovalo ... a kazdej browser bude pri nacteni kazdy stranky posilat 100 dotazu ... nebo sebou potahne databazi par mililard certifikatu?
A co si zjistit, jak Certificate Transparency funguje? Každá certifikační autorita má URL, kde vystavuje certifikáty v Merkle hash tree. Pokud máš interní CA pro interní certifikáty, tak můžeš certifikáty zveřejňovat na interní URL a nikam ven je posílat nemusíš. Navíc se tohle momentálně týká jen EV certifikátů, které interní autority stejně většinou nevystavují. Ale i kdyby vystavovaly nebo se to týkalo všech certifikátů, tak interní certifikáty stačí vystavit jen interně.
Navržené to pro to klidně mohlo být. To ale nic nevypovídá o tom, jestli je i přesto možné to zneužít. Mezi "navržené pro" a "praktické využití" může být propastný rozdíl. Např. auto je taky navržené pro to, aby tě spolehlivě a bezpečně dovezlo na místo a všichni víme že tomu tak občas prostě není ...
MitM útok na https je běžnou funkcionalitou korporátních firewalů.
Ano, jenže ten útok korporátního firewallu je založený na tom, že k tomu firemnímu počítači má administrátorská práva někdo, kdo spolupracuje s tím firewallem.
Pokud má na vašem počítači administrátorská práva útočník, nějaká chyba ve WPA2 je pro vás ten nejmenší problém.
zamnaskova a zjednodušil MitM útok pro vyvolené subjekty (každý, kdo má přístup k důvěryhodné CA, tj. zejména všechy trojpísmenkové organizace)
Útočit na HTTPS přes certifikační autority by od těch trojpísmenkových organizací byl hodně hloupý nápad. Znamenalo by to totiž vydat jiný certifikát na doménové jméno a nechat ho podepsat nějakou CA. Existuje dost nástrojů používaných např. v prohlížečích, které hlídají certifikáty nezávisle na certifikačních autoritách – třeba plugin certificate patrol, který vás upozorní, pokud se certifikát liší od minule. Takže je dost pravděpodobné, že by někdo takový podvržený certifikát vyhmátl – a tím pádem by měl v ruce nevyvratitelný důkaz, že příslušná CA vydala podvržený certifikát. Taková věc se okamžitě medializuje, příslušná CA musí vysvětlit, jak k tomu došlo a jaké podnikne kroky k nápravě. Pokud jsou problémy opakované, správci seznamů důvěryhodných autorit příslušnou autoritu vyřadí – za poslední rok se to stalo dvěma autoritám. Třípísmenkové organizace o takovou publicitu rozhodně nestojí.
@Filip Jirsák
Our attack is not limited to recovering login credentials (i.e. e-mail addresses and passwords). In general, any data or information that the victim transmits can be decrypted. Additionally, depending on the device being used and the network setup, it is also possible to decrypt data sent towards the victim (e.g. the content of a website). Although websites or apps may use HTTPS as an additional layer of protection, we warn that this extra protection can (still) be bypassed in a worrying number of situations. For example, HTTPS was previously bypassed in non-browser software, in Apple's iOS and OS X, in Android apps, in Android apps again, in banking apps, and even in VPN apps.
Mimochodem to teda asi mají špatně i v odkazu v článku. Měl bys je upozornit že to mají špatně
In general, any data or information that the victim transmits can be decrypted.
To se ovšem týká dat šifrovaných WPA2. Opravdu to neznamená, že by se tím nějak zázračně prolomily i všechny známé i neznámé šifry komunikačních kanálů přenášených přes ten Wi-Fi kanál.
Mimochodem to teda asi mají špatně i v odkazu v článku. Měl bys je upozornit že to mají špatně
Ne, nemají to špatně. Chyba je na vašem přijímači.
Jsou ta i další věty, celé se to jmenuje odstavec. Ale co, linků jsi už na to, že HTTPS není 100% ochrana jsi dostal dost ....
Vy mě opravdu těžko můžete poučovat o fungování HTTPS. Pokud jste poznal, že je mezi námi propastný rozdíl ve znalostech o HTTPS, pak jste to poznal správně – akorát jste možná špatně odhadl znaménko toho rozdílu.
Já jsem nikde nepsal, že HTTPS je 100% ochrana. Já jsem pouze uváděl na pravou míru tenhle váš blábol: „jenomže když budeš mít někoho MITM na té WIFI, tak ti to moc nepomůže, právě proto že je to nad tím, ne?“ Vysvětlil jsem vám, že HTTPS slouží právě jako ochrana komunikace procházející nezabezpečenou sítí. HTTPS předpokládá, že síť pod ním je zcela nezabezpečená, tj. útočník může veškerou procházející komunikaci číst i modifikovat. Samozřejmě, že jsou různé způsoby, jak zaútočit na HTTPS, ale to jsou útoky na HTTPS, ne na WPA2. HTTPS se na WPA2 žádným způsobem nespoléhá, a pokud chcete mezi HTTPS a WPA2 hledat nějaký vztah, pak lze vymyslet jediný – HTTPS je od začátku stavěné tak, jako by WPA2 bylo prolomené, stejně jako HTTPS od začátku předpokládá, že na druhém konci vašeho ethernetového kabelu má útočník svůj switch nebo jako od začátku předpokládá, že útočník ovládá každý router po cestě.
Dál s vámi nemíním ztrácet čas, abyste si rozšířil svoje znalosti, stačí vám prozatím bohatě třeba Wikipedie.
Filip Jirsák Dnes 18:56
Já jsem nikde nepsal, že HTTPS je 100% ochrana.
Hmmm, tak to se bude asi odborník na https divit:
Filip Jirsák Dnes 13:08
Pro vás to zjednoduším – protokoly HTTPS nebo SSH byly navržené právě proto, aby znemožnily tento typ útoků MitM, tedy případy, kdy útočník má pod kontrolou síť. Proti těmto typům útoků chrání perfektně, na 100 procent.
Ostatně v jednom s těch linků máš SSL-Stripping a ten funguje když je někdo MITM .... Netvdím ale že to je jediný možný útok ....
@Filip Jirsák
Opravdu?
"The MITM attack could also be done over an https connection by using the same technique; the only difference consists in the establishment of two independent SSL sessions ..."
https://www.owasp.org/index.php/Man-in-the-middle_attack
Asi bys měl napsat na OWASP a poučit je ...
Tak znovu a polopaticky.
Paket = dopis
WPA2 = obálka
HTTPS, ... = zašifrovaný text dopisu. Šifrovací a dešifrovací klíč se liší a nikdy se neposílá poštou.
Co se stalo je, že teď někdo může otevírat obálky, občas dopis přidat a nebo stopit. To ale nic nevypovídá o jeho schopnosti šifrovat nebo dešifrovat text v obálce a schopnost příjemce zjistit, že kus textu chybí nebo přebývá... Toť vše.
To: OWASP
Vážení,
mám vás prý poučit, abyste si dávali větší pozor, co píšete na web. V ČR máme jednoho takového exota, který nedokáže rozpoznat rozdíl mezi popisem obecného principu, ke kterému ani nemusí být známa praktická realizace, nebo je velmi obtížná – a popisem konkrétní situace. Například máte na webu popsaný princip útoku typu MitM, a dotyčný rozumbrada si myslí, že je to popis konkrétního útoku. Teď nejspíš vyměřuje pravítkem na glóbusu, kde je prostředek jeho cesty do školy. Až tam bude zítra stát a divně se rozhlížet okolo, právě přemýšlí o tom, jak pozná, že už ten školní server shodil. To se budou všichni divit, jaký on je expert! Ještě že se nenarodil jako holka, ty MitM útoky dělat nemůžou…
Je možné, že se na vás v nejbližší době obrátí vedení jeho školy a bude po vás chtít vysvětlení incidentu, při kterém jeden jejich žák natřel všechny židle sekundovým lepidlem, a když měl incident vysvětlit, ukázal vedení školy vaši stránku o útoku „session fixation“. Útoků hrubou silou se naštěstí bojí, protože už pár takových zažil a nikdy nebyl v roli útočníka.
Článek o útoku typu „Trojský kůň“ na webu naopak klidně můžete ponechat. Výběh koní v trojské zoo je dobře zabezpečen, a z Troje to není daleko do Bohnic.
S úctou
tak uz toho nechte, je to trapne.
kazdy kdo tomu rozumi a chce se tou srackou procitat ma jasno, kdo z vas se kde prepsal. podle vasich reakci tomu rozumite oba +- stejne.
ostatni jen klikaji up/down vote podle toho jak kazdemu z vas fandi.
jen vase erudovane ega to nedokazou prejit.
wpa2 jde cist, sem tam podvrnout.
https jde semtam prolomit jen to neni jadrem aktualne diskutovaneho problemu.
tech chyb je tam popsano vice,proto si tupuji ze tech use-case bude vice.
vime ze je je chyba zpetne kompatibilni a jedna opravena strana muze komunikovat s neopravenou stranou.
zajimalo by mne jestli staci pro spravne zabezpeceni opravit klienta napadeneho AP nebo se musi opravit i AP?
<toto_je_vtip>
KDO NEPORUSUJE ZAKONY A NEDELA NIC SPATNE, NEMUSI SE BAT A PROTO MU JE WPA2 JEDNO
</toto_je_vtip>
O možnost vstoupit do komunikace a podvrhávat obsah. Jedna věc je, že se koukáte na web banky přes https, druhá věc je, jestli se vůbec koukáte opravdu na web banky... Jestliže šlo vstoupit do komunikace, mohl jste dostat při konfiguraci přes DHCP podvržené DNS servery a ta stránka "vaší banky" může být její kopie někde v Číně/Rusku... Takže sice komunikujete šifrovaně, ale s úplně jiným serverem...
Jedna věc je, že se koukáte na web banky přes https, druhá věc je, jestli se vůbec koukáte opravdu na web banky...
Nikoli, to se normálně nepovažuje za dvě věci. Ověření protistrany se považuje za součást šifrování komunikace, protože kdybyste si neověřil protistranu, můžete komunikovat hezky šifrovaně, ale s útočníkem – přesně jak jste popsal.
K ověření protistrany slouží v HTTPS certifikáty. Protistrana vám posílá certifikát a data podepíše privátním klíčem odpovídajícím tomu certifikátu. Vy si na základě toho certifikátu ověříte, že komunikujete s tou správnou protistranou – obvykle to za vás dělá váš webový prohlížeč, který ověří, že na certifikátu je stejné doménové jméno, se kterým chcete komunikovat, a že certifikát podepsal nějaká certifikační autorita, kterou máte v prohlížeči na seznamu důvěryhodných autorit.
Pre hruby popis OK ale v principe by to nestacilo. Certifikat overuje ze public key v certifikate zodpoveda domene a na tej domene je private key ktorym sa overi ze naozaj komunikuje s niekym kto vlastni private key k tomu public key v certifikate. Takze MITM attack sa bez private key urobit neda.
Nejenom to, WiFi se používá i pro ty slavný IoT fekálie a ty jsou tak vyhnaný kozí branou a ořezaný, že vrchol bezpečnosti je http a telnet :Q. Je to přece v lokální síti, tam nikdo nemůže, že...
Bastly s Arduinem/Raspberry taky, tam je přece nešifrování otázkou cti a hrdosti.
Ale po tomhle je útočník za firewallem, má NAS (SMB), tiskárnu, odposlech hesel od administrace. A jak chytne hesla, může cokoliv... Skouknout kamery, vymazat nepohodlný kus záznamu, upravit nebo kopírovat soubory na sdílených diskách, cvičně si vypnout firewall,... Cokoliv.
Btw, i Turris má na obou web rozhraních (Foris i Luci) jenom HTTP :(
Jeste ze tak ... kdyby to totiz umelo https, tak bys musel co mesic ten HW zahodit a vymenit, protoze by se nekdo rozhod, ze to sifrovani ktery to umi, neni dost bezpecny.
Jen by me tak zajimalo, jestli soudruzi trebas v M$ kdyz uz teda maji ten patch, taky znemoznej pripojeni ke vsem neopatchovanym APckum.
Je od nich pěkné, že se podělili s výrobci routerů, kteží na to valnou většinou zvysoka.. . Ale uživatelé nezávislé varianty, kterým o bezpečnost jde především si mohou počkat.
nedozvi. idealne nikdy.
vetsine lidi (pokud nejste napr. celebrita), kdyz slohnete data, nabourate sit, tak nechcete aby se o tom dovedel. vytezite informace a hotovo.
stejne jako kdyz vyloupite banku, take nechcete aby to nekdo vedel.
to je casta mylka tech co si mysli, ze kdyz si mysli, ze se jich to netyka, tak ze se jim to nestalo.
nejlepsi je, kdyz si vsichni mysli, ze se jim to nemuze pro jejich nezajimavost stat.
Zdravím, jsem zmaten.
https://www.krackattacks.com/#faq
What if there are no security updates for my router?
Our main attack is against the 4-way handshake, and does not exploit access points, but instead targets clients. So it might be that your router does not require security updates. We strongly advise you to contact your vendor for more details. In general though, you can try to mitigate attacks against routers and access points by disabling client functionality (which is for example used in repeater modes) and disabling 802.11r (fast roaming). For ordinary home users, your priority should be updating clients such as laptops and smartphones.
Znamená to, že běžné AP s vypnutou funkční klient a vypnutím roamingem jsou v "poho" ? Díky
Ale to je pak ten největší problém, ne? Nemám problém aktualizovat, nebo v horším případě vyměnit router, ale doma mám další hromadu krabiček, kterou nezaktualizuji už nikdy. Různé čínské tablety, telefony, IoT krabičky, TV, ... .
Když k tomu útoku dojde, narušuje to bezpečnost komunikace mezi jedním konkrétním klientem a AP, nebo to otvírá celou sít a zdiskredituje i komunikaci ostatních klientů a AP, i když už jsou třeba aktualizovaní?
Poskytovatelé internetu přes wifi nic takového raději neřeší, protože jakékoli zabezpečení jen zpomaluje síť a komplikuje život. Není nad to sednout si pod takový spoj s mobilem, a počkat, až se někdo zkusí připojit na switch telnetem, a použije přitom master heslo.
Píšu z adresy právě takového poskytovatele.
Zatím asi nejlepší shrnutí důsledků, co jsem našel:
http://blog.erratasec.com/2017/10/some-notes-on-krack-attack.html
A co MFP? Šifruje řídící rámce, takže klient nebude poslouchat cizí pokyn k odpojení.. Bohužel, je to "optional" rozšíření, takže krom Intel WiFi karet, jsem to jinde neviděl. Více třeba tady: https://www.cisco.com/c/en/us/td/docs/routers/access/3200/software/wireless/3200WirelessConfigGuide/ManageFrameProt.pdf
Nevím, zda tomu rozumím správně, prosím o potvrzení/odmítnutí:
Všechny tři body máte v zásadě správně.
První bod je trošku jinak, bezpečnostně se k tomu sice musíte chovat jako k veřejné síti, ale přeci jen není úplně pravděpodobné, že by útočník zaútočil zrovna na vaši síť, protože ten útok snad ještě není úplně na lusknutí prstu. Na druhou stranu není pravda, že by útok umožnil data jenom odposlouchávat, v některých případech může do komunikace i vstupovat (v lepším případě vám jen ukončí spojení, v horším případě vám vloží něco ošklivého do načítané webové stránky nebo vás přesměruje na svůj web).
Akorát bych i před tímto útokem považoval domácí síť za bezpečnostně srovnatelnou s tou veřejnou nezaheslovanou sítí (kavárna, vlak, obchodní centrum). Protože v té domácí síti máte nejspíš zařízení, o kterých z bezpečnostního hlediska nic nevíte. Nejspíš tam budete mít nějaké telefony nebo tablety své a svých příbuzných, možná i nějakých přátel. Asi si nemůžete být jist, že někdo na tom telefonu nemá nainstalovanou nějakou havěť, protože bůhví, jak s tím telefonem zachází. Nejspíš v té domácí síti máte také nějaké počítače s Windows, kde je každý sám sobě administrátorem – pokud jsou to alespoň Windows 10 se zapnutými aktualizacemi a jsou tam zodpovědní uživatelé, kteří neinstalují všechno, co najdou na internetu, možná by se o nějaké bezpečnosti dalo mluvit – ale jste si opravdu jistí, že se tak chovají všichni doma? No a pak v té síti také můžete mít nějaká další síťová zařízení, router, Wi-Fi AP, NAS, webovou kameru – a ta byla nejspíš velmi děravá už v době, kdy jste si je kupoval.
Takže i v domácí síti se chovejte obezřetně. Pokud kontrolujete webovou adresu a jméno certifikátu, odposlechu se bát nemusíte – za předpokladu, že útočník nenapadl váš prohlížeč nebo operační systém. Pokud třeba nainstalujete s administrátorským oprávněním nějaký útočníkův trojský kůň, může prohlížeč klidně upravit tak, že vám namaluje zelený certifikát se zlatým písmem, ale nebude to mít nic společného s tím, co prohlížeč dělá doopravdy.
Druhý nezávislý kanál pro potvrzení operace (SMS s potvrzovacím kódem) je velmi dobrý způsob zabezpečení, útočník by musel ovládnout oba kanály. Ale pozor na to, že to opravdu musí být dva nezávislé kanály – pokud do banky polezete z mobilního prohlížeče na tom stejném mobilu, na který vám pak přijde ta potvrzovací SMS, ty dva „nezávislé“ kanály jste zase zpátky sloučil do jednoho.
> v lepším případě vám jen ukončí spojení
To je asi nejméně zajímavé využití KRACKu, toto může útočník mnoha způsoby i bez nněj
BTW, jakkoli zabezpečená síť je celkem k ničemu, pokud si nejste jist, že jste připojen ke správné síti. (Vizte třeba https://www.wifipineapple.com/ ). A i pokud to ověříte a zajistíte po celou dobu spojení, měl byste vyloučit útoky jako browser cache poisoning. Takže jinými slovy, většinou nemá smysl se na bezpečnost sítě spoléhat a je tp lepší řešit na jiné vrstvě.
To záleží, jaký algoritmus v tom WPA2 používáte. Pokud AES a váš klient neobsahuje workaround proti tomuto útoku (nové verze wpasupplicant jej již mají), tak všechny body platí. Pokud něco jiného, tak útočník může pakety i podvrhávat a v zásadě se může i připojit, pokud sežene klienta, za kterého se může vydávat.
To neni zadna "katolicka skola," ale KU Leuven (https://www.kuleuven.be/english/about-kuleuven/) je jedna z nejlepsich a nejstarsich Evropskych univerzit.
Gentoo vydalo opravu (wpa_supplicant-2.6-r3)
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=319c86d1f048618da77824081843a43f049eadb5
patch pro Ubuntu a jeho deriváty je už taky k dispozici
https://usn.ubuntu.com/usn/usn-3455-1/
MalejMěkkej to už asi taky potajmu vydal
https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2017-13080
Jelikož se zranitelnost týká převážně klienta, pomohlo vůbec nějak to že jsem zaktualizoval všechny Mikrotiky a už čekám jen na ten Turris. Ochrání AP toho klienta?
Nebo je nutné opravit všechny klienty pro ochranu mojí sítě? To vzhledem k aktualizační politice firem co dodávají levnější telefony asi jen tak nebude...
Ne. Útok je prováděn právě na klienta.
A vzhledem k androidům - velice zákeřná chyba, která tu s námi bude ještě hodně a hodně dlouho.
Oprava AP může pomoci jen v takových případech, kdy je samo klientem (nějaké ty repeater módy, WDS). A i tak tím opravíme jen to jedno, nikoliv připojující se klienty.
rofl, četl někdo tenhle bullshit? https://www.letemsvetemapplem.eu/2017/10/17/apple-zabranil-desifrovani-wpa2/
Arch Linux je už tiež zaplátaný: https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/wpa_supplicant&id=9c1bda00a846ff3b60e7c4b4f60b28ff4a8f7768
Tak si říkám, že frikulíni s domácí automatizací s ESPčkama jsou právě v pr... :D :D :D
Ono stačí jenom vynutit restart spojení, nahrát login na šifrovanou WiFi a nějakou dobu sledovat, jaká zpráva je spojená se začátkem/koncem otáčení plynoměru. Jak má člověk jistotu, který dva pakety to jsou, stačí vyhodit ze sítě termostat, ten se přihlásí s jiným NONCE. Druhý shození, přehrát mu patřičný krok z vlastního záznamu a můžu jménem termostatu vyhodit topení, připravit panu domácímu saunu nebo cyklovat s topením dle libosti...
Jako bych jim to neříkal už roky, že WiFi do IoT (z mnoha dobrých důvodů) nepatří, a když už, tak pakety pořádně šifrovat. Ale to ne, to tomu nerozumím a přece to funguje, tak co...
Ani zalepení jedné z mnoha děr ve WiFi furt nijak neospravedlňuje použití ESPeček v domácí automatizaci a furt to považuju za nesmysl.
Z pohledu komunikace nejde WiFi používat už jenom proto, že kdokoliv je schopný permanentně shazovat spojení i bez znalosti přihlašovacích údajů a bez spojení senzor-aktor žádná automatizace nikdy nefungovala.... a pak je tady celá řada dalších nevýhod i proti hloupé RS-485 nebo CANu.
Teoreticky jo, pokud bude aktualizace. Jistota je po WiFi provozovat jenom šifrovaný tunel (a samo, že s extra WiFi pro hosty s jiným heslem, ale to platilo odjakživa).
Android má takovou zajímavou vlastnost. 90+ % zařízení s ním je z pohledu SW odepsaný cca den po jeho koupi, kdy se po nabití nastavení a připojení na net zjistí, že půl roku od výroby bylo 20 CVE a žádná nová verze firmware... (jeden ze tří důvodů, proč nemám patlafoun s Androidem).
Zajímavá možnost by byla IPv6 only síť, kde
- WiFi dostane jiný prefix, kabelová síť jiný prefix a WiFi pro hosty jiný prefix
- Na WiFi se vynutí šifrování (vIPv6 standardní featura) - do děravé trubky se neinvazivně vloží hadice, kterou nic neproteče.
- Router odfiltruje nešifrovanou komunikaci z WiFi na vnitřní síť podle prefixu.
Jenomže IPv6 u ISP není a když je, tak idioti od kyslíků dají placený /64 prefix a už to nejde nasekat na tři sítě... :Q Nebo má někdo doma router, který IPv6 neumí.
Hlavně je vhodné zkontrolovat, jestli tam nemáte mnohem větší díry, které se tímhle dají využít, tedy vypnout WPS a používat pouze AES (CCMP). Pak může útočník posílané pakety tak maximálně číst, což řeší šifrování provozu (TLS).
Pro opravu té díry umožňující útočníkovi číst data bude potřeba aktualizovat klienty a nejspíš i standard. Aktualizace AP může přidat detekci útoku a vynutit rotaci klíčů, ale nemůže útoku zcela zabránit, útočník to může zkusit znovu.
Postupně se objevuje, že to asi nebude tak žhavé, jedna z podmínek totiž zřejmě je, že útočník musí být mezi AP a klientem, protože potřebuje některé zprávy zarušit a zároveň číst a občas přeposílat. To by v případě domácích a firemních Wi-Fi typicky znamenalo, že bude muset být u vás doma či ve firmě, a pokud se tam dostane, máte mnohem větší problém se zabezpečením než jen WPA2.
Správným řešením je chovat se k WiFi jako k přenosovému médiu bez bezpečnostních fíčur, a zabezpečení přenechat aplikační vrstvě :-)