Hast du dich schon einmal mit einem Kollegen oder einer Kollegin über ein bestimmtes Thema unterhalten und nur wenige Minuten später hast du auf Instagram genau dafür Werbung erhalten? Sicherlich ist das für viele ein beunruhigender Gedanke und unweigerlich stellt sich die Frage, ob das soziale Netzwerk von Meta seine User aushorcht.

Adam Mosseri, seit 2018 Geschäftsführer von Instagram, hat diesen Mythos kürzlich in einem Video auf seinem eigenen Account angesprochen. Schon seine Frau habe ihm gegenüber das Thema mehr als einmal erwähnt. Doch er beteuert: «Ich schwöre: Wir hören euer Mikrofon nicht ab.»

Diese Mechanismen nutzt Instagram laut Mosseri

«Erstens wäre das eine eklatante Verletzung der Privatsphäre. Es würde den Akku eures Handys leersaugen, und ihr würdet es bemerken. Und ihr würdet tatsächlich oben am Bildschirmrand ein kleines Licht sehen, das anzeigt, dass das Mikrofon an ist», sagt er.

Mosseri erklärt, dass Instagram andere Mechanismen nutze. Zum Beispiel sei es gut möglich, dass der User noch vor dem Gespräch etwas angetippt oder nach einem bestimmten Produkt gesucht hatte. «Wir arbeiten tatsächlich mit Werbetreibenden zusammen, die uns Informationen darüber geben, wer ihre Website besucht hat, um diese Personen mit Anzeigen anzusprechen», so Mosseri.

Die Wahrheit hinter der Fassade: Vier Wege der Überprüfung

Aber sagte Mosseri auch wirklich die Wahrheit? Es gibt vier Möglichkeiten herauszufinden, ob Social Media Apps wie Instagram, Facebook oder die von Google uns regelmässig abhören oder gar zeitweise unsere Kameras benutzen, um die Umgebung aufzunehmen.

1. Das Geständnis der Firmen: Diese Option ist, bis auf die Möglichkeit, dass sie durch einen Whistleblower selbst auffliegen würden, wahrscheinlich weitgehend ausgeschlossen.
2. Reverse Engineering der Apps: Diese Option ist sehr schwierig. Man müsste einerseits ein Experte darin sein und die entsprechenden Tools einsetzen. Viele dieser Firmen wissen zudem von diesem Risiko und setzen in ihren Apps entsprechende Abwehrmassnahmen wie Code Obfuscation, Anti-Hooking-Mechanismen oder weitere Anti-Reverse-Engineering-Mechanismen ein.
3. Hardware-Abstraktion: Dabei würde man gegenüber den Apps eine Zwischenschicht präsentieren, die sich als die Hardware Mikrofon oder Kamera ausgibt und sich zwischen die App und die eigentliche Hardware setzt. Jeder Zugriff auf die Kamera oder auf das Mikrofon durch die ausgewählten Apps könnte protokolliert und die Inhalte mit den tatsächlichen Aktivitäten der Benutzer abgeglichen werden. Doch so etwas ist sehr schwer zu implementieren und benötigt neben herausragenden Programmierkenntnissen auch Hardware-Architekturkenntnisse sowie Wissen über das jeweilige Betriebssystem des Natels.
4. Ein PoC im Sinne eines Man-in-the-Middles: Dabei wird die Kommunikation zwischen Apps und dem Internet abgehört und jeglicher Datenverkehr in einer entschlüsselten Art und Weise protokolliert.

Da dabei sehr grosse Datenmengen entstehen können und man den genauen Zeitpunkt einer Konversation mit darauffolgendem unerlaubtem Versand von heimlich aufgenommenen Daten untersuchen will, muss man ein Szenario mit mehreren Geräten mit gleichen Accounts durchführen.

Mein Versuchsaufbau: Der technische Deep Dive

Ich kenne leider keinen Whistleblower, der in einer der infrage kommenden Firmen arbeitet. Auch habe ich zu Punkt 2 oder Punkt 3 leider zu wenig tiefgehende technische Kenntnisse. Aber zu Punkt 4 traue ich mir auf jeden Fall zu, eine technische Umgebung aufzubauen und ein Szenario abzuspielen, worin ich eine verbale Konversation simuliere und dabei die Daten protokolliere.

