Seite 2: Absurde Downgrades

Inhaltsverzeichnis

Absurd ist, dass 13 Netzbetreiber, die alle Verfahren bis DH18 (8291 Bit) unterstützen, im Test ein Downgrade auf DH1 oder DH2 vorgeschlagen haben, zwei weitere wollten auf DH14 (2048 Bit) downgraden. Die Dunkelziffern aller dieser Statistiken dürften deutlich höher sein; einerseits greifen viele virtuelle Mobilfunkanbieter auf die Gateways ihrer Gastgeber-Netze zurück, andererseits haben sich rund 200 weitere Gateways gegen die Tests versperrt.

Noch absurder: Selbst wenn beide Seiten (Endgerät und Netzbetreiber-Gateway) anzeigen, den gleichen möglichst sicheren Schlüsselaustausch zu unterstützen, erlaubten 41 Prozent der Gateways der Gegenstelle, eine weniger sichere Variante zu wählen. Zwölf Prozent reagierten mit einer nicht aussagekräftigen Fehlermeldung, nur 42 Prozent forderten ein Upgrade, davon aber fast die Hälfte nur auf DH2 (2048 Bit). Vier Prozent waren sich nicht zu dumm, ein Downgrade auf DH1 (768 Bit) vorzuschlagen. Offenbar soll bei diesen die Verbindung um jeden Preis zustandekommen.

Für das als besonders schwierig zu knackende DH19 mit elliptischen Kurven haben die Forscher nur einen einzigen Netzbetreiber gefunden, der DH19 als verfügbar signalisiert: Die Deutsche Telekom. Allerdings klappte dann der Verbindungsversuch nicht. "In der Praxis scheinen elliptische Kurven also kaum eine Rolle zu spielen", sagte Autor Adrian Dabrowski vom Helmholtz-Zentrum für Informationssicherheit gegenüber heise online.

Chaos bei Configurations

Leider ist die 3GPP-Spezifikation für VoWiFi sehr allgemein gehalten, was viel Spielraum bei der Umsetzung lässt. Dass Ergebnis ist, dass es unzählige Kombinationen aus Endgeräte- und Netzkonfiguration gibt. Beispielsweise gibt es für iPhones 745 Netzbetreiberkonfigurationen, von denen 219 VoWiFi unterstützen. Dabei werden Parameter wie unterstützte DH-Schlüssel, Ablaufdatum einer verschlüsselten Verbindung (Rekey Timer), der Algorithmus für die wichtige Berechnung von Pseudozufallszahlen (PRF) und andere Parameter mehr bestimmt.

Auf Mobiltelefonen von Samsung und Oppo haben die Forscher sogar mehr als 300 voreingestellte VoWiFi-Konfigurationen gefunden, die allerdings allesamt unvollständig waren, weil sie nicht alle Parameter festlegen. Dann fallen die Geräte auf allgemeine Voreinstellungen zurück. Und die sind sehr unterschiedlich: Während beispielsweise Google Pixel mit Tensor-Chip Schlüssel nach spätestens vier Stunden neu aushandeln, erlaubt Samsung mit Exynos-Chips ganze 24 Stunden. Das lässt Angreifern mehr Zeit. Bei Qualcomm-Chips sind 18 Stunden der Defaultwert.

Diese Grenzen greifen aber, wie gesagt, nur, wenn es keine netzbetreiberspezifische Konfigurationsdatei gibt oder darin nichts Einschlägiges vorgegeben ist. Deren Vorgabe kann deutlich länger sein: Drei Netzbetreiber sehen in ihren Einstellungen eine Schlüssellebensdauer von einem ganzen Jahr (!) vor.

Veraltete Verfahren

Auch bei anderen Parametern hapert es: 83 Prozent der auf Oppo-Geräten gespeicherten Konfigurationsdateien unterstützen laut Studie zu kurze DH-Schlüssellängen, bei Xiaomi waren es 77 Prozent, bei Apple immerhin noch 59 Prozent. Auch andere Parameter waren nicht selten auf veraltete, unsichere Werte gesetzt, beispielsweise DES, RC5 oder Blowfish für die symmetrische Verschlüsselung oder MD5 für Integritätsprüfung oder Pseudozufallszahlen, sowie unzulängliche MODP-Varianten für den Schlüsselaustausch,

Die 219 Netz-Konfigurationen auf iPhones haben einen Vorteil gegenüber der Konkurrenz: Sie sehen jeweils nur eine bestimmten DH-Schlüssellänge vor. Damit dürften Downgrade-Angriffe scheitern. Bei Mediatek-Geräten war das anders, wie sich herausgestellt hat. Sie erlaubten in den Tests Downgrades der DH-Schlüssellänge.

Und das sogar auf Schlüssellängen, die der Chip laut eigener Angabe im IKE-Verfahren gar nicht unterstützt! Offenbar wurden bei Chips der Reihe Mediatek Dimensity die kürzeren Schlüssel zwar aus dem Dialog entfernt, nicht aber aus der zugrundeliegenden Implementierung, so dass ein Angreifer sie weiterhin auslösen kann (CVE 2024-20069, Risikostufe hoch). Rootrechte sind dafür nicht erforderlich.

Ältere Mediatek-Geräte mit (Helios-Chipset) haben diesen Fehler zwar nicht, aber dafür einen anderen. Sie setzen auf strongSwan-Software für die Verschlüsselung – allerdings läuft der Schlüsselaustausch (IKE) dabei mit einem Programm, das mehr als zehn Jahre alt ist (charon aus strongSwan 5.1.2 vom März 2014).