Datensparsames Android mit der Android Debug Bridge - Teil 2: Berechtigungen und Sensoren

Im ersten Teil (1) dieser Artikelserie wurden Wege aufgezeigt, die Übertragung von Nutzerdaten an Google und den Gerätehersteller Samsung für ein Android Stock-ROM einzuschränken. Als Nachtrag zum ersten Teil hier ein Hinweis auf den inzwischen auf dieser Plattform erschienenen Artikel „Google-Apps und weitere Bloatware loswerden mit dem ‚Universal Android Debloater Next Generation‘“ (2), sowie auf die in den Kommentaren zum ersten Teil genannten Tools. Das Entfernen von Bloatware, das ich über die ADB-Befehlszeile beschrieben hatte, wird mit diesen Tools vereinfacht und Nutzern zugänglich gemacht, die vor der Befehlszeile zurückschrecken.

In diesem zweiten Teil schauen wir uns nun die Erfassung und Kontrolle von Daten an der Quelle, auf dem Gerät genauer an. Die Android Debug Bridge (ADB) ist auch dabei ein nützliches Werkzeug. Zusätzlich werden die bereits im ersten Teil zur Installation empfohlenen Administrator-Apps „Package Manager“ und „Permission Pilot“ benötigt. Ich habe inzwischen bemerkt, dass auch der „Permission Pilot“ in F-Droid erhältlich ist, wenn dort das Repository „IzzyOnDroid“ aktiviert ist.

Berechtigungsmanagement

Das Berechtigungsmanagement unter Android ist leider ein tiefer, dunkler Sumpf, in dem Daten versickern. Jedes Android kennt nicht nur die Standardberechtigungen, wie Standort, Kamera, Kontakte etc., die in den Einstellungen angezeigt und dort eingeschränkt werden können. Ein Entwickler kann sich für seine Apps, insbesondere für Systemapps, neue Berechtigungen ausdenken und implementieren, die nirgendwo in der regulären Einstellungen-App sichtbar werden. So könnte der hypothetische Entwickler einer App namens „Datenkrake“ dieser eine alternative Standortberechtigung mit dem Namen „com.datenkrake_inc.datenkrake.permission.ALT_LOCATION“ geben, mit der die App auf das GPS zugreifen und Standortdaten nach Hause funken könnte, auch wenn die Standard-Standortberechtigung von Android der App nicht erteilt wurde. Tatsächlich könnte diese App in den Einstellungen so aussehen, als ob ihr überhaupt keine besonderen Berechtigungen erteilt worden wären.
Solche Tricks sind vorwiegend bei vorinstallierten Systemapps anzutreffen, da ausgerechnet Google mit seinen Richtlinien für Apps im Playstore dort solchen Missbrauch einschränkt. Systemapps gehen an dieser Kontrolle vorbei, da sie direkt mit dem Gerät geliefert werden. Die Lieferkette dieser Apps kann sehr undurchsichtig sein. Der Gerätehersteller kann ihre Programmierung bei Dritten in Auftrag gegeben haben, die, um ihre Einnahmen aufzubessern, Tracker für weitere, vierte Parteien einbauen. Andere Systemapps mit erweiterten Berechtigungen kann der Gerätehersteller selbst aufgrund von Deals mit weiteren Internetkonzernen einbauen. Diese Apps können ihre besonderen Berechtigungen weitergeben, z. B. an eine App dieser Konzerne, die der Nutzer erst später aus dem Play Store installiert. Mit diesen Methoden wird das ursprüngliche Berechtigungsmanagement von Android durchlöchert. Selbst Malware wurde bereits in vorinstallierten Systemapps gefunden. Solcher Missbrauch und seine Verbreitung sind in Veröffentlichungen des IMDEA-Instituts, Madrid dokumentiert (3), (4). Aus diesem Institut stammen weitere bedeutende Forschungsarbeiten zum Thema Tracking über alle möglichen Internetanwendungen und Kanäle, deren Studium nur empfohlen werden kann.