Dabei ist es wichtig zu berücksichtigen, dass wenn Instagram uns tatsächlich abhören und aus unseren Konversationen Schlüsselwörter extrahieren und diese uns als Werbung schalten sollte, dies wahrscheinlich randomized ist. Das bedeutet, um möglichst nicht erwischt zu werden, ist der Zeitpunkt des Versands zufällig oder in die nächste reguläre Aktivität eines Benutzers eingebettet. Dabei würde es ja bereits reichen, dass die lokale App selbst solche Auswertungen vornimmt, die Schlüsselbegriffe sammelt und bei der nächsten Nutzung der App diese Begriffe mit auf die Server schleust, wo sie dann als Customized Advertisement beim Scrollen zurückkommen.

Ich habe mich also auf den Weg gemacht und mir eine Umgebung gebaut. Da ich finanziell nicht viel Geld für die Sache ausgeben wollte, habe ich mir in meiner virtuellen Virtualbox-Umgebung ein paar Debian-Server installiert. Ziel war es, für die Man-in-the-Middle-Protokollierung eine TLS Inspection zu realisieren. Hierfür habe ich auf einem Debian 12.6 Linux-Server SQUID mit den BUMP-Funktionen installiert.

Squid ist ein beliebter Open-Source-Proxy-Cache, der neben seiner hohen Effizienz unzählige Konfigurations- und Integrationsmöglichkeiten bietet. Die BUMP-Erweiterung von Squid ermöglicht es dem Proxy-Server, eben solche TLS-Verbindungen aufzubrechen, sofern die entsprechenden Server- und CA-Zertifikate vorhanden sind. Dabei wird einem anfragenden Client, das kann ein Desktop sein, ein Natel oder ein Computer, ein Server-Zertifikat vorgegaukelt. Dieses ist zwar nicht das eigentliche Zertifikat des Webservers, das der Server selbst ausgeliefert hat, sondern eines, das eigens für diese Sache erstellt wurde. Damit aber der Client das Zertifikat auch akzeptiert, muss vorher das entsprechende Zertifikat der ausstellenden Autorität (Root CA) dem Client bekannt gemacht werden, gegen das der Client das Zertifikat des Servers prüfen kann. Im normalen Gebrauch des Internets passiert dieser Vorgang jedes Mal. Der Benutzer merkt nichts davon, da sein Client alle wichtigen Zertifizierungsstellen (Certification Authorities) kennt.

Die Hürde: Das Rooting und Instagrams Gegenmassnahmen

In meinem Beispiel jedoch würde Instagram sofort merken, dass das vorgegaukelte Zertifikat nicht von Instagram beziehungsweise Facebook selbst stammt, und würde die Verbindung sowie den Datenaustausch verweigern. Damit dies nicht passiert, muss ich ein wenig in die Trickkiste greifen. Da ich den ganzen Versuch auf Basis von Linux und Android durchführen wollte, muss ich für diesen Teil des PoC ein Android-Phone rooten.

Beim Rooten erhalten Sie die höchstmöglichen Zugriffsrechte über Ihr Android-Gerät, die ansonsten gesperrt sind. Diese Rechte können Sie selbst anwenden oder auf Apps übertragen, die diese benötigen. Dies eröffnet Ihnen einige Möglichkeiten, unter anderem:

• Android personalisieren: Durch das Rooten können Sie das Design Ihres Smartphones bis auf das Äusserste selbst anpassen.
• Custom ROMs: Falls Ihnen das installierte Android nicht gefällt, können Sie eine ganz eigene Custom ROM auf das Smartphone spielen. Im Idealfall hauchen Sie einem alten Gerät so wieder neues Leben ein.
• Vorinstallierte Apps entfernen: In einigen Fällen unterbindet der Hersteller das Löschen von installierten Apps. Mit Root-Rechten können Sie diese sinnlosen Applikationen loswerden.
• Bessere Backups: Dank Root erstellen Sie vollständige Systembackups. Auch App-Daten und Einstellungen lassen sich problemlos sichern und wiederherstellen.
• Effektive Werbeblocker: Werbeblocker wie AdAway entfernen unerwünschte Werbung aus den meisten Apps und von Webseiten. Zwar gibt es auch Werbeblocker ohne Root-Zwang, diese müssen dann aber als lokales VPN eingerichtet werden und arbeiten etwa nicht mit richtigen VPN-Diensten zusammen.

