Freie Software und deren Untersuchung sind die Schlüssel für vertrauenswürdige Computerprogramme

Die Untersuchung von Software ist essentiell für das Verständnis, was das Stück Software tatsächlich macht. Und freie Software heißt, dass alle Anwender die verbriefte Möglichkeit haben, den Quellcode, dem sie vertrauen, vollständig zu überprüfen. Die Cyber-Security-Industrie baut auf Prüfsoftware, um Malware herauszufinden und Schutz dagegen zu entwickeln. Malware-Scanner nutzen riesige Sammlungen von charakteristischen Software-Signaturen, um Milliarden von Geräten zu durchforsten, da das Finden neuer Angriffsziele die Inspektion, technical Analyse und Forensik von Code erfordert. Das ist das bekannteste Gebiet der Software-Untersuchung. Es gibt auch Freiwillige, Wissenschaftler und zivilgesellschaftliche Institutionen, die nach Tracking suchen, das gezielt Angriffe, verführerische Dark Patterns, Überwachungskapitalismus und andere unethische Praktiken ausübt. Die F-Droid-Community baut ebenfalls auf Überprüfung, um sicherzustellen, dass wir freie Software ausliefern und Anti-Features kennzeichnen.

Einige Entwickler werden die Merkmale beschreiben aber die wichtigen Einzelheiten dazu weglassen. Dies kann einfach ein schlichtes Übersehen sein, oder sie wissen vielleicht schon, dass Anwender damit unglücklich wären, und beabsichtigen, diese Details vor der Öffentlichkeit zu verbergen. Selbst Entwickler, die hart an sich arbeiten, transparent zu sein und ihre Anwender ehrlich bedienen, können verführt werden. Wir haben riesige Industrien, die Entwickler verleiten, alle Arten von Bibliotheken und Diensten in ihre Apps einzuschließen, weil sie die Funktionalität oder die Weiterentwicklung verbessern werden.

  • “Gelegenheiten zu finden, Einkommen zu generieren, sollte nicht schwierig sein!”
  • “Eine großartige Datenerhebungssoftware versetzt Sie in die Lage, Ihre Produktivität zu maximieren!”
  • “App-Monetarisierung ist eine Möglichkeit, Ihnen dabei zu helfen, Geld mit Ihrer mobilen App zu verdienen, ohne Gebühren für sie zu erheben.”

So etwas beinhaltet oft Dinge, die Anwender nicht möchten. Was solche Industrien eigentlich sagen ist: sammle so viel persönliche Daten wie möglich, überwache die Nutzer, fessle sie mit verführerischen Dark Patterns und beanspruche ihre Aufmerksamkeit, indem du ihnen so viel Werbung wie möglich zeigst. Wir arbeiten daran, solche Dinge aufzudecken und Tools zu entwickeln, damit wir schlagkräftiger werden und mehr Leute davon mitbekommen.

Nach Signaturen scannen

Eine der zuverlässigsten Methoden für die Softwareinspektion von Menschenhand ist die automatische Anwendung von Signaturen interessanter Features, die einem menschlichen Prüfer präsentiert werden sollen. Die Signaturen können Stücke binären Maschinencodes, URLs, Funktionsnamen, Domain-Namen oder Metadaten-Stückchen wie API-Key-IDs sein. Binärcode-Signaturen sind das Hauptverfahren, das von allen Arten der Malware-Scanner genutzt wird. Malware-Forscher arbeiten daran, kleine Muster herauszufinden, die für diese spezielle Malware einzigartig sind und sonst nirgends auftreten. Hier ist ein Beispiel für solch eine Signatur, es ist das YARA-Profil für den Trojaner Silentbanker:

    strings:
        $a = {6A 40 68 00 30 00 00 6A 14 8D 91}
        $b = {8D 4D B0 2B C1 83 C0 27 99 6A 4E 59 F7 F9}
        $c = "UVODFRYSIHLNWPEJXQZAKCBGMT"

    condition:
        $a or $b or $c

