IzzyOnDroid

• Intro
• App-Listen
• Artikel
• Bücher
• Downloads
• App-Repo
• Impressum

Exodus Privacy: Der Tracker-Checker

Tracker stecken mittlerweile in zwei Dritteln aller Apps. Selbst in kostenpflichtigen. Mehr als zehn Tracker in einer App sind keine Seltenheit. Knapp zwanzig Tracker sind dem Autor dieses Artikels auch bereits in einer App untergekommen – beim „Tracker Checker“ Exodus Privacy finden sich auch Apps mit über dreißig dieser Unholde.

Was sind denn nun „Tracker”? Dabei handelt es sich um in Apps eingebundene Module von Drittanbietern, die das Verhalten der Anwender beobachten und „nach Hause telefonieren“. Diese Module haben Zugriff auf alles, auf das auch die App selbst zugreifen kann – sie sind ja schließlich Bestandteil derselben. Und so landen dann auch gelegentlich das komplette Adressbuch oder Zugangsdaten auf den Servern der Drittanbieter.

Im Google Play Store sind diese Tracker jedoch nicht ausgewiesen – hier mangelt es an der nötigen Transparenz. Bei Appbrain sind bei einigen Apps die verwendeten Bibliotheken angemerkt. Leider jedoch nicht bei allen – denn für diese Daten ist man auf die Mithilfe der Anwender angewiesen: Die dafür notwendigen Daten werden über die App Appbrain Ad Detector auf den Geräten der Anwender ermittelt.

Bei Exodus Privacy hingegen kann man, ohne eine spezielle App installiert zu haben, beliebige konstenlose Android Apps zur Analyse einreichen. Exodus bezieht dann die APK Datei aus dem Play Store, analysiert sie, und weist die Ergebnisse aus.

Für welche Betriebssysteme ist Exodus verfügbar?

Exodus selbst lässt sich über den Web-Browser bedienen. Es kann derzeit ausschließlich Android Apps untersuchen. Die Untersuchung von iOS Apps ist nicht möglich; die FAQ weist darauf hin, dass Apple’s DRM die Untersuchung strikt verbietet. Technisch wäre es durchaus möglich – nur leider illegal (die einzige Ausnahme ist „Forschung”). Das Exodus-Team weist jedoch darauf hin, dass meist in iOS Apps die gleichen Tracking-Bibliotheken zum Einsatz kommen wie bei ihren Android Pendants. Gibt es also zur gewünschten iOS App ein Android Pendent, sollte man einfach dieses untersuchen lassen.

In welchen Sprachen wird der Dienst angeboten?

Derzeit beschränkt sich die Website auf Französisch und Englisch. Gern würde man aber auch weitere Sprachen – etwa Deutsch und Spanisch – anbieten. Das gesamte Team besteht jedoch aus (überwiegend französischen) Freiwilligen. Keiner dieser Freiwilligen ist der deutschen (oder spanischen) Sprache derart mächtig, die Projekte (Website, Videos etc) in diese Sprachen zu übersetzen. Weitere Freiwillige, die dies übernehmen könnten, sind daher herzlich willkommen! Kontaktmöglichkeiten finden sich auf der Website.

Wer steht da hinter?

Exodus Privacy ist eine Französische non-profit Organization. Verwaltet wird sie von Hacktivists, deren Ziel es ist, die Privatsphäre zu schützen wo immer möglich. Auf ihrer Website gibt das Team unter „Who“ einen kurzen Hinweis dazu, wer dahinter steht, und führt sowohl die „Main Contributors” als auch Kontaktmöglichkeiten auf.

Zur Entstehungsgeschichte erzählt ein Team-Mitglied¹:

Im Spätsommer 2017 berichtete eine Online-Zeitung über die Entdeckung eines bestimmten Trackers in mehr als 50 populären französischer Apps – betroffen waren etwa 10 Millionen französische Nutzer. Verschiedene Leute begannen sich zu fragen: „Und was ist mit anderen Apps?” Auf Twitter formte sich eine kleine Gruppe, und innerhalb weniger Tage entwickelten wir die erste funktionsfähige Platform. Dann gründeten wir eine französische non-profit Organization, um das Projekt zukunftsfähig zu machen.

Unser Ziel ist es Menschen (einschließlich nicht technik-affiner) bewusst zu machen, wie sie von Apps auf ihren Smartphones getrackt werden. Dafür entwickelten wir Analyse-Tools und auch pädagogische Inhalte, wie etwa unsere Videos. Derzeit arbeiten wir an verschiedenen Projekten, einschließlich der Verbesserung der Benutzererfahrung unserer Platform – um unsere Analyse-Reports für jedermann besser verständlich zu machen.

Wie funktioniert Exodus Privacy technisch?

Exodus Privacy führt lediglich eine statische Analyse aus – stellt also fest, welche Bibliotheken im Code einer App eingebunden sind. Dabei wird keine Aussage darüber getroffen, ob eine bestimmte Bibliothek überhaupt, nur in Teilen oder gar nicht aktiv ist. Der Ablauf einer Untersuchung wird auf der Website erklärt:

Die Grundidee ist es, das Vorhandensein bekannter Tracker in einer Anwendung zu erkennen, ohne die Anwendung auszuführen. Tatsächlich kann sich εxodus nicht beliebig viel Zeit für jede einzelne Analyse nehmen; daher muss die Erkennungsmethode zeitlich effizient, reproduzierbar und frei von „Falscherkennungen” (false positives) sein.

Android Anwendungen werden in JVM kompatiblen Sprachen wie Java, Kotlin, etc. geschrieben. In einer JVM laufende Applikationen haben diverse Unterschiede zu etwa C oder Go Programmen. Einer davon ist, dass sich die Klassen-Namen ohne Dekompilation direkt aus der Binärdatei lesen lassen. JVM identifiziert sie anhand ihres voll-qualifizierten Klassennamens – wie etwa org.exodus.Report: wobei org.exodus der Paketname und Report der Klassenname ist.

Google bietet dexdump -- ein Program zum Parsen von .dex Dateien. In der Java-Welt ist kompilierter Code in .class Dateien (eine pro Klasse) enthalten. In der Android-Welt wird kompilierter Code in .dex Dateien (eine oder mehrere je App) gespeichert. Die ganze App befindet sich dann in einer .apk Datei – bei der es sich um ein signiertes ZIP Archiv handelt. Diese .apk Datei enthält die Anwendung (.dex Dateien) sowie die Assets (Fonts, Bilder etc.).

Lassen wir dexdump über eine .apk Datei laufen, erhalten wir eine Ausgabe wie diese:

Class #0            -
  Class descriptor  : ’Landroid/databinding/Observable;’
  Access flags      : 0x0601 (PUBLIC INTERFACE ABSTRACT)
  Superclass        : ’Ljava/lang/Object;’
  Interfaces        -
  Static fields     -
  Instance fields   -
  Direct methods    -
  Virtual methods   -
    #0              : (in Landroid/databinding/Observable; )
      name          : ’addOnPropertyChangedCallback’
      type          : ’(Landroid/databinding/Observable$OnPropertyChangedCallback;​ )V’
      access        : 0x0401 (PUBLIC ABSTRACT)
      code          : (none)
    #1              : (in Landroid/databinding/Observable; )
      name          : ’removeOnPropertyChangedCallback’
      type          : ’(Landroid/databinding/Observable$OnPropertyChangedCallback; )V’
      access        : 0x0401 (PUBLIC ABSTRACT)
      code          : (none)
  source_file_idx   : 25639 (Observable.java)

Class #1            -
  Class descriptor  : ’Landroid/databinding/BaseObservable;’
[…]

