FYI: KRACK - súlyos hiba a WPA2 protokollban

Címkék

A sebezhetőség / PoC exploit neve: KRACK. A koordinált közlés ma várható. Elérhető a KRACK weboldala.

Hozzászólások

Javítsatok ki, ha tévednék, de nem úgy volt, hogy a WEP szuper gyorsan törhető mindenféle különös hardver nélkül.

Így a használj helyette WEP-et az kb. úgy hangzik, mintha azt mondanám, hogy kapcsolj ki minden titkosítást, és imádkozz...

Szerencsére a hup-ot https-en olvasom :-)

https://www.krackattacks.com

Should I temporarily use WEP until my devices are patched?

NO! Keep using WPA2.
--
Debian 8.8 Jessie, Android 6.0.1 Marshmallow+MIUI 8.2.9.0 Global, OpenWrt 15.05.1 Chaos Calmer, Armbian 5.24, Free MC Boot 1.953+OPL 0.10.15 Daily Build, Boyue C60 20140410 (Gentoo)

Vagy: dobj fel egy pénzt, mert mindkettő a rakás szar.

Esser azt akarta szerintem mondani, hogy a WEP-re váltás a mostani közlés hatására fellángoló WPA2 támadások ellen lehet afféle kisebbik rossz megoldás ideiglenesen (hint: current attack).

Abból indulhatott ki, hogy a napokban melyikből lesz több: WEP támadásból vagy WPA2-ből. Valószínűleg az utóbbiból, mivel a WEP-et évek óta nem használja senki.

Ez az egész úgyis csak az automatizált próbálkozások, wardriving stb. ok, ha célzottan téged támadnak valamiért, akkor úgyis bebuktad.

--
trey @ gépház

subscribe
-------------------------------------------------------------------------------
Az életben csak egy dolog a szép, de az épp nem jut eszembe.

Slackware Linux 14.2 | 4.4.37-janos

Fura, hogy a WiFi technológiája, sebessége sokat fejlődött (a/b -> g -> n -> ac), de a titkosítást mintha elfelejtették volna fejleszteni... Jó, persze, jobban el lehet adni egy WiFi eszközt, hogy ilyen, meg olyan gyors, mintha azzal próbálnák meg eladni, hogy ilyen vagy olyan szipi-szupi biztonságos. Kicsit olyan, mint amikor az a legnagyobb hír egy OS frissítés esetén, hogy van benne kaki meg csillámfaszláma emoji... szomorú...

--
www.haiku-os.org

A titkosításon nincs mit fejleszteni, az AES256 elég erős, nem tudják megtörni. Ez a támadás nem az AES gyengeségén alapul, hanem azon, ahogy a WPA2 protokollba implementálták. Egyébként nekem nem tiszta, mert ez a támadás csak arra jó, hogy másik kulcsot inicializáljon, a régi kulcsot nem lehet vele visszafejteni továbbra sem, ahhoz magát az AES-t kéne törni.

Elég rossz hír, a legszörnyűbb, hogy javítás sincs még rá, és az OS-ekben lehet gyorsan javítják, de a routerekhez vagy csak sokára jön javítás, vagy soha, attól függően melyik gyártó, kifutott típus-e. Lehet létrejön egy WPA3 vagy hasonló megoldás, de az még évek, mire kihozzák a végleges szabványt meg a gyártók többsége is implementálja. Abban viszont igazad van, hogy a gyártóknak és a szabványalkotóknak nem lett volna szabad évekig a babérjaikon ülni, és a biztonságot nem fejleszteni. Kellenek az új megoldások, hogy a hekkerek előtt járjanak. Olyan nincs, hogy van egy tökéletes biztonsági megoldás és akkor nem kell hozzányúlni évtizedekig, mert előbb-utóbb mindent megtörnek.

„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek stb…” Aron1988@Proharder Fórum

Jelszavakat nem is a titkositás törésével szokták megszerezni, hanem mezei bruteforce-al. Amig a buta egybites user születési dátumot, keresztnevet és hasonló gagyi jelszavakat állit be, addig felesleges bármit is tenni.

Mennyi idő szerinted végigpörgetni az összes dátumot minden numerikus formátumban mondjuk 1910-től? Kb 10 perc.
-------------------------
Dropbox refer - mert kell a hely: https://db.tt/V3RtXWLl
neut @ présház

