Mit fortschreitender Entwicklung drahtloser Technologien können zunehmend mehr Funktionalitäten darüber gehandhabt werden. Wenn Daten drahtlos verschickt werden, können sie in ihrer Rohform von jedem in der Umgebung abgehört werden, was neue Bedrohungen mit sich bringt. Dieser Artikel beleuchtet Angriffsmöglichkeiten auf Wi-Fi Direct am Beispiel eines Miracast-Geräts, auch Wi-Fi Display genannt.

Miracast kann auf drahtlosen Netzwerken im Infrastructure Modus und via Wi-Fi Direct verwendet werden. Dieser Artikel beschäftigt sich mit der Verwendung über Wi-Fi Direct, welches oft die bevorzugte Methode ist, Miracast zu verwenden. Über Wi-Fi Direct werden Latenzzeiten und drahtlose Interferenz verringert, da Daten nur einmal verschickt werden und nicht zweimal wie im Infrastructure-Modus (zuerst vom Client zum Access Point und danach vom Access Point zum Display). Nachdem die Layer 1/2 Verbindung über Wi-Fi Direct etabliert ist, können die Endpunkte normal miteinander kommunizieren über Standardprotokolle wie IPv4/IPv6.

Miracast verwendet RTSP zusammen mit RTP um Daten von der Quelle zum Display zu streamen. RTSP ist ein Control-Protokoll, welches zur Initiierung und der Verwaltung von Datenströmen verwendet wird. RTP ist das Application-Layer-Protokoll, welches die Datenströme transportiert. In den meisten Fällen gibt es keinen vorrausgehenden Sicherheitskontext, wie beispielsweise ein PSK oder eine PKI, welches die RTSP/RTP Kommunikation zwischen Quelle und Display authentisiert. Somit ist diese Kommunikation anfällig auf Man-in-the-Middle-Angriffe (MITM). Die einzige Absicherung wird durch das Layer 1/2 Protokoll Wi-Fi Direct bereitgestellt.

Angriff auf WPS

Alle Miracast-Geräte, die wir während unserer Recherche genutzt haben, verwendeten standardmässig entweder keine Authentisierung oder WPS-Authentisierung. Das Miracast-Gerät welches uns zu diesem Artikel inspiriert hat, verwendete standardmässig WPS-Authentisierung. Es zeigt eine dynamisch generierte, 4-stellige WPS-PIN auf dem Bildschirm an, die der Benutzer zur Authentisierung verwendet. WPS ist von Design- und Implementationsschwächen betroffen, welche die Sicherheit des Anwendungszwecks oft kompromittieren können.

Im Falle unseres Geräts wurde die dynamische PIN nach fehlgeschlagenen Authentisierungsversuchen nicht erneuert, sondern erst nachdem eine RTSP/RTP-Sitzung aufgebaut wurde. Dies ermöglicht Brute-Force-Angriffe, vor allem, wenn nur eine kurze PIN mit 4 Stellen genutzt wird. Damit kann eine PIN eruiert und zu einem späteren Zeitpunkt verwendet werden, beispielsweise in einem Rogue-AP Angriff, um eine MITM-Position bei einer neu entstehenden Verbindung zu erlangen. Wir waren neugierig, ob die PIN auch über andere Wege erlangt werden kann, beispielsweise in Situationen, wo keine derartige Schwachstelle vorliegt. Ein Ansatz, der in den Sinn kam, war das Verwenden eines Rogue-AP um einen Client dazu zu bringen, sich mit uns zu verbinden. Es stellt sich heraus, dass die WPS-Spezifikation dieses Angriffsszenario bedacht hat. Allerdings besteht viel Raum für potentielle Implementationsfehler, mit denen wir uns dennoch einen Vorteil verschaffen können. Von diesem Punkt an verwendet der Artikel den Begriff Registrar für das Miracast-Gerät, welches eine Verbindung entgegennimmt und Enrollee für das Gerät welches seine Bildschirmdaten teilen will.

Sicherheitsmassnahmen der Spezifikation