Diese Autoren listen derartige, missbräuchliche Berechtigungen auf, nach denen Geräte untersucht werden können. Auf meinem Tablet habe ich ein Beispiel gefunden. Es wurde von Samsung mit der Systemapp „com.netflix.partner.activation“ ausgeliefert, die die Berechtigung „com.netflix.partner.activation.permission.CHANNEL_ID“ erzeugt (Abb. 1). Unter Einstellungen / Apps wird für diese App selbst mit „Alle Berechtigungen“ (auf 3 Punkte klicken) allerdings keine einzige Berechtigung angezeigt. Für den durchschnittlichen Nutzer ist die Berechtigung also unsichtbar. Die App ist unauffällig und sendet selbst keine Daten. Die bekannte Streamingapp von Netflix „com.netflix.mediaclient“ nutzt diese Berechtigung aber, wie in Abb. 1 zu sehen ist und erhält damit die erweiterte Berechtigung einer Systemapp. Mit der Berechtigung können auch die Daten, die darüber gesammelt werden, an die Netflix Streamingapp übergehen.

Abb. 1 Hand in Hand: Die Channel_ID Berechtigung wird von der Netflix-Systemapp an die Netflix-Streamingapp weitergegeben (Permission Pilot). In den Einstellungen ist sie unsichtbar.

Ich kann nur spekulieren, was es mit der Berechtigung „Channel-ID“ auf sich hat. Offensichtlich hat Netflix mit Samsung einen Deal, die Systemapp „partner.activation“ vorinstalliert mitzuliefern. Die Berechtigung könnte harmlos sein, dafür wären aber nicht die erweiterten Berechtigungen einer Systemapp notwendig. Wahrscheinlicher ist daher, dass sie dazu dient, außerhalb der Sandbox, in die jede Nutzerapp aus Sicherheitsgründen eingesperrt ist, Daten zu sammeln oder zu teilen. Netflix könnte damit Daten mit Apps von Partnerunternehmen austauschen oder Daten aus Apps konkurrierender Streamingdienste ausspähen. Der Name der Berechtigung deutet auf solche Szenarien hin. Unter dem Strich verhalten sich die Netflix-Systemapp und ähnliche Apps mit besonderen Systemberechtigungen, die aufgrund undurchsichtiger Deals vorinstalliert werden, nicht anders als Trojaner und Malware.