Ein gerootetes Phone würde mir hier ebenfalls die Möglichkeit bieten, ein eigens gestricktes Zertifikat auf das Handy zu bringen, damit Instagram denkt, das Serverzertifikat, das ich ihm vorgaukle, sei das von seinem Gegenüber. Dies würde mir das Mitschneiden erst ermöglichen. Aber Instagram ist leider nicht so dumm. Tatsächlich hat Facebook in der Instagram-App seine eigenen Root-CA-Zertifikate eingerichtet und vertraut nicht unbedingt auf die Zertifikate, die auf dem Android-Betriebssystem von Haus aus mitgeliefert werden. Das ist eine zusätzliche Hürde, die Instagram-Entwickler in die App eingebaut haben.

Der Frida-Server als Workaround

Frida ist ein dynamisches Instrumentarium für Entwickler, Reverse-Engineer und Sicherheitsforscher. Mit einem Frida-Server auf einem Phone kann man seine eigenen Skripte in Black-Box-Prozesse einfügen. Man kann beliebige Funktionen einhaken, Krypto-APIs ausspionieren oder privaten Anwendungscode verfolgen, und das ganz ohne Quellcode. Der Frida-Server wird an dieser Stelle dafür benötigt, um einer vorhandenen Instagram-Installation das geeignete falsche Stammzertifikat zu injizieren. Dafür benötigt man eben ein gerootetes Android-Natel oder ein gejailbreaktes iPhone.

Rückschlag auf der Serverseite

Der Squid-Caching-Server ist zwar in solch einer Konstellation in der Lage, die TLS-Verbindungen aufzubrechen, aber es gibt für Squid keine Möglichkeit, die laufende Kommunikation, also die tatsächlichen TCP/IP-Streams, mitzulesen. Auch mit veränderten Loglevels und grosszügigen Konfigurationen bietet Squid keine Möglichkeit, in das reinzuschauen, was es selbst zwar sieht, mir aber nicht zeigen kann.

Kenner unter euch werden vielleicht denken, weshalb ich nicht einfach Werkzeuge wie TCPDUMP dafür genutzt habe. Doch TCPDUMP schneidet den Verkehr direkt auf einem Netzwerk-Interface mit, während Squid die Daten in sich mit dem falschen Zertifikat entschlüsselt und auf der anderen Seite mit dem richtigen Zertifikat wieder verschlüsselt. Denn der eigentliche Server soll ja auch nichts davon mitbekommen, dass hier auf dem Proxy eine ständige Umschlüsselung stattfindet. Squid bedient beide Seiten, ohne dass diese davon mitbekommen, dass sie gar nicht miteinander reden.

Doch es gibt eine Möglichkeit, diese Daten, die in Squid ja eigentlich im Klartext vorhanden sind, umzuleiten: zu einem sogenannten ICAP-Server. Das Internet Content Adaptation Protocol (ICAP) ist ein Kommunikationsprotokoll zur einfachen Weiterleitung von Inhalten für HTTP-, HTTPS- und FTP-basierte Dienste. Allgemein ist ICAP ein schlankes Protokoll, um einen «Remote Procedure Call» für HTTP(S) und FTP auszuführen. ICAP-Clients können HTTP-Daten an einen ICAP-Server weitergeben, der seinerseits die Inhalte umformt oder bearbeitet. Der Server sendet die Daten nach der Bearbeitung zurück an den Client.

Squid kann einen ICAP-Server ansprechen und die TCP-Daten auf einen ICAP-Server umleiten beziehungsweise replizieren. Das würde mir ermöglichen, in die Kommunikation hineinzuschauen und die Daten im Klartext zu lesen. Hierfür habe ich einen zweiten virtuellen Server aufgebaut und ICAP-Daten gesammelt. Auf der ICAP-Serverseite kommen die Daten im Klartext an, so dass ich nun mithilfe von TCPDUMP die Daten sammeln und diese dann später bequem in Wireshark auswerten kann. Doch das sollte sich im Nachgang als ein Irrtum herausstellen. Weder die gesammelten Daten auf der ICAP-Seite noch der direkte Mitschnitt durch Wireshark auf dem Netz-Interface des ICAP-Servers konnten dazu führen, dass Wireshark die fragmentierten Pakete wieder zusammenstellen und eine Zeitreihe nachbilden konnte. Die Pakete waren praktisch bis auf wenige unbrauchbar, weil das Format, mit dem die Daten auf dem ICAP-Server ankamen, nicht kompatibel mit Wireshark war.