Um zu verhindern, dass ein Angreifer einen Rogue-Registrar aufmacht und die legitime PIN vom Enrollee auf einem Silbertablett serviert bekommt, wird die PIN nicht im Klartext übertragen. Weiterhin authentisieren sich der Enrollee und der Registrar beide gegenseitig. Auch wenn die PIN nicht im Klartext ausgetauscht wird, besteht hier die Möglichkeit, die PIN mit Brute-Force-Methoden zu eruieren? Die Spezifikation denkt auch hier mit. Das PIN-Derivat, welcher versandt wird, ist der HMAC-SHA-256-Hash der PIN, einer 128-Bit Nonce und andere Session-Daten. Weiterhin wird die PIN in zwei Hälften gespalten und zweiteilig verschickt, was erst später relevant wird. Jetzt bereitet der Enrollee zwei HMAC Hashes vor, welche die Spezifikation E-Hash1 und E-Hash2 nennt.

E-Hash1 = HMAC(E-S1 || PSK1 || PKE || PKR)

E-Hash2 = HMAC(E-S2 || PSK2 || PKE || PKR)

Der Schlüssel für die HMAC-Funktion wird von Session-Parametern deriviert (Diffie-Hellman Secret, zwei beim Verbindungsaufbau geteilte Nonces, die MAC-Adresse des Enrollees) welche dem Registrar und Enrollee bekannt sind. E-S1 und E-S2 sind zwei separate 128-Bit Nonces welche zu diesem Zeitpunkt nur dem Enrollee bekannt sind. PSK1 und PSK2 sind die ersten 128 Bits des HMAC-SHA-256-Hashs, der ersten respektive zweiten Hälfte der PIN. PKE und PKR sind die Public-Keys des Enrollees und des Registrars.

Weil sich beide Parteien gegenseitig authentisieren, generiert der Registrar ebenfalls zwei HMAC-Hashes, auf dieselbe Art mit seinen eigenen geheimen Nonces R-S1 und R-S2.

R-Hash1 = HMAC(R-S1 || PSK1 || PKE || PKR)

R-Hash2 = HMAC(R-S2 || PSK2 || PKE || PKR)

In einem nächsten Schritt teilen Enrollee und Registrar ihre HMAC-Hashes miteinander. Die Addition der geheimen Nonces für die Erstellung des HMAC hindert uns daran, die PIN-Range mit Brute-Force-Methoden zu eruieren. Allerdings kann zu diesem Zeitpunkt keine Partei verifizieren, ob die andere die korrekte PIN zur Generierung des HMAC-Hashes verwendet hat, da die geheime Nonce unbekannt ist. Im nächsten Schritt tauschen Enrollee und Registrar ihre geheimen Nonces schrittweise miteinander aus. Zuerst teilt der Enrollee die geheime Nonce E-S1, die er zur Generierung seines HMAC-Hashes E-Hash1 verwendet hat. Der Registrar har damit alle nötigen Variablen, um denselben E-Hash1 wert zu berechnen wenn er dieselbe erste Hälfte der PIN verwendet. Kommt der Registrar auf denselben HMAC-Hash, hat er verifiziert, dass der Enrollee die erste Hälfte der PIN kennt. Jetzt antwortet er dem Enrollee mit der R-S2 Nonce. Der Enrollee verifiziert den Registrar gleichermassen und schickt, wenn alles Grünen ist, die E-S2-Nonce. Indem beide Parteien ihre HMAC-Hashes teilen bevor die geheimen Nonces ausgetauscht werden, müssen sie ihre Karten auf den Tisch legen bevor sie eine Chance erhalten, etwas über die PIN zu erfahren. Wenn irgendeine Partei merkt, dass die andere Partei die falsche PIN hat, wird der Nonce-Austausch frühzeitig abgebrochen und eine Offenlegung der ganzen PIN wird verhindert.

Schwachstellen

Unter der Annahme, dass eine 8-stellig PIN verwendet wird, gibt es einen Möglichkeitenraum von 100’000’000 PIN-Kombinationen. Wenn ein Registrar anfällig auf Brute-Force-Angriffe ist, kann die PIN nach spätestens 231 Tagen gefunden werden bei einer Abfragegeschwindigkeit von 5 PINs pro Sekunde. Allerdings wird die PIN in zwei Teile gespalten, welche separat verifiziert werden. Dies verringert den Möglichkeitenraum drastisch auf 10’000 Kombinationen pro PIN-Hälfte. Eine PIN-Hälfte kann bei 5 PINs/Sekunde in spätestens 33 Minuten eruiert werden. Die zweite Hälfte muss nicht einmal am Registrar mit Brute-Force-Methoden erprobt werden. Nachdem die erste PIN-Hälfte vom Registrar erfolgreich verifiziert wird, teilt dieser seine R-S2 Nonce mit, mit der die zweite PIN-Hälfte praktisch sofort offline mit Brute-Force errechnet werden kann. Die Authentisierung bei einem Registrar mit einer statischen PIN ist mit diesem Ansatz komplett kompromittiert. Wenn der Registrar eine dynamische PIN verwendet, sollte er die PIN nach jedem fehlgeschlagenen Login-Versuch erneuern, um solche Angriffe zu verhindern. Das Miracast-Gerät, zu welchem wir Zugang hatten, hat die dynamische PIN bei fehlgeschlagenen Anmeldeversuchen nicht aktualisiert.