Um solchen Missbrauch zu unterbinden, ist es zuerst notwendig, derartige Berechtigungen zu erkennen. Der „Package Manager“ zeigt alle Berechtigungen einer App an, also z.B. auch die „Channel-ID“ Berechtigung der Netflix App. Noch mächtiger ist der „Permission Pilot“. Mit ihm kann das ganze System nach Berechtigungen durchsucht werden. Als Stichwörter für die Suche nach Berechtigungen, wie der genannten „Channel_ID“ können die Namen der üblichen, verdächtigen Konzerne verwendet werden: Facebook, Amazon, Spotify, Netflix, MSC bzw. Microsoft, plus Handy- und SoC-Hersteller Samsung, LG, Lenovo, Sony, Qualcomm, Mediatek etc., bei Chinageräten auch QQ, Tencent, Mi bzw. Xiaomi, Huawei, Oppo, HTC etc. plus Telekomfirmen Vodafone, Telecom etc. Nicht überraschen wird, dass neben anderen Internetkonzernen vor allem Meta/Facebook vorinstallierte Apps mit erweiterten Berechtigungen auf Geräten platziert (3). Weiterhin ist zu empfehlen, sein Gerät nach besonders kritische Berechtigungen zu durchsuchen, wie „location“ (Standort), „call_log“ (Anrufliste), „phone_state“ (SIM-Karte auslesen), „camera“, „record_audio“ (Mikrofon), „contacts“ (Adressliste), „sms“, „mms“ (Nachrichten), „sensors“ (Körpersensoren), „calender“, „storage“ (Speicher lesen), „install_packages“ (Apps installieren). Bei den genannten handelt es sich im Prinzip um Standardberechtigungen von Android, die auch in den Einstellungen angezeigt und eingeschränkt werden können. Wie gezeigt, können Entwickler für Systemapps jedoch eigene, vergleichbare Berechtigungen definieren. Mit dem Permission Pilot würden diese gefunden, solange der Name der Berechtigung nicht zu stark von dem der Standardberechtigung abweicht, also z. B. der Begriff „location“ enthalten ist. Werden verdächtige Berechtigungen gefunden, gibt es mehrere Möglichkeiten: Die betreffende App per ADB deinstallieren, der App die Berechtigung entziehen oder die App in einem zusätzlichen Nutzerprofil, dem Arbeitsprofil isolieren. Für Systemapps dritter Parteien wie beim Beispiel Netflix würde ich eine Deinstallation vorziehen, da die Apps entweder nicht benötigt oder weniger verwanzte Versionen aus dem Play Store, aus Aurora, nachinstalliert werden können. In Abb. 2 ist eine Übersicht der Berechtigungen zu sehen, die der Permission Pilot im Hauptnutzerprofil und im Arbeitsprofil meines Samsunggeräts findet. Berechtigungen, die nicht zum Android Standard gehören, sind hier als „Other“ gelistet. Für diese ist der Unterschied zwischen den beiden Profilen enorm: 2122 davon gibt es im Hauptprofil, nur 11 im Arbeitsprofil. Somit zeigt sich ein weiterer Vorteil der Installation übergriffiger oder besonders schützenswerter Apps im Arbeitsprofil oder einem zusätzlichen Nutzerprofil: Sie können dort auf sehr viel weniger obskure Berechtigungen zurückgreifen oder andersherum über diese Berechtigungen in geringerem Umfang ausgespäht werden. Abb. 2 Vergleich der Berechtigungen im Haupt- und Arbeitsprofil (Permission Pilot).

Am Beispiel einer besonders gefährlichen Android-Standardberechtigung wird nun gezeigt, wie Berechtigungen mit der ADB entzogen werden können, auch wenn sie in den Einstellungen unsichtbar sind. Die Berechtigung heißt „android.permission.READ_LOGS“ und ist in den Einstellungen wieder unsichtbar.
Android verfügt über eine Logdatei, in der vom ganzen System Daten eingesammelt werden, darunter auch sensible wie nutzerspezifische IDs, Telefonnummer, Standortdaten (5). Wer diese Datei selbst durchschauen will, kann sie mit dem ADB-Befehl „logcat“ extrahieren. „adb logcat –help“ zeigt die Optionen an. Apps mit „READ_LOGS“ Berechtigung können sich selbst an diesen Logdaten bedienen. Um dies zu unterbinden, kann versucht werden, mit diesem Befehl die Berechtigung zu entziehen:
adb shell pm revoke --user android.permission.READ_LOGS
<n> ist die Nummer des Nutzerprofils, <PACKAGE_NAME> der Name der App, der die Berechtigung entzogen wird (zur ADB-Syntax siehe erster Teil) (1). Dies funktioniert aber nicht immer. Bei Systemapps kann dieser Befehl eine Fehlermeldung zurückgeben, in anderen Fällen funktioniert der Entzug nur bis zum nächsten Neustart des Gerätes. Dann bleibt nur, entsprechende Apps zu deinstallieren oder ihnen per Firewall das Versenden der Daten zu blockieren.

Derselbe Befehl funktioniert auch für andere Berechtigungen. Die Berechtigung ist immer in der Syntax einzugeben, in der sie im Package Manager oder Permission Pilot angezeigt wird. „grant“ anstatt von „revoke“ gibt die Berechtigung zurück. Ob der Entzug von Berechtigungen funktioniert hat, kann im Package Manager oder Permission Pilot kontrolliert werden. Bei der entsprechenden App muss unter Berechtigungen das Häkchen bei der entzogenen Berechtigung entfernt sein. Abb. 3 Die READ_LOGS Berechtigung wurde allen Apps entzogen, für die das möglich ist.