Letzter Versuch: ClamAV

Einen Versuch hatte ich noch: einen CLAMAV-Server, an den ICAP die Daten weiterleitet. ClamAV auf einem Linux-Server ist eine Open-Source-Antiviren-Engine, die Malware, Viren und Trojaner aus Dateien, E-Mails und Webinhalten erkennt. ClamAV kann mit ICAP umgehen, und man kann ICAP-Streams sogar in der Konfiguration des ClamAV-Servers einbinden. Ziel war es nämlich zu hoffen, dass durch die weitere Umleitung der Instagram-Daten auf einen ClamAV-Server ich ein Dump-Format der TCP/IP-Daten bekommen könnte, die ich speichern und auslesen könnte oder gar direkt auf dem ClamAV-Server an der Netzwerkschnittstelle durch Wireshark in Echtzeit beobachten könnte. Leider entpuppte sich auch dieses Experiment als Irrtum.

Wechsel zu MITMPROXY

Ich gab meine Konfiguration des Man-in-the-Middle für Instagram und Co. soweit auf, obwohl ich TLS-Verbindungen einfacher Apps bereits aufbrechen konnte, da ich auf dem Android-Gerät mein Stammzertifikat auch ohne das Rooten installieren konnte. Nur eben die Instagram-App akzeptierte dieses nicht beziehungsweise ignorierte es einfach, da sie ihr eigenes Zertifikat nutzte.

Also nutzte ich doch eine Software, die sehr einfach zu installieren ist und ihre eigene GUI auf Web-Basis mitbringt: MITMPROXY von mitmproxy.org. MITMPROXY ist, wie der Name schon selbst sagt, ein Proxyserver, der es ermöglicht, ebenfalls Man-in-the-Middle-Angriffe zu realisieren. Es ist ein Schweizer Taschenmesser für Debugging, Tests, Datenschutzmessungen und Penetrationstests. Es kann zum Abfangen, Überprüfen, Ändern und Wiedergeben von Webdatenverkehr wie HTTP/1, HTTP/2, HTTP/3, WebSockets oder anderen SSL/TLS-geschützten Protokollen verwendet werden. Gemäss der Erschaffer von MITMPROXY kann die Lösung eine Vielzahl von Nachrichtentypen, von HTML bis Protobuf, verschönern und dekodieren, bestimmte Nachrichten spontan abfangen und diese ändern, bevor sie ihr Ziel erreichen. Das klingt vielversprechend. Also gut, dann machen wir das eben so unkompliziert.

Das Produkt kannte ich noch von früheren Einsätzen und hatte es auch ein paar Mal eingesetzt, aber in diesem Versuch wollte ich sichergehen, dass ich die Daten wirklich so bekomme, wie sie entschlüsselt werden, ohne dass dies durch ein Programm geschieht, das für solche Zwecke geschaffen wurde. Als ich aber mit meiner eigenen PoC-Umgebung gescheitert war, wechselte ich zurück zu einem Produkt, das diese Art von Arbeit ebenfalls bewältigen kann. Es gibt noch weitere Möglichkeiten und Tools, mit denen man eine solche Untersuchung durchführen kann. Eine sehr bekannte Lösung ist dabei die BurpSuite, welche beliebt unter Pentestern und Hackern ist.

Die Hardware-Falle

Nachdem ich also MITMPROXY eingerichtet und getestet hatte, was nur fünf Minuten dauerte, kam ich zur eigentlichen Arbeit im ganzen PoC: Das Rooten meines Natels beziehungsweise Smartphones. Zu dieser Zeit hatte ich ein Test-Smartphone der Marke XIAOMI Mi 11 Lite 5G. Ich habe mir die Zähne an diesem Natel ausgebissen und habe unzählige Stunden verbracht, um in den Bootloader zu kommen, um das Natel später mit MAGISK zu rooten, welches das Native Image des Herstellers manipuliert, um den Root-Zugriff freizuschalten. Ich bin fast schon durchgedreht, als ich mich dann entschied, mein zu dieser Zeit neueres Natel zu rooten: ein Xiaomi Redmi Note 13 Pro 5G. Aber auch daran scheiterten jegliche Versuche. Diese Natels liessen sich zumindest durch mich nicht rooten.

