Ergebnisse der Analyse des abgefangenen Netzwerkverkehrs der offiziellen White-House-App

 (atomic.computer)
2 Punkte von GN⁺ 27 일 전 | 1 Kommentare | Auf WhatsApp teilen
  • Der tatsächliche HTTPS-Verkehr der White-House-iOS-App wurde mit einem MITM-Proxy erfasst, um zu analysieren, mit welchen Servern und welchen Daten die App kommuniziert
  • Die App kommuniziert nicht nur mit whitehouse.gov, sondern auch mit 31 Hosts von Drittanbietern wie Elfsight, OneSignal, YouTube, Google DoubleClick, Facebook und Twitter
  • An OneSignal werden fortlaufend Informationen zur Nutzerprofilbildung übermittelt, darunter Sprache, Zeitzone, IP-Adresse, Gerätemodell und Anzahl der Sitzungen
  • Über den Widget-Loader von Elfsight werden externe Skripte ausgeführt, und auch Google-DoubleClick-Code zur Werbeverfolgung läuft innerhalb der App
  • Im Privacy Manifest der App ist zwar „keine Datenerfassung“ angegeben, tatsächlich finden jedoch umfangreiche Drittanbieter-Tracking- und Datenübertragungen statt

Überblick über die Analyse des Netzwerkverkehrs

  • Der Netzwerkverkehr der offiziellen White-House-iOS-App wurde mit einem MITM-(Man-in-the-Middle-)Proxy erfasst und analysiert
    • In einer macOS-Umgebung wurde mitmproxy installiert und der gesamte HTTPS-Verkehr des iPhones über den Proxy aufgezeichnet
    • Die App-Version war v47.0.4 (build 81), und alle Tabs Home, News, Live, Social und Explore wurden durchlaufen
    • Der Verkehr wurde ohne Manipulation entschlüsselt und protokolliert, bei einer Nutzung wie durch einen gewöhnlichen Anwender

Server, mit denen sich die App verbunden hat

  • In einer einzelnen Sitzung sendete die App Anfragen an 31 eindeutige Hosts (ohne iOS-Systemverkehr)
    • Von insgesamt 206 Anfragen gingen nur 48 (23 %) an whitehouse.gov
    • Die übrigen 158 (77 %) wurden an Drittanbieterdienste wie Elfsight, OneSignal, YouTube, Google DoubleClick, Facebook und Twitter gesendet
  • Wichtige Zielsysteme
    • whitehouse.gov: WordPress-API (News, Home, Galerie usw.)
    • YouTube: Video-Einbettungen und Vorschaubilder
    • Elfsight: Laden von Widgets, statische Assets, Dateispeicher, Boot-API usw.
    • OneSignal: Analyse und Nutzerprofilbildung
    • Facebook/Twitter CDN: Laden von Bildern
    • Google APIs und DoubleClick: Werbung und Tracking

An OneSignal übermittelte Daten

  • Beim Start der App wird ein HTTPS-Request-Body an api.onesignal.com gesendet
    • Enthaltene Informationen: Sprache, Zeitzone, Land, IP-Adresse, Zeitpunkt des ersten Starts und der letzten Aktivität, Gerätemodell, OS-Version, Netzwerktyp (WLAN/Mobilfunk), Mobilfunkanbieter, Jailbreak-Status, Anzahl der Sitzungen, Sitzungsdauer, eindeutige Kennung
  • Bei jedem App-Start werden mehrere PATCH-Anfragen gesendet, um das Profil zu aktualisieren
    • Beim ersten Start 18 PATCH-Anfragen, in der gesamten Sitzung wurden 9 OneSignal-Anfragen festgestellt
    • Reihenfolge: vorhandenes Profil per GET abfragen → Sitzungsinformationen per PATCH aktualisieren
  • OneSignal protokolliert fortlaufend sitzungsbezogene IPs, Aktivitätszeiten, Anzahl der Sitzungen und Sitzungsdauer
    • Bei Änderung der IP-Adresse wird das Profil aktualisiert
    • Der Zeitstempel first_active ändert sich nach dem Installationszeitpunkt nicht mehr
  • Damit pflegt OneSignal faktisch ein dauerhaftes Profil pro Nutzer und verfolgt Nutzungsmuster der App sowie die Netzwerkumgebung
  • Der User-Agent des Verkehrs lautet WhiteHouse/81 CFNetwork/3860.400.51 Darwin/25.3.0

