 Wir haben dann, sind sie hier richtig, weil wir übersetzen den Vortrag, den WPA2-Vortrag ins Deutsche auf diesem Kanal und genau hier. Nettie studiert Formatik und Kryptografie und er hat in diesem Bereich einige Angriffe schon realisiert, insbesondere im drahtlosen Sektor. Und heutzutage, heute wird er uns zeigen, dass alle unsere WLAN-Geräte angreifbar sind, insbesondere die, die Linux oder Android benutzen. Also ich möchte jetzt gar nicht über die technischen Details reden, weil das seinen Job ist. Aber wenn ihr nur ein bisschen mehr darüber lernen wollt, dann hat er seinen Research Paper und die Skript in Fahrplan verlinkt. Also ein großer Runde Applaus für Metie von Hof. Vielen Dank für die Einführung und vielen Dank dafür, dass Sie hier sind, obwohl das schon so spät ist. Vielen Dank an den CCC, dass ich hier reden darf. Heute werde ich über meine Forschung über WPA2 reden und ihr habt wahrscheinlich schon darüber gehört die Crack Attacks. Die Geschichte dieser Forschung ist relativ interessant, weil ich während meiner Doktorarbeit die Sicherheit von drahtlosen Netzwerken erforscht habe. Während meiner Verteidigung der Doktorarbeit, als ich so fertig war mit der Doktorarbeit, einer der Professoren hat gefragt, ob WPA2 mit IS tatsächlich sicher ist und darauf habe ich so geantwortet, ja, es sieht so aus, 14 Jahre lang und es hat immer funktioniert, solange man ein vernünftiges Passwort nutzt. Es gibt keine bekannten Verwundbarkeiten, außerdem gibt es ein paar mathematische Beweise für den Handshake. Jedoch, als ich ein paar Jahre später an OpenSD Code geschaut habe, habe ich mir in dieser Funktion angeschaut und dort wird der Verschlüsselungsschlüssel beim Treiber installiert. Aber dann habe ich mich gefragt, was passiert, wenn das zweimal aufgerufen wird und dann habe ich mir gedacht, es wird neu installiert, der Schlüssel. Aber was passiert dann wirklich? Diese Frage hat dazu geführt, dass ich den Angriff gefunden habe, den ich gefunden habe und das hat zu diesem Angriff geführt. Und das zeigt, wie ich in meiner Doktorverteidigung falsch war. Um den Angriff zu erklären, möchte ich den Vierweger Handshake anzeigen. Dann werde ich den praktischen Auswirkungen meines Angriffs reden und dann bei ein paar Mythen aus dem Internet reden und dann haben wir ein paar Sachen, die wir daraus gelernt haben aus der Forschungsergebnissen und aus dem, was wir herausgefunden haben. Das ist uns den Angriff gegen den Vierweger Handshake anschauen. Was genau ist dieser Vierweger Handshake? Der Vierweger Handshake, der Austausch wird immer benutzt, wenn man sich mit einem weder einen Netzwerk verbindet. Ob es jetzt bei einem normalen Home-Netzwerk mit einem ausgeteiltem Passwort ist, aber auch wenn man sich auf ein Enterprise-Netzwerk verbindet und die Aufgabe davon ist festzustellen, dass man den richtigen Passwort weiß und außerdem wird der Passwort ausgehandelt. Und wie ich es gesagt habe, der Handshake scheint richtig sicher zu sein, weil es keine Angriffe gibt, die bekannt sind, wenn man davon ausgeht, dass ein sicheres Passwort benutzt wird. Und außerdem, der Vierweger Handshake ist bewiesen sicher. Und der Verschlüsselungsalgorithmus danach, AES, CCMP, ist auch formal als sicher bewiesen worden. Aber trotzdem haben wir einen Angriff gefunden, obwohl wir diese ganzen formalen Beweise haben, wo das Protokoll seit Jahren benutzt wird. Was ist da schiefgelaufen? Um das ein bisschen näher zu erklären, werde ich erklären, wie der Vierweger Handshake funktioniert, der Vierweger Austausch. Wir haben den Kleinen auf der rechten Seite und den Access Point auf der linken Seite. Um den Vierweger Austausch zu beginnen, muss ein vorher ausgeteiltes Geheimnis existieren. Zu Hause ist das im Endeffekt das Passwort von dem Netzwerk, aber wenn man ein professionelleres Netzwerk hat, z.B. wenn man ein benutzener Mund, ein Passwort benutzen muss, dann wird 8.02, z.B. Radiosauthentifikation, verwendet. Die Details sind jetzt nicht so wichtig, aber nach dieser Authentifikationsphase existiert ein geteiltes Geheimnis zwischen dem Kleinen und dem Zugriffspunkt, dem Access Point. Wenn wir dieses geteiltes Geheimnis haben, können wir den Austausch beginnen. Die ersten Nachrichten übertragen eine zufällige Zahl zwischen den beiden Geräten. Der Access Point wird eine Access Point in der Anons erstellen und diese an den Kleinen weiter senden. Der Kleinen wird daraufhin seiner eigenen Zufallzahl erstellen. Das Subplicant Nerns ist Nerns und wird diese Zufallzahl auch zu den Access Points senden in der zweiten Nachricht. Jetzt, wo beide Geräte die Zufallzahlen der jeweils anderen haben, wird ein Session Key erstellt. Wir benutzen den Pre-Shared Key, benutzen zusätzlich die beiden geheimen Zahlen und dann wird der PxDK erstellt. Ich möchte jetzt hier ein bisschen genauer feststellen. Man hat vielleicht davon gehört über Schlüssewiederbenutzung mit Nerns Neubennutzung. An der Stelle möchte ich bemerken, dass es nicht um die S-Nerns oder die A-Nerns geht. Also A-Nerns und S-Nerns, nicht vorhersehbar, also vollkommen zufällig. Nerns-Reviews, welcher passieren wird, ist während des Verschlüsstungsalgorithmuses. Das ist die erste Stufe des 4-Way Handshakes. In der zweiten Stufe des 4-Way Handshakes. Dabei reden Sie darüber, dass Sie den gleichen Schlüssel tatsächlich benutzt haben. Und der Server sendet dem Client eine Nachricht, der Client verifiziert ist und der Client sendet zurück zum Access Point, so dass auch der verifizieren können. Sobald diese 4 Nachrichten ausgetauscht werden konnten, werden beide Client und Access Points den ausgetauschten Schlüssel benutzen und installieren in den Treiber. Jetzt haben wir den 4-Way Handshake beschrieben. Nun brauche ich bloß noch eine weitere Sache beschreiben, nämlich wie funktioniert Verschlüsselung in einem WLAN-Netzwerk. Hier ein Beispiel, wir haben hier ein bisschen plaintext-Daten. Das Allerste, was wir tun werden, ist, wir nehmen den Sitzungsschlüssel und wir werden das mit der Paketnummer verbinden. Die Paketnummer wird in dem Fall NARS genannt. Die Paketnummer wird immer wieder inkrementiert um 1 und die Idee bei dieser Sache ist, dass wir eine einzigartigen Schlüssel pro Paket haben. Die Verschlüsselung funktioniert relativ einfach. Wir nehmen diesen Key, wir machen daraus ein Streamshyper, wir exorn die plaintext mit dem Keystream und dann kriegen wir den Verschlüsseling da. Dazu kommen noch ein bisschen Paketheader mit NARS und so weiter. Und dann kann der Empfänger das Paket entschlüsseln. Streamshyper mit einzigartigen Schlüssel pro Paket. Es gibt ein einziges Voraussetzung in diesem Schema, nämlich, dass die NARS in jedem, in der Session bloß einmal benutzt wird, solange wir den gleichen Session Key haben. Ansonsten kann man nämlich bei, wenn man die NARS neu benutzt, kann man wiederholt gesendete NARSen die Pakete fälschen. Ist diese NARS tatsächlich bloß einmal benutzt, ist jetzt die Frage, die wir uns stellen. Es wird immer um eins erzählt, erhöht, deswegen ist die einzige Frage, die bleibt, womit wird diese Paketnummer initialisiert. Und die Antwort dazu ist, klar, die NARS wird mit null initialisiert. Zuerst macht das sehr viel Sinn. Wir initialisieren die Nummer mit null und wir erhöhen sie bei jedem Paket um eins. Also klar, wird diese NARS, wird jede NARS-Varioure genau einmal verwendet werden. Leider ist das nicht der Fall. Und der Grund, weshalb diese NARS-Variou wiederholt wird, oder manchmal mehr als einmal benutzt wird, ist, weil wir eine Wiederinstallation des Sessions PDKs erzwingen. Und dann wird die NARS wieder auf null gesetzt und dann werden die NARS-Varioues erneut verwendet. Ich könnte mir eine Schlüssel erneut installieren zu zwingen. Lass uns doch mal diesen Beispiel anschauen, mit dem Kleinen auf der linken Seite und dem Access Point auf der rechten Seite. Wir haben auch noch zusätzlich eine Angreifer, die in der Mitte sitzt. Der Angreifer wird einen sogenannten Kanalbasierten Man in the Middle Position einnehmen. Der Angreifer ist jetzt noch nicht in der Lage, die Pakete zu entschüsseln. Der Mittel ist ausschließlich da, dass wir zuverlässig Pakete abfangen können und sie nochmal erneut senden können. Wir können eine Verschüsselung noch nicht aufbrechen. Wie wird diese Position kommen? Wir nehmen alle Punkte, die der Access Point zum Beispiel auf Kanal 6 sendet. Alle Pakete, die er sendet, empfangen wir sie und er senden sie erneut auf einem anderen Kanal, zum Beispiel Kanal 1. Damit klonen wir den wirklichen Access Point auf einem zweiten Kanal. Dann zwingen wir den Angriffen des Victims auf unseren eigenen Kanal. Wenn jetzt eine Anreifer diese Man in the Middle Position einnimmt und der ersten Stage des vier Weger handshakes, dann wird gar nichts modifiziert. Egal, welche Identifizierung er benutzt, wir leiten die Pakete einfach weiter. Und auch die ersten drei Pakete des Three Way Handshakes. Der Angriff beginnt, wenn Techline das Paket vier sendet. Und anstelle die Nachricht weiterzuleiten zum Access Point, senden wir es nicht weiter. In unserer Situation bedeutet das, wir blockieren die Nachricht einfach. Was hier daran interessant ist, dass von der Sicht des Clients war der Handshake erfolgreich. Es hat die Nachricht vier bekommen, es hat Nachricht fünf beantwortet und es vermutet, dass der Handshake fertig ist. Das heißt, der Schlüssel wird fertig installiert. Also ein bisschen mehr Platz. Der Client denkt, dass der Handshake fertig war, aber der Access Point hat die Nachricht vier noch nicht bekommen. Und der Access Point wird versuchen, die Verbindung wieder aufzubauen und sendet die Nachricht drei erdneut. Und wir als Anreifer werden diese Nachricht dem Client weiterleiten, der Client wird die wiederholte Nachricht akzeptieren und dann sagt der Wifi Standard, wenn man eine gesendete Nachricht drei hat, dann wird eine neue Nachricht vier gesendet. Und danach wird der Verschlussschüssel erneut installiert. Wenn wir diese erneut gesendete Nachricht drei bekommen, wird eine neue Nachricht vier gesendet. Aber diese neue Nachricht vier ist schon auf der Link Layer verschlüsselt und diese ganzen Handshake Nachrichten sind ganz normale Datenframes und wir haben schon ein Verschlüsselungskey und können damit schon Datenframes verschlüsseln. Alle Implementationen, die wir getestet haben, werden diese vierte Nachricht in einer verschüsselten Art und Weise senden. Der weder einen Standard, wenn die Nachricht erneut gesendet wird, muss laut Spezifikation Klartext gesendet werden, aber alle Implementationen, die wir getestet haben, wird diese Nachricht verschüsseln. Und dieses Problem werden wir später auszunutzen. Wenn der Klein die Nachricht drei erneut empfängt, wird er den Verschlussschüssel erneut installieren und damit wird diese Übertragung sonst zurückgesetzt. Also wenn der Klein jetzt ein neues Datenframe sendet, dann wird es denselben Non-Saleo erneut versenden. Und wir werden es eins erneut verwenden und damit ist Non-Treeuse und wir haben Keystream-Euse und jetzt können wir das benutzen, um das Datenframe zu entschüsseln. Wie werden wir das jetzt genau missbrauchen, weil wir müssen den Keystream, der verwendet wird, aufnehmen. Und wir haben hier die Nachricht vier, die wird in Klartext gesendet und eine erneute Sendung in eine verschlüsselten Art und Weise. Das ist ein kleiner Unterschied zwischen diesen beiden Nachrichten, aber wir haben ein Nachricht und ein Plaintext und das Einzige, was wir machen müssen, ist, die beiden mit X-Ohren mit anderen verknüpfen. Dann haben wir den Keystream für die Non-Swert 1. Und die Datenstream hier unten wird auch den Wert 1 benutzen. Das heißt, wir können wieder X-Ohr verwenden und damit können wir die Pakete entschlüsseln. Und damit haben wir WPR2 besiegt. Vielen Dank. Das beschreibt den Angriff gegen vier Wege Handshake. Der vier Wege Handshake ist nicht die einzige Form, dass Wlan Handshakes die verrundbar ist, sondern es gibt auch noch andere. Die werde ich jetzt nicht alle im Detail erklären. Wenn ihr die genauen Details wissen wollt, dann lese bitte mein akademisches Papier. Ich werde jetzt bloß die Idee hinter den Handshakes erklären. Der Group Key Handshake ist auch verwundbar. Der Group Key Handshake wird verwendet, um den Group Key von dem Access Point zum Client zu bringen. Dieser wird für Broadcast verwendet. Der FD Handshake wird verwendet, wenn zwei Access Points desgleichen, das gleiche Netzwerks miteinander reden wollen. Ein weiterer Handshake, der verwundbar ist, ist der TDLS Handshake, der passiert, wenn zwei Clients miteinander reden wollen. Im Folgenden werde ich den praktischen Einfluss dieser Attacke weiter erklären. Ein allgemeiner Schlüssel Neuverwendung ist im Folgenden problematisch. Die Device kann Smartphone, Laptop oder Toaster sein, selbst die haben Wifi. Oder es kann natürlich auch ein Access Point sein. Wenn ein Client oder ein Access Point verrundbar ist, dann ist das erste was passiert. Wenn das Gerät irgendwann verschüsselte Datenpakete sendet, dann können wir das Gerät dazu zwingen, Dinos neu zu benutzen. Aber das ist nicht das einzige was wir tun können. Wir können auch verschüsselte Pakete zu dieser Device replayen, also Neu-Sendung. Warum können wir das tun? Weil nicht nur die Nons-Value resetted wird, sondern auch die Replay-Value wird auch resetted. Diese Replay-Value geht normalerweise darum, dass man Replay-Pakete erkennt. Da sie aber zu Null zurückgesetzt wird, können wir einfach Pakete neu senden. Das ist die allgemeine Einfluss von Key-Neubennutzung. Aber es gibt auch noch andere Faktoren, die den Einfluss beeinflussen. Eines der größten Probleme damit ist, dass die Verschlußung der Bewendungswirt, das ist AES CCMP. Es gibt keinerlei praktikable Angriffe. Das einzige was wir tun können, ist Replayen und Decrypten. Forgen können wir die Pakete damit noch nicht, also wir können sie nicht spoofen, wir können sie nicht. Uns neue Pakete ausdenken. Das ist ein Dream-Seifer, das heißt wir können damit keine Pakete neu. Es gibt aber auch noch WPA TKIP, das ein anderes Verschlußung zu fahren. Dort ist es möglich, dass neue Frames erstellt werden können, als seien sie von dem Gerät, das wir angreifend gesendet wurden. Bei AES CCMP ist das nicht möglich und da das häufigste Protokoll ist, hatten wir der Glück. Es gibt auch ein neues Algorithmus, der langsam verwendet wird, der wird langsam unter dem Namen Y-Gig veröffentlicht. In dieser Situation ist der Key-Reinstallation-Angriff der schlimmste. Das heißt wir können den Ausentifizierungs-Schüssel herausfinden und wenn wir CCMP verwenden, dann wird derselbe Verschlußung in beide Richtungen benutzt. Das heißt bei CCMP können wir Frames vom Kleinen zum Exospawn senden, also auch solche, die vom Exospawn zum Kleinen gesendet werden. Wobei WPA TKIP nur Pakete neu erstellen können, die so aussehen, als seien sie von dem angegriffenen Gerät versendet werden. Es ist ein bisschen komisch, weil CCMP ist der neuste Standard, der beste und da ist der Angriff noch viel schlimmer. Darum haben wir Glück, wenn wir in zehn Jahre später gefunden hätten und all diesen neuen Verschlußungsverfahren benutzen würden, dann wäre das Problem viel größer. Also dem ist doch so ein bisschen die Frage, welchen Anshake wir benutzen. Wenn wir den Group-Handshake angreifen, dann können wir nur Broadcast und Multicast Frames senden. Warum können wir die nicht entschüsseln und der Grund dazu ist, dass wenn wir den Group-Handshake angreifen, dann können wir nur den gegen Kleinen angreifen und der sendet nie Broadcast Frames. Warum sendet der Kleinen nie Broadcast Frames? Der Grund ist relativ einfach. Wir haben ein Netzwerklayout wie das hier und der Kleinen links möchte ein Broadcast an alle anderen senden. Der Kleint wird den DataFrame als Unicast zum Access-Gerät senden und wird ihn noch nicht als Gruppen unter dem Medium-Gruppen-Schlüssel verschlüsseln. Der Access-Point wird dieses zu allen angeschossenen Kleins senden und dort wird der Gruppen-Schlüssel zuerst verwendet werden. Es führt dazu, dass alle, die vom Access-Point zugegriffen werden können, das richtig Paket bekommen. In dieser Situation greifen wir nur den Kleint an. Das heißt, wir können nur Broadcast Frames erneut senden. Damit ist der Angriff noch mal weniger schlimm. Broadcast Data erneut zu senden ist in der Regel weniger schlimm. Aber manche Haumautomatisierungsgeräte könnten das versenden, zum Beispiel den Lichter ein oder ausschalten. Das heißt, die Situation ist jetzt nicht so schlimm, aber es kann auch verwendet werden, je nachdem, welche Geräte man verwendet, welche Protokolle man verwendet. Der andere Handshake, der angegriffen werden kann, ist der 4-Wegel-Handshake. Das haben wir schon diskutiert. Wir können die Kleins angreifen. Das heißt, wir können Pakete erneut senden und entschlüsseln. Und abhängig davon, welcher Verschlüsselungsverfahren verwendet wird, können wir auch unsere eigenen Frames versenden. Der FT-Handshake ist aber interessanter. Das wird benutzt, wenn man von einem Access-Point zum nächsten roamed. Und hier können wir den Access-Point angreifen. Und darüber hinaus, wenn wir den alten Verwenden brauchen, brauchen wir nicht mehr die Mittel-Situation. Lass uns doch mal mit diesem Beispiel erklären. Der Kleinmächter verbinden und der FT-Handshake beginnt. Auf dem hohen Level ist der FT-Handshake das gleiche wie der 4-Wegel-Handshake. Aber der große Unterschied ist, dass der FT-Handshake der Kleint der erste Handshake Nachricht sendet. Beim 4-Wegel-Handshake war es genau andersrum. Das heißt, das ist quasi das gleiche wie der 4-Wegel-Handshake. Nur, dass es andersrum passiert. Wir tauschen wieder zufällige Zahlen zwischen den Geräten aus. Sie installieren in den Session Key. Und am Schluss bestätigen sie noch, dass sie den gleichen Verschlüssel verhandelt haben. Ich möchte noch ein bisschen über die letzte Phase reden. Die dritte Anfrage wird vom Klein gesendet. Das ist ein Reassociation Request. Und dann sind der Server die Antwort. Und daraufhin wird der Session Key installiert. Daraufhin können wir dann verschüsselte Datenframes senden. Was wir jetzt als Anreffer tun können, ist, wir können den Reassociation Request und Replay in ihn. Hier gibt es nämlich keine Replay Protection für den Handshake. Das heißt, wir nehmen einfach den Frame, dieses Paket, und wir senden es nochmal an den Access Point. Der wird es akzeptieren und es wird eine neue Assoziation vorgenommen. Bisher ist es noch kein Problem, aber das Problem hier ist, dass der Access Point den Session Key neu installieren wird. Und das ist genau das Problem. Hier wird die Nose wieder auf 0 zurückgesetzt. Daraufhin wird wieder die Nose Value 0 benutzt, um die Datenpakete zu senden. Das heißt, wir können wieder den Keystream recoveren und damit weiterangreifen. Wir brauchen hier keine Man in the Middle Position, weil hier keine Replay Protection existiert. Beim 4WG Handshake gibt es einen Sequence Counter, der das verhindert. Aber beim FD Handshake gibt es sowas nicht. Wir können die Nachrichten einfach nehmen und einfach neu versenden. Wir brauchen keine Man in the Middle Position, um die Returns Machine zu triggern. Das ist die Erklärung für den FD Handshake. Eine weitere Sache, die den Einfluss unserer Angriff beeinflussen kann, ist das Betriebssystem unseres Geräts. Zum Beispiel iOS und Windows sind zusammen vier Wege Handshake nicht angreffbar. Sie nehmen keine Re-Transmissions von der dritten Nachricht an. Folglich können wir sie nicht benutzen. Die erste Bemerkung, die ich dazu machen möchte, ist, dass wir den Group-Cree-Handshake immer noch attakieren können. Wenn wir uns iOS 11 haben, dann wird wieder die verwundbare 4WG Handshake verwendet, sodass wir es dann wieder angreifen können. Linux ist nicht besonders viel besser. Der WLAN-Client ist WPR-Supplicant, sowohl auf Android als auch auf anderen Linux. Wenn wir auf dieser Plattform ein Reinstallation verursachen, dann wird es einen ausgenullten Verschlüssel installieren. Ab diesem Punkt ist es natürlich vollkommen trivial, die Daten zu entschlüsseln, die der Client sein wird. Warum passiert das? Ich kann es sogar ein bisschen verstehen, warum das falsch gelaufen ist. Also insofern werde ich erzählen, was die Implementation falsch tut. Wie kommt es also, dass ein Nullschüssel installiert wird? Wir haben jetzt ein Android-Gerät, das sich mit einem Access-Point verbindet und lassen uns ein bisschen mehr den Android-Installationen anschauen. Wir haben zwei Intentitäten, wir haben den WPR-Supplicant, das ist das Handshake-Icon und wir haben noch eine weitere Intentität, das ist der Linux-Colonel, der dafür die Datenframes verschlüsseln wird. WPR-Supplicant wird nur den 4-Wager-Handshake durchführen und natürlich vermuten wir, dass wir als Angreifer in der Nähe sind und wir haben wieder diese man-in-the-middle-Position. Was müssen seine Angreifer machen, um diesen Nullschüssel zu installieren? Die erste Phase des 4-Wager-Handshakes lassen wir einfach durchlaufen und wenn der Access-Point die 4te Nachricht sendet, dann leiten wir sie weiter an Android, Android wird die Nachricht 4 senden und wir werden Android die Nachricht 4 blockieren. Das heißt, der Access-Point kriegt sie nicht. Die selben Situation wie beim 4-Wager-Handshake vermutet ist, dass alles fertig ist und installiert den Verschlüsselungs-Key. Es befindet den Linux-Colonel den neuen Schlüssel im Treiber zu installieren. Der Treiber selber wird eine Kopie des Verschlüsselungs-Key machen und ihn lokal speichern und dann kann der Treiber die Frames-Schlüssel und die Endschüssel. Das heißt, wer PR-Supplicent muss diesen Schlüssel nicht weiter speichern, also wollte sie ihn löschen. Was als Nächstes passiert, wenn wir den Angriff weitergehen, ist, dass der Zugriff die Nachricht 3 erneut sendet, weil es die 4 nicht bekommen hat. Es akzeptiert die Nachricht 4 mit Nachricht 4 und das wird den Linux-Colonel wieder sagen, hallo, installiere diesen Verschlüsselungs-Key an dieser Adresse im Arbeitsspeicher. Der Bereich ist inzwischen Nullen, weil der Schlüssel gerade gerecht wurde. Also jetzt befindet er den Linux-Colonel einen Null-Schüssel zu installieren. Der Linux-Colonel und Treiber hat damit überhaupt kein Problem und wird den Null-Verschlüsselungs-Schüssel installieren. Jetzt werden alle Daten mit einem bekannten Schlüssel verschlüsselt werden und wir können auch beliebige Traffic zum Kleinen senden. Wir sind ein Rogue Access Point und wir können beliebige Daten an den Kleinen senden und die Daten manipulieren. Thank you. Also, die Frage ist, ist mein Gerät angreifbar? Und die eigenen Geräte können mit diesem Skript getestet werden, das ist auf GitHub. Ich habe das Skript mit Kali-Linux und Arch Linux getestet, auch bei Ubuntu. Also, versucht, eins für diesen Distributionen zu verwenden und ich empfehle auch ein WLAN-Dongle, das wir ja schon mal getestet haben. Wenn unser Testskript mit alteren WLAN-Geräten verwendet wird, dann krebt das da eventuell ein paar Bugs, die dazu führen, dass unser Skript nicht ordentlich durchläuft und die andere Möglichkeit, dass das Skript ordentlich läuft, ist, die Hardware-Verschlüsselung auszuschalten. Und damit können Kleingeräte getestet werden, den 4-Way-Handshake und den Group-Key-Handshake, und gerade auch den Access Point-Testen gegen FT-Verschlüsselungsangriffe. Wenn ihr sehen wollt, welche Geräte angreifbar sind, dann werdet ihr sehen, dass ziemlich viele Kleins immer noch angreifbar sind mit unseren Angriffen. Glücklicherweise können wir den Access Point so modifizieren, dass solche Angriffe gegen Kleinen durchgehen. Wir können den Access Point modifizieren, sodass diese Nachricht 3 nie erneut sendet und das ist auch nie die erste Nachricht des Gruppenschüssel-Handshakes sendet. Und ein so modifizierter Access Point, dann können auch die meisten Angriffe nicht gegen den Kleinen gefahren werden. Es gibt immer auch ein paar Randfälle, wo der Kleinen angegriffen werden kann, aber die sind sehr selten. Und wenn wir unseren Access Point so modifizieren, dann sind die ganzen Kleins relativ sicher. Weil wir die einige Nachricht nicht mehr erneut senden, kann es sein, dass insbesondere in einer Nachricht mit einer unsicheren, schlechten Verbindung kann es sein, dass der Handshake viel schlecht, weil es einfach schwierig ist. Wenn ihr einen Router habt, der gegen unseren Angriff sicher ist und der Herrscher sagt, dass der dagegen ist, dann bedeutet es doch lange nicht, dass der Access Point diese Gegenmethoden verwendet. Das sind einfach zusätzliche Verteidigungsmethoden. Nur wenn der Herrscher sagt, dass unsere Patches auch die Kleintangriffe schützt oder gegen die Kleintangriffe schützt, dann ist der Kleint auch geschützt. Jetzt möchte ich noch ein paar Mythen aufklären, die im Internet herumfliegen. Zuerst, manche Leute behaupten, dass es reicht, nur den Kleint oder nur den Access Point zu patchen. Aber das ist nicht richtig. Beide sind verwundbar und sowohl Kleint als auch Access Points müssen Patches installieren. Auch wenn der Access Point den Patch installiert, sind die Kleins immer noch verwundbar, falls sie selber verwundbar sind. Das heißt, man kann das trotzdem verhindern mit den zusätzlichen Patches, die ich von denen ich gerade erzählt habe. Manche Leute sagen, ja, das funktioniert nicht so richtig, weil man ja relativ dicht zu einem Netzwerk sein muss. Aber das stimmt nicht. Wir können besondere Antennen benutzen, um von ganz weit weg WLAN-Verkehr über ganz lange Verbindungen machen. Diese Antennen können wir z.B. aus einem alten Metallgegenstand bauen. Das heißt, man muss nicht physisch nah an dem Netzwerk sein, um es anzugreifen. Ein anderer komische Bemerkung zu der Angriff ist, dass man zum Netzwerk verbunden sein muss. Aber das stimmt nicht. Man braucht das Passwort nicht von dem Netzwerk. Das einzige, was man braucht, ist, dass man nah dran ist. Man muss ein bisschen Pakete manipulieren können, aber man muss überhaupt nichts über das Netzwerk wissen. Man muss nur wissen, das Netzwerk ist da. Man muss die Kleinz kennen, und man kann anfangen anzugreifen. Eine weitere Bemerkung ist, Dinge, die direkt nach dem Handshake passieren. Das ist nicht wirklich interessant, weil an diesem Punkt senden die Devices so etwas wie eine neue TCP-Verbindung oder DNS-Request oder DHCP-Request. Es ist keine sinnvolle Information gesendet. Leider ist es nicht wirklich richtig, weil wir als Angreifer einfach den Kleinz ein bisschen das Internet benutzen lassen und ihn TCP-Verbindung öffnen lassen usw. Während der Kleinz das Abwahlbrows, können wir einen neuen Four-Way-Handshake enforzen, was darauf hinfolgt ist, dass die all die gecuten TCP-Streams neu gesendet werden. Das heißt, wir können als Angreifer einfach auf vermutlich interessante Daten warten, ihn disconnecten und den neuen Four-Way-Handshake angreifen. Dann können wir auch die interessanten Daten entschüsse. Noch eine weitere Sache, die das schwer machen könnte, ist, dass Channel-Based-Mannesmüll ein bisschen schwer ist. Aber nein, man muss nicht eine stärkere Signalstärke haben, als der echte Access-Point, weil wir besondere WLAN-Pakete senden, Channel-Switch-Anounzens, welche vom Klein verlangen, dass der Channel gewechselt werden soll und damit unseren attakierenden Access-Point benutzen. Das heißt, wir können einen Klein dazu manipulieren, unseren Access-Point zu benutzen. Diese Frames werden nicht signiert, das heißt, wir können sie einfach fälschen. Andere Leute sagen, die Komplexität des Angriffs ist so groß, dass es ein bisschen Wissen darüber braucht, über WLAN und so weiter. Aber tatsächlich muss man dieses Angriff ja bloß einmal schreiben als ein Script und dann können andere Leute das Script benutzen. Zum Beispiel, das Gleiche gilt ja auch für Stack Overflows, Buffer Overflows und so weiter. Der initiale Proof-of-Concept mag schwer sein, aber nachdem man das gemacht hat und das in Metasploit oder so getan hat, braucht man bloß noch irgendwie ein Scherzskript hinzufügen. Ein weiterer Missverständnis, das ich mich merke, ist, dass wir Leute sagen, wenn man AES-CCMP verwendet, dann ist der Angriff nicht so schlimm. Stimmt auch nicht. Der einzige Vorteil von AES-CCMP ist, dass der Angreifer nicht mehr neue Pakete oder gefälschte Pakete senden kann. Es können immer noch Entschlüsse und erneut senden. Und zum guten Netz, manche Leute sagen, dass Enterprise-Netzwerke dagegen sicher geschützt sind, weil zum Beispiel diesen 4-Wager-Handshake nicht benutzen, aber leider ist das auch nicht richtig. Sogar diese Netze benutzen den 4-Wager-Handshake und können damit auch angegriffen werden. Dann gibt es einige Leute, die sagen, WPA2 ist komplett kaputt, das ist Ende der Welt und wir haben alle riesige Probleme. Es ist auch nicht wirklich der Fall. Wir können diese Vulnerabilities patchen in einem rückwärtskompatibelem Art und Weise. Es ist wirklich eine Frage, was für Geräte man verwendet, im eigenen Netzwerk. Manchmal ist der Impact sehr klein und manchmal ist der Impact sehr groß. Wenn Linux gerät, dann kann ein Angreifer damit machen, was auch immer er oder sie möchte. Das letzte Frage ist, was können wir davon lernen von diesem Angriff und von der Forschung, die dahin geflossen ist. Eine der wichtigsten Fragen und Beobachtungen ist, warum ich diesen Angriff sehr mag, ist, dass der 4-Wager-Handshake bewiesen wurde, dass er sicher ist. IS ist auch bewiesenerweise sicher, aber wenn wir die beiden zusammenverwenden, verlieren wir auf einmal alle Sicherheit. Das ist ein signifikantes Problem. Was es uns beweist, ist, obwohl individuelle Parteien wirklich untersucht wurden und formal analysiert wurden, müssen wir auch die Verbindung zwischen diesen Entitäten überprüfen. Wir müssen auch beweisen, dass die Zusammenarbeit von beiden Werkzeugen sicher ist. Der Beweis des 4-Wager-Handshakes wird der Handshake sehr abstrakt modelliert. Der Beweis, da werden Erneutsennungen von Nachrichten nicht dargestellt. Das heißt, wir müssen sicherstellen, dass wir auch die Verbindung von diesen unterschiedlichen Entitäten analysieren müssen. Aber auch die abstrakten Modelle, die verwendet werden, real sind. Eine weitere Sache, die wir lernen können, ist, dass wir das Protokolle und auch die Implementationen einfach halten sollen. Das heißt, wenn man jetzt WPAS Sublicans 2.6 analysiert, wenn wir uns diese Sachen selber anschauen, dachten wir erst, dass die Schüsselreinstallationsangriffe nicht problematisch sind. Aber als wir die Firmen darüber analysieren, wurden auch gegen diese Version einen Angriff gefunden. Wir haben diesen Angriff nicht gefunden, weil WPAS Sublicans 2.6 ziemlich komplex ist. Es ist sehr komplex, das zu verstehen. Eine Möglichkeit ist, dass das Protokolle einfach gehalten wird. Und das Zweite ist, dass Implementation formal verifiziert werden kann. Natürlich können wir nicht allen Code formal verifizieren, mit diesen ganzen kriptografischen Protokolle, die sehr wichtig sind. Zumindest sollten wir uns die genau genug anschauen. Was auch sehr interessant ist, dass ich ein Dokument der CIA gefunden habe, ist, dass komplexe Implementationen oder Protokolle schlecht sind. Die CIA empfiehlt Leuten, wie man Hintertüren gut implementiert. Wenn man sagt, wenn sie sagen, wie tollen Daten zu uns gesendet werden, ja, verwendet Verschlüsselung, aber keine Regie Funktionalität, weil da so viel der zusätzlichen Features braucht. Und diese zusätzlichen Features sind einfach zu komplex oder führt zu mehr Komplexität und das führt zu Federn. Außerdem muss der Standard genau spezifiziert werden, so genau wie möglich. Der originale WPR2-Standard war ein bisschen wage. Er definierte nicht die State Machine. Sorry, die State Machine definiert, was eine Implementation machen soll, wenn es eine Nachricht empfängt. Es definiert nicht die Reihenfolge, in der die Nachrichten akzeptiert werden sollen. Es ist eine Erweiterung des Standards, die diese Nachrichten besser definiert, aber sogar dieser Standard ist ein bisschen wage. Und weil der originale Standard ein bisschen wage war, dann kann ich IOS und Windows gut verstehen, warum sie den Standard anders interpretiert haben, weil es war sehr einfach, den anders zu interpretieren. Zu diesem Thema, ich erzähle euch, ich leite ein Workshop, der, der, wo ich meine, ja, wie man sich als Protokolle schreibt, also Protokolle, die verschüsseln. Dort, genau, dort könnt ihr vielleicht einen Vortrag subneten, einsenden. Was können wir davon lernen? Wie können wir die Veröffentlichung einer Verwundbarkeit wie dieser koordinieren? Das ist keine normale Verwundbarkeit. Es beeinflusst fast alle Händler von WLAN-Karten. So wie, wie, wieen, wie sagt man zuerst Bescheid? Wie sagt man überhaupt Bescheid? Ich kann euch ein bisschen erzählen über die Strategie, die wir verwendet haben. Wir haben zuerst geschaut, ist das wirklich eine so große Verwundbarkeit? Ist es überall tatsächlich drin? Wir wollten nicht unnötig vom Kontakt hin. Wir haben erstmal ein paar ausgewählte Händler benachrichtigt, aber wir, und dann haben sie gefragt, ob das bei den Händlern auch funktioniert. Und die Händler haben dann geschaut, und tatsächlich unsere Geräte sind dagegen verwundbar. Das heißt, das hat uns bestätigt, dass dieses Problem tatsächlich sehr breit vorhanden war. Und an diesem Punkt haben wir uns gedacht, es ist tatsächlich ein Problem mit dem Standard, und viele, viele Firmen werden ein Problem damit haben. Das heißt, wem werden wir jetzt Bescheid sagen? Natürlich haben wir den großen Firmen alle einen Bescheid gegeben, aber wie haben wir das jetzt gemacht? Wir haben uns auf ein Third-Team verlassen. Sie haben die komplette Sache koordiniert. Eine andere Sache, die man tun könnte, wenn man nicht weiß, wer davon betroffen ist, wir könnten einfach ein Händler fragen, wer vielleicht noch, welche anderen Händler vielleicht auch noch verwundbar sein könnten. Ein Ding, was ein bisschen komplizierter ist hier, man möchte an sich so viel wie möglich Händlern Bescheid sagen, aber man kann irgendwie auch nicht allen Bescheid sagen. Weil wenn man alle benachricht, dann wird die Chance eines Leaks gegen eins konvergieren. Eine Frage ist, wie lange soll man den Herstellern geben, wie viel Zeit soll man über den Geben zwischen sagen und Veröffentlichung? Zu der einen Seite, man kann eine langen Periode geben, dann ist die Wahrscheinlichkeit, dass die ganzen Details veröffentlicht werden, steigt einfach. Auf der anderen Seite, wenn die Embargo-Periode zu kurz ist, dann gibt es nicht genug Zeit, um ein Patch einzufügen. Was wir im Endeffekt gemacht haben, was ich auch in der Zukunft wieder machen würde, ist es schwer, so eine Deadline zu definieren. Entscheidet euch trotzdem für eine Deadline, damit alle Leute wissen, woran sie sind. Außerdem möchte ich jetzt Zert und Ikasi danken, dass sie die ganze Koordination gemacht haben und dass sie dem Cisco, die auch viel gute Informationen gegeben haben. Damit sind wir am Ende des Talks. Wir haben einen Angriff gegen den WPA2-Standard diskutiert. Der spannendste Punkt dieser Research ist das WPA2. Bewiesenerweise sicher war, aber wir haben trotzdem nach mehr als einem Jahrzehnt diesen Fehler gefunden und noch mehr als das ist nicht nur ein theoretischer Angriff, sondern man kann ihn in der Welt benutzen und um dagegen zu schützen muss, sollte man alle Kleins updaten und auch überprüfen, ob die Access-Pollens problematisch sind. Damit haben wir noch ein bisschen Zeit für Fragen und Antworten. Wenn sie irgendwelche Fragen haben, einfach an die Mikrofone gehen. So, do we have any questions? There's mics everywhere. Sind überall Mikrofone im Saal? Directly here in front on mic number one. Ja, Sie meinten, dass GCMP noch stärker angreifbar sind. Wissen Sie, ob es irgendwelche Stabilisierung stattfindet? Wie man andere Angriffen verwendet, die nicht so leicht angriffen werden können? Ja, es gab einige Vorschläge, wie man den Algorithmus da vorschüssen kann, dass die NOS wieder benutzt wird. Soweit ich das verstehe, ist das noch so ein bisschen Forschungsgebiet. Es gibt Verschlossungsalgorithmen, wo NOS-Reuse nicht so schlimm sind. Sie existieren, aber sie werden noch nicht so richtig benutzt. Ja, es gibt für die Standardisierung. In ITF Standardisierung, aber ich freue mich jetzt bei WLAN-Standards, ob dort eine entsprechende Plan, eine entsprechende Version von AS zu verwenden. Würden Sie GCN-Modus verwenden? Ist dieser Zufallsinitialisierungsvektor möglich, wenn man da 96 Bits verwenden würde? Dann wäre der Impact nicht so groß. Also, um die erste Frage zu beantworten, mir ist nicht klar, dass der WLAN-Standard, dass man den Standard modifiziert hätte, einen NOS-Misuse-resistenten Cipher verwenden kann. Es gibt Bestrebungen in die Richtung, aber sie werden zurzeit noch nicht eingearbeitet werden, weil sie zurzeit wird die Technologie noch nicht als so ausgereift angesehen. Wenn ich die zweite Frage richtig verstanden habe, es gibt Verschlossungsalgorithmen, wo die NOS überall random ist. Es gibt zwei Standards für GCN, einer ist deterministisch und der andere ist zufällig. Das Problem mit einem zufälligen Algorithmus ist, dass wir einen vernünftigen Zufallszahlengenerator brauchen, ansonsten können wir mit einem schlechten Zufallszahlengenerator andere Angriffe möglich machen. Es gibt da ein Papier, was andere Angriffe gezeigt werden, weil die NOS dann doch nicht wirklich random ist, weil die Implementierung irgendwie zweimal die gleiche NOS benutzt oder so. Die erste Frage ist, gibt es eine Überlegung, den Standard in Richtung resistent gegen diesen Angriff zu sein? Aktuell gibt es keine Gruppe, die eine Erweiterung dafür versucht zu definieren? Sie arbeiten dran mit der Key Reinstallation? Es gibt immer noch keine große Taskforce, aber sie arbeiten trotzdem dran. Danke für den tollen Vortrag. Nur damit ich es selber verstehen kann, können Sie doch mal zu der Folie mit dem 4-Wegel-Handshake ganz am Anfang gehen? Ja. Der Angriff oder die Handshake selber? Der Angriff. Okay, dann gehen wir mal hier auf diese Folie. Das einzige, was hier herausgenommen wird, ist, dass der Keystream für die Nachricht 4 bekannt ist, alles, was man bekommt. Ja, das ist richtig, aber dann können wir anfangen Frames Datenpakete zu entschliesseln. Der Angriff hat mehrere Optionen. Man kann einfach zum Beispiel immer und immer wieder neue Handshakes forcieren. Dann können wir immer ein Paket entschliesseln. Man kann auch ein bisschen warten mit der Re-Transmission, mit dem erneuten Sinn. Wenn man die entschliesselten Daten kennt, dann kann man tatsächlich viel Pakete bekommen, wo man die Nachricht kennt. Und dann kriegt man den Keystream raus und dann kann man ziemlich viel Schlüssel abgespeichert haben. Und dann kann man viele Pakete gleichzeitig angreifen. Dann nutzt man irgendwelche Taktiken wie das. Dann kann man anhand von Known Plain Text gegen den Streamshyper... Hier bekommt man aber auch nur den Keystream für Nachricht 4. Wir kennen den Inhalt der Nachricht 4. Und wir nutzen diese Nachricht 4, um den Keystream herauszufinden. Und dann können wir damit eine neue Nachricht herausfinden. Vielleicht diskutieren wir es später, wenn ihr 1-on-1 seid. Vielen Dank. Toll, was du das gefunden hast. Ein toller Vortrag, um zu vielleicht ein bisschen mehr darüber reden, wie man formale Verifikationen noch wirklich verwenden kann. Mit den Problemen, die sie hat. Es gibt einen sehr falschen Sinn von Sicherheit. Man hat immer noch Vorteile von formaler Verifikation. Die Einstellung, die wir haben sollten, ist, dass formale Verifikationen von Code und Algorithmen, die den Vertrauen in das Programm erhöhen sollte. Aber es ist halt nicht so, dass ein formal verifiziertes Algorithmus einfach sicher ist. Das Problem war, früher war, wenn es formal verifiziert war, dann haben die Leute halt einfach gesagt, es ist sicher. Aber was sie eigentlich tun sollten, ist, wir haben einen formalen Beweis, aber jetzt sollten wir schauen, ob das Modell, was sie verwenden, sinnvoll ist. Das heißt, wir sollten auf jeden Fall weiterhin formale Verifikation verwenden, aber das heißt noch nicht, dass die Software dadurch eindeutig sicher ist. Der erste Teil meiner Frage ist, die Folie, die wir gerade sehen, so weit, wie ich das den Vortrag verstehe, ist, dass dies erneut sendend von Nachricht 4 nicht verschlüsselt sein soll, laut Standard. Das heißt, wenn man den Standard wirklich folgt, dann sollte man hier kein Problem haben. Doch, dann hat man immer noch ein Problem. Wir können nämlich einfach auf ein Duck-Paket warten, wo wir die Felder kennen, ein HTTP-Paket oder ein TCP-Synd-Paket oder irgendein plaintext HTML-Paket. Es gab Arbeit an Fingerprinting von HTPS, sodass wir anhand der Länge den Inhalt der Website erkennen. Dann haben wir einen plaintext, und dann gibt es einfach sehr viele Wege, den Inhalt eines Pakets zu erraten und dann mit der Key-Reinstallation diese Attacke durchzuführen. So weit, wie ich das verstehe, ist, deine Vorschau, das heißt, sind wir LV-verbänden, sind wir immer noch angreifbar? LV soll sich die selbe Verschüttelung verwenden. LV ist keine Absicherung betätigt. Wenn ich das richtig verstanden habe, ist W11 die Management-Pakete schützt. Das hilft aber nicht gegen diese Angriffe. Okay, es gibt hier noch sehr viele Details, die wir diskutieren können. Jeder, wenn einer noch diskutiert, und es war ein sehr schöner und verständlicher Vortrag, und ich danke allen, die die Fragen haben, vielleicht trage ich dir den Vortragenden später. Und damit verabschieden sich auch aus der Übersetzerkabine Franz T. und Eipen. Vielen Dank für das Zuhören. Wenn Sie irgendwelche Fragen haben, bitte, wenn Sie irgendwelche Feedback haben, dann senden Sie die Mitte an.