Ezért van n perc ban 5-10 darab próbálkozás után normálisan megcsinált loginnál.
Úgy már azért eltart egy darabig még végigpörgetnek ennyi dátumot. Még akkor is ha nincs extra "jutalom" miután a 10 darabos próbálkozás blokkokból is lement 10 darab mondjuk egy órás ban formájában. És ez csak egy jelszóséma. Ahhoz, hogy legyen valami esély a sikerre bruteforcenál nem árt ha van egy rakat tört géped különböző ip cimekkel, amik nem egy ip cimről de még nem is egy tartományból próbálkoznak.
Na persze egy wifi kulcs nem Google login. Így lehet próbálkozni, soho routereknél biztosan. Talán itt is nagy cégek bejáratott, biztonságos beléptetési rendszereihez kellene kötni a routerekhez való csatlakozást, otthoni routerekig bezárólag. Persze jönne a szokásos Big Brother mantrázás, de szomszéd okospistikéktől sokkal védettebbek lennének a routerek.

Ez most eléggé gáz szitu.
Gyors megoldásként nem tudok jobbat, mint az OpenVPN. A wifi-hez csatlakozott eszközök nem látnak ki a netre, egymást sem látják. Egyedül VPN szerverre lehet csatlakozni. Onnantól van minden.
... még nem jön valami baki az OpenVPN háza tájáról is. :)

Ennél sokkal árnyaltabb és egyszerűbb a dolog mint ahogy gondolod.

A brute force nem az eszközön történik. Egy sikeres kapcsolódáskor elcsipik a WPA handshake-t és utána azon brute forcolnak local gépen. A routered nem is kell hozzá. Miután kipörgették a jelszót, simán kapcsolódnak és csókolom. A legdurvább az egészben, hogy észre sem veszed. MAC szűrés nem jelent semmit (elvégre azt állitasz be MAC-nek amit szeretnél, akár a hálózaton kommunikáló "normál" eszköz cimét is.

A nagy cégek wifijei azért vannak védve, mert ott általában van Radius és certes hitelesités. Certet lopni már nehezebb, de az sem agysebészet.
-------------------------
Dropbox refer - mert kell a hely: https://db.tt/V3RtXWLl
neut @ présház

Elnézést ha félreérthetően fogalmaztam, de általánosságban írtam a brute force jelszótörésekről erre válaszolva: "Amig a buta egybites user születési dátumot, keresztnevet ..."
Ez szvsz általánosságban szól a gyenge jelszavak veszélyeiről, például webes szolgáltatások jelszavaira vonatkozik és nem kapcsolódik szorosan a témához. Ehhez kapcsolódva írtam a wifis bekezdést is. Na meg akkor még nem olvastam el a linkelt cikket. :)
Annyira nem gáz a helyzet, mert kliens oldalon patchelhető. Routerekhez nem kell hozzányúlni. Probléma persze a gyártók által már elfelejtett, nem frissített mobilokkal lesz.
Az sem mindegy mikorra készülnek el a patchek és milyen gyorsan terjednek el.

Az OpenVPN-es részt továbbra is tartom, az jó védelmi vonal a jövőbeli ilyen típusú biztonsági problémákra.

Do we now need WPA3?

No, luckily implementations can be patched in a backwards-compatible manner. This means a patched client can still communicate with an unpatched access point, and vice versa. In other words, a patched client or access points sends exactly the same handshake messages as before, and at exactly the same moments in time. However, the security updates will assure a key is only installed once, preventing our attacks. So again, update all your devices once security updates are available.

Nem, a jelszó nem kerül ki (és az, hogy melyik irányú forgalmat tudod decryptelni is függ attól, hogy mit tudsz támadni):

The direction in which packets can be decrypted (and possibly forged) depends on the handshake being attacked. Simplified, when attacking the 4-way handshake, we can decrypt (and forge) packets sent by the client. When attacking the Fast BSS Transition (FT) handshake, we can decrypt (and forge) packets sent towards the client. Finally, most of our attacks also allow the replay of unicast, broadcast, and multicast frames. For further details, see Section 6 of our research paper.

Note that our attacks do not recover the password of the Wi-Fi network. They also do not recover (any parts of) the fresh encryption key that is negotiated during the 4-way handshake.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

> ...amikor az a legnagyobb hír egy OS frissítés esetén, hogy van benne kaki meg csillámfaszláma emoji... szomorú...

Ha az Apple keynotera gondolsz, akkor ott nem ez volt a legnagyobb hir. De meg ha ez is volt, demoztak eleg komoly biztonsagi megoldast is.

Persze ehhez az is kell, hogy ne a csillamfaszlamara csillanjon fel a szemed, mint a tobbi consumernek, hanem kicsit tovabb is kene gondolni...

