Module in Apps identifizieren

Drupal Modules; © Richard Scott
(CC BY-NC-SA; Quelle: Flickr)

Die Verwendung von Modulen in der (App-) Entwicklung ist ein großartiges Konzept: Das Rad muss nicht jedes Mal neu erfunden werden, Fehlerbehebung sowie die Ergänzung neuer Funktionalitäten können an zentraler Stelle erfolgen – und jeder Entwickler sich auf den Bereich konzentrieren, in dem er oder sie am besten ist. Das ist die Kernidee hinter vielen nützlichen Modulen, die zur Funktionalität von Apps beitragen. Daher gibt es auch recht viele davon, die spezielle Bereiche abdecken; etwa Datenbank-Interaktionen, GUI Elemente, Datei-Operationen, und so weiter. Und dann wären da… Tracker, die unsere Aktivitäten verfolgen und „irgendwohin“ melden. Sowie proprietäre Module, deren Quellcode sich nicht einsehen lässt – und deren Tätigkeiten somit nicht einschätzbar sind. Beides zumindest potentielle Gefährder der Privatsphäre.

Danaer, die Geschenke bringen

„[…] timeo Danaos et dona ferentes“ sagt Vergil’s Priester Laokoon in der Aeneis – „ich fürchte die Danaer, auch wenn sie Geschenke tragen.“ Auch so manche App aus Google’s Play Store ließe sich mit Fug und Recht als „Trojanisches Pferd“ bezeichnen. Etwa haushoch bewertete „Antivirus“ Apps, die im Hintergrund Pornos surfen. Oder weitere Apps des gleichen Herstellers, die unter der Haube Werbebetrug betreiben. Millionenfach heruntergeladen, mit Bewertungen oberhalb der 4,5 Sterne – und nach wie vor im Google Play Store verfügbar (sowie auf etlichen Samsung-Geräten vorinstalliert).

App-Reviews auf etablierten Portalen gehen (mit wenigen Ausnahmen) nur auf „oberflächliches“ ein: grafische Gestaltung, Funktionsumfang und wie gut eine App funktioniert. Was hinter den Kulissen passiert, erfährt man dort selten. Die Frage, wie es um die Sicherheit der eigenen Daten bestellt ist, bleibt unbeantwortet – und zwar nicht nur in Bezug auf besagte Hintergrund- oder besser Untergrund-Aktivitäten, sondern auch bezüglich der Datenübertragung und -speicherung selbst: Werden die Daten verschlüsselt übertragen und gespeichert? Wo werden sie gespeichert? Wer hat noch alles Zugriff darauf? Und welche Daten sind überhaupt betroffen?

Gefahrenzone: Tracker inside!

am häufigsten angetroffene Tracker

Von Exodus Privacy habe ich bereits in meinem Artikel Exodus Privacy: Der Tracker-Checker berichtet – als einem Dienst, der sich dem Aufspüren von Tracking-Modulen in Android Apps verschrieben hat. In den Statistiken von Exodus finden sich zahlreiche Apps, die mehr als 50 Tracking-Module enthalten. Wer erinnert sich noch an die Zeiten, als eine App mit mehr als 100 Kilobyte als „ziemlich groß“ galt? Heute hat beispielsweise die Wecker-App Alarmy eine Größe von mehr als 80 Megabyte! Ob die in der App enthaltenen 40 Tracking-Module auch damit etwas zu tun haben könnten, halte ich für eine rhetorische Frage. Nicht so lustiger Fun-Fakt: Die Top-10 der am weitesten verbreiteten Tracking-Module bestehen ausschließlich aus Kandidaten von gerade einmal zwei Firmen. Unschwer zu erraten: Google und Facebook (siehe Grafik).

Nicht im Fokus von Exodus sind andere proprietäre Bestandteile von Apps. Proprietär heißt in diesem Zusammenhang: der Quellcode ist nicht (öffentlich) einsehbar. Wer kann also sagen, was diese Module in der Praxis tun – außer dem, was uns ihre Hersteller anpreisen? Nicht einmal der Anbieter der jeweiligen App kann garantieren, dass dabei alles mit rechten Dingen zugeht. Wie auch? Hier muss der Nutzer also nicht nur dem Anbieter der App, sondern auch denen der entsprechenden Module vertrauen. „Timeo Danaos“: Diese Module werden großteils von Werbefirmen (allen voran Google) gratis angeboten. Ein Schelm…

Inhaltsangaben: Wo zu finden?

Wer nun erwartet, etwa im Google Play Store dazu Angaben zu finden, glaubt sicher auch, dass der Klapperstorch die Kinder bringt. Google würde sich ja sein eigenes Werbegeschäft vermiesen – da insbesondere der übermäßige Einsatz solcher „Anti-Features“ doch einige Anwender abschrecken dürfte. Derartige Transparenz findet man allenfalls bei F-Droid, wo Anti-Features klar ausgewiesen werden. Dort ist die Anzahl verfügbarer Apps allerdings deutlich kleiner (derzeit sind es gerade einmal über 3.300 Apps).

