Google Android / eduroam-Zugangsdaten

Google Android gilt als eines der beliebtesten Betriebssysteme für mobile Endgeräte, wie Smartphones und Tablets, und naturgemäß werden auch von DFN-Anwendern in großem Umfang WLAN-Verbindungen, unter anderem über eduroam, genutzt, um mit ihren Geräten in das Internet zu gelangen. Mit großer Wahrscheinlichkeit sind zahlreiche DFN-Anwender jetzt erneut von einer alarmierenden Sicherheitslücke betroffen, die bei Verwendung der Default-Konfiguration für die WLAN-Einstellungen besteht.

Das DFN-CERT und die DFN-Geschäftsstelle in Berlin informieren hiermit in enger Zusammenarbeit über die konkreten Randbedingungen für ein mögliches Ausnutzen dieser Sicherheitslücke und einer weiteren Schwachstelle und geben Hinweise zur Vermeidung solcher Angriffe, die alle DFN-Anwender umsetzen können, um sich bestmöglich vor dem Diebstahl seiner sensiblen Zugangsdaten zu schützen.

Kurzbeschreibung

Bei mobilen Geräten mit Android-Betriebssystem ist die Default-Konfiguration für die Option CA-Zertifikat für WLAN-Verbindungen "keine Angabe". Konkret bedeutet dieses als normal dokumentierte Verhalten, dass die Prüfung der Zertifikatskette komplett deaktiviert ist, d.h. jedes beliebige Zertifikat wird ohne weitere Warnung akzeptiert. Erschwerend kommt hinzu, dass Benutzer nicht, wie sonst bei TLS/SSL-Verbindungen zu Servern üblich, darüber informiert werden, falls ein Serverzertifikat von einer unbekannten oder als nicht vertrauenswürdig angesehenen Root-CA (Wurzelzertifikat) ausgestellt wurde.

Weil ein Google Android-Gerät ohne irgendeine Meldung oder Nachfrage aufgrund dieser Voreinstellung jedes Serverzertifikat akzeptieren würde, muss jeder Benutzer in jedem Fall das für eduroam gültige CA-Zertifikat richtig einstellen.

Hat ein Benutzer auf seinem Android-Gerät eines oder mehrere Profile für 802.1X-Netzwerke (WLAN) konfiguriert, und nur eines davon verwendet die Default-Konfiguration, so kann es aufgrund einer neu identifizierten Sicherheitslücke bei Google Android passieren, dass selbst bei eigentlich sicherer Konfiguration des Profils für eduroam die dafür verwendeten Benutzerdaten und das Passwort kompromittiert werden, falls der Benutzer zuerst das Profil „ohne CA“ verwendet und dann unmittelbar auf das eigentlich sichere 802.1X Profil wechselt, um sich mit einem sogenannten „Rogue Access Point“ zu verbinden (siehe Detailinformationen).

Update: Google teilte mit, dass an einer geeigneten Lösung für das unter Schwachstelle ANDROID-2014-CERT-1 beschriebene Problem noch gearbeitet wird, die Schwachstelle ANDROID-2014-CERT-2 aber durch einen Bugfix für den "wpa_supplicant" in Android 5.0 behoben wurde. Dies konnte durch Tests der DFN-Geschäftsstelle in Berlin mit einem LG NEXUS 5 mit Android 5 (OTA-Dateien) bestätigt werden, indem einige Male zwischen dem korrekt mit eduroam-Root CA konfigurierten 802.1X-WLAN-Profil und einem weiteren Profil mit unsicherer Default-Konfiguration gewechselt wurde. Das eduroam-Passwort konnte dabei nicht mehr ausgespäht werden.

Detailinformationen

Die Universität Bonn konnte in Zusammenarbeit mit der DFN-Geschäftsstelle in Berlin dieses Verhalten in einer Testumgebung (802.1X WLAN) auf den Systemen NEXUS 4/5 mit Android 4.4.3 und 4.4.4, Samsung Galaxy S3 mit Android 4.3 sowie CAT B15 mit Android 4.1.2 nachweisen. Die Tests haben für diese Android-Betriebssystemversionen ein übereinstimmendes Verhalten gezeigt. Es ist also aktuell davon auszugehen, dass die Verwundbarkeit für alle Versionen besteht.

