Alors qu'il pousse pour une adoption du Full Self Driving dans toute l'Union européenne, la RDW invoque le secret des affaires pour ne rien dévoiler de son évaluation. Une opacité entretenue à la demande de Tesla elle-même, selon des échanges de courriels obtenus par Reuters.
La prochaine version de la distribution Linux devrait activer par défaut un important mécanisme de sécurité, la Shadow Stack. L’équipe effectue actuellement un gros travail préparatoire, qui pourrait largement débroussailler le terrain pour les autres systèmes Linux. Accrochez-vous un peu, on vous explique.
D’abord, qu’est-ce que la Shadow Stack ? Il s’agit d’une protection initialement créée par Intel en 2016 mais qui n’est réellement arrivée sur le marché qu’en 2020 avec la génération Tiger Lake. Elle fait partie d’une architecture nommée Intel CET (Control-Flow Enforcement Technology), qu’AMD a également reprise à partir de la génération Zen 3 de ses processeurs.
Le principe de la Shadow Stack (ou pile fantôme) est assez technique. Le processeur dispose en permanence d’une seconde pile d’exécution (call stack) en mémoire. Elle est cachée, isolée et protégée en écriture. Lorsqu’une instruction d’appel (CALL) survient, l’adresse de retour est ajoutée sur les deux piles. Quand l’instruction RET (RETURN) – qui sert à terminer l’exécution d’une fonction – survient, le processeur compare les deux piles : s’il y a correspondance des deux adresses de retour, l’opération se poursuit, dans le cas contraire le processeur déclenche une erreur (exception de protection de flux de contrôle). Cette erreur interrompt immédiatement le processus.
Il s’agit d’une fonction de sécurité, car en interrompant brutalement l’opération, le processeur empêche un pirate d’avancer dans son attaque. La Shadow Stack a été créée pour combattre les attaques de type ROP (return-oriented programming), qui peuvent mener à la prise de contrôle de la pile d’exécution. Elles peuvent également contourner des protections plus anciennes comme ASLR (Address Space Layout Randomization).
Ce que propose l’équipe de Fedora, c’est d’activer cette protection sur l’ensemble du système sur les configurations x86_64. Car il s’agit bien pour l’instant encore d’une proposition, même si elle a de très fortes chances d’être acceptée au vu de son statut avancé. Si elle ne passait finalement pas la validation, elle serait programmée pour Fedora 46 au printemps prochain.
Dans la fiche dédiée, on peut lire que le gros avantage de la Shadow Stack est son impact quasi nul sur les performances, contrairement aux solutions logicielles de contrôle d’intégrité du flux d’exécution. Le surcoût d’exécution est jugé négligeable et imperceptible sur la grande majorité des charges de travail, permettant en échange une élévation générale du niveau de sécurité.
Une activation générale de cette pile fantôme suppose toutefois des adaptations profondes. Il faut notamment que les compilateurs GCC, Clang et rustc soient prêts, ce qui est a priori le cas désormais. Le reste dépend surtout d’un long travail préparatoire commencé il y a des années, la majorité des paquets du dépôt principal possédant déjà les annotations ELF requises, en plus de certaines options compilées à la compilation depuis 2018. Le support de la bibliothèque glibc est également marqué comme prêt.
Sur un plan purement technique, Fedora n’est pas la première distribution à supporter la Shadow Stack. Sa prise en charge dans le noyau Linux remonte à la version 6.6 de 2023. Plusieurs distributions – dont Arch Linux, Ubuntu et Debian – compilent déjà une grande partie de leurs paquets avec l’option liée (-fcf-protection) de GCC/Clang.
Alors, en quoi la démarche de Fedora est-elle novatrice ? Parce qu’elle renverse la vapeur : on parle cette fois d’une activation générale et par défaut. Tout processus éligible bascule automatiquement sur la pile fantôme à son lancement, sans intervention de l’utilisateur. Ce changement a notamment nécessité un travail d’audit et de correction pour les binaires incompatibles, comme les routines en assembleur manuscrit, la chaine d’outils Rust ou encore les moteurs de compilation Just-in-time dans les navigateurs.
Pour ces derniers justement, l’équipe de Fedora note que Chrome et Firefox ne sont pas encore compatibles. Cependant, le mécanisme d’activation a été pensé avec cette limitation en tête et contient un processus de « dégradation élégante » (graceful fallback). En clair, si une application charge au démarrage un objet ELF ne disposant pas du marquage SHSTK (pour Shadow Stack), la glibc désactive silencieusement la pile fantôme pour ce processus unique, sans interrompre son exécution.
Précisons enfin que la Shadow Stack n’est que la première moitié de l’architecture Intel CET. L’autre partie se nomme IBT, pour Indirect Branch Tracking. Sa mission est de contrer un autre type d’exploitation, basé sur la programmation orientée saut ou appel indirect (JOP/COP) et qui peut mener, là encore, à une attaque de type ROP. Le travail réalisé sur la Shadow Stack préparera donc le terrain pour la prise en charge d’IBT dans une version « ultérieure » de Fedora, l’équipe ne donnant pas plus de précisions pour l’instant. Le support d’IBT signifierait alors celui d’Intel CET au grand complet, pour les processeurs Intel et AMD compatibles.
Il est très probable que ce travail de fond serve largement la communauté open source une fois Fedora 45 (ou 46 ?) disponible. On peut s’attendre à ce que la plupart des distributions emboitent le pas à Fedora, mais le système est habitué à être un précurseur.
La prochaine version de la distribution Linux devrait activer par défaut un important mécanisme de sécurité, la Shadow Stack. L’équipe effectue actuellement un gros travail préparatoire, qui pourrait largement débroussailler le terrain pour les autres systèmes Linux. Accrochez-vous un peu, on vous explique.
D’abord, qu’est-ce que la Shadow Stack ? Il s’agit d’une protection initialement créée par Intel en 2016 mais qui n’est réellement arrivée sur le marché qu’en 2020 avec la génération Tiger Lake. Elle fait partie d’une architecture nommée Intel CET (Control-Flow Enforcement Technology), qu’AMD a également reprise à partir de la génération Zen 3 de ses processeurs.
Le principe de la Shadow Stack (ou pile fantôme) est assez technique. Le processeur dispose en permanence d’une seconde pile d’exécution (call stack) en mémoire. Elle est cachée, isolée et protégée en écriture. Lorsqu’une instruction d’appel (CALL) survient, l’adresse de retour est ajoutée sur les deux piles. Quand l’instruction RET (RETURN) – qui sert à terminer l’exécution d’une fonction – survient, le processeur compare les deux piles : s’il y a correspondance des deux adresses de retour, l’opération se poursuit, dans le cas contraire le processeur déclenche une erreur (exception de protection de flux de contrôle). Cette erreur interrompt immédiatement le processus.
Il s’agit d’une fonction de sécurité, car en interrompant brutalement l’opération, le processeur empêche un pirate d’avancer dans son attaque. La Shadow Stack a été créée pour combattre les attaques de type ROP (return-oriented programming), qui peuvent mener à la prise de contrôle de la pile d’exécution. Elles peuvent également contourner des protections plus anciennes comme ASLR (Address Space Layout Randomization).
Ce que propose l’équipe de Fedora, c’est d’activer cette protection sur l’ensemble du système sur les configurations x86_64. Car il s’agit bien pour l’instant encore d’une proposition, même si elle a de très fortes chances d’être acceptée au vu de son statut avancé. Si elle ne passait finalement pas la validation, elle serait programmée pour Fedora 46 au printemps prochain.
Dans la fiche dédiée, on peut lire que le gros avantage de la Shadow Stack est son impact quasi nul sur les performances, contrairement aux solutions logicielles de contrôle d’intégrité du flux d’exécution. Le surcoût d’exécution est jugé négligeable et imperceptible sur la grande majorité des charges de travail, permettant en échange une élévation générale du niveau de sécurité.
Une activation générale de cette pile fantôme suppose toutefois des adaptations profondes. Il faut notamment que les compilateurs GCC, Clang et rustc soient prêts, ce qui est a priori le cas désormais. Le reste dépend surtout d’un long travail préparatoire commencé il y a des années, la majorité des paquets du dépôt principal possédant déjà les annotations ELF requises, en plus de certaines options compilées à la compilation depuis 2018. Le support de la bibliothèque glibc est également marqué comme prêt.
Sur un plan purement technique, Fedora n’est pas la première distribution à supporter la Shadow Stack. Sa prise en charge dans le noyau Linux remonte à la version 6.6 de 2023. Plusieurs distributions – dont Arch Linux, Ubuntu et Debian – compilent déjà une grande partie de leurs paquets avec l’option liée (-fcf-protection) de GCC/Clang.
Alors, en quoi la démarche de Fedora est-elle novatrice ? Parce qu’elle renverse la vapeur : on parle cette fois d’une activation générale et par défaut. Tout processus éligible bascule automatiquement sur la pile fantôme à son lancement, sans intervention de l’utilisateur. Ce changement a notamment nécessité un travail d’audit et de correction pour les binaires incompatibles, comme les routines en assembleur manuscrit, la chaine d’outils Rust ou encore les moteurs de compilation Just-in-time dans les navigateurs.
Pour ces derniers justement, l’équipe de Fedora note que Chrome et Firefox ne sont pas encore compatibles. Cependant, le mécanisme d’activation a été pensé avec cette limitation en tête et contient un processus de « dégradation élégante » (graceful fallback). En clair, si une application charge au démarrage un objet ELF ne disposant pas du marquage SHSTK (pour Shadow Stack), la glibc désactive silencieusement la pile fantôme pour ce processus unique, sans interrompre son exécution.
Précisons enfin que la Shadow Stack n’est que la première moitié de l’architecture Intel CET. L’autre partie se nomme IBT, pour Indirect Branch Tracking. Sa mission est de contrer un autre type d’exploitation, basé sur la programmation orientée saut ou appel indirect (JOP/COP) et qui peut mener, là encore, à une attaque de type ROP. Le travail réalisé sur la Shadow Stack préparera donc le terrain pour la prise en charge d’IBT dans une version « ultérieure » de Fedora, l’équipe ne donnant pas plus de précisions pour l’instant. Le support d’IBT signifierait alors celui d’Intel CET au grand complet, pour les processeurs Intel et AMD compatibles.
Il est très probable que ce travail de fond serve largement la communauté open source une fois Fedora 45 (ou 46 ?) disponible. On peut s’attendre à ce que la plupart des distributions emboitent le pas à Fedora, mais le système est habitué à être un précurseur.
Il y a décidément quelque chose qui cloche avec iCloud+. Le bouquet de services payants d’Apple promet de renforcer la confidentialité des internautes, notamment grâce au Relais privé. Mais des chercheurs en sécurité montrent que cette fonction peut faire fuiter l’adresse IP réelle des utilisateurs dans certains cas.
La fonction Relais privé iCloud est censée masquer l’adresse IP de l’internaute. Les requêtes sont redirigées via deux relais distincts : le premier connait l’adresse IP mais pas le site web consulté, le second connait le site web consulté mais pas l’adresse IP. Aucun ne possède toutes les informations permettant d’identifier l’utilisateur et de connaitre les sites visités.
Relais privé, réservé aux abonnés payants iCloud+, n’est pas un VPN au sens classique du terme. La fonction protège la navigation web dans Safari en masquant l’adresse IP et en chiffrant les requêtes DNS. Les VPN redirigent tout le trafic de l’appareil au niveau du système d’exploitation, pour toutes les applications. Les fuites dont il est question aujourd’hui « n’affectent pas les VPN », confirme le chercheur en sécurité Tommy Mysk.
Avec un autre chercheur, Talal Haj Bakry, ils tirent justement la sonnette d’alarme : certaines requêtes générées par WebKit, le moteur de Safari, échappent au mécanisme de protection de Relais privé et des fonctions de proxy pour partir directement de l’appareil. Un site ou un serveur distant est donc en mesure de voir l’adresse IP réelle de l’utilisateur, malgré l’activation du relais.
Trois fonctions de WebKit sont concernées. D’abord, des vérifications liées aux clés d’accès (passkeys) passent par le service système WebAuthn d’Apple (depuis iOS 18.0), et non par le chemin réseau proxy du navigateur. Ensuite, WebKit ouvrirait directement les connexions HTTP/3/QUIC utilisées par WebTransport (depuis iOS 26.4) sans appliquer le proxy. Le serveur WebTransport peut dès lors « voir » la véritable adresse IP.
Enfin, le dernier souci ne concerne pas l’adresse IP, mais le DNS. La résolution d’un nom de domaine à l’avance (DNS prefetching, depuis iOS 26.0) est réalisée directement depuis l’appareil au lieu de passer par le proxy. Cela laisse fuiter les serveurs DNS réellement utilisés par le terminal.
Pour prouver leur découverte, les deux chercheurs ont mis en ligne un site web capable d’identifier ces fuites et de révéler l’adresse IP réelle d’un internaute, y compris lors de l’utilisation du Relais privé iCloud. « Puisque la requête est émise par le service d’identification du système d’exploitation plutôt que par Safari, elle n’emprunte jamais le chemin proxy de Relais privé », expliquent-ils. « Dans tous les cas, le serveur de destination voit l’adresse IP réelle de l’appareil ».
Signalons que la fuite d’informations est également effective sur macOS avec Safari, et tous les navigateurs tiers reprenant ce moteur.
Cette découverte remet sérieusement en cause l’efficacité de la fonction iCloud+, et pose aussi problème aux navigateurs basés sur WebKit. Le moteur est obligatoire sous le capot des navigateurs alternatifs distribués dans l’App Store ; même si en Europe, le DMA permet en théorie à un éditeur d’utiliser un autre moteur, dans les faits aucun ne l’a encore fait.
Les chercheurs ont ainsi constaté que ces failles touchaient non seulement Safari, mais également au moins un navigateur Tor sur iOS, Onion Browser. Or, Tor est précisément conçu pour anonymiser le trafic en le faisant circuler dans une succession de relais situés dans différents pays. Ces nouvelles fuites peuvent donc, dans certains cas, exposer l’adresse IP réelle de l’utilisateur.
Mysk explique ne pas avoir contacté Apple en amont de la publication (contrairement à Tor et Onion Browser informés) : « Dans un monde idéal, nous aurions signalé les problèmes à Apple, ils les valideraient et publieraient un correctif rapidement. Malheureusement, sur la base de notre expérience passée avec Apple, signaler ce problème impliquerait des mois de retard, des communications incohérentes et, dans certains cas, un déni total de l’impact du problème ».
Selon un message sur X de Psylo – le navigateur axé sur la vie privée développé par ce même Tommy Mysk –, Apple aurait reproduit ces failles et « prévoit de traiter le problème », avec une correction prévue pour l’automne 2026. Cela fait suite à l’envoi d’un rapport à Apple après la publication du billet de blog. Apple confirme à 404 Media enquêter sur le sujet, mais sans plus de détails.
Espérons que ce soit plus rapide que pour boucher la vulnérabilité de « Masquer mon adresse email », là aussi une fonction iCloud+, qui permettait de retrouver l’adresse email originale. Apple a mis plus d’un an à la corriger.
Il y a décidément quelque chose qui cloche avec iCloud+. Le bouquet de services payants d’Apple promet de renforcer la confidentialité des internautes, notamment grâce au Relais privé. Mais des chercheurs en sécurité montrent que cette fonction peut faire fuiter l’adresse IP réelle des utilisateurs dans certains cas.
La fonction Relais privé iCloud est censée masquer l’adresse IP de l’internaute. Les requêtes sont redirigées via deux relais distincts : le premier connait l’adresse IP mais pas le site web consulté, le second connait le site web consulté mais pas l’adresse IP. Aucun ne possède toutes les informations permettant d’identifier l’utilisateur et de connaitre les sites visités.
Relais privé, réservé aux abonnés payants iCloud+, n’est pas un VPN au sens classique du terme. La fonction protège la navigation web dans Safari en masquant l’adresse IP et en chiffrant les requêtes DNS. Les VPN redirigent tout le trafic de l’appareil au niveau du système d’exploitation, pour toutes les applications. Les fuites dont il est question aujourd’hui « n’affectent pas les VPN », confirme le chercheur en sécurité Tommy Mysk.
Avec un autre chercheur, Talal Haj Bakry, ils tirent justement la sonnette d’alarme : certaines requêtes générées par WebKit, le moteur de Safari, échappent au mécanisme de protection de Relais privé et des fonctions de proxy pour partir directement de l’appareil. Un site ou un serveur distant est donc en mesure de voir l’adresse IP réelle de l’utilisateur, malgré l’activation du relais.
Trois fonctions de WebKit sont concernées. D’abord, des vérifications liées aux clés d’accès (passkeys) passent par le service système WebAuthn d’Apple (depuis iOS 18.0), et non par le chemin réseau proxy du navigateur. Ensuite, WebKit ouvrirait directement les connexions HTTP/3/QUIC utilisées par WebTransport (depuis iOS 26.4) sans appliquer le proxy. Le serveur WebTransport peut dès lors « voir » la véritable adresse IP.
Enfin, le dernier souci ne concerne pas l’adresse IP, mais le DNS. La résolution d’un nom de domaine à l’avance (DNS prefetching, depuis iOS 26.0) est réalisée directement depuis l’appareil au lieu de passer par le proxy. Cela laisse fuiter les serveurs DNS réellement utilisés par le terminal.
Pour prouver leur découverte, les deux chercheurs ont mis en ligne un site web capable d’identifier ces fuites et de révéler l’adresse IP réelle d’un internaute, y compris lors de l’utilisation du Relais privé iCloud. « Puisque la requête est émise par le service d’identification du système d’exploitation plutôt que par Safari, elle n’emprunte jamais le chemin proxy de Relais privé », expliquent-ils. « Dans tous les cas, le serveur de destination voit l’adresse IP réelle de l’appareil ».
Signalons que la fuite d’informations est également effective sur macOS avec Safari, et tous les navigateurs tiers reprenant ce moteur.
Cette découverte remet sérieusement en cause l’efficacité de la fonction iCloud+, et pose aussi problème aux navigateurs basés sur WebKit. Le moteur est obligatoire sous le capot des navigateurs alternatifs distribués dans l’App Store ; même si en Europe, le DMA permet en théorie à un éditeur d’utiliser un autre moteur, dans les faits aucun ne l’a encore fait.
Les chercheurs ont ainsi constaté que ces failles touchaient non seulement Safari, mais également au moins un navigateur Tor sur iOS, Onion Browser. Or, Tor est précisément conçu pour anonymiser le trafic en le faisant circuler dans une succession de relais situés dans différents pays. Ces nouvelles fuites peuvent donc, dans certains cas, exposer l’adresse IP réelle de l’utilisateur.
Mysk explique ne pas avoir contacté Apple en amont de la publication (contrairement à Tor et Onion Browser informés) : « Dans un monde idéal, nous aurions signalé les problèmes à Apple, ils les valideraient et publieraient un correctif rapidement. Malheureusement, sur la base de notre expérience passée avec Apple, signaler ce problème impliquerait des mois de retard, des communications incohérentes et, dans certains cas, un déni total de l’impact du problème ».
Selon un message sur X de Psylo – le navigateur axé sur la vie privée développé par ce même Tommy Mysk –, Apple aurait reproduit ces failles et « prévoit de traiter le problème », avec une correction prévue pour l’automne 2026. Cela fait suite à l’envoi d’un rapport à Apple après la publication du billet de blog. Apple confirme à 404 Media enquêter sur le sujet, mais sans plus de détails.
Espérons que ce soit plus rapide que pour boucher la vulnérabilité de « Masquer mon adresse email », là aussi une fonction iCloud+, qui permettait de retrouver l’adresse email originale. Apple a mis plus d’un an à la corriger.
Un « nouveau » malware s’est propagé dans des centaines de paquets sur npm, dont plusieurs très populaires. Il s’agit une nouvelle fois d’une attaque contre la chaine d’approvisionnement ayant réussi à contourner toutes les mesures de sécurité. Dans le code, l’ombre de Shai-Hulud plane, tandis que le point de défaillance initial n’est pas clair.
Le nouveau venu se nomme ChainDrop. Selon les analyses faites sur son code, il est basé sur Shai-Hulud (en référence au ver des sables dans l’univers de Dune), qui avait déjà fait un carnage dans NPM en septembre 2025. Il en reprend les principales caractéristiques, dont son aspect auto-répliquant et le vol de nombreuses informations.
On pourrait croire que l’attaque de l’automne 2025 avait provoqué une vague d’actions pour verrouiller les comptes et inciter à la plus extrême prudence. C’est en fait le cas, mais le ou les pirates s’y sont pris autrement.
La compromission a été réalisée en poussant directement des fichiers malveillants sur la branche principale des dépôts, puis en créant immédiatement de nouvelles versions. Conséquence, ces versions vérolées ont été publiées sur NPM avec une provenance valide signée par GitHub Actions. Les contrôles de provenance npm, censés garantir qu’un package provient bien d’un flux légitime, n’ont ainsi rien pu détecter car les pirates ont justement réussi à le détourner.
868 paquets, répartis sur 1 381 versions, ont pu être contaminés par ce biais. Le pouvoir de nuisance est réel, car beaucoup d’entre eux sont populaires, l’ensemble de la liste cumulant en moyenne deux milliards de téléchargements par mois.
Tout est parti de la compromission du compte du mainteneur du paquet keyv (Jared Wray), qui représente à lui seul plus de 600 millions de téléchargements par mois. S’en sont suivies les contaminations de flat-cache, file-entry-cache, cacheable-request, cacheable ou encore cache-manager, autant de projets spécialisés dans la gestion des caches pour de multiples cas de figure.
Une fois les paquets contaminés, la propagation s’est faite rapidement, atteignant des entreprises comme Deliveroo, Ornikar, OneReach, Picsart, Qlik ou ServiceTitan.
Les chercheurs de l’entreprise de sécurité Aikido se sont penchés sur ChainDrop. Dans leur billet publié le 4 aout, ils décrivent ainsi deux composants retrouvés dans les paquets contaminés, comme c’est souvent le cas.
Le premier est un dropper nommé setup.mjs. Un dropper est un code chargé d’installer un ou plusieurs composants malveillants sur le système. Il sert de vecteur d’installation pour la charge utile (payload) et remplit plusieurs missions : déposer l’exécutable sur le disque, l’extraire depuis des données intégrées dans le programme ou le télécharger depuis un serveur distant, l’exécuter en mémoire ou encore mettre en place des mécanismes de persistance avant de lancer la charge utile. Selon les chercheurs, setup.mjs est un dropper fortement obfusqué récupérant le runtime JavaScript Bun depuis son dépôt GitHub pour pouvoir exécuter ensuite la charge.
Adform, une importante agence de publicité en ligne qui se vante d’avoir comme clients de nombreux médias états-uniens mais aussi Spotify, a été piratée. Son script, appelé par tous ses sites clients, a été modifié pour substituer les adresses des portefeuilles de cryptomonnaies des utilisateurs.
L’agence de publicité en ligne Adform a été attaquée et l’un de ses scripts Javascript utilisé par ses clients pour ajouter de la pub sur leurs sites a été remplacé par un code substituant les adresses de portefeuille de crypto-monnaies copiées dans le presse-papiers des visiteurs par celles du pirate.
Adform est l’une des plus importantes agences de pub en ligne européennes. Elle propose tout un éventail de services dans ce domaine : demand-side platform (DSP) ou « plateforme d’achat », supply-side platform (SSP) ou « plateforme de vente », mais aussi des serveurs pour héberger les publicités et bien sûr des outils de monitoring.
Sur son site, l’entreprise revendique de nombreux clients très connus dans le milieu des médias comme dans celui du numérique. Ainsi, les médias américains Time, CNN, Bloomberg, CBS ou encore la plateforme de musique Spotify, la plateforme de clips Xite, les plateformes Disney+ et Paramount+, l’autre agence publicitaire Xandr ou encore les entreprises EDF, Deutsche Bahn ou Deutsche Telekom en font partie :
Le 31 juillet dernier, le chercheur en sécurité Kevin Beaumont a décrit dans un post Medium le fonctionnement du script qui compromettait les systèmes des utilisateurs des sites clients d’Adform. « Si vous visitez example.com et que ce site utilise Adform, example.com compromettra votre appareil », expliquait Kevin Beaumont avant que l’entreprise ait supprimé le code malveillant.
Le code utilise des expressions régulières pour remplacer tous les portefeuilles Bitcoin, Ethereum et TRX présents dans le presse-papiers par ceux possédés par des comptes du pirate. « Même si vous remarquez que l’adresse est erronée et que vous recopiez le portefeuille, il continue de la remplacer », explique Kevin Beaumont.
En plus de cette substitution de portefeuilles crypto, d’autres scripts récupéraient l’adresse IP de l’utilisateur, le site d’où il venait et l’URL du site visité. « Il semblerait qu’Adform soit au courant, ou que le pirate se soit rendu compte qu’il avait été démasqué, car le code malveillant semble disparaître au moment même où j’écris ces lignes », ajoutait le chercheur indépendant.
Et en effet, le même jour, Adform publiait un communiqué sur son site expliquant : « Le 27 juillet 2026, Adform a détecté une activité suspecte et a immédiatement ouvert une enquête conformément à ses procédures de gestion des incidents. Une fois la menace de cybersécurité confirmée, nous avons maîtrisé l’incident, supprimé le code malveillant et pris des mesures supplémentaires pour protéger les visiteurs du site web, nos clients et la plateforme Adform ».
C’est aussi le 27 juillet qu’un autre chercheur en sécurité, Maxx Maas, postait sur Mastodon la découverte du malware ainsi que le code Javascript remplaçant les portefeuilles crypto.
Dans son communiqué, Adform reconnait que le code malveillant avait pour but de « remplacer l’adresse d’un portefeuille de cryptomonnaies copiée dans le presse-papiers d’un utilisateur par une autre adresse ». Elle précise qu’à sa connaissance, « ce code n’était pas conçu pour installer un logiciel sur l’appareil d’un utilisateur ni pour s’y implanter de manière persistante. Il ne fonctionnait que tant qu’une page web affectée restait ouverte ».
De même, elle affirme n’avoir trouvé « aucune preuve indiquant que le code malveillant ait transmis les adresses IP des utilisateurs ou des informations concernant les sites web qu’ils ont consultés à un tiers. L’analyse technique suggère qu’une telle transmission aurait pu être possible, et cet aspect fait toujours l’objet d’une enquête ».
Elle reconnait que l’attaque a pu toucher les internautes qui ont visité « un site web utilisant la technologie Adform concernée, le 27 juillet 2026 ». Elle ajoute que « les navigateurs pouvant stocker temporairement le code d’un site web, nous recommandons aux personnes ayant consulté un site web concerné de vider le cache de leur navigateur par mesure de précaution ».
Adform assure avoir informé ses clients concernés ainsi que les autorités compétentes. Mais l’entreprise ne donne aucune information sur le nombre de sites concernés ni lesquels, le nombre de visiteurs exposés et la manière dont le pirate a pu accéder à sa chaine d’approvisionnement.
« Si vous aviez besoin d’une raison supplémentaire pour utiliser un bloqueur de publicités, la voici. En bloquant les publicités, vous pouvez empêcher le suivi omniprésent, la surveillance et, oui, même les logiciels malveillants, de s’introduire dans votre ordinateur », réagit le journaliste de TechCrunch Zack Whittaker dans sa newsletter personnelle.
Adform, une importante agence de publicité en ligne qui se vante d’avoir comme clients de nombreux médias états-uniens mais aussi Spotify, a été piratée. Son script, appelé par tous ses sites clients, a été modifié pour substituer les adresses des portefeuilles de cryptomonnaies des utilisateurs.
L’agence de publicité en ligne Adform a été attaquée et l’un de ses scripts Javascript utilisé par ses clients pour ajouter de la pub sur leurs sites a été remplacé par un code substituant les adresses de portefeuille de crypto-monnaies copiées dans le presse-papiers des visiteurs par celles du pirate.
Adform est l’une des plus importantes agences de pub en ligne européennes. Elle propose tout un éventail de services dans ce domaine : demand-side platform (DSP) ou « plateforme d’achat », supply-side platform (SSP) ou « plateforme de vente », mais aussi des serveurs pour héberger les publicités et bien sûr des outils de monitoring.
Sur son site, l’entreprise revendique de nombreux clients très connus dans le milieu des médias comme dans celui du numérique. Ainsi, les médias américains Time, CNN, Bloomberg, CBS ou encore la plateforme de musique Spotify, la plateforme de clips Xite, les plateformes Disney+ et Paramount+, l’autre agence publicitaire Xandr ou encore les entreprises EDF, Deutsche Bahn ou Deutsche Telekom en font partie :
Le 31 juillet dernier, le chercheur en sécurité Kevin Beaumont a décrit dans un post Medium le fonctionnement du script qui compromettait les systèmes des utilisateurs des sites clients d’Adform. « Si vous visitez example.com et que ce site utilise Adform, example.com compromettra votre appareil », expliquait Kevin Beaumont avant que l’entreprise ait supprimé le code malveillant.
Le code utilise des expressions régulières pour remplacer tous les portefeuilles Bitcoin, Ethereum et TRX présents dans le presse-papiers par ceux possédés par des comptes du pirate. « Même si vous remarquez que l’adresse est erronée et que vous recopiez le portefeuille, il continue de la remplacer », explique Kevin Beaumont.
En plus de cette substitution de portefeuilles crypto, d’autres scripts récupéraient l’adresse IP de l’utilisateur, le site d’où il venait et l’URL du site visité. « Il semblerait qu’Adform soit au courant, ou que le pirate se soit rendu compte qu’il avait été démasqué, car le code malveillant semble disparaître au moment même où j’écris ces lignes », ajoutait le chercheur indépendant.
Et en effet, le même jour, Adform publiait un communiqué sur son site expliquant : « Le 27 juillet 2026, Adform a détecté une activité suspecte et a immédiatement ouvert une enquête conformément à ses procédures de gestion des incidents. Une fois la menace de cybersécurité confirmée, nous avons maîtrisé l’incident, supprimé le code malveillant et pris des mesures supplémentaires pour protéger les visiteurs du site web, nos clients et la plateforme Adform ».
C’est aussi le 27 juillet qu’un autre chercheur en sécurité, Maxx Maas, postait sur Mastodon la découverte du malware ainsi que le code Javascript remplaçant les portefeuilles crypto.
Dans son communiqué, Adform reconnait que le code malveillant avait pour but de « remplacer l’adresse d’un portefeuille de cryptomonnaies copiée dans le presse-papiers d’un utilisateur par une autre adresse ». Elle précise qu’à sa connaissance, « ce code n’était pas conçu pour installer un logiciel sur l’appareil d’un utilisateur ni pour s’y implanter de manière persistante. Il ne fonctionnait que tant qu’une page web affectée restait ouverte ».
De même, elle affirme n’avoir trouvé « aucune preuve indiquant que le code malveillant ait transmis les adresses IP des utilisateurs ou des informations concernant les sites web qu’ils ont consultés à un tiers. L’analyse technique suggère qu’une telle transmission aurait pu être possible, et cet aspect fait toujours l’objet d’une enquête ».
Elle reconnait que l’attaque a pu toucher les internautes qui ont visité « un site web utilisant la technologie Adform concernée, le 27 juillet 2026 ». Elle ajoute que « les navigateurs pouvant stocker temporairement le code d’un site web, nous recommandons aux personnes ayant consulté un site web concerné de vider le cache de leur navigateur par mesure de précaution ».
Adform assure avoir informé ses clients concernés ainsi que les autorités compétentes. Mais l’entreprise ne donne aucune information sur le nombre de sites concernés ni lesquels, le nombre de visiteurs exposés et la manière dont le pirate a pu accéder à sa chaine d’approvisionnement.
« Si vous aviez besoin d’une raison supplémentaire pour utiliser un bloqueur de publicités, la voici. En bloquant les publicités, vous pouvez empêcher le suivi omniprésent, la surveillance et, oui, même les logiciels malveillants, de s’introduire dans votre ordinateur », réagit le journaliste de TechCrunch Zack Whittaker dans sa newsletter personnelle.
Pour la deuxième fois en deux mois, l’équipe de la distribution Arch Linux a dû intervenir dans le dépôt AUR (Arch User Repository). En cause, une nouvelle vague de prises de contrôle sur des paquets existants pour leur injecter du code malveillant.
La décision a été annoncée initialement le 30 juillet par le contributeur Robin Candau. Dans son message, il indiquait que la solution était temporaire, le temps qu’une solution soit trouvée.
Mais de quoi parle-t-on ? D’une désactivation de la fonction d’adoption, pour empêcher toute personne « d’adopter » un paquet plus ou moins abandonné du dépôt AUR pour contribuer à nouveau à son code. Ce processus avait été détourné en juin et avait abouti à l’insertion de code malveillant dans plus de 1 600 paquets du dépôt AUR.
Le gros problème dans la campagne malveillante de juin était le nombre élevé de paquets concernés. Même avec des actions rapides, il était impossible de s’assurer que personne n’avait reçu les versions contaminées via des mises à jour. Ce qui était tout l’intérêt pour les pirates et qui rend les attaques par compromission de la chaine d’approvisionnement aussi efficaces.
Dans la nouvelle attaque, comme relevé notamment par Bleeping Computer, l’ampleur semble nettement moindre, mais on ne connait pas encore le nombre exact de paquets compromis. Sur les listes officielles, on trouve des listes compilant une trentaine de paquets compromis, tandis que d’autres sur Reddit évoquent plus de 200 paquets.
Si l’on en croit l’analyse technique publiée par l’Independent Federated Intelligence Network (IFIN), la campagne a débuté le 29 juillet avec le paquet « openconnect-sso ». Les similitudes avec la campagne de juin sont évidentes, dont l’usage du réseau Tor pour l’hébergement de l’infrastructure ou l’emploi d’un fichier ELF précompilé et obscurci.
Nouveau record pour le bug bounty de Microsoft. Sur le dernier exercice annuel, le programme a distribué 20 millions de dollars de récompenses à 562 chercheurs en sécurité répartis entre 64 pays. La détection de bugs et de failles s’est accélérée sur les six derniers mois grâce à l’IA.
Le programme de chasse aux bugs de Microsoft a donc fait le plein entre le 1ᵉʳ juillet 2025 et le 30 juin 2026. Durant l’exercice précédent, l’éditeur a distribué 3 millions de dollars supplémentaires à 218 chercheurs de plus. 2 531 rapports de bugs ont été éligibles au bug bounty pendant l’exercice.
« Cette année a été marquée par une forte croissance des programmes de récompenses de Microsoft pour la découverte de vulnérabilités, ce qui nous a permis de distinguer davantage de chercheurs et de failles de sécurité à fort impact », explique l’entreprise.
L’an dernier, Microsoft a agrandi son programme pour récompenser les « recherches importantes » qui vont au-delà du périmètre classique des primes aux failles : logiciels open-source, composants tiers, services cloud. Un élargissement qui a permis à l’entreprise de recevoir « plus de 300 signalements supplémentaires et versé plus de 800 000 dollars de récompenses pour des vulnérabilités qui n’auraient auparavant pas été admissibles. »
Dans son bilan, Microsoft ajoute avoir également « constaté une hausse notable du nombre de signalements au cours du second semestre, qui témoigne à la fois de la forte mobilisation de la communauté des chercheurs et de l’utilisation croissante de l’IA dans la recherche en sécurité. »
Les modèles IA se montrent en effet plutôt doués pour fouiner dans le code logiciel afin d’y repérer des vulnérabilités, et c’est encore plus le cas des modèles spécialisés. On assiste actuellement à une véritable course aux correctifs de la part non seulement de Microsoft, mais aussi d’Apple et de tous les autres constructeurs et éditeurs : leurs mises à jour récentes regorgent en effet de correctifs de sécurité.
Apple a même dû mettre en place un plafond et un délai de carence pour les signalements, afin d’éviter de se noyer dans les rapports de bugs générés par IA.
Nouveau record pour le bug bounty de Microsoft. Sur le dernier exercice annuel, le programme a distribué 20 millions de dollars de récompenses à 562 chercheurs en sécurité répartis entre 64 pays. La détection de bugs et de failles s’est accélérée sur les six derniers mois grâce à l’IA.
Le programme de chasse aux bugs de Microsoft a donc fait le plein entre le 1ᵉʳ juillet 2025 et le 30 juin 2026. Durant l’exercice précédent, l’éditeur a distribué 3 millions de dollars supplémentaires à 218 chercheurs de plus. 2 531 rapports de bugs ont été éligibles au bug bounty pendant l’exercice.
« Cette année a été marquée par une forte croissance des programmes de récompenses de Microsoft pour la découverte de vulnérabilités, ce qui nous a permis de distinguer davantage de chercheurs et de failles de sécurité à fort impact », explique l’entreprise.
L’an dernier, Microsoft a agrandi son programme pour récompenser les « recherches importantes » qui vont au-delà du périmètre classique des primes aux failles : logiciels open-source, composants tiers, services cloud. Un élargissement qui a permis à l’entreprise de recevoir « plus de 300 signalements supplémentaires et versé plus de 800 000 dollars de récompenses pour des vulnérabilités qui n’auraient auparavant pas été admissibles. »
Dans son bilan, Microsoft ajoute avoir également « constaté une hausse notable du nombre de signalements au cours du second semestre, qui témoigne à la fois de la forte mobilisation de la communauté des chercheurs et de l’utilisation croissante de l’IA dans la recherche en sécurité. »
Les modèles IA se montrent en effet plutôt doués pour fouiner dans le code logiciel afin d’y repérer des vulnérabilités, et c’est encore plus le cas des modèles spécialisés. On assiste actuellement à une véritable course aux correctifs de la part non seulement de Microsoft, mais aussi d’Apple et de tous les autres constructeurs et éditeurs : leurs mises à jour récentes regorgent en effet de correctifs de sécurité.
Apple a même dû mettre en place un plafond et un délai de carence pour les signalements, afin d’éviter de se noyer dans les rapports de bugs générés par IA.
À quelques semaines d’écart, LG et Samsung ont annoncé la suspension ou l’interdiction sur leurs plateformes de téléviseurs connectés d’applications intégrant des systèmes de proxy résidentiel. Il en existe des utilisations légitimes, mais le manque de transparence de ces SDK, leur activation à distance et la difficulté pour les utilisateurs de comprendre ce à quoi ils consentent posent un vrai problème de confiance.
Début juillet, la société spécialisée en sécurité informatique Spur révélait que 42 % des applications proposées au téléchargement sur webOS – la plateforme smart TV de LG – intégraient des SDK permettant de transformer les téléviseurs connectés du constructeur en nœuds de sortie de proxy résidentiel. La même étude indiquait qu’au moins un quart des téléviseurs de Samsung fonctionnant sous Tizen embarquaient les mêmes composants.
Une fois la télé transformée en nœud de sortie proxy résidentiel, l’IP de l’utilisateur est utilisée par des services pour accéder à Internet… avec tous les risques que cela entraine, surtout en cas d’IP fixe. L’adresse peut être signalée en cas de scraping massif, de contournement de blocage, ou encore si elle sert de courroie de transmission à une activité frauduleuse. Le propriétaire de la télévision pourrait alors avoir des problèmes, sans oublier qu’un tel proxy peut générer de la latence sur son accès internet.
La branche américaine de LG a annoncé à KrebsOnSecurity que le constructeur travaillait avec les développeurs tiers au retrait dans leurs applications de cette fonction de proxy résidentiel. Et les développeurs qui s’y refuseront subiront une suspension de leurs applications. « Un réseau de proxy résidentiel n’est pas un usage prévu pour les téléviseurs connectés LG », déclarait le 21 juillet John Taylor, vice-président de LG Electronics USA.
L’examen des applications était déjà « bien avancé », assure le dirigeant, et « LG continuera de renforcer son processus d’évaluation des applications soumises par les développeurs, y compris celles qui intègrent des SDK de proxy résidentiel ». Au passage, LG file un mauvais coton en ce moment, après la controverse sur l’antivirus McAfee proposé de manière agressive aux utilisateurs de certains de ses moniteurs PC.
Une autre enquête, réalisée cette fois par Mnemonic, explique que des jeux distribués par la boutique de Samsung pour ses smart TV contiennent le kit de développement de Bright Data, une société israélienne qui commercialise des proxys résidentiels donnant accès à des millions de réseaux dans le monde.
Il existe des utilisations légitimes pour le proxy résidentiel, par exemple pour vérifier l’efficacité de dispositifs de censure ou de blocage géographique (voir si certains contenus sont accessibles depuis différents endroits), collecter des données publiques pour comparer des prix, ou encore pour contrôler la conformité de publicités (des marques peuvent vérifier que leurs pubs apparaissent correctement sans être associées à des contenus problématiques). Les proxys résidentiels sont prisés car ils ressemblent à du trafic humain « normal ».
Les téléviseurs enrôlés comme nœuds de sortie via Bright Data peuvent être utilisés pour télécharger des montagnes de données publiques sur le web depuis plusieurs sources à la fois pour éviter les protections anti-scraping. Mnemonic a observé du scraping de profils LinkedIn à grande échelle, ainsi que de la collecte de données pour entraîner des IA. Ce SDK, qui est aussi majoritairement présent dans les apps de proxy résidentiel distribuées par LG, veut pourtant montrer patte blanche.
Bright Data l’affirme à KrebsOnSecurity : « Chaque utilisateur accepte explicitement de participer via un écran de consentement et reçoit une contrepartie en retour ; chaque client est vérifié, et nos pratiques ont désormais fait l’objet d’un deuxième audit indépendant par PwC. » L’entreprise poursuit : « Nous restons attachés à un internet ouvert et transparent, où les entreprises légitimes, les chercheurs et les institutions peuvent accéder de manière responsable aux données relevant du domaine public. »
L’architecture de ces applications, comme la mise en avant de certaines d’entre elles par Samsung dans sa boutique, soulève des questions. Mnemonic indique que tout est « officiel » : le SDK est « dormant » tant que le téléspectateur n’a pas donné son accord… mais les apps ne sont que des coquilles vides qui chargent ensuite le vrai code depuis un serveur distant. Ce que Samsung ou LG vérifient dans leurs boutiques n’est donc pas ce qui se lance sur la télé.
Les jeux Pac-Man et 2048 Football Cup proposent par exemple une expérience « sans pub », pour peu que l’utilisateur accepte que son téléviseur télécharge des données publiques depuis internet en utilisant l’adresse IP de l’appareil. « Si c’est gratuit, c’est vous le produit » prend ici tout son sens.
Emboîtant le pas de son rival, Samsung a donc commencé à restreindre l’apparition de nouvelles apps intégrant de telles fonctions sur sa plateforme Tizen. « Nous mettons actuellement en place des politiques strictes à l’échelle de la plateforme pour les développeurs, interdisant explicitement les SDK de proxy résidentiel, et nous travaillons à identifier et supprimer toutes les applications actuellement disponibles dans notre boutique qui contiennent ces composants », ajoute un porte-parole de l’entreprise à TechCrunch.
Il y a deux ans déjà, Orange alertait sur les proxys résidentiels qui « représentent une menace croissante dans le cyberespace, car ils sont fréquemment utilisés par des groupes d’attaquants qui ainsi se cachent au sein du trafic légitime, mais aussi agissent de manière légitime […] Pour obtenir une infrastructure pouvant atteindre plusieurs millions d’hôtes, les fournisseurs de proxys résidentiels utilisent des techniques qui peuvent induire en erreur les utilisateurs qui installent des logiciels tiers ».
Le nombre d’adresses IP est un point crucial pour les proxys résidentiels, un déploiement massif des points de sortie est donc primordial : « Ces points de sortie incluent les adresses IP des routeurs domestiques, des ordinateurs personnels, des téléviseurs intelligents et, de plus en plus, des téléphones mobiles utilisant les réseaux 4G et 5G ». Il y a des utilisateurs prêts à louer leur connexion, mais aussi d’autres piratés et tout un dégradé de nuances entre ces deux extrêmes.
Depuis maintenant plusieurs années, une des stratégies des proxys résidentiels « est l’implication d’utilisateurs conscients et volontaires », mais qui ne comprennent pas toujours « l’utilisation finale de leur connexion Internet ». Dans le cas présent, nous y sommes probablement.
Côté développeurs, certains proxys résidentiels proposent une sorte de « PaaS » ou « Proxyware as a service » avec un kit pour intégrer directement et facilement cette fonctionnalité dans leur application.
À quelques semaines d’écart, LG et Samsung ont annoncé la suspension ou l’interdiction sur leurs plateformes de téléviseurs connectés d’applications intégrant des systèmes de proxy résidentiel. Il en existe des utilisations légitimes, mais le manque de transparence de ces SDK, leur activation à distance et la difficulté pour les utilisateurs de comprendre ce à quoi ils consentent posent un vrai problème de confiance.
Début juillet, la société spécialisée en sécurité informatique Spur révélait que 42 % des applications proposées au téléchargement sur webOS – la plateforme smart TV de LG – intégraient des SDK permettant de transformer les téléviseurs connectés du constructeur en nœuds de sortie de proxy résidentiel. La même étude indiquait qu’au moins un quart des téléviseurs de Samsung fonctionnant sous Tizen embarquaient les mêmes composants.
Une fois la télé transformée en nœud de sortie proxy résidentiel, l’IP de l’utilisateur est utilisée par des services pour accéder à Internet… avec tous les risques que cela entraine, surtout en cas d’IP fixe. L’adresse peut être signalée en cas de scraping massif, de contournement de blocage, ou encore si elle sert de courroie de transmission à une activité frauduleuse. Le propriétaire de la télévision pourrait alors avoir des problèmes, sans oublier qu’un tel proxy peut générer de la latence sur son accès internet.
La branche américaine de LG a annoncé à KrebsOnSecurity que le constructeur travaillait avec les développeurs tiers au retrait dans leurs applications de cette fonction de proxy résidentiel. Et les développeurs qui s’y refuseront subiront une suspension de leurs applications. « Un réseau de proxy résidentiel n’est pas un usage prévu pour les téléviseurs connectés LG », déclarait le 21 juillet John Taylor, vice-président de LG Electronics USA.
L’examen des applications était déjà « bien avancé », assure le dirigeant, et « LG continuera de renforcer son processus d’évaluation des applications soumises par les développeurs, y compris celles qui intègrent des SDK de proxy résidentiel ». Au passage, LG file un mauvais coton en ce moment, après la controverse sur l’antivirus McAfee proposé de manière agressive aux utilisateurs de certains de ses moniteurs PC.
Une autre enquête, réalisée cette fois par Mnemonic, explique que des jeux distribués par la boutique de Samsung pour ses smart TV contiennent le kit de développement de Bright Data, une société israélienne qui commercialise des proxys résidentiels donnant accès à des millions de réseaux dans le monde.
Il existe des utilisations légitimes pour le proxy résidentiel, par exemple pour vérifier l’efficacité de dispositifs de censure ou de blocage géographique (voir si certains contenus sont accessibles depuis différents endroits), collecter des données publiques pour comparer des prix, ou encore pour contrôler la conformité de publicités (des marques peuvent vérifier que leurs pubs apparaissent correctement sans être associées à des contenus problématiques). Les proxys résidentiels sont prisés car ils ressemblent à du trafic humain « normal ».
Les téléviseurs enrôlés comme nœuds de sortie via Bright Data peuvent être utilisés pour télécharger des montagnes de données publiques sur le web depuis plusieurs sources à la fois pour éviter les protections anti-scraping. Mnemonic a observé du scraping de profils LinkedIn à grande échelle, ainsi que de la collecte de données pour entraîner des IA. Ce SDK, qui est aussi majoritairement présent dans les apps de proxy résidentiel distribuées par LG, veut pourtant montrer patte blanche.
Bright Data l’affirme à KrebsOnSecurity : « Chaque utilisateur accepte explicitement de participer via un écran de consentement et reçoit une contrepartie en retour ; chaque client est vérifié, et nos pratiques ont désormais fait l’objet d’un deuxième audit indépendant par PwC. » L’entreprise poursuit : « Nous restons attachés à un internet ouvert et transparent, où les entreprises légitimes, les chercheurs et les institutions peuvent accéder de manière responsable aux données relevant du domaine public. »
L’architecture de ces applications, comme la mise en avant de certaines d’entre elles par Samsung dans sa boutique, soulève des questions. Mnemonic indique que tout est « officiel » : le SDK est « dormant » tant que le téléspectateur n’a pas donné son accord… mais les apps ne sont que des coquilles vides qui chargent ensuite le vrai code depuis un serveur distant. Ce que Samsung ou LG vérifient dans leurs boutiques n’est donc pas ce qui se lance sur la télé.
Les jeux Pac-Man et 2048 Football Cup proposent par exemple une expérience « sans pub », pour peu que l’utilisateur accepte que son téléviseur télécharge des données publiques depuis internet en utilisant l’adresse IP de l’appareil. « Si c’est gratuit, c’est vous le produit » prend ici tout son sens.
Emboîtant le pas de son rival, Samsung a donc commencé à restreindre l’apparition de nouvelles apps intégrant de telles fonctions sur sa plateforme Tizen. « Nous mettons actuellement en place des politiques strictes à l’échelle de la plateforme pour les développeurs, interdisant explicitement les SDK de proxy résidentiel, et nous travaillons à identifier et supprimer toutes les applications actuellement disponibles dans notre boutique qui contiennent ces composants », ajoute un porte-parole de l’entreprise à TechCrunch.
Il y a deux ans déjà, Orange alertait sur les proxys résidentiels qui « représentent une menace croissante dans le cyberespace, car ils sont fréquemment utilisés par des groupes d’attaquants qui ainsi se cachent au sein du trafic légitime, mais aussi agissent de manière légitime […] Pour obtenir une infrastructure pouvant atteindre plusieurs millions d’hôtes, les fournisseurs de proxys résidentiels utilisent des techniques qui peuvent induire en erreur les utilisateurs qui installent des logiciels tiers ».
Le nombre d’adresses IP est un point crucial pour les proxys résidentiels, un déploiement massif des points de sortie est donc primordial : « Ces points de sortie incluent les adresses IP des routeurs domestiques, des ordinateurs personnels, des téléviseurs intelligents et, de plus en plus, des téléphones mobiles utilisant les réseaux 4G et 5G ». Il y a des utilisateurs prêts à louer leur connexion, mais aussi d’autres piratés et tout un dégradé de nuances entre ces deux extrêmes.
Depuis maintenant plusieurs années, une des stratégies des proxys résidentiels « est l’implication d’utilisateurs conscients et volontaires », mais qui ne comprennent pas toujours « l’utilisation finale de leur connexion Internet ». Dans le cas présent, nous y sommes probablement.
Côté développeurs, certains proxys résidentiels proposent une sorte de « PaaS » ou « Proxyware as a service » avec un kit pour intégrer directement et facilement cette fonctionnalité dans leur application.
Mauvaise surprise pour des utilisateurs de portefeuilles de bitcoins de Coldcard. Des petits malins ont su reconstituer leurs phrases de récupération, générées par une méthode trop simple. Résultat, plus de 110 millions de dollars dérobés, et un rappel utile : les clés cryptographiques ne valent que si le système qui les crée est réellement imprévisible.
Une erreur de programmation aurait empêché certains wallets du fabricant Coldcard d’utiliser leur générateur matériel de nombres aléatoires pour créer des « seeds », ces phrases de récupération de 12 ou 24 mots. Cette erreur logicielle aurait poussé le générateur de ces portefeuilles à se rabattre sur une méthode reposant sur des données relativement prévisibles (numéro de série de la puce ou encore valeurs liées à l’horloge), explique l’équipe Bitcoin Engineering and Security de Block.
Le 30 juillet, 1 196 adresses ont été entièrement vidées pour un peu plus de 1 082 bitcoins, ce qui représente environ 70 millions de dollars selon les calculs de Galaxy Research. L’opération a été rapide, elle n’a duré en tout et pour tout 41 minutes. Deux autres vagues ont eu lieu par la suite, pour un total de 1 816 BTC, soit 114 millions de dollars.
Les bitcoins ne sont pas stockés dans les wallets Coldcard eux-mêmes, mais sur la blockchain ; le portefeuille physique ne conserve que les clés privées permettant de déplacer les bitcoins. En temps normal, ces clés sont impossibles à deviner. Mais dans ce cas, une entropie très insuffisante – autrement dit un hasard « prévisible » – aurait considérablement réduit le nombre de phrases de récupération possibles.
L’erreur ne venait pas de l’absence d’un générateur matériel de nombres aléatoires, mais d’un mauvais branchement logiciel. Le code chargé de créer les phrases de récupération appelait par erreur un générateur de secours alimenté notamment par l’identifiant de la puce et des valeurs d’horloge. Sur les anciens wallets Mk2 et Mk3 concernés, aucun véritable hasard cryptographique ne venait corriger cette faiblesse. Sur les modèles plus récents, Coldcard ajoutait bien une source sécurisée, mais n’en conservait que 32 bits, réduisant fortement le nombre de seeds possibles.
L’attaquant n’avait donc pas besoin de pirater les appareils : il lui suffisait de reproduire le générateur défaillant sur ses propres machines, puis de tester les seeds candidates. Toutes les clés privées et les adresses du propriétaire en découlent, c’est pourquoi il importe que la seed soit choisie de manière complètement aléatoire et imprévisible, ce qui n’était pas le cas ici.
Les fonds volés sont regroupés sur quatre adresses bitcoin. Leur parcours peut être suivi publiquement, mais les identités des personnes qui contrôlent ces adresses restent inconnues, sauf à recouper ces transactions avec d’autres informations, par exemple celles d’une plateforme d’échange. Il se trouve que l’attaquant aurait utilisé un compte payant auprès d’un fournisseur de données blockchain pour interroger les adresses au moment du vol.
Ces informations ne proviennent pas d’une plateforme d’échange, mais un compte payant peut laisser des traces potentiellement exploitables pour remettre la main sur le ou les auteurs de ce casse. Quant aux utilisateurs de Coldcard, ils ne doivent pas se contenter de mettre à jour leurs portefeuilles. Il faut aussi et surtout créer une nouvelle seed à partir d’un système mis à jour, puis transférer les cryptos vers les nouvelles adresses.
Cette histoire rappelle que les clés, même très longues (128 ou 256 bits) ne sont aussi solides que la méthode cryptographique qui sert à les générer. Si elle ne produit qu’un petit nombre de valeurs possibles, la sécurité de la clé devient largement illusoire. Dans le cas Coldcard, les wallets Mk4, Q et Mk5 généraient des clés d’environ quatre milliards de suites réellement distinctes. Un nombre immense à l’échelle humaine, mais suffisamment réduit pour pouvoir être exploré par des ordinateurs.
Il y a plusieurs exemples de mécanismes cryptographiques robustes, mais affaiblis par leur implémentation. On peut rappeler la découverte du groupe fail0verflow qui, fin 2010, révélait la clé privée permettant de signer les jeux et les logiciels de la PS3. Il devenait donc possible de faire tourner des homebrews et des programmes non autorisés par Sony sur la console.
L’algorithme ECDSA utilisé exigeait une valeur secrète différente pour chaque signature (« nonce »). Mais voilà, la PS3 réutilisait la même valeur… En comparant plusieurs signatures, les bidouilleurs ont pu calculer la clé utilisée par Sony. Le problème ne résidait pas dans l’algorithme en lui-même, mais dans son implémentation.
Autre exemple célèbre : en 2014, le National Institute of Standards and Technology (NIST) américain retirait un algorithme cryptographique de son projet de recommandations sur les générateurs de nombres pseudo-aléatoires. Il s’agissait de Dual_EC_DRBG, qui était très lent, favorisait certains nombres plutôt que d’autres, et avait cette réputation d’être un tuyau percé.
En septembre 2013, des documents révélés par Edward Snowden ont ravivé les soupçons autour de cet algorithme, soupçonné depuis plusieurs années de contenir une porte dérobée conçue par la NSA. L’agence avait justement insisté auprès du NIST pour conserver Dual_EC_DRBG, alors que ses faiblesses étaient connues depuis 2007.
Mauvaise surprise pour des utilisateurs de portefeuilles de bitcoins de Coldcard. Des petits malins ont su reconstituer leurs phrases de récupération, générées par une méthode trop simple. Résultat, plus de 110 millions de dollars dérobés, et un rappel utile : les clés cryptographiques ne valent que si le système qui les crée est réellement imprévisible.
Une erreur de programmation aurait empêché certains wallets du fabricant Coldcard d’utiliser leur générateur matériel de nombres aléatoires pour créer des « seeds », ces phrases de récupération de 12 ou 24 mots. Cette erreur logicielle aurait poussé le générateur de ces portefeuilles à se rabattre sur une méthode reposant sur des données relativement prévisibles (numéro de série de la puce ou encore valeurs liées à l’horloge), explique l’équipe Bitcoin Engineering and Security de Block.
Le 30 juillet, 1 196 adresses ont été entièrement vidées pour un peu plus de 1 082 bitcoins, ce qui représente environ 70 millions de dollars selon les calculs de Galaxy Research. L’opération a été rapide, elle n’a duré en tout et pour tout 41 minutes. Deux autres vagues ont eu lieu par la suite, pour un total de 1 816 BTC, soit 114 millions de dollars.
Les bitcoins ne sont pas stockés dans les wallets Coldcard eux-mêmes, mais sur la blockchain ; le portefeuille physique ne conserve que les clés privées permettant de déplacer les bitcoins. En temps normal, ces clés sont impossibles à deviner. Mais dans ce cas, une entropie très insuffisante – autrement dit un hasard « prévisible » – aurait considérablement réduit le nombre de phrases de récupération possibles.
L’erreur ne venait pas de l’absence d’un générateur matériel de nombres aléatoires, mais d’un mauvais branchement logiciel. Le code chargé de créer les phrases de récupération appelait par erreur un générateur de secours alimenté notamment par l’identifiant de la puce et des valeurs d’horloge. Sur les anciens wallets Mk2 et Mk3 concernés, aucun véritable hasard cryptographique ne venait corriger cette faiblesse. Sur les modèles plus récents, Coldcard ajoutait bien une source sécurisée, mais n’en conservait que 32 bits, réduisant fortement le nombre de seeds possibles.
L’attaquant n’avait donc pas besoin de pirater les appareils : il lui suffisait de reproduire le générateur défaillant sur ses propres machines, puis de tester les seeds candidates. Toutes les clés privées et les adresses du propriétaire en découlent, c’est pourquoi il importe que la seed soit choisie de manière complètement aléatoire et imprévisible, ce qui n’était pas le cas ici.
Les fonds volés sont regroupés sur quatre adresses bitcoin. Leur parcours peut être suivi publiquement, mais les identités des personnes qui contrôlent ces adresses restent inconnues, sauf à recouper ces transactions avec d’autres informations, par exemple celles d’une plateforme d’échange. Il se trouve que l’attaquant aurait utilisé un compte payant auprès d’un fournisseur de données blockchain pour interroger les adresses au moment du vol.
Ces informations ne proviennent pas d’une plateforme d’échange, mais un compte payant peut laisser des traces potentiellement exploitables pour remettre la main sur le ou les auteurs de ce casse. Quant aux utilisateurs de Coldcard, ils ne doivent pas se contenter de mettre à jour leurs portefeuilles. Il faut aussi et surtout créer une nouvelle seed à partir d’un système mis à jour, puis transférer les cryptos vers les nouvelles adresses.
Cette histoire rappelle que les clés, même très longues (128 ou 256 bits) ne sont aussi solides que la méthode cryptographique qui sert à les générer. Si elle ne produit qu’un petit nombre de valeurs possibles, la sécurité de la clé devient largement illusoire. Dans le cas Coldcard, les wallets Mk4, Q et Mk5 généraient des clés d’environ quatre milliards de suites réellement distinctes. Un nombre immense à l’échelle humaine, mais suffisamment réduit pour pouvoir être exploré par des ordinateurs.
Il y a plusieurs exemples de mécanismes cryptographiques robustes, mais affaiblis par leur implémentation. On peut rappeler la découverte du groupe fail0verflow qui, fin 2010, révélait la clé privée permettant de signer les jeux et les logiciels de la PS3. Il devenait donc possible de faire tourner des homebrews et des programmes non autorisés par Sony sur la console.
L’algorithme ECDSA utilisé exigeait une valeur secrète différente pour chaque signature (« nonce »). Mais voilà, la PS3 réutilisait la même valeur… En comparant plusieurs signatures, les bidouilleurs ont pu calculer la clé utilisée par Sony. Le problème ne résidait pas dans l’algorithme en lui-même, mais dans son implémentation.
Autre exemple célèbre : en 2014, le National Institute of Standards and Technology (NIST) américain retirait un algorithme cryptographique de son projet de recommandations sur les générateurs de nombres pseudo-aléatoires. Il s’agissait de Dual_EC_DRBG, qui était très lent, favorisait certains nombres plutôt que d’autres, et avait cette réputation d’être un tuyau percé.
En septembre 2013, des documents révélés par Edward Snowden ont ravivé les soupçons autour de cet algorithme, soupçonné depuis plusieurs années de contenir une porte dérobée conçue par la NSA. L’agence avait justement insisté auprès du NIST pour conserver Dual_EC_DRBG, alors que ses faiblesses étaient connues depuis 2007.
Une notification de sécurité informatique notée 10 sur 10 (le plus haut degré de gravité), reprise par le NIST, la CISA et le centre de cybersécurité néerlandais, décrivait une faille qui n'a jamais existé. Il aura fallu l'obstination du créateur de SQLite pour la faire retirer.
Apple, comme d’autres entreprises de la tech, se noie dans les signalements de bugs générés par IA. Pour tenter de garder la tête hors de l’eau, le constructeur a mis en place plusieurs mesures visant à limiter le volume des rapports reçus. Au risque de frustrer les chercheurs en sécurité.
Apple impose depuis juin un plafond et une période de carence de 30 jours pour les rapports de bugs transmis via le portail web dédié. « Face à l’augmentation du nombre de signalements de sécurité générés par IA dans l’ensemble du secteur, nous avons récemment ajusté le nombre de nouveaux rapports qu’un chercheur peut avoir ouverts simultanément », a confirmé l’entreprise au Financial Times.
Il s’agit pour le constructeur de donner le temps à ses propres équipes de vérifier les signalements et, le cas échéant, de développer les correctifs. Le tsunami de rapports de bugs de mauvaise qualité générés par IA est tel qu’il est très difficile (et très long) de trier le bon grain de l’ivraie. Le système qui examine les signalements est sous pression, il a donc fallu prendre des mesures radicales.
Malheureusement, cette solution peut avoir une conséquence négative : empêcher des chercheurs en sécurité légitimes d’alerter Apple de l’existence d’une importante vulnérabilité. C’est le cas de l’équipe italienne Bynario, qui a déniché une cinquantaine de failles dans la dernière version de macOS avec l’aide de ChatGPT en trois semaines seulement.
Parmi ces vulnérabilités, une d’entre elles est particulièrement sérieuse puisqu’elle permet une élévation de privilèges, qui pourrait donner à un pirate la possibilité de prendre le contrôle d’un Mac. Hélas, Bynario n’a pas pu prévenir Apple en raison des nouvelles limites imposées aux signalements. Le groupe a néanmoins accepté d’examiner le rapport, suite à la demande d’information du FT.
En 2025, les chercheurs italiens avaient soumis huit rapports de bugs à Apple, dont un qui a été corrigé en novembre. Depuis le début de l’année, ils ont signalé cinq failles supplémentaires, avant qu’Apple leur ferme la porte. La vulnérabilité impossible à soumettre concernait le système de Memory Integrity Enforcement, dévoilé en septembre dernier et censé empêcher les attaques par corruption de mémoire. Une faille de ce type peut se vendre jusqu’à 200 000 dollars sur le marché noir des cybercriminels, selon Bynario.
« Les responsables de projets et les éditeurs sont submergés par la quantité de bugs découverts », admet Alfredo Pesoli, directeur général et cofondateur de Bynario, pour qui « c’est une période très difficile pour le secteur ». Apple précise que les chercheurs peuvent « facilement demander à tout moment » une augmentation de l’enveloppe de signalements, pour faire en sorte que les rapports de sécurité critiques puissent être pris en compte.
Apple a bonifié l’an dernier son bug bounty, qui permet aux chercheurs d’empocher jusqu’à 2 millions de dollars (et même 5 millions avec les bonus) pour les failles les plus importantes. Il y a de quoi attiser l’intérêt de beaucoup d’amateurs qui tentent leur chance avec l’aide des outils d’IA.
Dans sa dernière livraison de mises à jour logicielles, Apple a multiplié les correctifs : 87 vulnérabilités corrigées dans iOS 26.6, 155 dans macOS 26.6. Plusieurs de ces correctifs ont été rendus possibles grâce à l’IA d’Anthropic et d’OpenAI, entre autres labos. Apple a également annoncé que le processus de distribution de ces mises à jour allait s’accélérer, là aussi en raison des gros volumes de signalements.
Apple n’est pas la seule entreprise du secteur à ployer sous les correctifs de sécurité en raison de l’IA. Google a ainsi annoncé la semaine dernière que Chrome allait avoir droit à deux mises à jour hebdomadaires, au lieu d’une.
Apple, comme d’autres entreprises de la tech, se noie dans les signalements de bugs générés par IA. Pour tenter de garder la tête hors de l’eau, le constructeur a mis en place plusieurs mesures visant à limiter le volume des rapports reçus. Au risque de frustrer les chercheurs en sécurité.
Apple impose depuis juin un plafond et une période de carence de 30 jours pour les rapports de bugs transmis via le portail web dédié. « Face à l’augmentation du nombre de signalements de sécurité générés par IA dans l’ensemble du secteur, nous avons récemment ajusté le nombre de nouveaux rapports qu’un chercheur peut avoir ouverts simultanément », a confirmé l’entreprise au Financial Times.
Il s’agit pour le constructeur de donner le temps à ses propres équipes de vérifier les signalements et, le cas échéant, de développer les correctifs. Le tsunami de rapports de bugs de mauvaise qualité générés par IA est tel qu’il est très difficile (et très long) de trier le bon grain de l’ivraie. Le système qui examine les signalements est sous pression, il a donc fallu prendre des mesures radicales.
Malheureusement, cette solution peut avoir une conséquence négative : empêcher des chercheurs en sécurité légitimes d’alerter Apple de l’existence d’une importante vulnérabilité. C’est le cas de l’équipe italienne Bynario, qui a déniché une cinquantaine de failles dans la dernière version de macOS avec l’aide de ChatGPT en trois semaines seulement.
Parmi ces vulnérabilités, une d’entre elles est particulièrement sérieuse puisqu’elle permet une élévation de privilèges, qui pourrait donner à un pirate la possibilité de prendre le contrôle d’un Mac. Hélas, Bynario n’a pas pu prévenir Apple en raison des nouvelles limites imposées aux signalements. Le groupe a néanmoins accepté d’examiner le rapport, suite à la demande d’information du FT.
En 2025, les chercheurs italiens avaient soumis huit rapports de bugs à Apple, dont un qui a été corrigé en novembre. Depuis le début de l’année, ils ont signalé cinq failles supplémentaires, avant qu’Apple leur ferme la porte. La vulnérabilité impossible à soumettre concernait le système de Memory Integrity Enforcement, dévoilé en septembre dernier et censé empêcher les attaques par corruption de mémoire. Une faille de ce type peut se vendre jusqu’à 200 000 dollars sur le marché noir des cybercriminels, selon Bynario.
« Les responsables de projets et les éditeurs sont submergés par la quantité de bugs découverts », admet Alfredo Pesoli, directeur général et cofondateur de Bynario, pour qui « c’est une période très difficile pour le secteur ». Apple précise que les chercheurs peuvent « facilement demander à tout moment » une augmentation de l’enveloppe de signalements, pour faire en sorte que les rapports de sécurité critiques puissent être pris en compte.
Apple a bonifié l’an dernier son bug bounty, qui permet aux chercheurs d’empocher jusqu’à 2 millions de dollars (et même 5 millions avec les bonus) pour les failles les plus importantes. Il y a de quoi attiser l’intérêt de beaucoup d’amateurs qui tentent leur chance avec l’aide des outils d’IA.
Dans sa dernière livraison de mises à jour logicielles, Apple a multiplié les correctifs : 87 vulnérabilités corrigées dans iOS 26.6, 155 dans macOS 26.6. Plusieurs de ces correctifs ont été rendus possibles grâce à l’IA d’Anthropic et d’OpenAI, entre autres labos. Apple a également annoncé que le processus de distribution de ces mises à jour allait s’accélérer, là aussi en raison des gros volumes de signalements.
Apple n’est pas la seule entreprise du secteur à ployer sous les correctifs de sécurité en raison de l’IA. Google a ainsi annoncé la semaine dernière que Chrome allait avoir droit à deux mises à jour hebdomadaires, au lieu d’une.
Vendredi, le ministère a reconnu « une intrusion frauduleuse dans l’un de ses systèmes d’information », qui « a pu conduire à l’exfiltration de données à caractère personnel concernant un nombre important de ses agents ».
C’est la troisième fois cette année, après l’intrusion sur le portail RH Compas en mars qui a exposé les informations de quelque 243 000 agents et stagiaires, ainsi qu’une cyberattaque contre ÉduConnect en avril. Dans ce cas, les élèves étaient visés avec leurs prénoms, noms, identifiants ÉduConnect, établissements, classes et emails.
Cette fois-ci, l’attaque a visé le service dédié à la formation des personnels. L’attaque s’est déroulée dans la nuit du 25 au 26 juillet 2026, avec l’usurpation d’un compte professionnel. Les cibles potentielles sont larges car elles concernent « les agents du ministère ayant exercé en académie depuis 2001 », soit il y a 25 ans tout de même.
Dans le lot des données dérobées, des éléments d’identité et d’informations professionnelles (statut et fonctions) ainsi que, « pour une partie d’entre eux », les coordonnées postales, le numéro de téléphone ainsi que celui de sécurité sociale. Aucun détail n’est donné sur la volumétrie précise, tout juste savons-nous qu’il « s’agit entre autres d’enseignants » via une confirmation du ministère à l’AFP.
Le ministère annonce qu’une plainte a été déposée. L’ANSSI (Agence nationale de la sécurité des systèmes d’information) et la CNIL (Commission nationale de l’informatique et des libertés) ont été saisies. Bien évidemment, les « personnes susceptibles d’être concernées seront informées dans les meilleurs délais ». Pour rappel, la notification des personnes concernées est une obligation « en cas de risque élevé ».
Le ministère rappelle les règles élémentaires de prudence en matière de cybersécurité et notamment le risque de phishing avec des pirates qui tenteraient de se faire passer pour le ministère. Il met aussi en garde contre… l’usurpation d’identité, qui est justement en cause dans le cas présent.
Connexion