Jetzt wo wir den PIN-Austausch-Prozess kennen, können wir die Idee mit dem Rogue-AP erneut aufgreifen. Wenn der Enrollee versucht sich gegenüber unserem Registrar zu authentisieren, wird er die erste Hälfte der PIN offenlegen, da der Enrollee als erster seine Nonce E-S1 teilt. Nachdem wir die Nonce erhalten und dem Enrollee unsere R-S2 Nonce schicken, wird der Enrollee uns nicht E-S2 schicken, sondern den Nonce-Austausch abbrechen da unsere Authentisierung ihm gegenüber fehlschlägt. Allerdings haben wir uns damit bereits alles, was wir vom Enrollee benötigen, geholt. Wir verbinden uns jetzt mit dem Registrar und präsentieren die korrekte erst PIN-Hälfte zusammen mit einer zufälligen zweiten PIN-Hälfte. Weil wir demonstrieren können, dass wir im Besitz er ersten PIN-Hälfte sind, wird der Registrar uns die R-S2 Nonce schicken, mit welcher die zweit PIN-Hälfte offline in kürzester Zeit berechnet werden kann. Da wir bereits mit dem E-Hash2 eine falsche zweite PIN-Hälfte auf den Tisch legen mussten bevor der Nonce-Austausch begonnen hat, können wir diesen Authentisierungs-Flow nicht mehr erfolgreich absolvieren. Allerdings haben wir die komplette PIN eruiert mit nur einem einzelnen fehlgeschlagenen Anmeldeversuch am Registrar. Für alle Registrars, die auch nur ein klein wenig Spiel erlauben, kann so eine valide PIN eruiert werden und die Authentisierung am Registrar erfolgen. Dieser Ansatz ist dann attraktiv, wenn der Registrar einigermassen abgesichert ist, wie beispielsweise mit Rate-Limits und Lockouts gegen Brute-Force-Angriffe oder wenn eine dynamische PIN sich nach ein Paar fehlgeschlagenen Anmeldeversuchen erneuert. Die einzigen Registrars, die hier hiervon abgesichert sind, sind jene, die dynamische PINs verwenden, welche nach jedem einzelnen fehlgeschlagenen Authentisierungsversuch erneuert werden.

Fazit

WPS ist von Designfehlern betroffen. Selbst in den bestmöglichen Szenarien, in denen dynamische PINs verwendet werden, scheint die Sicherheit durch verbreitete Implementierungsfehler untergraben zu sein. Da WPS in vielen Miracast-Konfigurationen der einzige Schutzmechanismus ist, sollte die Verwendung von Miracast zum Teilen sensitiver Inhalte gut abgewogen sein. Motivierte Angreifer, die in Funkreichweite von Miracast-Einrichtung gelangen, haben signifikante Erfolgschancen. Dies kann insbesondere für lukrative Ziele wie Unternehmen relevant sein. Hersteller sollten das Bedrohungsmodell und gängige Angriffe auf WPS verstehen, um zu vermeiden, anfällige Implementierungen auf den Markt zu bringen. Hier bietet die WPS-Spezifikation ausreichend Anleitung in sicherheitsrelevanten Belangen.

Über den Autor

Ahmet Hrnjadovic arbeitet seit dem Jahr 2017 im Bereich Cybersecurity, wobei er sich auf die Bereiche Linux, sichere Programmierung und Web Application Security Testing fokussiert. (ORCID 0000-0003-1320-8655)

Links

• https://www.lifewire.com/infrastructure-mode-in-wireless-networking-816539
• https://www.wi-fi.org/downloads-registered-guest/Wi-Fi_Direct_Specification_v1.9.pdf/29559
• https://www.wi-fi.org/downloads-registered-güst/Wi-Fi_Display_Technical_Specification_v2.1_0.pdf/34726