F-Droid nutzt auch Signaturen, um App-Maintainer dabei zu helfen, unerwünschte Merkmale zu finden und unfreie Bits zu blockieren. Die älteste Version davon ist das Befehlszeilen-Tool fdroid scanner. F-Droids Gründer, Ciaran Gultnieks, fügte vor mehr als zehn Jahren einen Scanner hinzu, um einige „übliche Verdächtige“ zu finden:

    # Nach allgemein bekannten unfreien Blobs suchen:
    usual_suspects = ['flurryagent',
                      'paypal_mpl',
                      'libgoogleanalytics',
                      'admob-sdk-android',
                      'googleadview',
                      'googleadmobadssdk']

Exodus Privacy hat eine große Sammlung von Profilen bei Überwachungsfirmen aufgebaut. ETIP ist ihre Plattform für die Erstellung und Verwaltung der Profile von Trackern. Die Daten werden dort eingetragen und gepflegt und wenn sich dann die vorgegebenen Profile als genau genug erwiesen haben, werden sie dem offiziellen Exodus-Datenstamm hinzugefügt. Diese Profile beinhalten Signaturen zur automatischen Erkennung der Tracker in den APK-Dateien, die auf eurem Gerät gespeichert sind, wenn ihr eine App installiert. F-Droid nutzt schon seit langer Zeit indirekt die Exodus-Profile.

id: d25d820d-4c97-420e-a7d7-72434c58a575
name: ABTasty
description: |
  You can use this library to access AB Tasty endpoints, which can
  generate a unique visitor ID, allocate a visitor to a test, and push
  visits and conversions events in order to help you analyze the
  outcomes of your campaigns.
documentation:
  - https://developers.abtasty.com/android-sdk.html
is_in_exodus: true
code_signature: com\.abtasty
network_signature: abtasty\.com
api_key_ids:
website: https://www.abtasty.com
maven_repository:
  - https://sdk.abtasty.com/android/
  - https://dl.bintray.com/abtasty/flagship-android
  - https://dl.bintray.com/abtasty/Android-sdk
group_id: com.abtasty
artifact_id: librarybyapi
gradle: com.abtasty:librarybyapi:1.1.0

@IzzySoft unterhält das F-Droid-Repo für „fast freie“ Apps. Es beinhaltet seine eigenen Signaturen zur Erkennung der Anti-Features, die auf f-droid.org nicht erlaubt sein mögen, wie auch eine weitere Verteidigungslinie zur Erkennung gewöhnlicherer Anti-Features wie Tracking.

anti_features:
- NonFreeDep
- Tracking
code_signatures:
- com\.heapanalytics
description: |-
  automatically captures every web, mobile, and cloud interaction:
  clicks, submits, transactions, emails, and more. Retroactively
  analyze your data without writing code.
license: Proprietary

Plexus ist ein Projekt des Techlore-Gemeinschaftsvorhabens zur Festlegung, welche Apps auf „google-freien“ Geräten laufen und welche Apps mit microG dem freien Softwareersatz für die Google Play Services funktionieren. Sie erfassen die Ergebnisse der von Menschen durchgeführten Tests in einem maschinenlesbaren Format. Obwohl es auf menschlichen Testern beruht, nicht auf automatisiertem Abgleichen von Mustern wie die meisten anderen hier erwähnten Projekte, besitzen die entstehenden Daten eine ähnliche Struktur und können in derselben Weise abgeschöpft werden, um Berichte zu generieren, beispielsweise mit issuebot.

Application: The New York Times
Package: com.nytimes.android
Version: 0.0.0
DG_Rating: X
MG_Rating: 4
DG_Notes: X
MG_Notes: Can't login with Google

Mobil Sicher überprüft ebenfalls Apps, mit dem Schwerpunkt auf Deutschland. Sie besitzen ein beeindruckendes System, um dynamische Analysen von Apps durchzuführen, die genau herausfinden sollen, welche Dienste sie im Internet nutzen. Und mit diesen Daten, können sie nicht nur Tracker markieren, sondern auch ob eine App persönliche Daten zu Drittanbieter-Diensten wie Werbefirmen, Cloud-Diensten usw. sendet.

Unsere Partner verwenden auch Signaturen, lasst uns die Kräfte bündeln!

