Für technisch Interessierte hier die “ganze” Android-eduroam-Story.
Auch wenn die dem eduroam-Verbund zugrundeliegende Infrastruktur als sicher gelten kann, könnten doch unzureichend implementierte Radius-Klienten in Mobilgeräten die eigentlich sichere Umgebung untergraben. Bei drahtlosen WLAN-Netzen muss der Client immer überprüfen, ob er mit dem richtigen Accesspoint verbunden ist. Eine SSID (den Namen des WLAN-Netzes) kann jeder Angreifer sehr leicht kopieren. Deshalb sind offene WLANs auch immer gefährlich.
Ein Client kann niemals sicher sein, dass bei einer DNS-Anfrage wirklich die dazu passende IP-Adresse zurückgeliefert wird. Nur wer in offenen Netzen verschlüsselt per https kommuniziert und auch wirklich die in dieser Verbindung verwendeten Zertifikate überprüft, kann sicher sein mit dem richtigen Server verbunden zu sein. Wer im Web Zertifikatswarnungen ignoriert kann dort, wie auch im richtigen Leben, von Betrügern übers Ohr gehauen werden. Bei herkömmlicher WEP- (das Verfahren ist unsicher) oder WPA-Verschlüsselung ist durch das sowohl dem Klienten als auch dem Accesspoint bekannte Passwort sichergestellt mit dem „richtigen“ Accesspoint zu kommunizieren. In Firmen- oder Hochschulnetzen ist ein einfaches WPA-Passwort aber nicht praktikabel und so kommt das Radius-Protokoll ins Spiel. Ursprünglich für die Authentifikation in Modem-Einwahlnetzen konzipiert, kann Radius auch in WLAN-Netzen mit dem Standard 802.1X (ursprünglich vorgesehen für LANs) eingesetzt werden.
Um sicher mit einem Radius-Server zu kommunizieren, werden in 802.1X (Extensible Authentication Protocol) die Methoden TTLS (Tunneled TLS) und PEAP (Protected EAP) eingesetzt. In beiden Fällen handelt es sich prinzipiell um einen sicheren TLS-Tunnel wie er auch von https oder ähnlich bei SSH-Verbindungen genutzt wird. Wie bei diesen Verbindungen ist auch bei Enterprise WPA (802.1X EAP) das Zertifikat entscheidend.
Ohne Überprüfung des Zertifikats gibt es keine sichere Verbindung! Wer auf die Zertifikate im eduroam WLAN verzichtet, handelt grob fahrlässig!
Abb. 1 So ist eduroam korrekt konfiguriert
Übrigens wird die Unikennung nur im Tunnel übertragen, d. h. wenn ein UDE-Nutzer z. B. an der TU-Dortmund unterwegs ist, sehen die Kollegen dort nur die äußere anonyme Identität, welche nach unserer Anleitung „anonymous@uni-due.de“ lauten soll. Der Suffix „uni-due.de“ ist wichtig, damit die Anfrage über die Radius-Server des DFN-Vereins an unsere Radius-Server weitergeleitet werden kann. Innerhalb des sicheren Tunnels kann die Authentifikation mit einem Klartextpasswort (PAP) oder viel sicherer mit MSCHAPv2 stattfinden. Bei MSCHAPv2 werden nur Hashes (challenge/response) ausgetauscht, das Klartext-Passwort wird niemals übertragen. Das auf dem veralteten DES-Verschlüsselungsverfahren beruhende MSCHAPv2 ist aber angreifbar. Klartextauthentifizierung mit PAP sollte aber in keinen Konfigurationsanleitungen mehr empfohlen werden!
Neben der vom DFN-Verein beschriebenen Sicherheitslücke (1) im Android-Radius-Klienten bei der Konfiguration mehrerer Enterprise-WPA-WLAN-Profile, übrigens ein ungewöhnlicher Fall – nur wenige unserer Kunden haben daheim einen eigenen Radiusserver – gibt es weitere Sicherheitslücken, die sich bei unzureichend konfigurierten Klienten ausnutzen lassen. Ein Angriff auf einen unserer Kunden wurde im Mai 2014 mit dem Exploit „PEAP-ing TOM“ (3,4) durchgeführt. Durch diesen Exploit lassen sich nur Geräte angreifen, die unzureichend konfiguriert sind. Ein modifizierter Radius-Server bringt den Android-Klienten dazu sein Passwort per GTC (Generic Token Card, ein one-time Passwort) herauszugeben.
Um per PEAPing TOM angreifbar zu sein, reicht es aus in die Android-WLAN-Konfiguration kein Root-Zertifikat und keine Phase 2-Authentifizierungsmethode einzugeben (Siehe Abbildung 2).
Abb. 2: unten: So nicht! Ein angreifbares Android Profil – oben: das Angriffswerkzeug
Leider vertraut Android (in allen Versionen, erst Android 5 ist sicher) auch bei korrekt konfiguriertem eduroam-Zugang allen Zertifikaten unterhalb der Deutschen Telekom Root und nicht nur den Zertifikaten unserer Radius-Server. Daher würde der beschriebene Angriff auch funktionieren, wenn der Angreifer ein gültiges Zertifikat unterhalb der Telekom Root besitzt (2). Auch MSCHAPv2 im inneren Tunnel hilft nicht wirklich zuverlässig, da auch dieses angreifbar ist (5). Alle unsere eduroam-Konfigurationsanleitungen für Android sind seit dem Frühjahr 2014 auf dem aktuellen Stand. Wir können aber nicht sicherstellen, dass nicht noch Kunden mit falscher Konfiguration unterwegs sind. Aufgrund der Vielzahl der mobilen Klienten, deren Integrität nicht immer überprüft werden kann, erschien es uns sinnvoll ein separates WLAN-Passwort einzuführen. Dazu wurden sowohl die zentrale Benutzerverwaltung AUM als auch die Radius-Server angepasst.
Als Reaktion auf die Android-Sicherheitslücken planen alle UAR-Rechenzentren gemeinsam die Einführung eines optionalen separaten Passwortes für eduroam. Übergangsweise wird das bisherige zur Unikennung passende Passwort für eduroam weiterverwendet werden können. Wenn ein Kunde ein separates Passwort konfiguriert, wird ausschließlich dieses für die eduroam-Authentifikation verwendet werden. Mittelfristig wird von den UAR-Rechenzentren eine Authentifikation mit persönlichen Zertifikaten angestrebt.
(1) https://www.dfn-cert.de/aktuell/Google-Android-Eduroam-Zugangsdaten.html
(2) https://h4des.org/blog/index.php?/archives/341-eduroam-WiFi-security-audit-or-why-it-is-
broken-by-design.html
(3) https://www.youtube.com/watch?v=-uqTqJwTFyU
(4) https://www.leviathansecurity.com/blog/peap-at-def-con-21/
(5) https://www.heise.de/security/artikel/Der-Todesstoss-fuer-PPTP-1701365.html