Mar megbocsass, de en kiemeltem, hogy mire valaszolok es szerintem egyertelmu volt, hogy a topic eredeti temajatol kicsit eltavolodva, a szalindito felvetesere reagaltam.

Abban termeszetesen igazad lehet, hogy a topic beli serulekenysegre a macOS erzekenyebb, de mivel az iPhone meg mindig iOS-t futtat, ennek a tema szempontjabol nem tulajdonitanek nagy figyelmet ;) :)

Az iOS pedig macOS alapú, a hiba által érintett terület pedig éppen közös pont a két rendszerváltozatban. Csak éppen nem nevesítette a cikk. OpenBSD, macOS nem véletlenül közös metszet és ebben az iOS is benne van.

Dohh! Nagyon nem megy ez ma neked! Így még flamelni sem lehet rendesen! :) Tök uncsi így.
Úgyhogy inkább segítek. Neked ezzel kellett volna kontráznod:

"For an attacker this is easy to accomplish, because our key reinstallation attack is exceptionally devastating against Linux and Android 6.0 or higher. This is because Android and Linux can be tricked into (re)installing an all-zero encryption key"
:D

Hat ha nem lehet vele ingyen+barhol netezni..
Kit erekel masok csomagja ?
Ami bizalmas ep eszu ember ugysem kuldi egyeb titkositas nelkul
(Ha tehetne sem tudna a legtobb esetben)

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Az ilyenek a protokolba a fejlesztők által tudatosan beletervezett, "backdoor"-pótló hibák. (Mert VALAKIKNEK, - ADOTT ESETBEN.., - kell a "mindenáron" elérhetőség..)

Egyet a sokból befoltoztak.

Amikor telefonos cégnél dolgoztam, tudtuk, hogy Kínában az összes azonosított WAP forgalomnak egy központi kínai szerveren kellett átmenni, az USA-ba szállított cuccokon meg a titkosítási algoritmusokból a jókat ki kellett venni, hogy telefonon ne lehessen komoly titkosítással adatot átvinni.

- a router-eket Kínában gyártják
- amerikai cégek

Mindkét állam ellenérdekelt a titkos adatátvitelben. Ez van, jobbat tőlük nem kapsz.

Fejlemények: a MS már javította kliensoldalon, ahogy a Debianban, Ubuntuban (és így a Mintben is) javítva lett, ma Arch Linuxék is kitolták a wpa_supplicant frissítését. De ez csak a kliensoldal, az AP oldaláról is kell frissítani, és ez lesz a bukó a legtöbb esetben. Sokan nem léptek még, gyártók pl., de OS oldalról még a FreeBSD-nél sem látok javítást.

„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek stb…” Aron1988@Proharder Fórum

Nemtudom mekkora az atjaras Open<>FreeBSD forraskod kozott, de OpenBSD-ben mar juliusban javitottak:

OpenBSD was notified of the vulnerability on 15 July 2017, before CERT/CC was involved in the coordination. Quite quickly, Theo de Raadt replied and critiqued the tentative disclosure deadline: “In the open source world, if a person writes a diff and has to sit on it for a month, that is very discouraging”. Note that I wrote and included a suggested diff for OpenBSD already, and that at the time the tentative disclosure deadline was around the end of August. As a compromise, I allowed them to silently patch the vulnerability. In hindsight this was a bad decision, since others might rediscover the vulnerability by inspecting their silent patch. To avoid this problem in the future, OpenBSD will now receive vulnerability notifications closer to the end of an embargo.

Nade nem suttogja ki (legalabbis nem a szo szigoru ertelmben) ... csak open source - ilyen az alaptermeszete ennek a fogalomnak, tehat barki megnezheti a forrast. Ez benne a poen, hogy igy elvileg az open source "buntetheto", mert azt barki megnezheti, milyen patch-ek kerultek bele, es ha nincs is hozza pl commit magyarazat (ha jol ertem itt arrol van szo, hogy nem volt odairva, hogy ezert-vagy-azert patch-eltek ..), azert tippelni lehet, hogy miert kellett valamit modositani, ha valaki allandoan commit-log-ot buj peldaul ... Ugyanakkor closed source vendor siman belerakhatja a deadline elott is a patch-et termekebe (es ezzel elonyhoz is jut, mert rendszere elobb lesz vedett - open source termeknel viszont ne tegye meg az ember, mert ezzel akaratlanul is "kisuttogja a titkot", tehat az open source itt hatranyba kerul eleve, barmit is csinal), mivel ott nem olyan egyszeru kideriteni, hogy konkretan mit modositottak nyilt forras hianyaban, ha nem arulja el, miert kellett a patch.