Nachdem wir mit verschiedenen Organisationen über deren Signatur-Sammlungen sprachen und einige von ihnen auf die App-Sammlung von f-droid.org anwandten, wurde klar, dass es eine Menge gemeinsamer Strukturen gab. Aber jedes System ist auf eine Art eingerichtet, dass es für die anderen fremd aussieht: Python-Code, Admin-Gremien von Django, E-Mail-Anträge usw. Wenn weitere Mitwirkende dazustoßen und einen Beitrag leisten wollen, müssen sie das Format eines jeden Projekts verstehen. Das kann zeitaufwändig sein, und es gibt kein standardisiertes Format, dem man folgen kann. Dann machte @pnu von Exodus Privacy den Vorschlag, ihr Bearbeitungssystem als Dateien in einem Git-Repo neu zu schreiben. Das war der Funke, der uns erkennen ließ, dass ein Git-Repo aus von Menschen bearbeitbaren Datendateien auf alle diese Datensammlungen angewandt werden könnte.

Dieser Idee folgend starteten wir F-Droid SUSS (Suspicious or Unwanted Software Signatures - Verdächtige oder unerwünschte Software-Signaturen). Es ist F-Droids Signatursammlung, um Anti-Features oder unerwünschte Merkmale in Android-Apps aufzuspüren. SUSS ist das erste Live-Projekt und das Tool fdroid scanner wird es verwenden. SUSS basiert auf YAML-Dateien, eine Datei pro Profil. YAML sind im Wesentlichen strukturierte Daten, das heißt von Menschen bearbeitet (jedes valide JSON ist selbst gültiges YAML). YAML wird auch überwiegend verstanden, nachdem das .yml-Format in FDroids eigenen Metadaten, in GitLabCI, Github Actions und FUNDING.yml sowie vielen weiteren verwendet wird. Außerdem wird es in allen Arten von Editoren, samt Syntax-Hervorhebung, unterstützt.

Dies ist ein Schritt hin zu besserer Vernetzung mit anderen Organisationen, die dieselben Ziele wie F-Droid verfolgen. Standardisierung kann die Unstimmigkeiten bei gemeinschaftlicher Nutzung und Zusammenarbeit vermindern, da es gemeinsame Instrumente, gebräuchliche Datenformate und automatische Interoperabilität gibt. Diese Basisarchitektur sollte flexibel genug sein, es den Maintainern dieser Datensätze zu überlassen, nach ihrem Ermessen Profile zu erstellen und zu warten. Die standardisierten Tools sollten die Leute nicht in kontraproduktive Muster zwingen. Dieses Projekt untersucht Datensätze von Exodus/ETIP, IzzySoft, MobilSicher, F-Droid und TechLore Plexus. Jedes hat eigene und spezifische Werkzeuge und Arbeitsabläufe. Aber der grobe Rahmen der Daten stimmt mit einem gemeinsamen, projektübergeifenden Muster überein.

Es gibt einen guten Präzedenzfall für diese Art der Standardisierung: YARA. Es ist ein Tool für Malware-Signaturen, das von einem Unternehmen begonnen wurde und nun von Dutzenden genutzt wird. Dieser Aspekt von YARA gilt direkt für die Sammlungen der hier diskutierten Signaturen von öffentlichem Interesse. Sobald ein Standard alltäglich wird, verstärkt er nicht zuletzt die Allgemeingültigkeit der Daten, wodurch sie einfacher zu verwenden sind. Dies kann dann weitere Anwender und Mitwirkende anziehen. YARA wurde rund um Desktop-Malware entwickelt und funktioniert unglücklicherweise in Android schlecht. Teilweise liegt das daran, dass sie YARA zu einem eigenen Format machten, dass im YARA-Tool eingebettet ist. Dieses Setup macht YARA-Regeln einfach und lesbar, hat aber große Nachteile. YARA ist in Python implementiert, somit bedeutet seine Nutzung in anderen Sprachen eine grundlegende Neu-Implementierung. Android APKs sind immer eine ZIP, im Gegensatz zu Binärdateien für Desktop-Software, welche im Allgemeinen unkomprimierte Dateien sind. Die Entwickler des YARA-Tools entschieden, dass sie keinen Code aufnehmen wollen, um Scans für ZIP, XML usw. auszuführen. So bleibt die Nutzung von YARA als Android-Scanner holprig.

Wie sehen geteilte Signaturen und Profile aus?