Diese Ausgabe ist nicht wirklich „menschenfreundlich lesbar“ – aber für jede in der App deklarierte Klasse haben wir hier einen Block, der auch einen „Class Descriptor“ enthält. Der Class descriptor ist die JVM-Repräsentation der Namensräume einer App (voll qualifizierte Klassennamen, siehe oben). In obigem Beispiel ist Class #0 android.databinding.Observable mit dem Paketnamen android.databinding und dem Klassennamen Observable.

Wir können jetzt die Ausgabe von dexdump bereinigen, sodass wir nur den jewiligen Class Descriptor sehen – und das Ganze dann sortieren:

$ dexdump my.apk | grep "Class descriptor" | sort | uniq
  Class descriptor  : ’Landroid/databinding/adapters/AbsListViewBindingAdapter;’
  Class descriptor  : ’Landroid/databinding/adapters/AbsListViewBindingAdapter;’
  Class descriptor  : ’Landroid/databinding/adapters/AbsListViewBindingAdapter$OnScroll;’
  Class descriptor  : ’Landroid/databinding/adapters/AbsListViewBindingAdapter$OnScrollStateChanged;’
  Class descriptor  : ’Landroid/databinding/adapters/AbsSeekBarBindingAdapter;’
  Class descriptor  : ’Landroid/databinding/adapters/AbsSpinnerBindingAdapter;’
  Class descriptor  : ’Landroid/databinding/adapters/ActionMenuViewBindingAdapter;’
  Class descriptor  : ’Landroid/databinding/adapters/AdapterViewBindingAdapter;’
  Class descriptor  : ’Landroid/databinding/adapters/AdapterViewBindingAdapter$OnItemSelected;’
  Class descriptor  : ’Landroid/databinding/adapters/AdapterViewBindingAdapter$OnItemSelectedComponentListener;’
  Class descriptor  : ’Landroid/databinding/adapters/AdapterViewBindingAdapter$OnNothingSelected;’
  Class descriptor  : ’Landroid/databinding/adapters/AutoCompleteTextViewBindingAdapter;’
  Class descriptor  : ’Landroid/databinding/adapters/AutoCompleteTextViewBindingAdapter;’
  Class descriptor  : ’Landroid/databinding/adapters/AutoCompleteTextViewBindingAdapter$FixText;’

In Java, C++, Python und anderen Sprachen sind Namensräume wirklich wichtig. Hat man eine Bibliothek muss man sicherstellen, dass ihr Namensraum nicht mit anderen Bibliotheken kollidiert. Man kann somit eine Bibliothek am verwendeten Namensraum erkennen.

εxodus durchsucht .apk Dateien, um Tracker zu finden – und diese Tracker können an den von ihnen verwendeten Namensräumen erkannt werden. So ist beispielsweise die Wurzel des Namensraums (der „Paketname”) der Amazon Ad Bibliothek com.amazon.device.ads und sie teilt sich den com.amazon Präfix mit anderen Amazon Bibliotheken. Somit kann der Namespace als „Tracker Signatur” verwendet werden.

Derzeit (Juni 2019) kennt εxodus 196 Tracker.

Wollen wir beispielsweise nach der Bibliothek von Flurry schauen, haben wir die Erkennungs-Regel com.flurry. – bei der es sich um einen regulären Ausdruck handelt.

Schauen wir doch einmal, ob my.apk Flurry’s Klassen enthält:

$ dexdump my.apk | grep "Class descriptor" | sort | uniq | grep -E "com.flurry." | head -n 10
  Class descriptor  : ’Lcom/flurry/android/Constants;’
  Class descriptor  : ’Lcom/flurry/android/FlurryAgent;’
  Class descriptor  : ’Lcom/flurry/android/FlurryAgent;’
  Class descriptor  : ’Lcom/flurry/android/FlurryAgent;’
  Class descriptor  : ’Lcom/flurry/android/FlurryAgent;’
  Class descriptor  : ’Lcom/flurry/android/FlurryAgent;’
  Class descriptor  : ’Lcom/flurry/android/FlurryAgent$Builder;’
  Class descriptor  : ’Lcom/flurry/android/FlurryAgentListener;’
  Class descriptor  : ’Lcom/flurry/android/FlurryEventRecordStatus;’
  Class descriptor  : ’Lcom/flurry/android/FlurryGamingAgent;’

