Internationale Forscher haben eine verdeckte Tracking-Methode aufgedeckt, die von Meta und dem russischen Technologieriesen Yandex verwendet wird und es deren Android-Anwendungen ermöglicht, das Surfverhalten der Nutzer im Web zu überwachen – selbst dann, wenn die Nutzer glauben, privat zu surfen.
Covert Web-to-App Tracking via Localhost on Android](https://localmess.github.io/?utm_source=perplexity)
Iat doch schon wieder aufgehoben. Ertappt und problem behoben ?
„UPDATE : As of June 3rd 7:45 CEST, Meta/Facebook Pixel script is no longer sending any packets or requests to localhost. The code responsible for sending the _fbp cookie has been almost completely removed. Yandex has also stopped the practice we describe below.“
Nö, ich nutze grundsätzlich kein Fratzenbuch, Instagramm und den restlichen Dreck und auch kein Android. 
Das Thema ist aber trotzdem interessant, weil zwar die Ursache angeschaltet wurde, das Problem damit aber imho nicht behoben ist 
Ja ich meinte auch nicht dich. Die wurden ertappt bei ihren Spionageversuchen. Sauerei ist das auf jeden Fall. Wenn das eine nun eingestellt wurde dann kann man ja sicher sein das das nächste schon in der Pipeline ist.
Ja man tut gut daran diese scheiße nicht zu nutzen. Und auf jeden Fall interessant. Hätte ich ohne den Beitrag hier wieder nichts von mitbekommen
Firefox geht mal wieder den schlechtesten Weg und blockiert nur die involvierten Ports, statt das localhost-Problem systematisch anzugehen:
Version 139 will include countermeasures to block the ports involved.
Edit: Siehe auch https://hg-edge.mozilla.org/releases/mozilla-release/rev/e1800ff0651761a8450c01c25b84ff0a4ca1cd98
Hinter der Forschergruppe „localmess“ steckt ein Verbund, an dem federführend das IMDEA-Networks Institut in Madrid unter Prof. Vallina-Rodriguez beteiligt ist. Die vorliegende Analyse ist nicht die erste bahnbrechende Arbeit dieses Instituts. IMDEA ist eines der führenden, wenn nicht das führende Institut weltweit, das sich der Analyse der Trackingindustrie, ihrer Apps, ihrer Endgeräte, ihrer Marktplätze und Lieferketten auf globaler Ebene verschrieben hat. Ich hänge am Ende meines Beitrags ein paar Links an, mit den aus meiner Sicht interessantesten Publikatinen dieses Institus.
Nun zurück zu den Meta und Yandextrackern. Ich fürchte gegen diese Methode hilft nicht einmal die Trennung von Browser und „schmutzigen“ Apps in unterschiedliche Nutzerprofile (Arbeitsprofil, Vertrauliches Profil). Der Entwickler der Insular App, zum Aufsetzen von Arbeitsprofilen, Oasis Feng empfiehlt den localhost ausdrücklich zum Dateiaustausch zwischen Arbeitsprofil und Hauptprofil, wenn alle anderen Kanäle vom jeweiligen Stock-ROM versperrt wurden (z.B. Samsung Knox):
https://github.com/oasisfeng/island/issues/564
Daher sollte auch der Austausch von Cookies darüber funktionieren, wahrscheinlich sogar bei GrapheneOS, sofern sie nicht bereits im Browser (Stichwort Webapps) geblockt werden. Oder gibt es hier andere Meinungen zum Schutz mit getrennten Profilen?
Zwar hat Meta die Methode gestoppt, nachdem sie erwischt wurden. Da die Methode nun veröffentlicht ist, ist allerdings zu befürchten, dass noch skrupellosere Unternehmen sie imitieren. Es kommt daher darauf an, den Datenfluss über den localhost zu überwachen. Ich habe das unter einem Samsung Stock-ROM direkt auf dem Gerät versucht, mit Netzwerk und Firewallapps wie PCAPdroid, RethinkDNS, wohlgemerkt ohne Root und daher über das VPN-Netz, das diese Apps aufspannen und bin gescheitert.
Wenn ich im Termux-Terminal des Androidgeräts einen ping auf google.com starte, wird dieser umgehend im Protokoll unter RethinkDNS sichtbar, samt vom DNS-Server zurückgegebener IP-Adresse. Wenn ich dagegen ping localhost eingebe, erhält dieser im Terminal zwar die erwartete IP-Adresse 127.0.0.1, RethinkDNS oder PCAPdroid zeigen jedoch keinerlei Netzwerkaktiviät an. Auch die Eingabe von localhost oder der IP-Adresse 127.0.0.1 in den Browser verursacht keinerlei Zucken in RethinkDNS, PCAPdroid. Es scheint, dass unter Android der localhost bereits antwortet, bevor die Daten ins VPN weiterlaufen, das RethinkDNS, PCAPdroid überwachen. Hier im Blog wird RethinkDNS an mehreren Stellen als Schutz empfohlen. Worauf basiert diese Empfehlung, bzw. welche Einstellungen sind erforderlich, damit RethinkDNS vor einer Datenweitergabe zwischen zwei Apps über den localhost schützen kann?
Als nächstes habe ich wieder im Termux-Terminal versucht, über den Befehl netstat etwas über den Zustand des localhost herauszufinden. Die Befehlssyntax, die die IMDEA-Forscher verwendet haben, ist hier zu sehen:
Sie benutzen zwar den netstat-Befehl, schränken die Abfrage aber offensichtlich auf die Ports ein, an denen die Yandex und Meta-Apps lauschen, was bei einem modifizierten Angriff eines anderen Akteurs wenig hilfreich wäre, da wahrscheinlich andere Ports benutzt würden. Weiterhin führen sie den Befehl unter root über die ADB aus.
Ich habe mehrere Varianten von netstat ohne root, direkt auf dem Gerät im Terminal ausprobiert, darunter netstat -a -e | grep "LISTEN"; netstat -a -e ; netstat -untap alles ohne irgendwelche nützliche Informationen über den Zustand des localhost zurückzubekommen. Ich habe allerdings keine Meta, Yandex oder ähnliche Apps laufen, hätte dennoch irgendwelche Daten vom localhost zurückerwartet.
Ist Euch ein Setup bekannt, über das sich möglichst ohne Root der Zustand von localhost allgemein auslesen lässt? Hier sind ja Daten aus dem Terminalfenster abgebildet z.B. von strauch_2, jedoch sehe ich nicht den Befehl mit dem sie erzeugt wurden und ob es sich um Daten aus dem localhost handelt.
Zum Schluss noch mal zurück zu IMDEA und eine Auswahl ihrer interessantesten Publikationen. Diese zeichnen sich u.a. durch ihren globalen Ansatz aus, d.h. es wird versucht, z.B. alle App-Stores, Android-Systemapps, die weltweit in Umlauf sind, zu analysieren:
Analyse zum Missbrauch von App-spezifischen Berechtigungen, die außerhalb des AOSP definiert wurden
2023, Mules and Permission Laundering in Android: Dissecting Custom Permissios in the Wild
https://dspace.networks.imdea.org/handle/20.500.12761/1715
Datenlecks über die Android Logdatei
2023, Log: It’s Big, It’s Heavy, It’s Filled with Personal Data! Measuring the Logging of Sensitive Information in the Android Ecosystem
https://dspace.networks.imdea.org/handle/20.500.12761/1680
Preisbildung auf den Markplätzen der globalen Trackingindustrie
2023, Understanding the Price of Data in Commercial Data Marketplaces
https://dspace.networks.imdea.org/handle/20.500.12761/1672
Analyse der Datenströme von Alexa und Co.
2022, Leakage of Sensitive Information to Third-Party Voice Applications
https://dspace.networks.imdea.org/handle/20.500.12761/1599
2021 Don’t Accept Candy from Strangers: An Analysis of Third-Party Mobile SDKs
https://dspace.networks.imdea.org/handle/20.500.12761/1565
Preisgekrönte Arbeit zum Ausspähen von Kindern und Jugendlichen über Apps zur elterlichen Kontrolle
2020, Angel or Devil? A Privacy Study of Mobile Parental Control Apps
https://dspace.networks.imdea.org/handle/20.500.12761/775
Für diese eindrucksvolle Analyse von Systemapps wurden mit Hilfe einer Crawler mehr als 100.000 (!) Systemapps weltweit eingesammelt und sowohl Datensendeverhalten als auch ihr Sourcecode analysiert, anders als bei Trackern mit ausdrücklicher Genehmigung der Systemnutzer (Datenspende):
2020, An Analysis of Pre-installed Android Software
https://dspace.networks.imdea.org/handle/20.500.12761/684
Weitere Arbeit zum Aushebeln des Android Berechtigungssystems
2019, 50 Ways to Leak Your Data: An Exploration of Apps’ Circumvention of the Android Permissions System
https://dspace.networks.imdea.org/handle/20.500.12761/778
Auch exotische Marktplätze wurden untersucht
2019, Tales from the Porn: A Comprehensive Privacy Analysis of the Web Porn Ecosystem
https://dspace.networks.imdea.org/handle/20.500.12761/761
Wer glaubt, dass chinesische Appstores, wie z.B. der von Huawei eine Alternative zu Google Play sind, wir hier eines besseren belehrt:
2018, Beyond Google Play: A Large-Scale Comparative Study ofChinese Android App Markets
https://dspace.networks.imdea.org/handle/20.500.12761/618
Frühe Analyse der globalen Trackingindustrie, Datenströme, Aufdeckung der Firmen zu denen die Daten fließen
2016, Tracking the Trackers: Towards Understanding the MobileAdvertising and Tracking Ecosystem
https://dspace.networks.imdea.org/handle/20.500.12761/311
Die komplette Liste der IMDEA-Publikationen ist hier:
https://networks.imdea.org/research/publications-patents/?termcat=0&years=2025
Du benötigst Shell-Rechte(UID 2000) im Terminal. Also entweder adb per Kabel oder Wlan.
Alternative:
Termux und Shizuku(rish muß zu Termux exportiert und gestartet werden) funktioniert lokal auf dem Gerät, nutzt aber „Debugging über WLan“(Shizuku muß gekoppelt sein und zum Start eine WLan-Verbindung bestehen, rein technisch wird das ein ähnlicher „Trick“ sein.
Gerät(adbd) lauscht auf dem WLan-Interface auf dem entsprechenden Port und Shizuku verbindet sich (aber das funktioniert nur mit Nutzerinteraktion bei erstmaligem Start(!), weil seit etlichen Android-Versionen eine Abfrage des Nutzers erfolgt und nur bei entsperrtem Display.
Aber dort fängt das Android ab, vielleicht in Interaktion mit adbd, aber damit überließe man es der App bzw. dem Binary, was nicht der richtige Weg sein dürfte, auch wenn es funktioniert. iptables bzw. ip6tables wird auch auf Android-Geräten genutzt und könnte das auch blocken und/oder Interaktionen mit Meldung von Quelle und Ziel, bei lokalen auch mit Prozess bzw. eben der App auslösen.
Bewußt habe ich genutzte Regeln von iptables aber bisher nur mal bei einem Huawei-Gerät gesehen, das hatte erweiterte Einstellungen. Sowas schafft allerdings Probleme, wenn man AFWall+ auf einem gerooteten Gerät benutzt, wenn man da oder noch was anderes die Regeln ändert. Ob aktuell auch die Einstellungen für das Verwehren des Mobilfunk-Zugriffes über iptables erfolgt, weiß ich nicht.
Administratives Blocken der „metered data“, auch kostenpflichtiges WLan zählt dazu, erscheint jedenfalls auch nicht mehr im Traffic von NetGuard oder Rethink. Die Apps sind stumm und im Test auch nicht online, daher setze ich hier gezielt alle WLan auf kostenpflichtig.
Bis vor kurzem wurde man bei Shizuku auch nach Kopplung bei jedem Start direkt noch in die Entwickleroptionen geschickt, um das „Debugging über WLan“ wieder einzuschalten, seit letztem Update nicht mehr(dafür mußte man die Aktion mit dem Export der zwei Dateien zu Termux wiederholen), ansich könnte Shizuku(übrigens verfügbar im IzzyOnDroid-Repository oder im Play Store) imho derzeit ohne Interaktion auch ohne root-Rechte starten, wenn es implementiert wäre.
Danke für die Ausführungen zu der Firma, hochinteressant.
An alle: Profilübergreifende App-zu-App-Kommunikation via Netzwerk hat nichts mit dem ursprünglichen Problem in diesem Thread zu tun. Es geht hier einzig um Web-zu-App-Tracking via der vorgestellten Methoden. Bitte Off-topic-Diskussionen einstellen.
Ich denke das hat sehr wohl mit diesem Thema zu tun. Die Frage, die ich aufgeworfen hatte ist, lässt sich Web-zu-App Tracking nach der von Meta & Yandex verwendeten Methode unterdrücken, wenn Browser und spionierende App in zwei unterschiedlichen Nutzerprofilen desselben Androidgerätes sind, also Browser im Haupprofil und Meta-Apps isoliert z.B. im Arbeitsprofil. Dieser Ansatz wird für die Verwendung von trackerverseuchten Apps, wie denen von Meta ja vielfach empfohlen.
Meine Befürchtung ist, dass die Methode dennoch funktioniert, da nach Oasis Feng auf den localhost aus beiden Profilen zugegriffen werden kann. Das wäre eine weitere schlechte Nachricht. Ausprobiert habe ich das aber noch nicht.
@ strauch_2, danke für den Hinweis! Ich werde dann mal versuchen, den localhost über die adb auszulesen.
Dazu wäre es hilfreich, eine Anwendung zu haben (App, Webseite), die dort standardmäßig an einem Port lauscht, wie die Meta-Apps bis vor kurzem. Ist hier jemand eine solche Anwendung bekannt? Laufen z.B. die hier bereits genannten WebDav-Verbindungen über den localhost?
würde Dich gern mal da rüber locken zum antworten →
Nach dem Start der adb mit adb shell zeigt der Befehl netstat -a -e | grep "LISTEN" tatsächlich die Dienste an, die an irgendeinem Port am Lauschen sind. Hier der komplette Dialog:
gta7lite:/ $ netstat -a -e | grep "LISTEN"
tcp6 0 0 Galaxy-Tab-A7-:http-alt [::]:* LISTEN u0_a304 1556005
tcp6 0 0 [::]:6100 [::]:* LISTEN system 45642
Auf meinem Samsung Tablet ist das System an Port 6100 dauerhaft auf Lauschstation. Ich nehme an, das ist normal. Der zweite Dienst Galaxy-Tab-A7-:http-alt ist ein WebDav-Server, den ich testehalber gestartet habe, um sicher zu gehen, dass individuell gestartete Dienste erkannt werden. Wenn ich ihn stoppe, ist diese Zeile weg. Der Befehl funktioniert ohne root-Rechte und die Ports, an denen gelauscht wird, müssen nicht vorab bekannt sein. Ich finde auf meinem Gerät keine unerwarteten Apps auf Lauschstation, vergleichbar den Yandex- und Metaapps, die die Forscher von localmess gefunden hatten 
Da Filterapps wie RethinkDNS Lauschangriffe auf den localhost, wie gezeigt, nicht generell stoppen können, ist eine Abfrage mit netstat wohl die realistischste Option, um solche Angriffe zu erkennen.
Android hat keine per-Profil-isolierten Localhost-Interfaces, deshalb funktioniert das vorgestellte Web-zu-App-Tracking auch profilübergreifend.
Das ist ein klares Loch in der Sandbox.Sonst kann auch keine App die privaten Daten der andren lesen.
Das müsste man eindeutig mit Berechtigungen versehen: Localhost, lokales Netz, Internet und dann wie bei der Kamera ja/nein/temporär als Frage aufploppen lassen.
Sonst sieht das ja keiner und kann nicht entscheiden ob das in Ordnung ist.
Browser sollten nicht Inhalte der 3 Kategorien mischen dürfen.
Danke für die Bewertung des profilübergreifenden Trackings.
Da ich auf meinem eigenen Androidgerät keine lauschenden Apps gefunden habe, habe ich auch die Androidgeräte in meinem sozialen Umfeld mit dem netstat Befehl untersucht. Da sind Geräte mit sehr viel mehr trackerverseuchten Apps dabei („soziale“ Netzwerke, Spiele, Streamingdienste etc.). Auf einem Pixel, das mit CalyxOS läuft, habe ich das hier gefunden:
sunfish:/ $ netstat -a -e | grep "com"
unix 2 [ ACC ] STREAM LISTENING 7281076 @JsEngine_com.zhiliaoapp.musically_devtools_remote
unix 2 [ ACC ] STREAM LISTENING 26370 @com.android.internal.os.WebViewZygoteInit/aba2507a-8e05-4297-85d5-66a4adec6271
unix 2 [ ACC ] STREAM LISTENING 7278938 /data/user/11/com.zhiliaoapp.musically/files/socket_pipe
unix 3 [ ] STREAM CONNECTED 26395 @com.android.internal.os.WebViewZygoteInit/aba2507a-8e05-4297-85d5-66a4adec6271
com.zhiliaoapp.musically ist die hierzulande herausgegebene Version der Tiktok-App, die hier offensichtlich in einer Lauschposition ist. Sie ist auf diesem Handy im Arbeitsprofil (user11) installiert. Die beiden Einträge der Tiktok-App erscheinen nur, wenn sie geöffnet ist. Es gibt weitere Unterschiede zu dem, was die localmess-Forscher für die Meta- und Yandex-Apps herausgefunden haben. Die Tiktok-App verwendet hier nicht das Internetprotokoll tcp6, sondern ein als unix bezeichnetes Protokoll und das Lauschen wird hier nicht als LISTEN sondern als LISTENING aufgeführt. Tiktok ist allerdings die einzige nutzerinstallierte App, die über dieses unix-Protokoll kommuniziert. Ansonsten sind dort nur Systemapps und -dienste sichtbar, wie hier im Beispiel WebView. Meine Kenntnisse an Netzwerkprotokollen sind leider nicht ausreichend, um dieses Ergebnis zu bewerten. Bei Tiktok würde ich aber nicht in dubio pro reo gelten lassen. Ich traue denen nichts Gutes zu.
Kann hier im Forum jemand beurteilen, welche Kanäle dem unix-Protokoll offenstehen, welche Daten darüber fließen könnten und ob es auch zur Umgehung der App- oder sogar Profil-Sandbox verwendet werden kann und in diesem Fall mutmaßlich verwendet wird?
„Endpunkte von bidirektionalen Kommunikationsverbindungen“
https://de.wikipedia.org/wiki/Unix_domain_socket
etwas ausführlicher
https://en.wikipedia.org/wiki/Unix_Domain_Socket
deswegen hatte ich gezielt das ’ | grep "LISTEN "’ angehängt (mit Leerzeichen am Ende)
wobei natürlich dennoch interessant ist, ob damit auch Apps untereinander kommunizieren könnten, ansich sollten die mit den Rechten der anlegenden UID angelegt werden und durch andere UIDs kein Zugriff erfolgen können.
PS: wobei das entsprechend des Konzeptes „alles ist eine Datei“ vielleicht auch den.Dateiberechtigungen unterworfen ist schreiben/lesen/ausführen für Benutzer/Gruppe/Rest der Welt
bitte korrigiert mich, falls es anders ist
Habe mich nun selbst etwas in das Thema Unix Domain Sockets eingelesen. Sie dienen der Kommunikation zwischen Prozessen (IPC - Inter Process Communication), die normalerweise auf demselben System parallel laufen. Theoretisch könnten sie sogar auf unterschiedlichen Systemen laufen, die über ein Netzwerk verbunden sind. Daten werden über ein Socket in eine Pipe/FIFO eingeschoben, der zweite Prozess kann diesen Datenstrom über sein Socket daraus auslesen. Den Sockets kann ein unixartiges Rechtemanagement auferlegt werden. Sie werden unter Unix wie Dateien behandelt. Rechtebeschränkung ist also möglich, es können aber wohl auch Rechte vergeben werden, um einen Datenkanal aus einer App-Sandbox heraus zu legen. Die Datenpipeline ist ähnlich der über das Internetprotokoll TCP/IP und den localhost, nur dass es noch einfacher zu implementieren und effizienter ist, da die Daten nicht erst in Packets zerlegt werden müssen. Der Unterschied zwischen einem Prozess im Status "LISTEN" und "LISTENING" scheint minimal zu sein. Bei Systemen mit deutschem Interface werden beide Zustände als "ABHÖREN" wiedergegeben.
Anwendung finden die Unix Domain Sockets normalerweise für den Datenaustausch zwischen Systemprozessen. Es ist daher sehr verdächtig, wenn eine einzelne, nutzerinstallierte App, wie Tiktok davon Gebrauch macht.
Ein Socket für die beobachtete Pipe von Tiktok befindet sich im Appverzeichnis /data/user/11/com.zhiliaoapp.musically/files/socket_pipe. Das ist zu erwarten, wenn Daten von oder zu der App laufen sollen. Bei dem zweiten Socket JsEngine_com.zhiliaoapp.musically_devtools_remote handelt es sich um ein Java Script Engine, das also Java Code ausführen kann. Das ist die verdächtige Seite der Pipe. Das Setup ist also sehr vergleichbar zu dem der Meta und Yandextracker. Das Java Script Engine könnte Daten von Trackern auf Webseiten oder sonstigen Prozessen einsammeln und über die Pipe an die Tiktok-App weitergeben.
Eine harmlose Interpretation dieses Setups wäre, dass die Pipe eine Debugschnittstelle für die Tiktok-App sein könnte. Immerhin wird die Pipe nur aufgebaut, wenn die App geöffnet ist. Wenn sie zum Auslesen von Webseiten gedacht wäre, wäre es effizienter sie auch im Hintergrund laufen zu lassen.
Ich würde sagen, die Chancen stehen ungefähr 50/50, dass auch Tiktok das Web-zu-App Tracking verwendet. Entschieden werden könnte die Frage vielleicht, wenn sich herausfinden ließe, wo das Java Script Engine läuft, in der App Sandbox oder außerhalb. Kennt jemand einen magischen Befehl, der diese Information preisgibt?
Javascript und Java sind zwei verschieden Dinge
Die Berechtigung zum Zugriff auf Unix Sockets wird über Unix-Gruppen unter Android gesteuert. Du musst also die Unix-Gruppen der installierten Browser mit denen der genannten Sockets vergleichen, sowie die Berechtigungen (Unix und Selinux).
Wobei ich dir gleich sagen kann, dass da kein Zugriff besteht, aber es ist für dich vielleicht trotzdem interessant, die Berechtigungen zu checken. Unix sockets werden normalerweise nur innerhalb einer App verwendet. Appübergreifende Kommunikation findet darüber nur im Legacy-Fall via android:sharedUserId statt, was nur bei Apps des gleichen Hersteller zu erwarten ist und, wenn ich mich recht erinnere, nicht mehr für Apps im Play Store erlaubt ist.
Nach den Daten die du bisher präsentiert hast, ist die Wahrscheinlichkeit wohl eher bei 0