Um zu zeigen, wie dies in der Praxis aussieht, können wir ein Beispiel aus fdroid scanner weiter oben heranziehen. Die Signatur flurryagent im momentanen Scanner wird verwendet, um die Deklarationen von Abhängigkeiten in Gradle-Dateien zu durchsuchen, welche die Standardkonfiguration zur Erstellung von Android-Apps und Dateien in einer Standard-JAR-Bibliothek sind. Die Gradle-Koordinate com.fasterxml.jackson.core:jackson-core:2.11.1 würde nicht markiert werden aber dieses Modell würde auch die Gradle-Zeile com.flurry.android:analytics:10.0.0@aar übergehen. Ist aber ein JAR in der App eingeschleust, würde es erfasst und com/flurry/android/FlurryAgent in diesem JAR würde eine Übereinstimmung produzieren. Aber es gibt lediglich Dateien mit Treffern ohne Kontext zum was oder warum aus. Als Teil von SUSS erhält jeder Eintrag nun ein voll ausgestattetes Profil in einer eigenen YAML-Datei, in dem jede Scan-Signatur explizit erklärt wird. Diese Metadaten können dann mehr Kontext liefern, wenn es Treffer gibt.

name: Flurry
website: http://www.flurry.com
code_signatures:
  - com.flurry.
network_signatures:
  - flurry\.com
api_key_ids:
  - flurry\.com
  - com\.flurry\.admob\.MY_AD_UNIT_ID
gradle_signatures:
  - com\.flurry\.android
license: NonFree
anti_features:
  - Ads
  - NonFree
  - Tracking

In SUSS können wir nun die fdroid scanner-Signaturen mit der Flexibilität von Exodus Privacy darstellen. Dies ergänzt zusätzliche Scans, einschließlich nach Domain-Namen und den zur Deklaration von API Keys verwendeten Namen. fdroid scanner besaß eine zusätzliche Liste mit zulässigen Signaturen, für den Fall, dass eine falsch positiv gewertet wurde. Die Zugelassenen-Liste wurde zugunsten reiner regulärer Ausdrücke (Regex) entfernt. Die Zugelassenen-Liste macht die Implementierung von F-Droid einfach ein Bisschen komplizierter und fesselt unsere Signatur-Profile an die fdroidserver-Tools. Andere Datensätze, die wir irgendwie betrachteten, verwendeten einfach schlichte Einträge, meistens mittels regulärer Ausdrücke, somit ist es wichtig, herauszufinden, ob das alle für den Scan erforderlichen Fälle abdecken kann. Wenn es gut läuft, dann ist der Weg zur Standardisierung klar. Ja, Regex sind kompliziert und können mühsam sein aber sie sind auch weitreichend genutzt, eingebunden, dokumentiert und verstanden.

Ein großer Vorteil von ausschließlich regulären Ausdrücken führt dazu, dass SUSS eine superschnelle, einfache Testsuite besitzt. Hier ein Weg um mit ihr zu arbeiten:

  • Die Gradle-Koordinaten, die relevant sind, finden und den Listen mit Übereinstimmungen und Ausnahmen in tests/test_suss.py hinzufügen
  • Die Tests einmal pro Sekunde laufen lassen (in Farbe!):
    watch --color -n1 pytest-3 --color=yes
  • Die Regex bearbeiten, beispielsweise in suss/com.mapbox.yml

Da nur Regex verwendet wird, braucht diese Testsuite keinen fdroidserver-Code. Genauso trivial würde es in Javascript, Ruby, Rust, Java, Kotlin, etc. verwendet werden, solange die Profile YAML und die Signaturen Regex sind.

Anwendung von Signaturen

Der issuebot, der auf fdroid/rfp und fdroiddata läuft, verwendet nun Signaturen aus Exodus Privacy ETIP, fdroid scanner und Plexus. Es ist jetzt einfach, ETIP-Signaturen in Modulen des issuebot zu nutzen, um experimentieren zu können, wie die Dinge durchsucht werden sollten. Hier einige Ausschnitte mit markierten Sachen aus issuebot, die auf diesen Signaturen beruhen.

gradle-dependencies-1
Dies ist eindeutig eine proprietäre Abhängigkeit, sie wird für alle Builds dieser App benötigt.

