La smart TV du salon est un nœud de l’économie du scraping IA

 (blog.includesecurity.com)
1 points par GN⁺ 3 시간 전 | 1 commentaires | Partager sur WhatsApp
  • Le SDK Bright Data intégré dans des applications grand public transforme, avec le consentement de l’utilisateur, un téléphone ou une smart TV en nœud de sortie de proxy résidentiel, et achemine le trafic de web scraping des clients via des IP domestiques
  • Les proxies résidentiels sont un moyen de contournement permettant d’atteindre des sites cibles via l’IP de clients résidentiels payants, dans un environnement où Cloudflare, DataDome, HUMAN et d’autres limitent ou bloquent les requêtes provenant d’IP cloud connues
  • Les TV connectées n’ont pas de contrainte de batterie, restent toujours connectées au Wi‑Fi et fonctionnent 24/7 en veille, ce qui en fait de meilleures conditions de proxy que les téléphones en matière de disponibilité permanente et de capacité à être laissées sans surveillance
  • Le SDK iOS récupère depuis un endpoint de configuration non authentifié les critères d’inactivité, les limites de bande passante et la liste des partenaires, puis ouvre un tunnel pair à pair WebSocket pour traiter la télémétrie d’état de l’appareil et les tâches de scraping cmd_tun
  • La défense repose surtout sur le blocage DNS de proxyjs.* et clientsdk.*, le filtrage SNI, la détection d’empreintes de certificats TLS et l’analyse binaire des applications par MDM ; sur iOS, use_netifs limite la visibilité fondée sur les VPN

Vue d’ensemble

  • Indépendamment de l’opposition communautaire à la construction de datacenters destinés à renforcer les capacités IA, les appareils domestiques peuvent être utilisés comme structure de collecte distribuée de données pour l’entraînement de l’IA
  • Bright Data vend l’accès à un réseau de proxies résidentiels de plus de 400M d’adresses IP domestiques, utilisées par ses clients pour acheminer du trafic de web scraping ; la source d’approvisionnement est un SDK intégré à des applications grand public
  • Ce SDK transforme, avec le consentement de l’utilisateur, des téléphones ou des smart TV en nœuds de sortie ; l’analyse porte sur son mode de fonctionnement, les plateformes de déploiement et les raisons pour lesquelles les TV connectées à Internet conviennent aux proxies de web scraping pour modèles d’IA

Pourquoi c’est important maintenant

  • Les entreprises d’IA dépendent du contenu issu du web scraping pour le préentraînement, la recherche et la recherche augmentée, le grounding des agents et les fonctions de recherche
  • Le web moderne ne se laisse pas facilement scraper depuis des datacenters, et Cloudflare, DataDome, HUMAN ainsi que d’autres limitent ou bloquent les requêtes en provenance d’IP cloud connues
  • L’alternative consiste à atteindre les sites cibles depuis les IP de clients résidentiels payants, comme des abonnés Comcast ou T-Mobile, via des proxies résidentiels
  • Une citation d’un article de Krebs d’octobre 2025 affirme que « l’excès de proxies provenant d’Aisuru et d’autres sources alimente des efforts massifs de collecte de données liés à plusieurs projets d’IA »
  • Des mesures académiques remontant à 2019 concluent que ces réseaux sont massivement détournés, et le FBI a également publié au début de l’année une alerte officielle
  • La plupart des reportages existants se concentrent sur l’offre illégale de proxies résidentiels, comme les botnets tels que Aisuru et Kimwolf, les applications trojanisées comme PROXYLIB, ou le matériel IoT préinfecté comme IPIDEA
  • Le versant de l’offre légale a été relativement peu examiné ; Bright Data, qui se présente dans son marketing comme le plus grand réseau mondial de proxies résidentiels, met en avant « 150M+ IPs » issues d’un SDK avec consentement intégré dans des applications partenaires

Pourquoi les TV connectées sont des proxies idéaux

