Thomas Skora

Vor einiger Zeit fiel mir auf meinem Android-Smartphone auf, dass es etwa ein mal die Stunde beim Entsperren des Geräts einen GPS-Fix durchführte. Dieses Verhalten konnte ich mir nicht wirklich erklären, weil ich während dessen und auch zuvor keine Navigationssoftware, Maps oder sonstiges genutzt hatte, was auf meine GPS-Position zugreift. Glücklicherweise wurde in dieser Zeit auch der LBE Privacy Guard veröffentlicht - übrigens ein Stück Software, dass ich jedem technisch und an seiner Privatsphäre interessierten Android-Nutzer mit gerootetem Gerät nur empfehlen kann. Mit Hilfe des LBE Privacy Guards konnte der Übeltäter schnell ausgemacht werden: die Musikerkennungs-Software Shazam.

Nun war die Neugierde geweckt und ich musste herausfinden, was Shazam damit macht und ob sich diese Verhaltensweise irgendwie beeinflussen lässt. Die erste Vermutung war, dass Shazam oder eine darin enthaltene Ad- bzw. Spyware in regelmäßigen Abständen die aktuelle Position des Nutzers erfasst und überträgt.

Erste Untersuchung

Mit Hilfe einer meiner WRT-Router sniffte ich den Datenverkehr zwischen Smartphone und Internet, während ich etwas mit Shazam rumspielte. Hier zeigte sich, dass es bei der Erkennung von Musikstücken neben der dafür benötigten Daten auch eine Device-ID, sowie die aktuelle Position an Shazam und den Ad-Service AdMarvel versendet wurde. Die Übertragung der Positionsdaten an Shazam ließ sich durch das Abschalten der "Position mittaggen"-Option unterbinden.

Langzeit-Analyse

Während des Sniffens am Router kam es leider nicht dazu, dass Shazam beim Entsperren des Geräts versuchte auf meine Position zuzugreifen. Also ließ ich auf dem Androiden ca. 20 Stunden lang einen tcpdump laufen, der sämtlichen Traffic protokollierte und zahlreiche Standortbestimmungen von Shazam mitbekam.

Nachdem der Standort durch den Shazam-Prozess bestimmt wurde, wird dieser an die URL http://ads.admarvel.com/fam/androidGetAd.php per POST gesendet:

&site_id=14488&partner_id=ef8a30b841b36346&timeout=5000&version=1.5&language=java&format=android
&sdk_version=2.1.23&sdk_version_date=2011-06-28&device_model=HTC Desire&device_name=FRF91
&get_cached_ads=true&device_systemversion=2.3.4&resolution_width=480&max_image_width=480
&resolution_height=800&max_image_height=800&device_os=Android
&target_params=...

Der Parameter target_params enthält URL-Encoded folgendes:

appv=>com.shazam.android||
loc=>xx.xxxxxxxx%2Cx.xxxxxxxx||
co=>DE||
screenorient=>p||
appvn=>3.2.1-BB70972||
osv=>2.3.4

Man sieht, dass hier unter anderem der Standort, Gerätetyp, Android-Version, Bildschirmausrichtung und -auflösung versendet werden. Identifier, die eine eindeutige Zuordnung des Geräts erlauben scheint es nicht zu geben. Die beiden Parameter site_id und partner_id wirken vom Namen her nicht wie eindeutige Geräte-IDs.

Und nun?

Tatsache ist, dass über Shazam die aktuelle Position neben anderen Daten an AdMarvel übermittelt wird. Das erfolgt in regelmäßigen Abständen von 1-2 Stunden anonymisiert, beim Taggen wird der Benutzer mit einer eindeutigen Geräte-ID identifiziert. AdMarvel erhält in jedem Fall den Standort, unabhängig davon, ob man die Standortbestimmung in Shazam aktiviert hat.

In der FAQ steht davon nichts. In den Nutzungsbedingungen wird das Thema "Location Based Services" aufgegriffen, allerdings nur für den Musikerkennungsdienst selbst. Werbung und deren Handhabung mit Standortdaten wird gesondert behandelt. Von einem regelmäßigen Versenden der Standortdaten konnte ich beim überfliegen der Nutzungsbedingungen nichts finden.

Ich habe an sich nichts gegen Werbeeinblendungen in Apps, irgendwo muss sich die Entwicklung auch lohnen. Mir ist auch bewusst, dass Standortdaten vom Mobilfunker und Google erfasst und verarbeitet werden. Dem habe ich aber irgendwo mal explizit zugestimmt und bin mir dessen ständig bewusst bzw. es fließen für mich wertvolle Informationen wie präzise und aktuelle Staumeldungen zurück. Ein ungefragtes regelmäßiges versenden der Position an einen Werbedienstleister geht mir dann aber doch etwas zu weit, auch wenn es anonym erfolgt. Deswegen ist Shazam jetzt auch dauerhaft von meinem Androiden runtergeflogen ;)

Rest-Traffic

Der Mitschnitt war nicht nur wegen Shazam erkenntnisreich, es gab auch ein paar andere interessante Beobachtungen. Die werde ich hier demnächst auch mal zusammenfassen.

Vor ein paar Wochen hab ich mich mal der Webseite des Online Brokers Cortal Consors gewidmet und dort, während ich eingeloggt war, nach Schwachstellen gesucht. Ich war dann doch erstaunt, dass ich in so einem sensiblen Bereich bereits nach wenigen Minuten fündig wurde und dort eine Cross-Site Scripting-Schwachstelle ausfindig machen konnte. Im Online-Archiv kann man die dort hinterlegten Dokumente unter anderem nach WKN filtern. Gab man dort etwas ein, womit das System nichts anfangen konnte, dann wurde diese Eingabe ungefiltert wieder ausgegeben. Kleingeschriebenes wird zwar in Großbuchstaben umgewandelt, einem erfolgreichen Cross-Site Scripting steht das aber nicht im Wege. Kurze Zeit später stand der PoC, mit dem die Sicherheitslücke demonstriert werden konnte:

Da das betroffene Formular kein CSRF-Token aufweist, hätte diese Sicherheitslücke auch über Cross Site Request Forgery ausgenutzt werden können. Dies unterstreicht meine Sichtweise, dass auch Formulare welche keine Zustandsänderung der Webanwendung bewirken, wie z.B. Suchfunktionen, mit einem CSRF-Token abgesichert werden sollten, um genau solche Schwachstellen nicht von außen Ausnutzbar zu machen.

Die Schwachstelle habe ich umgehend (am 21.06.) gemeldet und aufgrund der aus meiner Sicht hohen Kritikalität um schnelle Behebung gebeten. Irgendwann um den 04.07. herum war sie dann behoben. Seitdem ist man sofort ausgeloggt, wenn man im OnlineArchiv nach WKNs sucht, die z.B. das Zeichen "<" enthalten :-)