gradle-dependencies
Dies ist ein Doppelschlag: proprietäre Bibliothek, die für das Tracking genutzt wird!

source-scan-0
Es ist ein Treffer, aber ist das „Test“-Flavor relevant?

source-scan-1
Es gibt eine passende Übereinstimmung, aber die Bibliothek ist ins „Play“-Flavor eingeschlossen und diese Variante ist offenkundig nicht für f-droid.org bestimmt.

Der issuebot-Bericht hat viele Abschnitte, die auf dem Scan beruhen, der durchgeführt wurde. Wenn ein Bereich irgendwelche Einträge hat, die gekennzeichnet sind, dann wird dieser Abschnitt standardmäßig geöffnet werden. So werden diese Abschnitte beim ersten Lesen leicht augenscheinlich, können aber immer nach der Überprüfung ausgeblendet werden.

Es gibt nun aktive Methoden, um Domain-Namen und URLs in binären APKs herauszufinden. Die Netzwerk-Signaturen werden benutzt, um diese auf Übereinstimmungen zu prüfen. Es bestehen außerdem alternative Methoden, die Daten herauszukratzen und sie danach der Prüfung nach Signaturübereinstimmungen zu unterziehen. Es gibt ein neues Modul für Gradle Dependencies, das die komplette Liste der Abhängigkeiten aus jeder gradle/verification-metadata.xml, falls vorhanden oder erzeugbar, oder aus ./gradlew androidDependencies bezieht, falls alles andere fehlschlägt. Es wendet dann die Code-Signaturen an, um die Gradle-Koordinaten zu markieren. Es sind jetzt multiple, sich überlappende Verfahren vorhanden, die verwendeten Bibliotheken sowohl im Quellcode als auch in den binären APKs herauszufinden. Diese können, wenn wir sie bestimmen können, in eine einzige Methode zusammengeführt werden, die verlässlich alle Abhängigkeiten findet.

Zukünftige Arbeiten

Dieses Projekt hat bedeutende Verbesserungen bei dem bestehenden issuebot-Setup zum Ergebnis und die Grundlagen für eine projektübergreifende Integration geschaffen. Wir erhoffen uns ein Daten-Layout und einen Workflow, der als Vorlage für weitere verwandte Arbeiten dienen kann. Es ist nun an den Start gegangen und in Aktion, wir freuen uns über Rückmeldungen, was funktioniert und was nicht. Und Beiträge zur Verbesserung jedes Teils davon werden immer begrüßt. F-Droid-SUSS ist momentan ein wirklich einfacher Weg, um damit anzufangen, jeder, der einfaches YAML bearbeiten und einen Merge Request einreichen kann, kann jetzt F-Droid helfen, unseren Inspektionsprozess zu verbessern. Hier einige tief hängende Früchte, die bei diesem Projekt übrig geblieben sind:

  • Ein Nachteil bei der Verwendung mehrerer Signatur-Sammlungen ist, dass es schwieriger wird, herauszufinden, wo die Profile zu bearbeiten und zu verwalten sind. Ein gut gestaltetes benutzerfreundliches Design kann hier eine Menge helfen. Zum Beispiel, wenn es einen Treffer gibt, kann die Benutzeroberfläche einen direkten Link zur Bearbeitung des Profils präsentieren, damit es für Maintainer von fdroiddata einfach ist, die Feinabstimmung der Profile vorzunehmen, selbst wenn sie in Exodus Privacy oder anderswo gewartet werden.

  • Wir haben die Umwandlung der Daten von MobilSicher und IzzySoft ins SUSS-Format aufgebaut. Wenn SUSS sich als Format durchgesetzt hat, können wir jene Datensätze leicht in dieses Format übertragen.

  • Einige der issuebot-Berichte können immer noch ziemlich lang sein. Berichte der Module von @IzzySoft sind ein gutes Beispiel dafür, wie man das handhabt: gekennzeichnete Dinge direkt anzeigen, der Rest wandert dann in einen verlinkten Bericht, der in den Prüfgegenständen abgelegt ist und nur auf Anfrage geladen wird.

(Diese Arbeiten wurden von NLnet im Rahmen eines fortlaufenden Projekts namens Tracking the Trackers und The Search for Ethical Apps unter der Schirmherrschaft von Guardian Project gefördert)