Élément Téléphone Smart TV / CTV
Alimentation Sur batterie la majeure partie de la journée Toujours branchée au secteur
Réseau Wi‑Fi + cellulaire Toujours en Wi‑Fi, haut débit
Temps de fonctionnement Intermittent 24/7 en veille
Limites de bande passante Faibles, contraintes cellulaires Pratiquement illimitées
Attention de l’utilisateur Utilisation active Souvent laissée sans surveillance
Interface de consentement Texte sur écran de téléphone Texte à parcourir avec les flèches de la télécommande
Supervision entreprise/famille Plus élevée, via MDM, EDR mobile, etc. Pratiquement inexistante
  • Une TV n’atteint pas 1 % de batterie, ne change pas souvent de réseau Wi‑Fi et ne se verrouille pas pendant que l’utilisateur dort
  • Certains éditeurs partenaires révèlent leur relation avec Bright Data dans leur politique de confidentialité ; la politique de confidentialité de PlayWorks en est un exemple
  • Une mention dans la politique de confidentialité n’est pas un point de contrôle adapté au téléviseur : il est difficile de faire défiler des documents juridiques avec les flèches d’une télécommande, et les boîtes de dialogue de consentement intégrées à l’application ne montrent pas clairement que des clients payants de Bright Data font transiter leur trafic de scraping via l’accès Internet domestique de l’utilisateur
  • L’écran d’opt-in de l’application Roku Petflix, documenté par The Verge, indique : « pour voir moins de publicités et profiter gratuitement, autorisez Bright Data à utiliser occasionnellement les ressources disponibles de votre appareil et son adresse IP pour télécharger des données web publiques sur Internet »
  • La boîte de dialogue Petflix emploie le terme « occasionnellement », mais la configuration du SDK publiquement consultable contient max_bw_monthly_wifi: 200,000,000,000, soit un budget Wi‑Fi mensuel par défaut de 200 Go

Entités que Bright Data désigne comme partenaires

  • Bright Data expose un endpoint de manifeste partenaires accessible à tous, sans authentification
  • Éléments d’identification à forte confiance d’après des sources publiques
Partner ID Entité Taille
playworks_digital PlayWorks Digital Ltd Plus de 400 jeux CTV, portée d’environ 250M de foyers TV via Comcast, Sky, Cox, LG, Samsung, Vizio et Roku
cloudtv CloudTV Intégré à plus de 125 marques de TV et plus de 15 OEM
longvision_media_hong_kong_co_limited Longvision Media HK (LongTV) 5M d’utilisateurs OTT à Hong Kong et en Malaisie
viber_media_s_r_l Viber Media S.à r.l. (Rakuten) 250M à 820M d’utilisateurs mensuels de la messagerie Viber
supercent_inc Supercent Éditeur mobile n°1 en Corée du Sud par téléchargements en 2023
moonfrog_labs_private_limited Moonfrog Labs Environ 10M de MAU pour Teen Patti Gold seul, société acquise pour 90M$
hola_networks Hola Networks Maison mère historique de Bright Data ; selon l’ancien marketing de Hola, le pic d’utilisateurs allait de plusieurs dizaines de millions à environ 100M+
  • desoline, free_time, ott_studio, global_microtrading, m_m_media, easystaff_lp figurent dans le manifeste, mais il est difficile de les identifier à partir de sources publiques
  • bright_screensavers, bright_videos, brightdata sont des applications propres à Bright Data
  • Le fait que ces noms apparaissent dans la configuration de Bright Data suggère qu’une intégration a pu exister à un moment donné, mais ne constitue pas une preuve directe que les applications actuellement distribuées par un éditeur donné embarquent le SDK en production
  • Ce que la liste des partenaires démontre directement, c’est que Bright Data diffuse cette liste sur un endpoint public sans authentification, et qu’au moins trois acteurs centrés sur la CTV — dont PlayWorks, CloudTV et Longvision — ont monétisé les appareils des utilisateurs comme nœuds de sortie de proxy résidentiel
  • Selon ses propres supports marketing, PlayWorks revendique une distribution CTV couvrant les principales plateformes TV et les FAI, avec une portée de plusieurs centaines de millions de foyers
Publicité

