16.10.2017 13:36
Es steht KRACK auf dem Speiseplan!
Auch wenn die Arbeit für ein nationales CERT reichlich stressig ist, für den Konsum harter Drogen reicht die Verzweiflung dann doch noch nicht, auch wenn der Titel dieses Eintrages vielleicht anderes suggerieren mag. Nein, heute wurden Details zu den sogenannten "Key Reinstallation Attacks", kurz "KRACK", veröffentlicht (technisches Paper / Webseite).Kurz zusammengefasst stellen diese Schwachstellen die ersten Angriffsmöglichkeiten gegen WPA2 auf Protokollebene dar, bisherige Angriffe gegen moderne Drahtlosnetzwerke richteten sich gegen veraltete Standards, wie WPA-TKIP, Technologien wie WPS, oder waren schlichtweg schnödes Bruteforce. Dementsprechend gross ist auch die Aufregung innerhalb der Community und der Medienwelt. Wie berechtigt ist diese allerdings tatsächlich?Auf den ersten Blick wirkt die Situation relativ dramatisch, je nach konkreter Implementation des Standards ist es möglich, nahezu beliebig verschlüsselte Pakete zu entschlüsseln, zu manipulieren oder gar gänzlich zu fälschen. Das bedeutet dass Daten die nicht auf anderer Ebene verschlüsselt sind (z.B. via TLS), für einen Angreifer potentiell lesbar sind. Persönliche Daten, Kreditkartennummern, Benutzernamen und Passwörter - die Liste an gefährdeten Informationen ist lang.In der Praxis, so schreiben die Autoren in dem oben verlinkten Paper selbst, gibt es Komplikationen, die die Ausnutzung der Schwachstellen, teils erheblich, erschweren. Zum einen halten sich nicht alle Hersteller bei der Implementierung an die vorgeschriebenen Standards, was einige Betriebssysteme für den potentiellen Angreifer 'unvorhersehbar', beziehungsweise deutlich schwerer angreifbar macht:
In practice, some complications arise when executing the attack. First, not all Wi-Fi clients properly implement the state machine. In particular, Windows and iOS do not accept retransmissions of message 3 (see Table 1 column 2). This violates the 802.11 standard. As a result, these implementations are not vulnerable to our key reinstallation attack against the 4-way handshake. Unfortunately, from a defenders perspective, both iOS and Windows are still vulnerable to our attack against the group key handshake (see Section 4). Additionally, because both OSes support 802.11r, it is still possible to indirectly attack them by performing a key reinstallation attack against the AP during an FT handshake (see Section 5).Weiters muss der Angreifer es schaffen, sich in eine MitM-Position zu bringen:
A second minor obstacle is that we must obtain a MitM position between the client and AP. This is not possible by setting up a rouge AP with a different MAC address, and then forwarding packets between the real AP and client. Recall from Section 2.3 that the session key is based on the MAC addresses of the client and AP, meaning both would derive a different key, causing the handshake and attack to fail. Instead, we employ a channel-based MitM attack [70], where the AP is cloned on a different channel with the same MAC address as the targeted AP. This assures the client and AP derive the same session key.Das ist technisch, wie in dem PoC-Video des Researchers gezeigt, zwar mit mittlerem Aufwand möglich, erfordert aber immer noch, dass sich ein Angreifer in der Nähe der potentiellen Ziele befindet, was die massenhafte Ausnutzung erheblich erschwert. Und zuletzt gibt es einige generelle Implementierungseigenheiten, die die Vorhersagbarkeit des Angriffes verringern:
The third obstacle is that certain implementations only accept frames protected using the data-confidentiality protocol once a PTK has been installed (see Table 1 column 3). This is problematic for our attack, because the authenticator will retransmit message 3 without encryption. This means the retransmitted message will be ignored by the supplicant. Although this would seem to foil our attack, we found a technique to bypass this problem (see Section 3.4).Eine wirklich zuverlässige, gezielte Ausnutzung der Lücke ist also wesentlich schwerer, als es die Zusammenfassungen und Überschriften auf den ersten Blick vermuten lassen. Am schwersten betroffen sind bestimmte Versionen von Android (welche das tatsächlich sind, daran scheiden sich ein wenig die Geister - Paper, Webseite und Medienartikel haben allesamt unterschiedliche Angaben hierzu), die nicht einen alten Key wiederverwenden, sondern gar dazu gebracht werden können, einen 'leeren' Schlüssel zu verwenden.Dennoch ist die eigentliche Gefahr hier nicht die besonders schwere 'Ausprägung' der Schwachstelle, sondern die generell eher problematische Situation rund um den Patchzyklus von Android. Manche Hersteller werden die Patches dafür wohl erst in einigen Monaten in ihre angepassten Versionen des Betriebssystems inkludieren, wenn überhaupt. Stichwort Patches: Die grossen Linuxdistributionen, und OpenBSD, haben bereits Patches zur Verfügung gestellt, selbiges gilt für einige - aber bei weitem noch nicht den Grossteil - der Hardwarehersteller.Der grosse Vorteil ist, dass die Sicherheitsupdates 'abwärts'kompatibel sind, ein gepatchter Client kann mit einem ungepatchten AP kommunizieren, und vice-versa. Das ist vor allem für Unternehmen hilfreich, die eventuell nur eine von beiden Seiten patchen können. Die wesentlichen Punkte zusammengefasst sind also:
- Die Schwachstellen lassen sich durch Sicherheitsupdates beheben, ohne dadurch Kompatibilitätsprobleme zu verursachen
- Diese Updates gibt es bereits für die gängigsten Linuxdistributionen und einige Access Points, es ist damit zu rechnen, dass andere Projekte und Hersteller in Bälde gleichziehen
- Es gibt noch keinen öffentlichen Exploit-Code, und einige Hindernisse - wie das Erfordernis der räumlichen Nähe - machen eine Ausnutzung der Schwachstellen erheblich schwerer