Einfacher wäre es gewesen, wenn ich ein Google Pixel 4 oder ein Samsung der A-Serie gehabt hätte. Dabei habe ich gelesen, dass es auch bei Samsung inzwischen sehr schwierig sei, die Natels zu rooten. Jetzt auf Tutti.ch oder auf Ebay.com nach einem gebrauchten Natel suchen und mindestens 150 Stutz ausgeben? Ja klar, ich wollte unbedingt wissen, was nun daran ist an den Behauptungen, Instagram und Google würden uns ausspionieren. Und wer sagt denn, dass es am Ende nicht Google ist, das die Keywords ermittelt und an sich selbst vermittelt, um über Google Ads in Instagram Werbung anzeigen zu lassen? Moment mal, geht das? Sind das nicht zwei Konkurrenten? Inzwischen muss man heute alles annehmen, denn beide Gesellschaften profitieren tatsächlich davon, indem sie auf Cross-Plattformen Werbung schalten.

Das geplante Szenario

Mein Versuchsaufbau sah zwei Smartphones, zwei Räume, den gleichen Benutzer und einen Stimmenrecorder vor, der im Loop immer die gleichen Begriffe wiederholt. Der Versuch sah in der Ausführung vor, dass ich auf dem gerooteten Natel mithilfe vom Frida-Server Instagram soweit gebracht hätte, dem gefälschten Zertifikat zu vertrauen. Das war zuvor ebenso möglich und es gibt im Internet diverse Demonstrationen, dass Frida es schafft, Root-CAs zu injizieren.

Nachdem ich also sichergestellt hätte, dass dieses spezielle Natel über den MITMPROXY-Server mit den Instagram-Servern kommunizieren würde, würde ich dieses Natel nun in ungenutztem Zustand in einen Raum stellen und unmittelbar in dessen Nähe einen Stimmrecorder platzieren, der durch meine Stimme aufgenommene, vorher selektierte Sätze mit potenziellen Schlüsselbegriffen in einer Endlosschleife ausgeben würde. Dies würde sicherstellen, dass der Zeitpunkt auf jeden Fall erwischt werden würde, in dem die App gegebenenfalls Stimmen aufnehmen würde.

In einem anderen, geräuschmässig von diesem Raum abgeriegelten Raum würde ich ein weiteres Natel nutzen, das ich nur für diese Zwecke ungerootet, mit der gleichen Instagram-App in der gleichen Version still nutzen und einfach scrollen würde. Ziel wäre es, so lange in Instagram zu scrollen und aktiv zu sein, bis eine Werbung zu sehen ist, die genau auf ein Schlüsselwort aus der Aufnahme hindeuten würde. Hierzu hatte ich bereits eine Liste von Begriffen gemacht, für die es potenziell viele Werbungen geben würde, für die ich mich jedoch nie interessieren würde und deren Schlüsselbegriffe weder mit meinem Berufsleben noch mit meinem Privatleben etwas zu tun hätten. Es war also fern von der Wahrscheinlichkeit, dass durch das reguläre Profiling von Instagram diese Werbungen eingeblendet werden würden.

Ab diesem Zeitpunkt hätte ich die Aufzeichnung der Netzwerkprotokolle gestoppt und die Inhalte fein säuberlich dekodiert, analysiert und untersucht, bis ich diesen kleinen Hinweis gefunden hätte, mit dem ich Instagram endlich an den Ostereiern hätte.

Was ist daraus geworden?

Was ist daraus geworden? Habe ich nun etwas entdeckt? Ich muss euch enttäuschen. Ich habe das Experiment abgebrochen. Nicht nur, dass ich mir kein gerootetes oder rootbares Natel gekauft habe, kurz nachdem ich diesen Versuch gestartet hatte, kamen in meinem Leben viele Dinge und Prioritäten dazu, die mich gezwungen haben, dieses Vorhaben zu unterpriorisieren. Irgendwann habe ich dann auch das Interesse verloren, da ich kein Instagram oder dergleichen mehr nutze.

Mich würde es aber sehr stark interessieren, ob jemand von euch das Interesse hätte, solch ein Experiment zu starten. Lasst es mich bitte in den Kommentaren wissen. Ich stehe euch mit Rat und Tat zur Verfügung und bin natürlich auch gespannt, wie ihr solch eine PoC-Herausforderung angehen würdet.

Der Mensch lernt ja bekanntlich nie aus. In diesem Sinne 🙂