Es geistern einige, gefährliche Unwahrheiten durch’s Netz. Insbesondere klären die Medien nicht ausreichend über das Problem auf. Ich will versuchen, in kurzen, prägnanten Stichworten „auf Deutsch“ zu erläutern, wo das Problem liegt.
Update vom 25.10.2017: Hinweis zu 802.11R hinzugefügt.
„KRACK“ ist eine Sicherheitslücke, welche auf die WPA2-Verschlüsselung in WiFi Umgebungen zielt. Hierbei geht es primär um die nachträglichen Entschlüsselungsmöglichkeiten der Verkehrsinhalte, nicht um den Zugangsschlüssel zum Netzwerk selbst. Am Verkehr generell teilnehmen können Angreifer über dieses Szenario nicht. Angenommen, es handelt sich um unverschlüsselten Datenverkehr (z.B. ungesichertes http), ist jedoch ein Verändern von TCP-Strömen einzelner Clients möglich:
„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.“ Mathy van Hoef, Key Reinstallation Attack
Das in WiFi Umgebungen verwendete Protokoll „WPA2“ sieht einen mehrstufigen Handshake (Verfahren, während der Nutzer einer Funkzelle beitritt) vor, jener nicht „ganz zu Ende gedacht“ ist. Dieser Vorgang geschieht mehrfach, während dauerhaft aufrecht gehaltener Verbindungen und kann auch durch Hintergrundrauschen ausgelöst werden.
Eine MITM (man in the middle) Angriff auf der Anwenderseite ist in der Lage, die Verwendung eines Nonces (Sessionkey, Sitzungsschlüssel, nicht der Zugangsschlüssel, XOR-Funktion) während des Handshakes zwischen Client und Accesspoint zu beeinflussen. Hierbei verwendet der Client den bereits zuvor verwendeten Nonce mehrfach. Das ist so definitiv nicht vorgesehen, war jedoch auch in der Spezifikation nicht genauer definiert. Das ist das Problem. Die Hersteller haben bislang nichts falsch gemacht, da die Spezifikation hier ungenau war.
Da der Client in diesem Fall die Nutzung des Schlüssels nicht überprüft, ist der bereits aufgezeichnete Datenverkehr unter Verwendung von ein wenig Mathematik im Replay später viel leichter zu entschlüsseln, als bislang. Zukünftiger, unverschlüsselter Datenverkehr kann auch verändert werden, sofern TKIP und nicht AES-CCMP verwendet wird.
WiFi ist generell nicht auf lokale Räumlichkeiten begrenzt und kann daher von jedermann in Funkreichweite aufgezeichnet werden. Eine Toolbox für Pentest-Maßnahmen, welche die notwendigen Features enthält, findet man u.A. in Metasploit.
-> Anders, als von einigen Medien suggeriert: Entgegengewirkt werden kann dem aus meiner Sicht hier nur auf der Clientseite, mit aktualisierter Software, damit die mehrmalige Verwendung des Nonce unterbunden wird. Accesspoints selbst haben keinen Einfluss auf die korrekte Umsetzung durch den Client*. Sie bekommen davon in der Regel (bislang) auch nichts mit und funken fleißig weiter. Dennoch gibt es auch bei ihnen ein paar Ansatzpunkte.
*Anmerkung: Die Unterstützung von 802.11R/Fast BSS Transision/Fast Roaming (und das seltener verwendete 802.11s) erleichtern den Angriff. Es ist ratsam, die Funktion am Accesspoint/Controller zu deaktivieren, bis ein Patch verfügbar ist.
Accesspoints
In Accesspoints selbst sind Löcher zu stopfen, wenn sie ebenfalls selbst als Client auftreten. Dieses ist in vom Standardbetrieb abweichenden Konfigurationen üblich, z.B. dem „Repeaterbetrieb“ (in größeren Haushalten und Wohnungen – meine Meinung zu dem Plaste-Mist sollte bekannt sein), dem „Mesh-Betrieb“ oder bei „Richtfunkstrecken“. Alle derzeit verfügbaren Patches der Hersteller zielen auf dieses Szenario.
Noch exponierter ist der Verkehr, wenn nicht einmal „AES/CCMP“ eingesetzt wird, sondern das noch ältere TKIP Verfahren. Dann ist mit der KRACK-Methode quasi überhaupt kein Rechenaufwand notwendig. Ebenso kann die Unterstützung von Fast-Roaming/Fast BSS Transision/802.11R die nachträgliche Entschlüsselung des Verkehrs fördern. Es ist also ratsam, jenes Feature im Moment zu deaktivieren.
Die Aussage, Fritzboxen oder andere Heimplaste seien von der Lücke generell ausgeschlossen, ist riskant, da deren Grundeinstellung durch deren Nutzer schon problematisch sein kann.
Da im schlimmsten Fall durch den Angreifer ein Fallback erzwungen werden kann, sofern die Firmware oder die Hardware des Anwenders mitspielt, ist das besonders bei Haushalten mit eingesetzter Chinaplaste (z.B. Webcams) problematisch.
Es ist notwendig, mindestens mal die Minimalvoraussetzungen des Accesspoints oder des „Speedports“ in Sachen Verschlüsselung zu überprüfen. TKIP gehört sowieso verboten, siehe hierzu auch mein deutlich älterer Artikel zu einem ähnlichen Thema WPA1/2: Link.
Erschwert wird das Entschlüsseln des Verkehrs, wenn PMF (Protected Management Frames, Feature in modernen Accesspoints) eingesetzt oder sogar erzwungen werden. In diesem Fall kann die Reassociation der Clients durch Störung der sonst unverschlüsselten Managementframes von Angreifern nicht mehr so einfach forciert werden. Exponierte Clients werden über dieses Verfahren leichter ausgeschlossen. Das Feature, welches möglicherweise von einem Controller bedient wird, verringert jedoch die Übertragungsleistung (=schlecht für Netflix).
-> Setzen Sie generell AES/CCMP ein und erzwingen Sie dieses. PMF erschwert das Entschlüsseln. Deaktivieren Sie 802.11R, bis ein Patch des Herstellers verfügbar ist.
Clientseite
Im großen und ganzen fällt im schlechtesten Fall lediglich die Transportverbindungsverschlüsselung (auf Hardwareebene) selbst weg, sofern man angegriffen wird. Auf Deutsch: Die Sicherheit der Verbindung fällt also auf den Stand der offenen WiFi Hotspots bei McDonalds zurück. Dem Netzwerk kann lediglich, mangels Bekanntheit des Zugangsschlüssels, nicht beigetreten werden. Laut Mathy van Hoef ist jedoch eine Veränderung unverschlüsselter Inhalte möglich.
Exponierte Clients sind in der Masse zukünftig wohl eher ältere Android Geräte und Cloud-Chinaplaste. Nicht jedoch iOS, Windows und Mac mit aktuellem Patchstand, da sie i.d.R. die mehrfache Schlüsselverwendung nach den aktuellen Sicherheitsupdates bereits unterbinden.
So ganz sicher ist das jedoch nicht, MDM-Lösungen können hier besonders in BYOD-Szenarien helfen, um ein aktuellen Versionsstand der Endgeräte zu erzwingen.
WiFi-„Sicherheitskameras“ aus China, welche in „zu privaten Umgebungen“ eingesetzt werden, sind da schon eher ein gutes Negativbeispiel für diese Problematik.
Generell sollten auf Anwendungsebene TLS-Verbindungen (z.B. https:// im Browser) bei Datenverkehr der Anwender eingesetzt werden, um den Inhalt der Übertragung zu sichern. Dies ist z.B. immer der Fall bei Online-Banking, anders als besonders in den schlecht recherchierten Beiträgen der privaten Medien suggeriert.
Ungesicherte Übertragungen, wie z.B. unverschlüsseltes FTP oder POP3, sollte man in Wifi’s jedoch tunlichst unterlassen. Hilfreich ist die Verwendung von VPN-Tunneln zu einem bekannten Router oder dem Company-VPN-Gateway des Arbeitgebers. Von „irgendwelchen VPN-Anbietern“ oder VPN-Apps rate ich generell ab.
Alles in allem hat für mich die WPA2-Lücke keinerlei Auswirkungen, da ich meinen eigenen Datenverkehr grundsätzlich durch eine weitere Tunnelschicht sichere und auf ungeschützte Verbindungen verzichte. In fremden Netzen tunnele ich generell nach hause. Möglicherweise hat dieses jedoch Auswirkungen auf Menschen, jene sich mit der Materie weniger auskennen.
Es macht also Sinn, auf die Wichtigkeit der Anwendungsverschlüsselung bei Freunden, Bekannten und Familie hinzuweisen, so dass der eigentliche Weg der Pakete egal ist. Aluhüte tun das, spätestens seit Snowden.
Beispiel 1: POP3
Nutzt der Anwender ungeschütztes POP3 zum Abholen seiner Emails ist das doof. Erstens wird der Inhalt seiner Email sichtbar, zweitens sind die Anmeldedaten am Server bekannt und können für den Spamversand verwendet werden. Es sollte keine ungesicherte Kommunikation für den Emailversand- und Empfang genutzt werden.Beispiel 2: IMAPs/Exchange EWS/ActiveSync
Nutzt der Anwender dieses Protokoll zum Abholen der Emails, so ist die Übertragung grundsätzlich gesichert. Es können weder die Anmeldedaten, noch die Inhalte mitgelesen werden. Die Anwendung ist geschützt.Beispiel 3: Unbekannte, fiktive Dating App XYZ auf einem Smartphone
Nutzt der Anwender eine mir unbekannte, fiktive Dating App, welche den Datenverkehr vom und zum Server unverschlüsselt überträgt, ist der Inhalt lesbar. Die App sollte gemieden werden.Beispiel 4: Ungesichertes Webforum
Nutzt der Anwender ein Web-Forum, welches ohne http Verschlüsselung erreichbar ist, so sind seine Anmeldedaten und der Inhalt seiner auch privaten Posts sichtbar. Das Forum/Die Webseite sollte gemieden werden.
Das war’s soweit, mit möglichst einfachen Worten.
Fazit: Die Diskussion in den Medien geht am eigentlichen Problem (fehlende Sicherheitsaktualisierungen am Client) vorbei, während andere Probleme zu wenig Aufmerksamkeit bekommen, wie z.B. die Problematik in Infineon Chips zur Signatur von Dokumenten, Personalausweisen der elektronischen Gesundheitskarte oder in TPM (Link).
Die technisch beste Erklärung zu KRACK ist derzeit bei Rapid7 verfügbar.