Szoval en itt ezt nem erzem annyira jogosnak egy szemszogbol nezve ... Ugyanakkor megis jogosnak erezheto mas szempontbol esetleg, pl amit irtal. Szoval ezert "poen" szerintem, persze szigoruan idezojelben.

Biztosan elég? Valami forrás erről? Nagyon király lenne, ha ennyi elég lenne.

Lehet a FreeBSD-nél is javították, csak utalást nem találtam rá, de ettől még javíthatták ők is réges-rég.

„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek stb…” Aron1988@Proharder Fórum

Forrâs a krakattacks.com fentebb a bejegyzésböl

Q&A

Do we now need WPA3?

No, luckily implementations can be patched in a backwards-compatible manner. This means a patched client can still communicate with an unpatched access point, and vice versa. In other words, a patched client or access points sends exactly the same handshake messages as before, and at exactly the same moments in time. However, the security updates will assure a key is only installed once, preventing our attacks.

Én abban látom a hibát, hogy OK, hogy a Linuxomat frissítettem, és lejött egy új wpa-supplicant csomag.

Innentől én biztonságosan kommunikálok a routeremmel.

De a patch-eletlen routerem a patcheletlen telefonommal, vagy más eszközzel továbbra is támadhatóan kommunikál.

OK, jobb ez így, mintha a laptopom se lenne javítva, de azért jó lenne, ha az ISP-m új firmware-t tolna le a routerre majd valamikor nem túl sok idő múlva.

Ezért szívom a fogam én is. Az egy dolog, hogy a PC-imet patcheltem, de a router nincs foltozva, és a 6-os androidos telóm sem (ami frissítést sem kap, mert kínai középkategóriás modell, nem nevesebb márka csúcsmodellje).

„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek stb…” Aron1988@Proharder Fórum

"és a 6-os androidos telóm sem (ami frissítést sem kap, mert kínai középkategóriás modell, nem nevesebb márka csúcsmodellje)"

Félig off, félig csak neked

Ne izgulj, Shamesung is csak addig fogja peccselni az aktuális szupersztár 300 ezer HUF-os univerzum galaxis S-nyócát, amíg 3 hónap múlva nem tolják ki a következő csúcsszuper 350 ezres (de lehet h. inkább 400 ezer pénz legyen) S-kilencet, ami után 3 hónappal már jön is majd az S-10 500 ezer HUF-ért. 'nyátok picsája fog évente 500 ezret nyomkodós drogra kibaszni az ablakon :|
--

Értem, mit akarsz mondani, csak annak mondom, aki esetleg azt hinné, hogy tényleg így van, ahogy mondod:

A régebbi modelleket is frissítik azért, persze nem a végtelenségig.

Nekem egy S7 van, erre szeptemberben jött az utolsó frissítés, ami az augusztusi android security patch-eket tartalmazta.

Igen, ez nem olyan jó, mint mondjuk a Nexus 9-em, ami ugyan öregebb, de az októberi security patch-ek már rajta vannak. De azért nem is az történt, hogy amikor kijött az S8, akkor onnantól az S7 már nem támogatottá vált.

Nem biztos, hogy jól értelmezem:
- a támadó csellel ráveszi a klienst, hogy használjon újra egy kulcsot a handshake üzenetek visszapörgetésével
- miután ugyanazt a kulcsot használja csomó üzenethez, a törés lehetővé válik, mert sok üzenet megy ugyanazzal a kulccsal
- miután feltörték olvassák az adatforgalmat

Jól érted, a titkosítás gyengül addig a szintig amíg már könnyű visszafejteni a hálózati forgalmat. A 4 fázisú handshake 3. lépését ismételgeti a támadás, csupa nullákból álló kulcsot küld többször. A patch lényege hogy a küldött kulcsot átmenetileg meg kell jegyezni és következő kulcsküldéskor összehasonlítani az előző kulccsal. Ezt idáig nem vizsgálta semmi.

Tegnap használaton kívüli raspi-mat beékeltem a "fő router" és a wifi router közé. Jó kis tűzfallal most már nincs internet a wifi routeren, csak a 1194-es udp portot engedem át, így rákényszerítem a felhasználókat, hogy csak openvpn-nel lehessen a wifin netezni és ha nem él a vpn véletlenül se legyen internetes forgalom.

Problem solved.