Comment le SDK Bright Data transforme les appareils des utilisateurs en nœuds de sortie de proxy résidentiel

  • Le SDK Bright Data est un produit commercial publiquement documenté, avec une documentation d’intégration SDK pour les éditeurs et une variante JavaScript pour le web

  • L’analyse s’appuie sur de la rétro-ingénierie d’un framework iOS déployé et sur 30 jours d’instrumentation du trafic à l’exécution

  • Le SDK est distribué sous la forme du framework iOS brdsdk.framework à l’intérieur des applications partenaires

  • Configuration sans authentification

    • À chaque exécution, le SDK appelle la requête suivante
    • GET https://clientsdk.bright-sdk.com/sdk_config_ios.json/…;
    • Le point de terminaison fonctionne sans authentification significative, et le serveur ne vérifie que deux paramètres de requête : appid, qui correspond à l’identifiant de bundle de l’app, et ver, qui correspond à la chaîne de version du SDK
    • En fournissant l’identifiant de bundle visible dans la fiche App Store d’une application partenaire, une chaîne de version du SDK et un UUID généré arbitrairement, on obtient une configuration identique à celle renvoyée à un véritable appareil
    • La réponse contient des feature flags, des seuils de détection d’inactivité comme le niveau de batterie, les plafonds CPU/mémoire et les règles Wi‑Fi/cellulaire, des paliers de bande passante par pays, ainsi qu’une structure contenant le manifeste partenaire
    • La configuration inclut des règles d’inactivité permettant à l’appareil d’être éligible au relais de trafic, un flag pour router le trafic pair autour du VPN, une map reliant les installations multi-plateformes à une seule identité, et des limites de bande passante par pays

  • Tunnel pair

    • Après avoir récupéré la configuration, le SDK ouvre un WebSocket persistant vers l’adresse suivante
    • wss://proxyjs.brdtnet.com:443
    • À la date de rédaction, ce nom d’hôte se résout vers les IP AWS Global Accelerator 3.33.193.183, 15.197.193.114
    • Le certificat TLS est CN=*.luminatinet.com, et Luminati Networks était le nom de l’entreprise Bright Data avant 2018
    • Même après le rebranding de 2018, l’infrastructure SDK active utilise encore des certificats legacy, et le trafic luminatinet.com ou brdtnet.com n’indique pas un usage de Bright Data côté client, mais constitue un indice d’identification du plan de tunnel pair
    • Les services proxy actuels destinés aux clients fonctionnent sur des domaines de marque brightdata.com, donc le trafic réseau vers luminatinet.com et brdtnet.com correspond au plan de tunnel pair
    • Le serveur s’identifie comme uWebSockets: 20
    • Le point de terminaison pair n’exige pas d’authentification à l’upgrade : après avoir accepté un upgrade WebSocket valide au niveau TLS, il envoie immédiatement une trame de couche applicative qui renvoie l’IP publique du client
    • Flux du handshake
      1. Serveur → Client tunnel_init : crée la session et renvoie l’IP publique du client
      1. Serveur → Client cid_set : assigne un identifiant de suivi de session au format <IP>-<token>/ls<N>c<M>p443_<IP>_<counter>, confirmé comme correspondant au champ cid observé dans la télémétrie de vrais appareils
      1. Serveur → Client status_get : interroge l’état d’inactivité de l’appareil, sa batterie, son type de réseau et sa bande passante disponible, et l’appareil répond avec une télémétrie continue comprenant idle, wifi_connected, mobile_connected, mobile_type, roaming, battery_level, using_battery, screen_on, on_call, cpu_usage, mem_usage, raw_bw, bw, ipv6_supported, appid, sdk_version, platform, cid
      Publicité
      1. Une fois le handshake terminé, si l’appareil déclare un état favorable, la couche serveur d’appariement des tâches peut pousser des trames cmd_tun, que le SDK exécute sous forme de requêtes HTTP vers des sites tiers avec comme origine l’IP résidentielle de l’utilisateur
    • Toutes les trames du WebSocket sont du JSON brut avec une enveloppe fixe
    • {"type": "ipc_call"|"ipc_post"|"ipc_result"|"ipc_error","cmd": <command>, "cookie": <correlation-id>,"err_code": 0, "msg": { ...payload... }}
    • Commandes extraites du binaire et confirmées dans les communications réelles
    • | Direction | cmd | But |
    • |---|---|---|
    • | Serveur → Client | tunnel_init | Ouverture de session, écho de l’IP publique |
    • | Serveur → Client | cid_set | Attribution de l’identifiant de session |
    • | Serveur → Client | status_get | Interrogation de l’inactivité, de la batterie et de la bande passante de l’appareil |
    • | Serveur → Client | cmd_tun / tun | Livraison d’une tâche de scraping |
    • | Serveur → Client | dns | Demande de résolution DNS cible |
    • | Serveur → Client | consent | Demande d’état du consentement |
    • | Client → Serveur | status_send | Heartbeat périodique d’état de l’appareil |
    • | Client → Serveur | tun_report / tun_ack / tun_fin | Réponses sur le cycle de vie de la tâche de relais |
    • | Client → Serveur | tunnel_init_decline | Refus de session |
    • | Client → Serveur | logs | Envoi de journaux de diagnostic au serveur |
    • Il n’existe ni signature de message, ni HMAC, ni certificat client, ni attestation d’appareil ; dans les faits, seuls la couche TLS et les filtres de réputation IP du serveur distinguent les pairs qui reçoivent de vraies tâches
    • Pour les lecteurs familiers des protocoles de malware commerciaux, le niveau de sécurité est en pratique inférieur à celui d’un C2 classique

  • Ce que le SDK considère comme « inactif »

    • La configuration définit les règles d’état de l’appareil autorisant le relais du trafic d’autrui
    "idle_metrics": {
  "ignore_screen_on": true,
  "ignore_on_call": true,
  "max_bw_ratio": 1,
  "min_battery": 0.2,
  "wifi_on_battery": true,
  "min_battery_wifi": 0.2,
  "max_cpu_usage": 70,
  "max_mem_usage": 90,
  "mem_screen_off": true,
  "idle_timeout": 30,
  "not_idle_timeout": 10
}
    • En raison des flags ignore_screen_on et ignore_on_call, « inactif » ne signifie pas que l’utilisateur est éloigné de son appareil, mais que CPU, mémoire et batterie restent dans les seuils du SDK
    • Un utilisateur en appel ou en train de lire activement l’écran peut donc malgré tout être considéré comme inactif à des fins de relais

  • Liaison d’identité entre plateformes

    • La configuration contient la map dual_pairing suivante
    Publicité
    "dual_pairing": {
  "ios_com.brd.earnapp": ["win_earnapp.com", "mac_com.earnapp"]
}
    • Cette map est une structure de liaison côté serveur qui regroupe comme une seule entité les installations iOS, Windows et macOS d’une même marque
    • Le champ http3_enabled: true est un flag pour le transport pair basé sur QUIC, et de futures versions pourraient déplacer le tunnel pair de TCP/443 vers UDP/443
    • Les défenses qui détectent le WebSocket par suivi des connexions TCP pourraient ne plus fonctionner en cas de bascule vers UDP/443

  • Contournement de l’inspection

    • Le flag use_netifs: true de la configuration SDK est la condition qui amène le code binaire du SDK à construire NWConnection sur des interfaces requises spécifiques, au lieu du chemin par défaut du système
    • Les interfaces requises sont en0 pour le Wi‑Fi ou pdp_ip0 pour le cellulaire
    • Sur iOS, cette méthode contourne complètement l’interface tun0 d’un VPN configuré ; même si le reste du trafic HTTPS de l’application passe par le VPN, le tunnel pair, lui, n’emprunte pas le VPN configuré par l’utilisateur

  • L’environnement de recherche d’interception TLS transparente a capturé tous les appels HTTPS du SDK, mais n’a pas réussi à capturer le tunnel pair proxyjs.brdtnet.com:443, alors même que le port 443 était explicitement redirigé vers l’inspecteur

    • Le contournement utilise l’API documentée d’Apple NWParameters.requiredInterface
    • Le SDK utilise deux contournements d’inspection indépendants
    • Plan de contrôle : la récupération de configuration et les pings de télémétrie reposent sur les primitives CFHTTPMessage de CFNetwork plutôt que sur URLSession et NSURLConnection, neutralisant ainsi l’instrumentation au niveau de URLSession, le swizzling, les network extensions et les sous-classes URLProtocol, courants dans les outils de sécurité pour applications mobiles, tout en respectant le proxy système, ce qui maintient une visibilité pour les chercheurs travaillant sur l’interception TLS
    • Plan de données : le tunnel pair repose sur NWConnection avec l’interface physique définie comme interface requise, neutralisant le VPN et garantissant que le scraping s’exécute depuis une IP résidentielle
    • Pour les équipes sécurité qui utilisent le MDM, l’inspection du trafic via VPN d’entreprise ou le contrôle parental du routeur domestique, le canal le plus sensible est conçu pour contourner la couche de visibilité