Falls die Default-Konfiguration für Option CA-Zertifikat „keine Angabe“ verwendet wird, verbindet sich das Gerät (Client) mit jedem Server, der ein beliebiges Zertifikat vorweisen kann. Anscheinend ohne weitere Prüfung wird der öffentliche Schlüssel, den der Server beim SSL-Handshake schickt, angenommen und eine Verbindung zu dem Server etabliert. Anschließend werden die User-Credentials (Benutzerkennung, Passwort, Challenge Response) bei den Authentifizierungsverfahren EAP-TTLS (PAP, MSCHAPv2) und PEAP (MSCHAPv2) an den Server übermittelt.

Weitere Tests in der oben beschriebenen Testumgebung haben ergeben, dass bereits ein anderes, mit den Default-Einstellungen konfiguriertes Profil für 802.1X erlaubt, dass ein für eduroam mit korrekter Root-CA konfiguriertes 802.1X Profil kompromittiert werden kann. Meldet sich ein Benutzer zunächst an einem 802.1X-Netzwerk ohne Zertifikatsüberprüfung und anschließend an einem „Rogue eduroam“ (802.1X) WLAN mit korrekt konfigurierter Zertifikatsüberprüfung an, findet der zweite SSL-Handshake ohne die eigentlich erforderliche Überprüfung des Serverzertifikates statt, die Benutzerdaten werden übermittelt, und erst im nächsten Schritt erkennt Android ein falsches CA-Zertifikat und sendet auch erst dann ein „Unknown CA“ zum Server.

Wir können zu diesem Zeitpunkt also zwei angreifbare Szenarien unterscheiden:

Ein Benutzer hat nur ein Profil für das eduroam WLAN konfiguriert, verwendet aber – was aufgrund der Benutzerführung sehr naheliegend ist – die Default-Konfiguration mit der Option CA-Zertifikat „keine Angabe“.
Ein Benutzer hat zwar für das eduroam korrekt das richtige CA-Zertifikat eingetragen, hat aber weitere 802.1X Profile ohne Zertifikatsüberprüfung konfiguriert, z. B. für ein WLAN zu Hause.

In beiden Szenarien ist es möglich, durch einen sogenannten "Rogue Access Point" eduroam-Identitäten und Passwörter abzugreifen, ohne dass der Nutzer selbst davon Kenntnis erlangt. Indem ein entfernter, nicht authentifizierter Angreifer einen Nutzer auf einen "Rogue Access Point“ lockt, kann er dessen eduroam-Benutzerdaten relativ leicht im Klartext ausspähen. Wenn dagegen für alle 802.1X Profile ein CA-Zertifikat explizit ausgewählt ist, dann wird in jedem Fall das Serverzertifikat geprüft und bei allen getesteten Versionen konnte das Passwort zumindest nicht mehr mittels eines falschen Serverzertifikates abgegriffen werden.

Es handelt sich streng genommen also um zwei Sicherheitsprobleme unterschiedlichen Schweregrades:

Eine unsichere Default-Einstellung bei zugleich „unglücklicher“ Wortwahl im Konfigurationsmenü und fehlender Warnung ist geeignet, Nutzer in falscher Sicherheit zu wiegen. Insofern mag dieses Verhalten der Google Android-Betriebssysteme nicht als schwerwiegender Fehler, aber doch als moderate Schwachstelle angesehen werden.
Im zweiten Fall handelt es sich um eine kritische Sicherheitslücke (Bug), denn korrekt müssten die Profile unabhängig von einander funktionieren, ohne Querwirkung von einem Profil zum anderen.

Durch entsprechende Konfigurationsänderung können aber beide Sicherheitslücken umgangen werden, indem für alle auf einem Gerät eingerichteten 802.1.X-Profile jeweils explizit ein CA-Zertifikat ausgewählt wird; dann werden auch im zweiten Fall trotz des Bugs alle Serverzertifikate korrekt geprüft.

Update zu den beiden beschriebenen Angriffsszenarien:

Google arbeitet derzeit noch an einer geeigneten Problembehebung für dieses Szenario.
Android 5 enthält ein Bugfix für den „wpa_supplicant“, wodurch das Szenario 2 offenbar erfolgreich ausgeschlossen werden kann.

