WPA ist unsicher

Seite 1 von 2 - Forum: Netzwerktechnik auf overclockers.at

URL: https://www.overclockers.at/netzwerktechnik/wpa-ist-unsicher_249894/page_1 - zur Vollversion wechseln!

COLOSSUS schrieb am 16.10.2017 um 08:44

Bester Text bisher dazu: https://www.alexhudson.com/2017/10/...oken-krack-now/

Die Schwachstelle im Protokoll wird erst morgen offengelegt. Wer noch immer TKIP einsetzt, sollte auf AES wechseln - aber auch das wird mit den fuer morgen erwarteten Angriff nicht helfen; manche Hersteller (Ubiquiti) verbreiten bereits Firmware-Updates mit Workarounds fuer das Problem. Wie effektiv die sind, wird sich zeigen.

Das werden ein paar interessante Wochen...

othan schrieb am 16.10.2017 um 09:01

Bin gespannt. An WPA wurde ja immer gerüttelt, aber so richtig gebröckelt hats bisher ja noch nicht.
Ein neuer Standard wird sich wohl nicht so schnell definiert werden, bzw. wird sich nur sehr langsam verbreiten.

Erinnert mich an einen Bekannten der sein Wifi ohne Verschlüsselung hatte, dafür auf der Firewall nur einen Port für OpenVPN offen.

Smut schrieb am 16.10.2017 um 10:05

wird vermutet, dass es im schlechten seed des RNGs liegen kann. Dieser wird entgegen Empfehlungen oft vereinfacht abgeleitet.
WPA2-PSK/WPA-Enterprise sind ev. gleichermaßen betroffen, da es kein Angriff auf die Authentifizierung/Shared Secret ist.

Die Auswirkung wäre immens, da jedes mitm-anfällige protokoll ungeschützt wäre. Auch HTTPs kann bei ungünstiger Implementierung ausgehebelt werden: http to https Redirect, Rouge intermediate CAS, CRL-block bei kompromittierten keys.

Cobase schrieb am 16.10.2017 um 10:17

Muß ich jetzt auf RADIUS umstellen? Oder gar komplett auf VPN auf allen Clients?

Smut schrieb am 16.10.2017 um 10:26

radius ist ein authentifizierungsprotokoll, diese sind davon nicht direkt betroffen.
die schwachstelle liegt vermutlich im session-encryption key von WPA2 und einer art down-grading attacke, die den austausch des session keys verzögert oder den darauf folgenden key mit verringerter komplexität bruteforcen kann - sind aber derzeit eben keine gesicherten informationen.

userohnenamen schrieb am 16.10.2017 um 11:22

paper ist da
https://papers.mathyvanhoef.com/ccs2017.pdf

zusammenfassung hier (selbst noch nicht gelesen)
https://www.krackattacks.com/

was ich jetzt vom kollegen gehört hab ist auch enterprise kaputt

Cobase schrieb am 16.10.2017 um 11:29

Zitat
Notably, our attack is exceptionally devastating against Android 6.0: it forces the client into using a predictable all-zero encryption key.

Totales WTH?!?!

Smut schrieb am 16.10.2017 um 11:55

wenn ich es richtig verstehe:
Solange der Access Point gepatcht ist, ist das WLAN sicher.
Beim Client es es schwieriger, wenn der Client gepatcht ist und der AP nicht, dann kann über ein weiteres device im WPA2 eingestiegen werden. Client Isolation schafft hier vermutlich Abhilfe.

edit: scheinbar muss der angreifer lt. paper KEIN authentifizierter teilnehmer des Wifis sein. hm

wergor schrieb am 16.10.2017 um 12:41

Zitat aus einem Post von Cobase
Totales WTH?!?!

offenbar ist linux auch betroffen, nicht nur android

Viper780 schrieb am 16.10.2017 um 12:54

Alle sind betroffen - das ganze ist sogar von einer untersuchung bei OpenBSD ausgegangen

daisho schrieb am 16.10.2017 um 12:59

Zitat aus einem Post von Cobase
Totales WTH?!?!

Ja, das ist nice, hier die Erklärung warum das passiert: https://www.krackattacks.com/#details-android

Zitat
Here, the client will install an all-zero encryption key instead of reinstalling the real key. This vulnerability appears to be caused by a remark in the Wi-Fi standard that suggests to clear the encryption key from memory once it has been installed for the first time. When the client now receives a retransmitted message 3 of the 4-way handshake, it will reinstall the now-cleared encryption key, effectively installing an all-zero key.

mr.nice. schrieb am 16.10.2017 um 13:21

Ich vermute die Prozedur zum all-zero key hat sich jemand ausgedacht, um den geheimen Schlüssel vor Angriffen auf den Speicher zu schützen, die Geräte werden dabei quasi geopfert.

Keine schöne Sache insgesamt, der Angriff setzt jedenfalls am Client an und weniger am Access Point.
Ein Grund mehr zeitnah Updates zu installieren.

Cobase schrieb am 16.10.2017 um 13:21

Mikrotik ist anscheinend nicht anfällig dafür:

https://forum.mikrotik.com/viewtopi...21&t=126695

Smut schrieb am 16.10.2017 um 13:27

Zitat aus einem Post von Viper780
Alle sind betroffen - das ganze ist sogar von einer untersuchung bei OpenBSD ausgegangen

interessanterweise sind windows und ios weniger betroffen, da der mechanismus leicht abseits vom standard implementiert wurde.

das problem ist weniger schwerwiegend als zuerst angenommen:

angreifer (mitm) muss selbe SID+MAC auf anderem channel haben: er muss aktiv mit dem client kontakt aufnehmen, dadurch ist eine gewisse physische nähe notwendig.
angreifer kann nur client-verbindung durch MiTM entschlüsseln und mitlesen.
damit er TCP pakete injecten kann, muss er TCP-sequence number erraten (gar nicht so trivial). injection AFAIK nur mit TKIP möglich (bitte um korrektur!)
angreifer kann nicht sich nicht vollwertig gegen WPA2-psk authentifizieren, da trotz MiTM der psk nie übertragen wird, sondern nur für challenge-response zum einsatz kommt.
ios/windows unterstützten keinen re-transmit des message keys

allen in allem ist es ein protokollfehler, jedoch wird es schwer werden das protokoll kurzfristig in einer neuen version aufzulegen. abhilfe schaffen unmittelbar nur client-patches, die den re-transmit erschweren. somit tut diese schwachstelle am meisten bei devices weh, die keine updates mehr erhalten. wie lange diese dann vertretbar sind, wird die zeit zeigen - würd das mal auf 2-3 jahre einschätzen.

Zitat aus einem Post von Cobase
Mikrotik ist anscheinend nicht anfällig dafür:

https://forum.mikrotik.com/viewtopi...21&t=126695

ich sehe es als client problem. somit imho nur der client-mode des APs betroffen.

Viper780 schrieb am 16.10.2017 um 13:28

Zitat aus einem Post von Cobase
Mikrotik ist anscheinend nicht anfällig dafür:

https://forum.mikrotik.com/viewtopi...21&t=126695

doch sind sie natürlich schon. So wie alle WLan devices die sich an den Standard gehalten haben.
Mikrotik hat nur schon Patches dafür veröffentlicht.