AppLovin Mediation Cipher geknackt: Geräte-Fingerprinting umgeht ATT

Eine eingehende Untersuchung des Werbevermittlungsprotokolls von AppLovin hat eine benutzerdefinierte Chiffre aufgedeckt, die den Datenschutz der Nutzer nicht gewährleistet. Der Forscher entschlüsselte über 5.000 echte Gebotsanfragen von einwilligenden Nutzern und stellte fest, dass die verschlüsselten Nutzdaten genügend Gerätedaten übertragen, um ein iPhone eindeutig über Apps verschiedener Publisher hinweg zu identifizieren – selbst wenn der Nutzer die App-Tracking-Transparenz (ATT) verweigert hat.

Wie die Chiffre funktioniert

Jede Vermittlungsanfrage ist ein HTTPS-POST an ms4.applovin.com/1.0/mediate. Innerhalb der TLS-Schicht umhüllt eine zweite Chiffre die Nutzdaten. Nach Base64-Decodierung besteht das Drahtformat aus drei durch Doppelpunkte getrennten Feldern und Chiffretext:

2:8a2387b7dbed018e5e485792eac2b56833ce8a3a:T7NreIR729giTKR-thJPcKeT6JXevACogl57SIFzwKp-1BASwpBT6v:<binary>

Felder:

• Versions-Tag (2)
• 40-stellige Protokoll-ID — sha1(salt).hex()
• 54-stelliges Suffix des Publisher-eigenen AppLovin-SDK-Keys (im Klartext in Info.plist oder AndroidManifest.xml gespeichert)

Die Chiffre verwendet zwei Zutaten: ein 32-Byte-konstantes Salt, das in jedes SDK-Binary eingebacken ist (21 signifikante Bytes + 11 Null-Bytes, identisch über mehrere Apps und Plattformen hinweg), und den publisher-eigenen SDK-Key. Der abgeleitete Schlüssel ist SHA-256(salt || sdk_key[:32]). Der Schlüsselstrom wird mit SplitMix64, einem nicht kryptografischen PRNG, erzeugt. Der Zähler ist System.currentTimeMillis() XOR mit den ersten 8 Bytes des abgeleiteten Schlüssels – die Echtzeit wird vor der Entschlüsselung auf dem Draht preisgegeben. Es wird kein MAC oder Authentifizierung angewendet, sodass ein Angreifer den Chiffretext manipulieren kann.

Was übertragen wird

Der entschlüsselte Klartext ist gzip-komprimiertes JSON mit etwa 30 Top-Level-Schlüsseln. Die entscheidenden:

• device_info – AppLovins eigener Fingerprint-Payload mit etwa 50 Feldern
• signal_data[] – undurchsichtige Token von jedem Nachfragepartner-SDK

Ein Beispiel aus einer Anfrage, bei der ATT verweigert wurde (IDFA auf Null gesetzt):

Feld         Wert                Beschreibung
revision      iPhone14,3           Hardwaremodell (iPhone 13 Pro Max)
os            18.6.2               Betriebssystemversion
tm            5918212096           Gesamt-RAM (5,51 GB)
ndx / ndy     1284 × 2778          Native Bildschirmpixel
kb            en-US,es-ES          Installierte Tastaturen
font          UICTContentSizeCategoryXXXL  Barrierefreiheit-Textgröße
tz_offset     -4                   Zeitzone
volume        40                   System-Lautstärke
mute_switch   1                    Physischer Stummschalter
bt_ms_2       1770745989000        Gerätestartzeit (ms Epoche)
dnt / idfa    true / 00000…       ATT verweigert
idfv          81E958C3-…-51DE7CE11819  Anbieter-ID (stabil über Apps hinweg)

Weitere Felder umfassen Safe-Area-Einschnitte, freien Arbeitsspeicher, Betreibercode, Ländercode, Gebietsschema, Ausrichtung, Statusbalkenhöhe, monotone Uhr, Batteriestatus und Zustand der sicheren Verbindung. Dies sind im Wesentlichen alle Systemeigenschaften, die für Drittanbieter-Code zugänglich sind.

Weitergabe an Dritte

Ein typischer Publisher integriert etwa 18 Nachfrage-SDKs (Meta, Google, Mintegral, Vungle, ironSource, Unity, InMobi, BidMachine, Fyber, Moloco, TikTok, Pangle, Chartboost, Verve, MobileFuse, Bigo, Yandex, plus AppLovins eigenes). Bei jeder Banner-Ladung (ca. alle 30 Sekunden) übergibt das AppLovin-SDK den entschlüsselten Geräte-Payload an jedes dieser nachgelagerten Netzwerke, was app-übergreifendes Nutzer-Tracking ohne ATT-Zustimmung ermöglicht.

Auswirkungen

Die Annahme, dass ATT allein eine deterministische Identifizierung verhindert, ist falsch. Geräte-Fingerprinting über die preisgegebenen Felder funktioniert genauso gut. Das Fehlen einer Authentifizierung in der Chiffre-Schicht wirft zudem Integritätsbedenken auf.