Es sind am Ende sogar drei verschiedene "handshakes", die von Schwachstellen betroffen sind - einmal der (aus vier Nachrichten bestehende) Austausch des privaten Schlüssels zwischen AP und STA, einmal der Austausch des "Gruppenschlüssels" (damit werden Verwaltungsinformationen, Broadcasts und Multicasts verschlüsselt, die mehrere Clients gleichzeitig erhalten sollen/müssen) und schließlich noch eine spezielle Form der "Ummeldung", die beim Roaming einer STA zwischen APs den Aufwand beim Schlüsselaustausch senken kann, wenn alle Beteiligten 802.11r unterstützen.
Dieses Schielen auf "nur die Clients sind verwundbar und müssen geändert werden" gilt nur für den Angriff auf den 4-Wege-Handshake beim WPA/WPA2 ... hinzu kam eben noch diese "All-Zero Encryption Key Vulnerability", die
in der Publikation im Punkt 6.3 beschrieben ist - diese war zwar auch die Folge eines Angriffs auf diesen Schlüsselaustausch, aber eben eine Spezialität des "wpa_supplicant".
Wer es genau wissen will, schaut sich Tabelle 3 im Paper an (Seite 12, oben). Da steht dann auch für jeden der Angriffe, welche Auswirkungen (Pakete wiederholen, Daten entschlüsseln, Pakete fälschen) für jedes Händeschütteln denkbar wären und da muß man dann eben konstatieren, daß für WPA2-CCMP ein "Fälschen" nicht möglich ist, für WPA-TKIP aber sehr wohl (wobei es auch WPA2-TKIP und WPA-CCMP dem Standard nach als Option geben kann) - das führt am Ende dazu, daß man den MIC key (Message Integrity Check) des Clients ermitteln kann und damit in der Lage ist, im Namen des Clients Pakete an den AP zu senden, die der dann halt weiter im Netz verteilt, je nachdem wohin sie adressiert sind (Punkt 6.1).
Damit muß/kann man sich aber einen Angreifer (auf einen verwundbaren Client/STA und zwar unabhängig vom "Zustand" des AP) praktisch so vorstellen, als könne er mit einem LAN-Kabel direkt in den Router und nach Herzenslust senden (allerdings nicht wirklich empfangen, denn dazu müßte er wieder die Richtung vom AP zum Client dekodieren können) ... und das ist dann nur noch in Grenzen "lustig" und "kein Geheimnis".
Auch schon das reine Wiederholen von Paketen (replay attack) kann durchaus negative Auswirkungen haben in einem Netzwerk ... die Autoren der Publikation führen als Beispiel (Punkt 6.2 für mögliche Angriffsszenarien) das NTP-Protokoll an, wo man durch das wiederholte Aussenden eines NTP-Broadcasts mit einer alten Uhrzeit einen Client zu einer falschen Uhrzeit "überreden" kann, was dann wieder Auswirkungen auf alle möglichen anderen Protokolle haben kann.
Die Autoren haben es doch in Punkt 8 schon schön zusammengefaßt:
All Wi-Fi clients we tested were vulnerable to our attack against the group key handshake. This enables an adversary to replay broadcast and multicast frames. When the 4-way or fast BSS transition handshake is attacked, the precise impact depends on the data-confidentiality protocol being used. In all cases though, it is possible to decrypt frames and thus hijack TCP connections. This enables the injection of data into unencrypted HTTP connections. Moreover, against Android 6.0 our attack triggered the installation of an all-zero key, completely voiding any security guarantees.
Die "Absolutheit" der Aussage, daß kein Verkehr verändert werden kann, gilt also für den 4-Wege-Handshake für den PTK auch nur dann, wenn da wirklich CCMP benutzt wird (also AES im Counter-Mode mit CBC-MAC). Zwar wurde TKIP schon seit längerem schief angesehen und bereits seit 8 Jahren wird die Verwendung vom IEEE als "deprecated" klassifiziert, aber finde mal (als normaler Kunde) in der FRITZ!Box den Hinweis, daß WPA eigentlich nicht die richtige Wahl ist. Bei der Auswahl von (purem) "WPA (TKIP)" kommt wenigstens noch eine Nachricht: "Es wird empfohlen, den verbesserten WPA-Modus "WPA2" zu wählen. Falls Sie auch WLAN-Geräte nutzen, welche nur WPA (TKIP) unterstützen, wählen sie den WPA-Modus "WPA + WPA2"." ... aber wenn man dann "WPA+WPA2" wählt, gibt es keinen entsprechenden Hinweis auf den Status und die Schwächen von WPA bzw. genauer von TKIP.