Bei Appbrain finden sich häufig die in einer App verwendeten Bibliotheken ( „gute“ wie auch „böse“) aufgelistet. Die Spreu vom Weizen zu trennen bleibt dabei jedoch dem Besucher überlassen. Zwar wird eine grobe Unterteilung in „Werbenetzwerke“, „Soziale Netze“ und „Entwicklungs-Tools“ vorgenommen – Tracking-Module werden aber nicht explizit als solche ausgewiesen; so würde etwa das Facebook-SDK (einer der größten Sammler für den gleichnamigen Konzern) in den Bereich „Soziale Netze“ fallen, oder Flurry (ein recht übergriffiger Analysedienst) unter „Entwicklungs-Tools“; der Besucher muss also schon wissen, was sich hinter welchem Namen verbirgt.

Besser sieht es da bei Exodus Privacy aus: Hier werden ausschließlich Tracking-Module berücksichtigt. Zu den jeweiligen Modulen sind außerdem teilweise recht umfangreiche Informationen hinterlegt. Apps, die dem Dienst noch nicht bekannt sind, kann man zur Analyse selbst einreichen (und das Ergebnis gleich abwarten). Der Haken: Es lassen sich nur frei verfügbare Apps untersuchen, die entweder im Google Play Store oder bei F-Droid verfügbar sind. Kostenpflichtige oder nur in bestimmten Ländern verfügbare Apps aus dem Google Play Store oder gar APK-Dateien, die man aus anderer Quelle herunter geladen hat, leider nicht.

Besonders empfehlenswert ist in diesem Kontext der MobilSicher AppCheck. Dieser führt nicht nur automatische Analysen durch: Zahlreiche Apps wurden (und werden) auch von Experten kritisch seziert – etwa auf ihre Hintergrund-Aktivitäten, auf welche Daten zugegriffen und wohin selbige ggf. übertragen werden, ob Speicherung und Übertragung verschlüsselt erfolgen, und mehr. Auch hier gilt jedoch: Nur Apps von F-Droid oder aus dem Google Play Store werden berücksichtigt.

Was aber nun tun, wenn man Apps aus anderen Quellen bezieht? Etwa von der Website des jeweiligen Entwicklers selbst, oder von Codeberg, Github, GitLab & Co?

Library Scanner to the rescue!

Es gibt diverse Projekte, die sich diesem Thema gewidmet haben: Wie analysiere ich eine APK-Datei um herauszufinden, was „drin steckt“? Auf die Methodik dazu wurde im bereits genannten Exodus-Artikel eingegangen. Weitere Beispiele von Software, die man auch auf dem eigenen Rechner einsetzen kann, wären etwa

LibRadar (Python-basiert; leider seit 12/2018 nicht mehr weiter entwickelt)
radare2 (aktiv entwickeltes Forensik-Toolkit)
Apktool (Java, aktiv entwickelt)
Androguard (Python, aktiv entwickelt; im Einsatz u. a. bei Exodus und F-Droid)
android-classyshark (von vielen Tools als Grundlage verwendet)
zahlreiche weitere Tools in der Liste von android-security-awesome

Diese Tools erlauben es, eine APK-Datei zu „reverse engineeren“ und einen Blick in die Bestandteile zu werfen. Hat man zusätzlich noch eine Datenbank mit Library-Specifications zur Hand, lässt sich so einiges daraus ableiten. Am Beispiel von Apktool soll das im Folgenden kurz aufgezeigt werden.

Apktool

Da Apktool als *.jar Datei daher kommt, wird für die Verwendung Java benötigt. Desweiteren bewegen wir uns an der Kommandozeile:

# ein Verzeichnis erstellen, in dem gearbeitet werden soll, und dort hinein wechseln
mkdir test
cd test
# Apktool herunterladen und einsatzbereit machen
wget https://github.com/iBotPeaches/Apktool/releases/download/v2.5.0/apktool_2.5.0.jar
wget https://github.com/iBotPeaches/Apktool/raw/master/scripts/linux/apktool
chmod u+x apktool
ln -s apktool_2.5.0.jar apktool.jar

Fertig. Jetzt kann eine beliebige APK-Datei dorthin kopiert und „zerlegt“ werden, indem man ./apktool d meine.apk eingibt. Als Resultat erhält man ein Verzeichnis mit dem Namen der APK-Datei (nur ohne die .apk Endung) – hier also meine. Darin befindet sich u. a. ein Verzeichnis namens smali – über welches sich die in der App verwendeten Bibliotheken ermitteln lassen. Verwendet eine App also beispielsweise Google Mobile Services, findet sich ein Verzeichnis namens meine/smali/com/google/android/gms.