Paliers par pays

  • Les paramètres incluent des seuils de bande passante par pays
Publicité
Pays Batterie minimale pour le relais Limite quotidienne Limite mensuelle
Uzbekistan 1% 1GB 30GB
Oman 1% 1GB 30GB
Qatar 20% 40MB 250MB
UAE 20% 40MB 250MB
default, worldwide 20% 50MB 500MB
  • Sur les appareils en Uzbekistan et à Oman, le relais est autorisé jusqu’à 1% de batterie, avec une limite quotidienne 20 fois supérieure à la valeur par défaut et une limite mensuelle 60 fois supérieure
  • Les appareils au Qatar et aux UAE sont limités à des quotas inférieurs à la valeur par défaut
  • Il est impossible de déterminer avec certitude pourquoi ces paliers par pays sont configurés ainsi ; on ne peut que spéculer
  • Même l’allocation par défaut au niveau mondial autorise 500MB par mois du trafic d’autres personnes via la connexion Internet domestique de l’utilisateur

Configuration de test et méthodologie

  • Une capture via proxy d’interception TLS a été réalisée pendant 30 jours sur un appareil iOS exécutant une app partenaire installée avec consentement ; l’app d’exemple inclut XYO COIN, qui embarque Bright SDK
  • Analyse statique effectuée sur brdsdk.framework version 1.532.120, binaire iOS arm64
  • Les noms d’hôte spécifiques de Bright Data, les empreintes de certificats et l’infrastructure TLS sont observables publiquement par quiconque effectue les mêmes requêtes
  • Le document ne contient aucune donnée d’identification par session concernant un parc de recherche ou des clients de recherche