Im ersten Teil dieser Reihe (1) hatten wir gesehen, dass gemäß den Recherchen von Leith et al., 2021 die Systemapp „Software-Update“, die für Systemupdates verantwortlich ist, bei Kontakten zu Samsungservern die ID der Mobilfunkzelle und damit den ungefähren Standort des Gerätes an Samsung überträgt. Für Android ist der Zugriff auf IDs von Mobilfunk-, WLAN- und Bluetoothzellen mit der Standortberechtigung verknüpft, da sich über diese IDs der Gerätestandort bestimmen lässt. Tatsächlich besitzt die App „Software-Update“ die Standardberechtigung „android.permission.ACCESS_COARSE_LOCATION“ zur ungefähren Standortbestimmung. Um die Übertragung des ungefähren Standorts zu verhindern, ist daher naheliegend, der App diese Berechtigung mit dem genannten ADB-Befehl „pm revoke…“ zu nehmen. Dieser Versuch wurde allerdings mit der Fehlermeldung „cannot revoke system fixed permission“ beantwortet. Der Versuch, mit der ADB, ohne Root, Datensparsamkeit zu erreichen stößt hier also an eine Grenze.

Abb. 4 Standortberechtigung der App für System-Updates von Samsung (Package Manager)

Ich kann hier das Thema Berechtigungen insgesamt nur streifen und für die Problematik sensibilisieren. Der Permission Pilot zeigt für mein Samsunggerät ca. 900 Custom-Permissions an, die alleine von Samsung definiert wurden!

Sensoren

Unter Android kann jede App ohne besondere Berechtigungen Sensoren wie den Kompass, Beschleunigungs-, Luftdrucksensoren, Schrittdetektoren und was sonst verbaut ist, auslesen. Nur auf die Sensorchips von Kamera, Mikrofon und GPS ist der Zugriff über Berechtigungen generell beschränkt. Mit den unbeschränkten Sensoren Kompass, Beschleunigungs- und Luftdrucksensor können Apps feststellen, ob das Gerät gerade benutzt wird, in welcher Position es gehalten wird (45° geneigt vor dem Gesicht und schwankend vom Gehen oder horizontal stabil auf einem Tisch liegend), mit welchem Transportmittel es sich in welche Himmelsrichtung auf welcher Höhe über dem Meer bewegt und vieles mehr. Die Erfassung solcher Daten durch Google hat Douglas C. Schmidt bereits 2018 nachgewiesen (6).  Es ist also auch ohne Standortberechtigung eine ungefähre Standortbestimmung möglich, in Verbindung mit weiteren Daten, wie Karten, IP-Adressen, bekannter Heimat- oder Arbeitsadresse des Nutzers. Eine weitere Möglichkeit ist, dass eine App einen Beschleunigungs- oder Luftdrucksensor zur Tonaufzeichnung missbraucht, ohne dafür auf das eigentliche Mikrofon zuzugreifen und damit ohne eine Mikrofonberechtigung haben zu müssen! Dies ist möglich, weil der innere Aufbau dieser Sensoren fast identisch ist.

Abb. 5 Ein Teil der Sensordaten, die Apps ohne besondere Berechtigungen auslesen können.

