... mert választani kell

Breaking: WiFi sebezhetőség kapcsán álhírekkel megy a pánikkeltés

2017/10/21. - írta: Válasszunk

Az Index Tovább ketyeg a WiFibomba című cikkében Hegyeshalmi Richárd újságíró azt írja, hogy "Ezzel az a fő probléma, hogy ez a protokoll a biztonsági védelmi rendszer hierarchiájában legalul helyezkedik el. Alap elvárás, alap biztonsági szint, amiben mindenki megbízik; de ha ez feltörhető, az ennél feljebb helyezkedő védelmi vonalakat már gyerekjáték áttörni." Az egyetlen probléma az írásával az, hogy teljesen valótlan. Méghozzá még egy "bölcsészmérnök" újságíró számára is látható, hogy miért valótlan. Alaptalan pánikkeltés, álhír. Természetesen a forrásul használt ITCafé cikk is álhír. 

Hegyeshalmi Richárd álhíre többek között azért is veszélyes, mert a további rétegek nyújtotta biztonságot valótlanul és félrevezetően állítja be hatástalannak. A sebezhetőség kihasználhatóságához írt távolság kapcsán pedig megjegyezném, minden olyan helyről kihasználható, ahol a WiFi a vezetéknélküli természete miatt plusz titkosítás nélkül sebezhető és a WPA2-t eddig használták és az eddig bármilyen érdemi védelmet jelentett (nem volt ismert a jelszó).  Ahol ez a 3 feltétel nem adott, ott a sebezhetőség semmit sem számít. 

Először a kevésbé technikai analfabétáknak egy kis magyarázat: Ha ugyanis ez igaz lenne, akkor a WPA2 vagy más link layer szintű védelem nélkül bárhol gyerekjáték lenne feltörni a többi rétegen zajló kommunikációt. Márpedig ilyen szintű védelem nincs pl. a vezetékes hálózatok esetében sem. A valóság ezzel szemben az, hogy sem mondjuk az Internet Layer szintjén működő opcionális IPSec védelem, sem az application layer szintjén SSL / TLS vagy az SSH, sem az egyes VPN megoldásoknál használt tunneling megoldások nem feltételeznek link layer szintű biztonságot. Az egyes rétegek azt feltételezik, hogy az alattuk lévő réteg többféle módon implementálható és nem feltétlenül biztonságos.

Az után, hogy elvetettük Hegyeshalmi Richárd álhírét, és "a Microsoft frissített, szóval a Windows Mobile tulajok jártak jól" megjegyzés után elmennénk Lumia 950 XL-t venni érdemes megérteni mit jelent a fenti állítások sokasága. Az SSL / TLS továbbra is véd. Ahol lehet használjunk ezért https kapcsolatot. A blog.hu továbbra sem nyújtja ezt a lehetőséget. 

Ha ez nem lehetséges, akkor használjunk vezetékes hálózatot, vagy mobilnetet, kerüljük a sebezhetővé vált WiFi hálózatok használatát.

Ha a vezetékes hálózat nem jelent megoldást (pl. telefon, tablet esetében) és nem akarjuk a drága mobilnet használatát erőltetni, akkor bármely titkosítást nyújtó, önmagában nem sebezhető VPN képes helyreállítani a biztonságot. Megfelelő VPN szolgáltatás számos szolgáltató kínálatában elérhető. Sok biztonsági software is nyújt szükség kapcsolódó esetére VPN szolgáltatást. Továbbá a TOR rendszer használata szintén képes garantálni a biztonságot. 

Az, hogy az Index szerkesztőségén átmegy egy olyan cikk ami pont akkor hazudja hatástalannak a plusz védelmi rétegeket amikor azokra a legnagyobb szükség van, és amikor az Indexhez kapcsolódó blog.hu ezek egyikét véletlenül nem nyújtja (pedig ma már elvárás, és a BKK ügy rávilágított miért kellene biztonságos SSL) az komoly botrány. 

Mivel nem tudjuk, hogy kit vezetett meg az Index cikke, és bárkinek szüksége lehet ebben az időszakban arra, hogy tudja, milyen plusz biztonsági megoldásokat érdemes használni, kérjük oszd meg a postot a lehető legtöbb emberrel!

Továbbá, ha valamely VPN szolgáltatóval tapasztalatod van, vagy valamely megfelelő kliens software (pl. androidra TOR kliens, stb) kapcsán van értékes tapasztalatod, akkor azt a vonatkozó linkkel együtt kommenteld be a post alá, hogy az olvasók tájékozódni tudjanak! Köszönöm. 

Természetesen nem csak ez a modell említ rétegeket, hanem az OSI modell is. És természetesen a sokszor elmondott Defense in Depth koncepció, a több egymástól független védelmi réteg léte ezért alapvető a biztonságunk érdekében. 