Chronologie

  • 11 mai 2026 : envoi d’un e-mail de notification préalable à publication à privacy@brightdata.com
  • Au moment de la publication, aucune réponse à cette notification

Approches de défense

  • Le trafic laisse une empreinte claire à la frontière du réseau, et le SDK est conçu pour laisser des symboles identifiables dans le binaire de l’app
  • Approche 1 : le blocage DNS est une méthode simple et efficace pour les appareils routant leur trafic via le réseau
    • proxyjs.brdtnet.com
    • proxyjs.luminatinet.com
    • proxyjs.bright-sdk.com
    • clientsdk.bright-sdk.com
    • clientsdk.brdtnet.com
  • Le blocage de proxyjs.* interrompt les tunnels pair à pair, sans impact pour les clients qui utilisent légitimement les services proxy de Bright Data destinés aux clients fonctionnant sur d’autres domaines
  • Approche 2 : le filtrage TLS SNI consiste à bloquer ou signaler les handshakes TLS dont le server_name correspond à *.brdtnet.com, *.luminatinet.com, *.luminati.io
  • Le filtrage SNI fonctionne à la frontière du réseau sans inspection TLS
  • Approche 3 : la détection par empreinte de certificat TLS permet de bloquer ou signaler selon les empreintes suivantes
    • .brdtnet.com → SHA256 313ce4ec7d5a51e5…
    • .luminatinet.com → SHA256 5028612e625befea…
  • Les empreintes de certificats restent stables jusqu’au remplacement des certificats Sectigo, et les certificats actuels sont valides jusqu’à mi-2026
  • En raison des contraintes liées à use_netifs, les trois couches ne fonctionnent que lorsque le trafic traverse la frontière du réseau
  • Quand un appareil iOS utilise le cellulaire, la liaison use_netifs du SDK crée une condition dans laquelle le trafic pair à pair contourne entièrement le Wi-Fi d’entreprise
  • Un contrôle compensatoire pour un parc d’appareils gérés consiste à effectuer, via MDM, un scan des binaires d’apps afin de rechercher les symboles Swift BrdWebSocketFacade et BrdNetwork.DNSResolver, puis d’interdire sur les appareils fournis par l’entreprise les apps contenant ces symboles
  • Les particuliers inquiets d’une smart TV ou d’une app mobile spécifique peuvent bloquer les noms d’hôte ci-dessus dans les paramètres DNS de leur routeur
  • Exemples d’outils de blocage : Pi-hole, NextDNS, Cloudflare Gateway, ou la fonctionnalité équivalente de leur FAI

À lire aussi

1 commentaires

 
GN⁺ 3 시간 전
Avis sur Lobste.rs

  • En parlant de ce protocole, créer un honeypot inversé qui renverrait volontairement des données aléatoires et inutiles à chaque requête pourrait faire un projet de vibe coding amusant pour quelqu’un qui a des tokens en trop

    • Il ne semble même pas nécessaire d’implémenter le protocole. D’après les logs, une bonne partie de ces proxys résidentiels échouent complètement à se dissimuler, donc on peut simplement leur envoyer facilement des données poubelles
      Pas besoin non plus de vibe coding, il existe déjà des dizaines d’outils capables de faire ça. Beaucoup d’entre eux fournissent déjà sans fin des données poubelles à ce type de proxy depuis plus d’un an

  • Je ne comprends absolument pas pourquoi on connecte une TV, ou n’importe quel autre appareil électroménager, à Internet. Il n’y a aucune bonne raison de le faire

    • Les gens regardent des services de streaming sur leur TV. Connecter la TV à Internet est la manière la plus simple de le faire