COLOSSUS
AdministratorGNUltra
|
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
Layer 8 Problem
|
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
takeover & ether
|
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
Mr. RAM
|
Muß ich jetzt auf RADIUS umstellen? Oder gar komplett auf VPN auf allen Clients?
|
Smut
takeover & ether
|
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
leider kein name
|
|
Cobase
Mr. RAM
|
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
takeover & ether
|
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
Bearbeitet von Smut am 16.10.2017, 12:20
|
wergor
connoisseur de mimi
|
Totales WTH?!?! offenbar ist linux auch betroffen, nicht nur android
|
Viper780
Er ist tot, Jim!
|
Alle sind betroffen - das ganze ist sogar von einer untersuchung bei OpenBSD ausgegangen
|
daisho
SHODAN
|
Totales WTH?!?! Ja, das ist nice, hier die Erklärung warum das passiert: https://www.krackattacks.com/#details-androidHere, 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.
differential image maker
|
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
Mr. RAM
|
|
Smut
takeover & ether
|
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. 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.
Bearbeitet von Smut am 16.10.2017, 13:29
|
Viper780
Er ist tot, Jim!
|
|
Anmeldung