Elfsight-bezogener Verkehr

  • Die in der statischen Analyse festgestellten 6 Widgets und der zweistufige JavaScript-Loader wurden auch im tatsächlichen Verkehr bestätigt
  • Beim Öffnen des Social-Tabs verbindet sich die App mit 13 Elfsight-Domains
    • darunter elfsightcdn.com, core.service.elfsight.com, static.elfsight.com, storage.elfsight.com, widget-data.service.elfsight.com, video-proxy.wu.elfsightcompute.com
  • Wird über eine /p/boot/-Anfrage die jeweilige Widget-ID gesendet, liefert der Server eine Liste der auszuführenden Skripte (assets-Array) zurück
    • Beispiel: TikTok → tiktokFeed.js, Instagram → instashow.js, Facebook → facebookFeed.js, YouTube → yottie.js
  • Die Funktion loadAssets der App fügt jede URL als <script> ein und führt sie aus
    • Eine Struktur also, bei der der Server bestimmt, welcher Code ausgeführt wird
  • Die Elfsight-Server setzen während der Sitzung mehr als 10 Cookies
    • darunter elfsight_viewed_recently, Cloudflare-Tracking-Cookies (_cfuvid, __cf_bm) und Sitzungskennungen

Werbe-Tracking mit Google DoubleClick

  • Beim Einbetten von YouTube werden zusätzlich Tracking-Infrastruktur für Google-Werbung geladen
    • Anfragen an googleads.g.doubleclick.net und static.doubleclick.net wurden bestätigt
  • DoubleClick ist Googles Plattform für Werbeauslieferung und Tracking, und innerhalb der offiziellen White-House-App wird Code zur Werbeverfolgung ausgeführt
    • Im Privacy Manifest der App wird dies nicht offengelegt

Abweichung zwischen Privacy Manifest und tatsächlichem Verhalten

  • Die deklarierten Privacy-Einstellungen der App: 
    NSPrivacyCollectedDataTypes: []
NSPrivacyTracking: false
  • Die in der tatsächlichen Sitzung beobachteten Datenübertragungen:
    • An OneSignal werden Gerätemodell, OS, IP, Zeitzone, Sprache, Anzahl der Sitzungen, Sitzungsdauer und eindeutige Kennung gesendet
    • Verbindungen zu 13 Elfsight-Domains und Empfang von mehr als 10 Tracking-Cookies
    • Ausführung von Google-DoubleClick-Code zur Werbeverfolgung
    • Anfragen an Facebook, Twitter/X, YouTube und Google APIs
  • Damit wird die App zwar als „keine Datenerfassung“ ausgewiesen, tatsächlich erfolgen jedoch umfangreiches Tracking durch Dritte und Datenübertragungen

Analysemethodik

  • Proxy-Tool: mitmproxy (mitmdump)
  • Umgebung: macOS, iPhone (iOS), identisches WLAN-Netzwerk
  • Zertifikat: mitmproxy-CA in die iOS-Vertrauenseinstellungen aufgenommen
  • Umfang der Erfassung: HTTPS-Verkehr beim vollständigen Durchlaufen der 5 Tabs der App
  • Manipulation: keine, der Verkehr wurde nur beobachtet
  • Umgang mit personenbezogenen Daten: IP, Gerätekennungen, OneSignal-ID usw. wurden im Beitrag vollständig maskiert
  • Kein Eindringen in Server und keine Manipulation, es wurde nur die freiwillige Kommunikation der App aufgezeichnet