GrapheneOS hat daher die Möglichkeit eingeführt, jeder App einzeln den Zugriff auf alle Sensoren zu entziehen. Wenig bekannt ist, dass seit Version 10 Android generell einen Schalter hat, um alle Sensoren abzuschalten. Dazu unter „Einstellungen / Entwickleroptionen / Entwicklerkacheln für Schnelleinstellungen“ den Schalter „Sensors Off“ aktivieren. Die Entwickleroptionen hatten wir im ersten Teil bereits für die ADB aktiviert (Build-Nr. siebenmal antippen). In den Schnelleinstellungen erscheint dann der Schalter „Sensors Off“, mit dem alle Sensoren des Gerätes global abgeschaltet werden können. Detailierte Abschaltmöglichkeiten für einzelne Apps gibt es aber nur bei GrapheneOS und anscheinend auch bei DivestOS. Mit „Sensors Off“ sind auch Kamera, automatische Bildschirmdrehung, GPS und das Mikrofon, einschließlich externer Headset-Mikrofone gesperrt, nicht aber der Lautsprecher und die Funkmodule für Bluetooth, WLAN und Mobilfunk. Der „Sensors Off“-Schalter wird daher nicht durchgehend aktiv sein können, kann aber in besonderen Szenarien nützlich sein. Angenommen, eine sehr übergriffige App ist im Arbeitsprofil isoliert und dort bei Nichtnutzung eingefroren. Wenn sie aufgetaut und genutzt wird, können vorsichtshalber Sensoren zeitweise ausgeschaltet werden. Abb. 6 Sensors Off Schalter ist im Schnellstartmenü aktiviert, Status wird in Kopfzeile angezeigt.

Fazit

In diesem zweiten Teil der Artikelserie wird nun die Begrenzung des Ansatzes sichtbar, ein vorinstalliertes Stock-Android ohne Rootrechte datensparsam umzubauen. Ein Stock-Android weist eine unübersichtlich große Anzahl von Custom-Permissions auf, die vom Hersteller oder Appentwicklern definiert werden, für den Nutzer zunächst unsichtbar sind und die zu Daten- und Sicherheitslecks führen können. Zum Teil legen diese Berechtigungen obskure Deals zwischen Geräteherstellern und Internetkonzernen zulasten von Nutzern offen. Selbst wenn kritische Berechtigungen mit den aufgezeigten Methoden aufgespürt werden, können sie ohne Root-/Adminrechte den Systemapps im Allgemeinen nicht entzogen werden. Es bleibt die Option, Apps mit solchen Berechtigungen zu deinstallieren oder zu isolieren. Ähnlich verhält es sich mit dem Zugriff auf nicht durch Berechtigungen eingeschränkte Sensoren. Über diese Sensoren lassen sich Nutzer in beträchtlichem Umfang ausspähen. Zwar lassen sich diese Sensoren bei neueren Android-Versionen über einen versteckten Schalter global abschalten. Damit werden aber auch wesentliche Funktionen des Gerätes, wie das Mikrofon zum Telefonieren abgeschaltet. In beiden Fällen sind also in Bezug auf den Datenschutz nur Kompromisse möglich. Ich würde dennoch empfehlen, bei Gelegenheit Sensoren abzuschalten und mit einer App wie dem Permission Pilot Berechtigungen von Androidgeräten zu durchforsten.

Literatur:

(1) https://gnulinux.ch/datensparsames-android-mit-der-android-debug-bridge-teil1-samsung-phablet
(2) https://gnulinux.ch/google-apps-und-weitere-bloatware-loswerden-mit-dem-universal-android-debloater-next-generation
(3) Gamba et al, IMDEA 2019: https://dspace.networks.imdea.org/bitstream/handle/20.500.12761/684/An_Analysis_of_Pre-installed_Android_Software_2019_EN.pdf
(4)  Gamba et al, IMDEA 2022: https://dspace.networks.imdea.org/bitstream/handle/20.500.12761/1715/Mules_and_Permission_Laundering_in_Android_Dissecting_Custom_Permissions_in_the_Wild.pdf
(5) Lyons et al, IMDEA 2023: https://dspace.networks.imdea.org/bitstream/handle/20.500.12761/1680/sec23fall-prepub-89-lyons.pdf
(6) Schmidt, 2018: https://www.dre.vanderbilt.edu/~schmidt/PDF/google-data-collection.pdf

Dieser Artikel ist Teil einer Artikelserie

Teil 1: Samsung Phablet
Teil 2: Berechtigungen und Sensoren