- Le trafic HTTPS réel de l’application iOS de la Maison-Blanche a été capturé via un proxy MITM afin d’analyser avec quels serveurs elle communique et quelles données elle échange
- En plus de whitehouse.gov, l’application communique avec 31 hôtes tiers, dont Elfsight, OneSignal, YouTube, Google DoubleClick, Facebook et Twitter
- Des informations de profilage utilisateur sont continuellement envoyées à OneSignal : langue, fuseau horaire, IP, modèle d’appareil, nombre de sessions, etc.
- Des scripts externes sont exécutés via le chargeur de widgets Elfsight, et du code de suivi publicitaire Google DoubleClick fonctionne également à l’intérieur de l’application
- Alors que le privacy manifest de l’application indique “aucune collecte de données”, on observe en réalité de multiples mécanismes de suivi tiers et des transferts de données
Vue d’ensemble de l’analyse du trafic réseau
- Analyse du trafic réseau de l’application officielle iOS de la Maison-Blanche en le capturant avec un proxy MITM (attaque de l’homme du milieu)
- Installation de mitmproxy sur macOS, puis enregistrement de tout le trafic HTTPS de l’iPhone via le proxy
- Version analysée de l’application : v47.0.4 (build 81) ; tous les onglets ont été parcourus : Home, News, Live, Social et Explore
- Le trafic a été déchiffré et enregistré sans modification, dans des conditions d’usage ordinaires
Serveurs contactés par l’application
- Au cours d’une seule session, l’application a envoyé des requêtes vers 31 hôtes uniques (hors trafic système iOS)
- Sur un total de 206 requêtes, seules 48 (23 %) ont été envoyées à whitehouse.gov
- Les 158 restantes (77 %) ont été envoyées à des services tiers tels que Elfsight, OneSignal, YouTube, Google DoubleClick, Facebook et Twitter
- Principales destinations des requêtes
- whitehouse.gov : API WordPress (actualités, accueil, galerie, etc.)
- YouTube : intégration vidéo et miniatures
- Elfsight : chargement des widgets, ressources statiques, stockage de fichiers, API de démarrage, etc.
- OneSignal : analyse et profilage utilisateur
- CDN Facebook/Twitter : chargement d’images
- Google APIs et DoubleClick : publicité et suivi
Données envoyées à OneSignal
- Au lancement de l’application, un corps de requête HTTPS est envoyé à
api.onesignal.com
- Informations incluses : langue, fuseau horaire, pays, adresse IP, heure du premier lancement et de la dernière activité, modèle d’appareil, version de l’OS, type de réseau (Wi‑Fi/cellulaire), opérateur, statut jailbreak, nombre de sessions, durée des sessions, identifiant unique
- À chaque exécution, l’application envoie plusieurs requêtes PATCH pour mettre à jour le profil
- 18 requêtes PATCH lors du premier lancement ; 9 requêtes OneSignal observées sur l’ensemble de la session
- Séquence : consultation du profil existant par GET → mise à jour des informations de session par PATCH
- OneSignal enregistre en continu l’IP par session, l’heure d’activité, le nombre de sessions et leur durée
- Le profil est mis à jour lorsque l’adresse IP change
- L’horodatage
first_active ne change pas après l’installation
- En conséquence, OneSignal maintient un profil persistant par utilisateur et suit les habitudes d’usage de l’application ainsi que l’environnement réseau
- Le User-Agent observé dans le trafic est
WhiteHouse/81 CFNetwork/3860.400.51 Darwin/25.3.0
Trafic lié à Elfsight
- Les 6 widgets et le chargeur JavaScript en 2 étapes identifiés par l’analyse statique ont également été confirmés dans le trafic réel
- À l’ouverture de l’onglet Social, l’application se connecte à 13 domaines Elfsight
elfsightcdn.com, core.service.elfsight.com, static.elfsight.com, storage.elfsight.com, widget-data.service.elfsight.com, video-proxy.wu.elfsightcompute.com, etc.
- En envoyant chaque identifiant de widget via la requête
/p/boot/, le serveur renvoie la liste des scripts à exécuter (tableau assets)
- Exemples : TikTok →
tiktokFeed.js, Instagram → instashow.js, Facebook → facebookFeed.js, YouTube → yottie.js
- La fonction
loadAssets de l’application insère ensuite chaque URL sous forme de balise <script> pour l’exécuter
- La structure permet donc au serveur de décider quel code sera exécuté
- Les serveurs Elfsight définissent plus de 10 cookies au cours d’une session
- Dont
elfsight_viewed_recently, des cookies de suivi Cloudflare (_cfuvid, __cf_bm) et des identifiants de session
Suivi publicitaire Google DoubleClick
- Lors de l’intégration de YouTube, l’infrastructure de suivi publicitaire de Google est également chargée
- Requêtes observées vers
googleads.g.doubleclick.net et static.doubleclick.net
- DoubleClick est la plateforme de diffusion publicitaire et de suivi de Google,
et du code de suivi publicitaire s’exécute dans l’application officielle de la Maison-Blanche
- Cet élément n’est pas mentionné dans le privacy manifest de l’application
Écart entre le privacy manifest et le comportement réel
Méthodologie d’analyse
- Outil proxy : mitmproxy (mitmdump)
- Environnement : macOS, iPhone(iOS), même réseau Wi‑Fi
- Certificat : ajout de la CA mitmproxy aux réglages de confiance iOS
- Périmètre de capture : trafic HTTPS généré pendant l’exploration complète des 5 onglets de l’application
- Modification du trafic : aucune, observation uniquement
- Traitement des données personnelles : IP, identifiants d’appareil, identifiant OneSignal, etc. ont tous été masqués dans le billet
- Aucune intrusion ni manipulation côté serveur, uniquement l’enregistrement des communications initiées volontairement par l’application
Recherches associées
- Rapport d’analyse statique de l’application iOS de la Maison-Blanche
- Résultats de l’analyse Thereallo de la version Android
Présentation d’Atomic Computer
- Atomic Computer est une entreprise fournissant des services de cybersécurité, d’infrastructure et de développement
- Elle réalise des prestations d’évaluation et d’analyse de la sécurité des applications mobiles
1 commentaires
Avis Hacker News
Sur l’ensemble des requêtes tierces, 43 % sont liées à Google (y compris YouTube, Fonts et Analytics), et on arrive à environ 55 % en ajoutant Facebook et Twitter
C’est problématique qu’une appli gouvernementale intègre trop de tracking ou de code d’analyse, mais Google Fonts ou une intégration YouTube ne me semblent pas si graves
Avec le titre, je m’attendais à voir des domaines choquants du type Palantir ou ICE ; au final, Google/Facebook, c’est un peu plat
Le titre devrait moins insister sur le simple fait que « 77 % sont des requêtes tierces » et davantage sur la nature et la gravité de ces requêtes
À noter qu’atomic.computer utilise aussi Google Fonts et Analytics. Avant de présenter les requêtes tierces comme mauvaises en soi, il faudrait vérifier son propre site
En fin de compte, ils peuvent décider eux-mêmes quelles données suivre via l’appli, et aussi collecter des données en les faisant transiter par des fournisseurs de tracking généralistes
Les requêtes liées à Google semblent avoir été incluses par souci de transparence, pas dans l’intention d’accabler l’appli White House
atomic.computer n’a pas dit que les requêtes tierces étaient intrinsèquement mauvaises ; il les a seulement analysées comme moyens de collecte et de suivi des données
Les utilisateurs n’ont aucun contrôle sur l’usage fait des données une fois collectées ; au fond, le vrai problème est l’absence de contrôle
Il dit avoir installé mitmproxy sur un Mac et redirigé le trafic de l’iPhone vers celui-ci pour déchiffrer le HTTPS
Je me demandais si c’était vraiment si simple de faire confiance à un certificat utilisateur sur iPhone
Sur Android, inspecter le trafic réseau est plutôt pénible
Ce genre d’expérience montre bien que nous devrions avoir le contrôle de nos appareils. Nous avons le droit de savoir où vont nos données et ce qui est envoyé
Cela rappelle aussi le cas où Zoom envoyait du trafic vers la Chine, ou celui où Facebook suivait les données de navigation dans son navigateur intégré
L’exception, c’est quand une appli utilise son propre OpenSSL ou applique du certificate pinning
La plupart des grosses applis comme Facebook ou Twitter utilisent le pinning, mais ce genre d’appli simple ne le fait généralement pas
En revanche, il est difficile de contourner les applis avec pinning, et une plateforme permettant d’installer ses propres applis est plus avantageuse
Pour les cas fortement protégés comme les applis bancaires, il faut un appareil rooté
On peut même imaginer qu’elles aient servi de données d’entraînement pour des deepfakes
Il existe des fils de discussion précédents sur le sujet
Discussion précédente 1, Discussion précédente 2
Je bloque au niveau DNS la plupart des domaines publicitaires (par ex. doubleclick.net)
Il est frappant de voir que la plupart des sites web, y compris les sites d’actualité, ouvrent un grand nombre de connexions tierces
atomic.computer essaie aussi de charger Cloudflareinsights et Google Fonts, mais c’est bloqué sur mon réseau
Ces requêtes sont l’une des principales raisons pour lesquelles Google peut suivre les utilisateurs sur l’ensemble d’Internet
Une appli gouvernementale devrait être soumise à des exigences bien plus élevées qu’une appli B2C ordinaire
Charger Google Fonts, pourquoi pas, mais envoyer de la télémétrie à OneSignal ou Facebook, c’est autre chose
En Australie, les règles PSPF et ISM interdisent que des données gouvernementales soient transmises à des tiers non approuvés
Une appli comme celle-ci échouerait immédiatement à une évaluation IRAP
La solution est simple : héberger les polices soi-même, faire de l’analyse en 1st-party et traiter les requêtes externes comme des vecteurs d’exfiltration de données
La plupart des applis B2C ont elles aussi plus de 50 % de requêtes tierces
Les 77 % de l’appli White House ne sont donc pas si surprenants, mais le vrai problème était que les éléments de collecte de données dans l’App Store étaient mal renseignés
Cela a ensuite été corrigé et c’est désormais affiché correctement
Les applis gouvernementales devraient certes répondre à des exigences plus élevées, mais ce chiffre de 77 % n’est peut-être pas très éloigné de la moyenne du secteur
Énormément d’applis embarquent du code publicitaire et des trackers ; ce niveau est donc peut-être assez ordinaire
On peut consulter la liste des SDK utilisés par l’appli sur AppGoblin
Le privacy manifest indique « aucune collecte de données », alors qu’en réalité l’appli envoie à OneSignal le modèle de l’appareil, l’adresse IP, le nombre de sessions et un identifiant de suivi
C’est clairement un cas de fausse attestation (false attestation)
La prochaine étape sera sans doute d’ajouter de la publicité