Verwandte Forschung

  • Bericht zur statischen Analyse der White-House-iOS-App
  • Analyseergebnisse von Thereallo zur Android-Version

Über Atomic Computer

  • Atomic Computer ist ein Unternehmen, das Cybersicherheits-, Infrastruktur- und Entwicklungsdienstleistungen anbietet
  • Das Unternehmen führt Bewertungen und Analysen zur Sicherheit mobiler Apps durch

Verwandte Beiträge

1 Kommentare

 
GN⁺ 27 일 전
Hacker-News-Kommentare

  • 43 % aller Third-Party-Anfragen beziehen sich auf Google (einschließlich YouTube, Fonts und Analytics), zusammen mit Facebook und Twitter sind es etwa 55 %
    Dass eine Regierungs-App übermäßig viel Tracking oder Analyse-Code einbindet, ist problematisch, aber Google Fonts oder YouTube-Embeds halte ich nicht für besonders gravierend
    Beim Titel hätte ich eher schockierende Domains wie Palantir oder ICE erwartet, daher wirken Google/Facebook etwas unspektakulär
    Im Titel sollte es nicht einfach nur heißen „77 % sind Third-Party-Anfragen“, sondern er sollte sich auf den Charakter und die Schwere der Anfragen konzentrieren
    Übrigens verwendet atomic.computer ebenfalls Google Fonts und Analytics. Bevor man Third-Party-Anfragen pauschal als schlecht darstellt, sollte man auch die eigene Website überprüfen

    • Es ist nicht so, dass es ICE oder Palantir verboten wäre, Daten von Google oder Facebook zu kaufen
      Letztlich kann man selbst entscheiden, welche Daten man über die App tracken will, und Daten über gängige Tracking-Anbieter quasi wie durch Geldwäsche gesammelt werden
    • Im eigentlichen Artikel lag der Fokus eher auf Anfragen an OneSignal und Elfsight als auf Google oder YouTube
      Die Google-bezogenen Anfragen scheinen aus Transparenzgründen aufgeführt worden zu sein und nicht mit der Absicht, die White-House-App zu verurteilen
    • Man sieht aktuell zwar Versuche der Regierung, die USA in eine autoritärere Richtung zu drängen, aber ich denke, das System ist so groß, dass es sich nicht leicht verändern lässt
    • Der Einwand nach dem Muster „atomic.computer verwendet auch Third-Party-Anfragen“ ist schwach, weil er im Grunde den Überbringer der Nachricht angreift
      atomic.computer hat nicht behauptet, dass Third-Party-Anfragen an sich schlecht seien, sondern sie nur als Mittel zur Datensammlung und zum Tracking analysiert
      Nutzer haben keine Kontrolle darüber, wie die Daten nach ihrer Erfassung verwendet werden, und genau dieses Fehlen von Kontrolle ist das Kernproblem

  • Laut Bericht wurde mit mitmproxy auf einem Mac gearbeitet und der iPhone-Traffic dorthin umgeleitet, um HTTPS zu entschlüsseln
    Ich habe mich gefragt, ob es wirklich so einfach ist, ein iPhone dazu zu bringen, einem Benutzerzertifikat zu vertrauen
    Unter Android ist es ziemlich umständlich, Netzwerk-Traffic einzusehen
    Solche Experimente zeigen gut, dass wir Kontrolle über unsere Geräte haben sollten. Wir haben ein Recht zu wissen, wohin welche Daten mit welchem Inhalt gesendet werden
    Das erinnert auch an frühere Fälle, in denen Zoom Traffic nach China schickte oder Facebook das Surfverhalten innerhalb von Apps verfolgte

    • iOS vertraut standardmäßig weiterhin vom Nutzer installierten Zertifikaten
      Eine Ausnahme ist, wenn die App ihr eigenes OpenSSL verwendet oder Certificate Pinning einsetzt
      Große Apps wie Facebook oder Twitter nutzen meist Pinning, aber so einfache Apps tun das oft nicht
    • Die Einrichtung von mitmproxy ist unter iOS viel einfacher als unter Android
      Allerdings sind Apps mit Pinning schwer zu umgehen, und Plattformen, auf denen man eigene Apps installieren kann, sind dabei im Vorteil
    • Die Installation der CA ist zwar umständlich, aber bei Apps ohne Pinning ist das Abfangen von Traffic nicht besonders schwer
      Bei stark abgesicherten Fällen wie Banking-Apps braucht man ein gerootetes Gerät
    • Interessant ist, dass Teile der Security-Community MITM-Proxys kritisieren und dabei doch von einer unternehmenszentrierten Sichtweise geprägt sind
    • Als Zoom Traffic nach China schickte, könnten sogar Videos von Regierungssitzungen einfach mit übertragen worden sein
      Man kann sich sogar vorstellen, dass das als Trainingsdaten für Deepfakes verwendet wurde

  • Es gibt dazu frühere Diskussions-Threads
    Frühere Diskussion 1, Frühere Diskussion 2

  • Ich blockiere die meisten Werbe-Domains (z. B. doubleclick.net) auf DNS-Ebene
    Es überrascht mich, dass die meisten Websites, einschließlich Nachrichtenseiten, so viele Third-Party-Verbindungen öffnen
    Auch atomic.computer versucht, Cloudflareinsights und Google Fonts zu laden, aber das wird in meinem Netzwerk blockiert
    Solche Anfragen sind ein Hauptgrund dafür, dass Google Nutzer über das gesamte Internet hinweg verfolgen kann

  • Für Regierungs-Apps sollten deutlich höhere Standards gelten als für normale B2C-Apps
    Google Fonts einzubinden ist in Ordnung, aber Telemetrie an OneSignal oder Facebook zu senden, ist eine andere Sache
    In Australien dürfen gemäß PSPF- und ISM-Vorgaben Regierungsdaten nicht an nicht vertrauenswürdige Externe übertragen werden
    Eine solche App würde bei einer IRAP-Bewertung sofort durchfallen
    Die Lösung ist einfach — Fonts selbst hosten, Analytics als 1st-Party umsetzen und externe Anfragen als Vektor für Datenabfluss behandeln

    • Hohe Standards existieren tatsächlich, aber die aktuelle Regierung hält sich nicht daran
    • Manche stellen infrage, warum Regierungs-Apps höhere Standards haben sollten. Letztlich sei es nur ein Branding-Problem

  • Bei den meisten B2C-Apps liegt der Anteil an Third-Party-Anfragen ebenfalls über 50 %
    Dass die White-House-App bei 77 % liegt, ist nicht überraschend, problematisch war aber, dass die Datenerfassungsangaben im App Store falsch deklariert waren
    Das wurde später korrigiert und ist inzwischen korrekt ausgewiesen

    • Ich lehne Third-Party-Telemetrie in der White-House-App ebenso ab wie in anderen Apps. Beides gleichzeitig ablehnen ist möglich
    • Dass die Regierungs-App wie eine B2C-App gebaut wurde, ist genau der Kern des Problems
    • Es gab auch überzogene Behauptungen, die White-House-App sende Daten an Huawei, aber tatsächlich ist eher bemerkenswert, dass sie 20 % mehr als andere Apps sendet

  • Auch wenn für Regierungs-Apps höhere Standards gelten sollten, ist ein Wert von 77 % womöglich gar nicht so weit vom Branchendurchschnitt entfernt
    Viele Apps enthalten Werbecode und Tracker, daher könnte das ein ziemlich normales Niveau sein

  • Die Liste der von der App verwendeten SDKs kann man bei AppGoblin einsehen

  • Im Privacy Manifest steht „keine Datenerfassung“, tatsächlich werden aber an OneSignal Gerätemodell, IP-Adresse, Anzahl der Sessions und Tracking-ID gesendet
    Das ist ein klarer Fall einer falschen Bestätigung (false attestation)

  • Der nächste Schritt ist vermutlich, Werbung einzubauen