Android: IMSI-Leaking bei GPS-Positionsbestimmung

Nach dem Beitrag »Android: Google erfährt Identität und Standort bei aktivem GPS« waren viele Fragen offen und einige Leser verunsichert. Um der Sache auf den Grund zu gehen muss ich etwas weiter ausholen.

Zunächst einmal die Grundlagen:

Assisted GPS (abgekürzt als A-GPS) ist ein System, das die Zeit bis zum ersten Fixieren eines satellitengestützten Positionierungssystems (GPS) meist deutlich verbessert – die GPS-Positionsbestimmung wird also beschleunigt. Wie funktioniert das? Bei Mobiltelefonen ist anhand der Funkzelle, in der euer Gerät eingebucht ist, der ungefähre Aufenthaltsort bereits bekannt. Via Secure-User-Plane-Location-Protokoll (SUPL) wird nun dieser ungefähre Standort an einen SUPL-Server gesendet, der anhand dieser Informationen den Suchbereich für die Satellitensignale einschränkt und somit eine schnelle GPS-Positionsbestimmung ermöglicht. Die Kommunikation mit dem SUPL-Server erfolgt via TCP/IP oder auch SMS.

Eben so einen SUPL-Server nutzen Android-Systeme, um die GPS-Positionsbestimmung zu beschleunigen. Problem dabei ist allerdings, dass bei der Anfrage auch eure IMSI-Nummer an den SUPL-Server übermittelt wird – was technisch gesehen eigentlich nicht notwendig wäre. Das Problem: Die Kombination der IMSI-Nummer mit der Funkzellen-ID ermöglicht dem Betreiber eines SUPL-Servers, die eindeutige Identifizierung eines Nutzers, sobald das Smartphone via SUPL-Anfrage den Standort lokalisiert bzw. eingrenzt. Das SUPL-Protokoll ist so gesehen also eigentlich relativ sinnvoll, nur wissen wir nicht, was die Betreiber der SUPL-Server mit diesen Informationen anfangen.

Mit meinen Testgeräten habe ich nun versucht herauszufinden, wann solch ein SUPL-Request abgesetzt wird. Ergebnis: Immer dann, wenn ihr GPS aktiviert und eine App den Standort abfragen möchte. Es spielt dabei keine Rolle, welchen Modus ihr gewählt habt:

  • Hohe Genauigkeit: GPS, WLAN, Bluetooth oder Mobilfunknetze zur Standortbestimmung nutzen.
  • Energiesparmodus: WLAN, Bluetooth oder Mobilfunknetze zur Standortbestimmung nutzen.
  • Nur Gerät: GPS zur Standortbestimmung nutzen.

Das heißt: Selbst wenn ihr als Modus »Nur Gerät« gewählt habt, wird via A-GPS bzw. SUPL-Request ein Anfrage abgesetzt. Die Frage lautet nun, welcher SUPL-Server bzw. Betreiber erhält die Funzelleninformationen gemeinsam mit der IMSI-Nummer?

Das ist eben ganz unterschiedlich – auch bei LineageOS. Herausfinden könnt ihr es, wenn ihr folgende Datei (Root vorausgesetzt) auf eurem Android öffnet:

/etc/system/gps.conf

oder

/vendor/etc/gps.conf

Dort sucht ihr nach folgenden Einträgen:

SUPL_HOST=supl.google.com
SUPL_PORT=7275 (kann variieren)

Bisher als SUPL_HOST bzw. Betreiber identifiziert:

  • supl.google.com: Google
  • supl.sonyericsson.com: Sony
  • supl.qxwz.com: SUPL-Server in China
  • supl.nokia.com: Nokia
  • […]

Aktiviert ihr GPS, wird ein SUPL-Request an den SUPL_HOST gesendet – das passiert allerdings nicht jedes mal. Erzwingen könnt ihr es nach einem Geräteneustart in Kombination mit einer App, die den GPS-Standort bestimmen möchte. Teilweise war es auch notwendig, die WLAN-Schnittstelle zu deaktivieren.

Jetzt müsst ihr euch die Frage stellen, ob euch eine schnelle GPS-Positionsbestimmung via SUPL wichtig ist oder doch vielleicht eure Privatsphäre. Sollte es die Privatsphäre sein, dann müsst ihr folgende Änderung an der gps.conf vornehmen und danach euer Gerät neustarten:

SUPL_HOST=localhost
SUPL_PORT=7275

Hinweis: Es genügt nicht die Zeilen auszukommentieren. Dann wird ein Fallback aktiv. Woher die Fallback-Informationen stammen konnte ich leider noch nicht feststellen.

Mittels tcpdump könnt ihr direkt auf dem Gerät feststellen ob nun noch weiterhin SUPL-Requests versendet werden:

tcpdump -i any -s0 port 7275

Eine Frage bleibt aktuell leider weiterhin ungeklärt: Versendet das proprietäre Baseband möglicherweise selbstständig einen SUPL-Request und umgeht das Android-Betriebssystem? Dies deutet jedenfalls folgender Beitrag an: How SUPL Reveals My Identity And Location To Google When I Use GPS. Wer bei der Klärung dieser Frage behilflich sein kann, der kann mich gerne per E-Mail kontaktieren.

Mit einem »Spielzeug« wie dem HackRF One ließe sich der Mobilfunkverkehr auf dieser Ebene sicherlich mitschneiden.

Du kannst den Blog aktiv unterstützen! Mitmachen ➡