Die Grundlagen sind somit vorhanden – eine händische Analyse ist jedoch nicht nur mühsam, sondern man muss auch die Paketnamen kennen, nach denen gesucht werden soll. Dabei helfen Library Definitionen, die die jeweiligen Pfade Modul-Namen sowie den Modulnamen weitere Details zuordnen – und ein kleines Wrapper-Skript, welches die Analyse weitgehend automatisiert.

Mit Library Definitions

Eine passende Sammlung von Library Definitions sowie ein passendes Wrapper-Skript finden sich beispielsweise im GitLab-Repo von IzzyOnDroid. Das Skript selbst setzt eine Kommandozeilen-Version von PHP einschließlich des zugehörigen JSON-Paketes voraus (Debian/Ubuntu/Mint: apt install php-cli php-json), lässt sich aber mit ein wenig Programmierkenntnissen recht einfach in andere Sprachen übertragen.

Um die Library-Definitionen in Zukunft einfach auf dem aktuellen Stand¹ halten zu können empfiehlt es sich, das Repo zu clonen:

# das Repo clonen
git clone https://gitlab.com/IzzyOnDroid/repo.git
# ein Verzeichnis für Apktool erstellen und die apktool* Dateien dorthin verschieben
mkdir -p repo/lib/radar/tool
mv test/apktool* repo/lib/radar/tool
# einen Alias für den einfacheren Aufruf erstellen
alias scanapk=$(pwd)/repo/bin/scanapk.php

Das war es auch bereits – jetzt lassen sich APK-Dateien weitgehend automatisch analysieren:

$ scanapk com.bhandari.music_190.apk

Libraries detected:
-------------------
* Android Design Support Library (/android/support/design): Utility
* Android Support v4 (/android/support/v4): Development Framework
* Android Support v7 (/android/support/v7): Development Framework
* Androidx Core (/androidx/core): Utility
* Media (/androidx/media): Utility
* Butter Knife (/butterknife): Utility
* Material Dialogs (/com/afollestad/materialdialogs): UI Component
* Glide (/com/bumptech/glide): Utility
* Google Ads (/com/google/ads): Advertisement Ads
* FlexboxLayout (/com/google/android/flexbox): Utility
* Google Mobile Services (/com/google/android/gms): Development Framework NonFreeDep
* Firebase (/com/google/firebase): Utility NonFreeNet,NonFreeDep
* Firebase Analytics (/com/google/firebase/analytics): Mobile Analytics Tracking
* Google Gson (/com/google/gson): Utility
* SnappySmoothScroller (/com/nshmura/snappysmoothscroller): UI Component
* ShineButton (/com/sackcentury/shinebuttonlib): UI Component
* RecyclerView-FastScroll (/com/simplecityapps/recyclerview_fastscroll): UI Component
* Android Sliding Up Panel (/com/sothree/slidinguppanel): UI Component
* OkHttp (/com/squareup/okhttp): Utility
* Android Image Cropper (/com/theartofdev/edmodo/cropper): Utility
* AVLoadingIndicatorView (/com/wang/avi): UI Component
* MaterialProgressBar (/me/zhanghai/android/materialprogressbar): UI Component
* jsoup (/org/jsoup): Utility
* Calligraphy (/uk/co/chrisjenx/calligraphy): Utility

Offending libs:
---------------
* Google Ads (/com/google/ads): Ads
* Google Mobile Services (/com/google/android/gms): NonFreeDep
* Firebase (/com/google/firebase): NonFreeNet,NonFreeDep
* Firebase Analytics (/com/google/firebase/analytics): Tracking

4 offenders.

Wie am Beispiel ersichtlich, werden alle identifizierten Bibliotheken/Module aufgelisted – und als kritisch bekannte am Ende nochmals zusammengefasst. Für letztere werden auch die zugehörigen Anti-Features aufgeführt, deren Bedeutung sich beispielsweise bei F-Droid nachschlagen lassen. Leicht abweichend von der dortigen Beschreibung bedeutet NonFreeDep hier jedoch, dass das entsprechende Modul selbst „unfrei“ ist – wie am Beispiel von Google Mobile Services sowie Firebase zu sehen.

Details zu den aufgespürten Modulen lassen sich übrigens in der Datei lib/libinfo.txt finden, wenn man dort nach "id": "<PaketName>" (also z. B. "id": "/com/google/firebase") sucht: eine Kurzbeschreibung, sowie ein Link zum jeweiligen Projekt. Und wem das jetzt irgendwie bekannt vorkommt: Genau, das wird im F-Droid Repo von IzzyOnDroid verwendet.

appshowtoprivacysecurity

im genannten Git-Repo werden sie regelmäßig um neue Einträge ergänzt sowie bei Bedarf auch korrigiert; dies geschieht etwa ein bis zwei Mal monatlich. ↩︎

2021-01-29