In Zusammenarbeit mit der DFN-Geschäftsstelle konnte letzteres in Tests mit einem NEXUS 5-Gerät von LG mit Android 5 (OTA - Dateien) bestätigt werden. Sobald das Profil für das eduroam-WLAN mit korrekter Root CA konfiguriert war, wurde korrekt gegen diese Root CA geprüft und zwar auch dann, wenn ein weiteres Profil mit einer anderen SSID für 802.1X und der unsicheren Default-Einstellung, also: „CA keine Angabe“, konfiguriert war. Es konnten bei dem Wechsel zwischen den Profilen dann keine eduroam-Zugangsdaten mehr mittels eines „Rogue eduroam“ (802.1X) WLAN abgegriffen werden.

Maßnahmen für Benutzer

Um zu vermeiden, dass ihre Benutzerdaten im Klartext abgefangen werden können, sollten Benutzer unbedingt darauf achten, dass in allen WLAN-Einstellungen immer ein korrektes CA-Zertifikat eingetragen ist und dass kein 802.1X-Netzwerk mit der Default-Einstellung arbeitet. Bei der Verwendung von eduroam ist die Installation des Root-CA-Zertifikates der Deutschen Telekom („T-TeleSec GlobalRoot Class 2“), das innerhalb der DFN-PKI verwendet wird, normalerweise sinnvoll. Über diese Konfiguration kann sichergestellt werden, dass nicht jedes beliebige Serverzertifikat für die Verbindung akzeptiert wird, sondern nur eines, das von dieser vertrauenswürdigen CA-Hierarchie signiert wurde.

Bisher haben wir noch keine aktive Ausnutzung dieser neu bekannt gewordenen Sicherheitslücke beobachtet. Für den Fall, dass Benutzer befürchten müssen, dass ihre Benutzerkennung und/oder Passwörter ausgelesen wurden, müssen diese natürlich unbedingt geändert werden. Weiterhin muss in solchen Fällen überlegt werden, ob die betroffenen Benutzerdaten, oder auch nur das Passwort, außerdem noch für andere Dienste oder Zugänge verwendet wurden. Das Passwort sollte dann auch auf diesen anderen Systemen geändert werden.

Grundsätzlich muss unbedingt vermieden werden, dieselben Passwörter für unterschiedliche Systeme/Dienste/Zugänge zu verwenden.

Update: Benutzer von Android-Geräten sollten diese, falls dies für den jeweiligen Gerätetyp möglich ist, auf Android 5 aktualisieren.

Ausblick

Das Ausspähen von Passwörtern, ob durch Trojaner, durch Ausnutzen spezifischer Schwachstellen, wie auch dem "Heartbleed"-Bug, oder aufgrund unsicherer Default-Einstellungen in der Kombination mit mangelhaften Warnmeldungen, wie in diesem Falle, entwickelt sich zunehmend zu einem Angriffsszenario, dem heute nahezu jeder Internetnutzer potentiell ausgesetzt ist. Wir müssen uns eingestehen, dass der Einsatz von Verschlüsselung zwar grundsätzlich gut, aber blindes Vertrauen in Sicherheitsmechanismen wie SSL/TLS-Verschlüsselung nicht (mehr) angemessen ist. Erst die richtige Konfiguration und die Transparenz der Mechanismen schafft ein gerechtfertigtes Vertrauen, und das erfordert Zeit und Aufwand.

Darum ist jeder Einzelne von uns aufgerufen, zu hinterfragen, wo, wann, womit und wie sie/er verschiedene Internet-Dienste nutzt, und sich mit den möglichen Sicherheitseinstellungen ihrer/seiner Geräte vertraut zu machen, Sicherheitsupdates ernst zu nehmen, fortwährend dazu zu lernen und die von den Betreibern zur Verfügung gestellten Sicherheitsinformationen aufmerksam zu studieren. Im Angesicht solcher Schlagzeilen wie „Millionen kompromittierter Passwörter“ und ähnlichen kann sich niemand mehr einfach der Illusion hingeben, dass einem selbst „so etwas schon nicht passieren wird“.

Nach Kenntnis des DFN-CERT wurden bis zu diesem Zeitpunkt weder für die beschriebene kritische Sicherheitslücke noch die ebenfalls beschriebene Schwachstelle Schwachstellenbezeichner (CVE) in der National Vulnerability Database (NVD) des National Institute of Standards and Technology (NIST) vergeben. Das DFN-CERT hat Google jedoch bereits durch einen Bug Report über die Testergebnisse informiert.