Angriffe auf Android-Verbindungen über Googles "authToken"

Das auf Linux basierende Android-Betriebssystem für mobile Geräte erfreut sich mittlerweile einer enormen Beliebtheit. Umso kritischer sind Sicherheitslücken in diesem System wie etwa die unsichere Übertragung von Tokens für Google-Dienste.

Wer die Nachrichten letzte Woche verfolgt hat, wird festgestellt haben, dass ein gravierendes Sicherheitsleck in Android gefunden wurde. Den Stein ins Rollen brachte ein Blog-Beitrag von Dan Wallach, der Ende Februar erschien. Dieser eigentlich harmlos anmutende Beitrag berichtete über ein Studentenexperiment, bei dem der Netzwerkverkehr von Android-Smartphones mit Hilfe eines einfachen Netzwerksniffers (Wireshark) analysiert wurde. Überraschenderweise übertrugen zahlreiche Protokolle ihre Daten in Klartext, beispielsweise zu Twitter und Facebook.

Auch wenn eine unverschlüsselte Übertragung solcher Daten derzeitigen Sicherheitsstandards Lichtjahre hinterhinkt, so könnte man zumindest argumentieren, dass beides keine extrem sensitiven Dienste sind. Aber auch Google Kalender übermittelt die Daten unverschlüsselt und ermöglicht dem Angreifer möglicherweise sogar, den Kalender zu ändern. Das ist schon recht kritisch, denn viel Android/Google-Benutzer verwenden den Kalender regelmäßig und verlassen sich auf dessen Integrität.

Trotz der Brisanz dieses Blog-Eintrags hat es diese Meldung zunächst nicht in die deutschen Massenmedien geschafft. Aber eine Forschergruppe um Bastian Könings vom Institut für Medieninformatik an der Universität Ulm wurde dadurch Bericht motiviert, weitere Untersuchungen über die Sicherheit des Netzwerkverkehrs von Android-Applikationen anzustellen. Der Fokus ihrer Analyse lag speziell auf den Google-Applikation des Systems, da diese das Rückgrat von Android bilden. Zahlreiche Dienste wie Google Mail, Talk, Kalender, Picasa werden ständig von einem typischen Android-Benutzer verwendet. Gerade weil diese Dienste so oft verwendet werden und so gut wie immer über einen Google-Account abgewickelt werden, hat Google den so genannten ClientLogin-Mechanismus in das Android-Programmiermodell eingebaut: Statt fortwährend Benutzername und Passwort zwischenf dem Smartphone und den Google-Servern hin- und herzuschicken bekommt das System ein Authentifikations-Token ("authToken"). Alle weiteren Anfragen an den Dienst laufen dann über dieses Token, und eine Account-Authentifikation ist nicht mehr notwendig.

Schematische Darstellung des Google "ClientLogin"-Mechanismus (Abbildung: Google).

Die Authentisierung ist in der Abbildung schematisch dargestellt. Die Schritte eins bis sechs stellen die erste Authentifikation dar. Grün markierte Pfeile sind optional und markieren eine zusätzliche Sicherheitsstufe via Captcha (Completely Automated Public Turing test to tell Computers and Humans Apart). Die verbreitetste Captcha-Implementierung stellen allseits bekannten kleine Bildchen dar, in denen ein Text enthalten ist, den der Benutzer dann eingeben muss. Im Prinzip eignet sich jedes komplizierte Problem künstlicher Intelligenz als Captcha. Es dient einfach dazu, Bot-Angriffe zu verhindern. In Schritt sieben schließlich wird das Token an die Applikation gesendet. Mit diesem Token kann diese im Weiteren auf den Google-Dienst zugreifen. Das Token ist typischerweise mehrere Tage gültig, laut Google-FAQ maximal zwei Wochen. Offensichtlich sollte es höchste Priorität sein, dieses Token so gut wie möglich zu schützen, wenn es über das Netzwerk geschickt wird. Denn wenn der Angreifer erst einmal das Token hat, kann er es mehrere Tage verwenden, um auf alle Google-Dienste des Anwenders zuzugreifen. Kurzum, der Kommunikationskanal, über den das Token verschickt wird, sollte immer verschlüsselt sein.

Und genau hier liegt das Problem: Das Token wird tatsächlich manchmal unverschlüsselt versendet, also via HTTP und nicht via HTTPS. Bis zur Android-Version 2.3.3 versenden Google Kalender und Contacts das Token ungeschützt über HTTP. Laut aktueller Statistik betrifft dieses Problem nahezu alle im Umlauf befindlichen Geräte (99.7 Prozent).

Wie kommt aber der Angreifer an das "authToken"? Er begibt sich zunächst an einen belebten Ort wie einen Flughafen oder Bahnhof und richtet dort einen Wifi-Access-Point ein. dann muss er noch eine gebräuchliche ESSID für das Netzwerk wählen. Wählt er zum Beispiel "tmobile", so wird sich das Android-Phone direkt mit diesem Hotspot verbinden, falls es vorher schon einmal Verbindung zu einem "tmobile"-Netz hatte, was recht wahrscheinlich ist. Sobald die Verbindung hergestellt ist, werden die Google-Applikationen versuchen, eine Synchronisation ihrer Daten herzustellen. Dabei wird das Token übertragen. Der Angreifer muss dann nichts weiter tun, als einen Sniffer laufen zu lassen, und so alle über das Netzwerk strömenden Tokens abzufangen. Auf diese Weise kann er bequem zahlreiche Tokens sammeln, und dann mehrere Tage lang damit auf die Daten der dazugehörigen Anwender zugreifen.

Diese Schwachstelle zeigt noch ein ganz allgemeines Problem der Google-Dienste: Benutzer neigen durch das große und reibungsfreie Angebot von Google zu einer Art Monokultur: Mails, Kontakte, Kalender, Photos, Buzz et cetera: Alles wickeln sie über einen zentralen Account ab. Das ist einfach für den Anwender, aber auch einfach für einen Angreifer.