Ezért arra is szeretnék mindenkit megkérni, hogy az Index és a blog.hu adminisztrátorai számára is küldjön egy-egy levelet amiben megkéri őket, hogy a TLS (https) használatát tegyék lehetővé a blog.hu-n.

komment

A bejegyzés trackback címe:

https://valasszunk.blog.hu/api/trackback/id/tr5813047794

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

Online Távmunkás · http://onlinetavmunka.blog.hu 2017.10.21. 20:34:00

"Az SSL / TLS továbbra is véd."
Szóval ez a poszt is álhír?
Az SSL nem véd a náthától se és a TLS-ből is csak a legújabb verzió használható, ami olyan szinten nem terjedt még el, hogy iPhone-on nem lehet bankkártyával fizetni sok webshopban, mert a Safari blokkolja a nem biztonságos webhelyeket...

Válasszunk · http://valasszunk.blog.hu 2017.10.21. 21:30:46

@Online Távmunkás: Nem értek veled egyet. Egyszerű oknál fogva. A "nem véd a náthától se" pl. nem jó megfogalmazás. Mert valamennyi védelmet jelent, és ez a védelem független a WPA2-től. A gond az, hogy az SSL jelentette védelem már nem elég, mert sebezhető sok módon.

Ezért fontos a több védelmi réteg :)

Válasszunk · http://valasszunk.blog.hu 2017.10.21. 21:39:05

@Online Távmunkás: Plusz amíg a legtöbb CA, a certificateit SSL certként árulja, a library amit használsz az sokszor az openssl, addig bizony ezt a "köznyelv" akkor is SSLnek hívja, ma már az SSL v3 is csak az oldalak 13%-ában támogatott. A TLS 1.0 pedig több, mint 93%-ban. A wikipedia-n szereplő adatok szerint.

Online Távmunkás · http://onlinetavmunka.blog.hu 2017.10.22. 10:11:35

@Válasszunk: A TLS 1.0 nem biztonságos, így szomorú, hogy olyan sokan támogatják. Ha ugyanazt a Wikipedia oldalt megnézed, akkor azt láthatod, hogy a legnépszerűbb honlapok jelentős része nem biztonságos TLS megoldást használ...

Válasszunk · http://valasszunk.blog.hu 2017.10.22. 22:11:41

@Online Távmunkás: Szerintem meg a támogatása egyáltalán nem szomorú. Ugyanis a táblázat szerint a biztonságos volta "depends on cipher and client mitigations".

A fő probléma az, hogy nézzünk meg két forgatókönyvet:

A eset: Sok helyen járkálsz, sem a routeren / APn nincs frissítés, sem az eszközökön. A WiFi forgalom lehallgatható. Te semmi mást nem csinálsz csak sniffeled a forgalmat.

Támadás nehézsége: Triviális, minden adatot megszerzel.

B eset: Ősöreg készüléken, ősöreg browser, SSL 3.0-ra tér vissza. Poodle támadásra sebezhető az egész. De neked már nem elég csak mindent szépen sniffelni, hanem azonosítanod kell azonnal hol van sebezhető kapcsolat, jöhet a Poodle attack és jöhet az ellen az SSL ellen támadás.

Támadás nehézsége: Ismert exploitokkal és némi odafigyeléssel könnyen megvan.

C eset: Van ahol csak SSL van, de többnyire TLS a sebezhetőségek mitigációja is stimmel. A WPA2 sebezhetősége miatt sniffelni triviális, de onnan az, hogy mikor van sebezhető kapcsolat, ott vagy-e kicsit rulett kérdése, közel sem biztos, hogy megéri ott lenni. Ahol a TLS vagy ne adj isten SSL sebezhető, ott kell még támadás, de ezek egy részénél van a lebukásnak egy nagyobb kockázata.

A támadás nehézsége: Szerencse, odafigyelés, jó időzítés is kell hozzá, és az is, hogy ahol lehet ott se bukj le.

D eset: Van ahol csak SSL van, de többnyire TLS a sebezhetőségek mitigációja is stimmel. A WPA2 sebezhetősége miatt sniffelni triviális, de onnan az, hogy mikor van sebezhető kapcsolat, ott vagy-e kicsit rulett kérdése, közel sem biztos, hogy megéri ott lenni. Ahol a használt protokol verzió sebezhető és a kockázatot sem mitigálta semmi, tudsz támadni ott támadhatsz, de... Nem csak te látod a többiek adatforgalmát, hanem ők is a tiédet, így a támadásra jelezhet biztonsági software, ezt megkerülni viszont pl fertőzőtt vagy "számukra láthatatlan eszközök" bevonásával, bonyolultabb koordinált támadással tudod.

A támadás nehézsége: ....

Szerintem érted, hogy bár még az utóbbi is csak SSLv3 ami ritka mégis nagyságrendi különbség van az itt említett esetek kapcsán a biztonság mértékében.
süti beállítások módosítása