wie wir sehen, sind Flurry’s Klassen in my.apk zu finden.

Wenn man also eine App zur Analyse an εxodus übermittelt, lädt εxodus diese vom Google Play Store herunter, extrahiert die .apk Datei, ruft dexdump auf, speichert die gefilterte Ausgabe in einer Datei (welche bei Updates des Reports genutzt wird, um die Analyse zu beschleunigen), nimmt die Erkennungs-Regeln jedes bekannten Trackers und schaut, ob sich passende Klassen finden. Gibt es einen oder mehrere Treffer wird davon ausgegangen, dass der Tracker in der App eingebunden ist – andernfalls nicht.

Welche Schwächen und Lücken hat das Verfahren und wie kann man sie eventuell mit anderen Mitteln stopfen?

Wie bereits ausgeführt, kann eine statische Analyse nur das Vorhandensein von Bibliotheken feststellen – jedoch keine Aussage darüber treffen, ob der entsprechende Code aktiv ist (also irgendwann ausgeführt wird) oder nicht.

Derzeit dürfen in Frankreich lediglich Forscher Anwendungen dekompilieren (und somit feststellen, ob ein Tracker aktiv ist oder nicht). Das ist keine Schwachstelle von Exodus selbst, sondern vom Gesetz. An dem Tag, an dem das Gesetz die Prüfung von Tracker Aktivität erlaubt (entweder, weil eine App Open Source wird, oder weil das Gesetz das Dekompilieren erlaubt), wird Exodus dies auch umsetzen. Die größte Schwachstelle ist, dass jede Tracker-Signatur manuell erfasst werden muss, basierend auf der Hilfe der Community.

Als Anwender kann man jedoch die Netzwerk-Aktivität einer App z. B. mittels Net Monitor testen (wobei eine Zuordnung zu einem bestimmten Tracker dabei nicht unbedingt immer einfach ist) – oder auch ClassyShark3xodus verwenden (welches die Apps direkt auf dem Gerät prüft).

Anders als Exodus Privacy führt beispielsweise AppCensus eine dynamische Analyse durch. Das heisst: Die Apps werden in einer Laufzeitumgebung gestartet und der Netzwerkverkehr einer App wird auf die Übermittlung sensibler, personenbeziehbarer Daten / Identifier überprüft. Kurz beschrieben ist dies beim Sicherheits-Experten (und c’t Autoren) Mike Kuketz. Die aktuellste Analyse dort stammt allerdings von August 2018; es ist daher unklar, ob der Dienst aktuell noch aktiv ist. Anders als bei εxodus kann der Anwender hier keine Apps zum Scannen einreichen, sondern nur in vorhandenen Ergebnissen suchen.

Beispiele einiger prominenter Tracker

Eine Liste der Apps mit den meisten Trackern findet sich u. a. auch bei Exodus Privacy. Sprach ich eingangs davon, bereits Apps mit bis zu 20 Trackern gesehen zu haben, ist hier der höchste „Tracker-Befall” 40 oder mehr – bei gleich 6 Apps²!

Ebenfalls bei Exodus Privacy zu finden: Eine Statistik mit den am häufigsten anzutreffenen Trackern.

Es gibt verschiedene Arten von Trackern. Ihnen ist gemein, dass sie Daten in der Regel ohne Einverständnis bzw. gar ohne Wissen der Anwender verschicken:

• Crashreporter verschicken automatisch Absturz-Berichte, wenn die App sich abnormal beendet (abstürzt). Was dabei übertragen wird ist je nach Bibliothek unterschiedlich; im Vergleich zu den anderen Trackern sind sie jedoch eher „harmlos”. In diese Kategorie gehören beispielsweise Bugsee und Bugsnag, welche ihre Berichte ungefragt verschicken. Dass es auch anders geht bezeugen ACRA und Bugclipper, die eher Privatsphäre-orientiert arbeiten: ob und was verschickt wird, entscheidet bei ihnen der Anwender.
• Analytics Module protokollieren das Nutzerverhalten – und schicken die teilweise recht umfangreichen gesammelten Daten ohne Einverständnis/Wissen des Anwenders „nach Hause”. Besonders brisant wird dies, wenn es sich bei den Betreibern um Netzwerke handelt, die ohnehin schon umfangreiche Benutzerprofile erstellen – wie etwa Google oder Facebook. Und so sind die bekanntesten Vertreter hier auch Google Crashlytics, Google Firebase Analytics und Facebook Analytics.
• Werbemodule sollen den Anwender mit (oftmals persönlich zugeschnittener) Werbung versorgen. Das mag jetzt zunächst harmlos klingen – ist es aber meist nicht: Diese Werbemodule haben, wie alle anderen Bestandteile einer App, Zugriff auf alles, auf das auch die App Zugriff hat – wie ich in meinem Artikel Was hat es mit den Modulen in Apps auf sich ausführlich erkläre. Und für die Personalisierung der Werbung bedienen sie sich häufig auch ausführlich und teilweise recht übergriffig, siehe Warnungen vor „Schnüffel-Modulen”. Bekannteste Kandidaten hier sind Google Ads, Google DoubleClick, AdMob und Facebook Ads – aber auch Twitter’s MoPub.
• Social Networks werden häufig für „Sharing“ (Teilen von Inhalten mit Freunden) verwendet – obwohl Anwender, die diese Funktionalität nutzen wollen, das eigentlich ganz normal über die in Android integrierte „Share-Funktionalität” tun könnten, sofern sie die Apps ihrer sozialen Netzwerke installiert haben. Das Gemeine an der Sache: Auch wenn man selbst nicht bei einem solchen Netzwerk aktiv ist, landen mit diesen Modulen in der Regel recht sensible Daten dort. Besonders häufig eingebunden sind Module von Facebook – wozu Heise bereits berichtete.

Den Entwicklern ist die Übergriffigkeit dieser Module oftmals gar nicht bewusst; gelegentlich werden sie trotz Wissens jedoch auch ignoriert. Insbesondere in Bezug auf Analytics und Crash Reporting ist der Grund häufig, dass die verwendeten Dienste vom Entwickler weit bequemer zu nutzen sind, und ausführlichere/tiefer-greifende Details bieten.

Ist IzzyOnDroid mit Exodus verbandelt?

In gewisser Weise, ja: die Applisten machen sich Exodus’ Services zu Nutze. Wann immer eine App (hinzugefügt oder) aktualisiert wird, fragt der „App List Updater“ bei Exodus an, ob für die neue Version Scan-Ergebnisse vorliegen – ist dies nicht der Fall, wird die entsprechende App sogar für einen Scan eingereicht. Ergebnisse landen in der Datenbank, und werden für die Anzeige in den App-Listen verwendet: Neben der App erscheint ein wenn Exodus sie als „Tracker-frei“ ausweist – oder ein (e Reihe von) sofern sie besonders intrusive Tracker enthält. Daher an dieser Stelle auch mein besonderer Dank an das Exodus-Team!

Weiterführende Links

• F-Droid: New Collaborations on Exposing Tracking
• Exodus Privacy auf Github
• Exodus Privacy Peertube Channel
• Exodus Privacy als Android-App (Video Walk-Through (6/2018))
• ClassyShark3xodus prüft die Apps auf dem Gerät – also unabhängig von ihrer Quelle
• Exodify: Ein Addon für Firefox und auch für Chrome/Chromium, das die Anzahl der Tracker einer App direkt auf der zugehörigen Play Store Webseite einblendet