Archives par mot-clé : PyPI

Cybersécurité, Entreprise, Espionnage Spy, Linux, Mise à jour, Securite informatique, Social engineering

ChocoPoC cible les chercheurs en vulnérabilités

Des chercheurs français en cybersécurité ont identifié une campagne sophistiquée utilisant de faux exploits CVE pour infecter les environnements des pentesters avec un cheval de Troie Python.

Une enquête menée par YesWeHack et Sekoia révèle une attaque de chaîne d’approvisionnement visant directement les chercheurs en vulnérabilités. Depuis fin 2025, des acteurs malveillants diffusent de faux dépôts GitHub proposant des preuves de concept pour des failles critiques. Sept dépôts piégés ont été identifiés. Leur installation déclenche des dépendances Python malveillantes capables de déployer ChocoPoC, un RAT conçu pour voler des fichiers, récupérer des identifiants et exécuter des commandes.

Des exploits CVE transformés en pièges

L’affaire débute le 25 juin 2026. Après la publication d’un modèle Nuclei consacré à Joomla JCE, l’équipe de YesWeHack reçoit une suggestion concernant deux preuves de concept associées à une vulnérabilité critique Joomla. L’un des dépôts, consacré à CVE-2026-48908, attire rapidement l’attention.

Son fichier de dépendances réclame un paquet Python inconnu nommé « frint ». Celui-ci installe à son tour « skytext », publié récemment sur PyPI. Le paquet se présente comme une bibliothèque destinée à produire rapidement des couleurs dans un terminal. Son contenu réel est beaucoup moins décoratif.

Skytext distribue des extensions compilées pour Linux et Windows. L’analyse de la version Windows révèle du code obfusqué, une exploration du Process Environment Block, des fonctions résolues dynamiquement et plusieurs blocs chiffrés. Le programme vérifie également son environnement avant d’exécuter son activité malveillante.

Cette précaution complique fortement l’analyse automatisée. Le code recherche notamment la présence d’un fichier portant un nom précis, comme « EXPLOIT_POC.py ». Sans ce contexte, aucune charge utile ne se déclenche. Un échantillon isolé dans un bac à sable peut ainsi sembler inoffensif.

Lorsque les conditions attendues sont réunies, l’extension déchiffre plusieurs composants et modifie l’environnement Python. Elle installe une version détournée du paquet _distutils_hack ainsi que des fichiers .pth. Ces éléments sont ensuite chargés lors du démarrage d’un nouvel interpréteur Python.

Cette persistance permet de lancer choco.py, le téléchargeur intermédiaire de ChocoPoC. Celui-ci récupère une nouvelle charge utile grâce à un jeu de données hébergé chez Mapbox. Les requêtes DNS peuvent passer par DNS-over-HTTPS, notamment via AliDNS ou Cloudflare, afin de contourner certains mécanismes locaux de filtrage.

Le trafic conserve par ailleurs l’apparence d’une connexion légitime vers l’API Mapbox. Cette infrastructure sert de point mort pour récupérer le RAT et échanger des informations, réduisant la visibilité du canal de commande.

Une campagne pensée pour les outils offensifs

Le dernier étage de l’infection est un RAT (logiciel espion) écrit en Python. ChocoPoC peut collecter des données issues de Chrome, Brave, Edge et Firefox, notamment les mots de passe, cookies, historiques et informations de remplissage automatique.

Il recherche également certains fichiers locaux, des bases de données, des historiques de commandes shell, des informations réseau et la liste des processus actifs. L’opérateur peut lancer des commandes système, exécuter dynamiquement du code Python, récupérer des fichiers ou modifier la fréquence des communications avec le serveur de contrôle.

L’enquête a permis d’identifier au moins sept dépôts GitHub malveillants associés à des vulnérabilités très médiatisées. Les leurres visaient notamment FortiWeb, React2Shell, MongoBleed, PAN-OS, Ivanti Sentry, Checkpoint VPN et Joomla SP Page Builder.

Deux chaînes de dépendances apparaissent. En 2025, plusieurs dépôts utilisaient les paquets « slogsec » et « logcrypt.cryptography ». En 2026, les opérateurs ont privilégié « frint » et « skytext ». Malgré ces changements, YesWeHack et Sekoia relèvent plusieurs caractéristiques communes, dont le même identifiant de fonctionnalité Mapbox, des contrôles environnementaux similaires et des mécanismes identiques contre les relances récursives.

Ces éléments conduisent les chercheurs à attribuer avec une forte confiance les deux périodes d’activité au même acteur. Selon leur analyse, l’opérateur aurait régulièrement changé de comptes GitHub, PyPI et Mapbox pour limiter les blocages et compliquer le suivi de son infrastructure.

Les adresses électroniques utilisées pour certaines publications semblent également liées à des comptes compromis. Des identifiants concernant deux des quatre adresses étudiées figuraient dans des bases de données de fuites, dont l’une probablement issue d’une infection par infostealer.

Les statistiques de téléchargement renforcent l’inquiétude sans démontrer, à elles seules, une compromission. Le paquet skytext aurait enregistré environ 2 400 téléchargements sur Linux et Windows, avec une majorité sous Linux. Plusieurs hausses coïncident avec la divulgation ou l’exploitation publique de vulnérabilités importantes.

Le risque dépasse donc la seule machine d’un chercheur. Un pentester compromis peut manipuler des identifiants clients, des rapports confidentiels, des données techniques sensibles ou des informations concernant des systèmes vulnérables.

ChocoPoC illustre ainsi une évolution préoccupante du renseignement cyber : le code visible peut rester crédible tandis que l’infection se déplace vers les dépendances, transformant l’urgence autour des nouvelles CVE en véritable surface d’attaque.

Cybersécurité, Entreprise, Mise à jour, Patch, Securite informatique

Google lance OSS Rebuild pour sécuriser la chaîne d’approvisionnement open source

L’open source représente aujourd’hui 77 % des applications et sa valeur mondiale excède 12 000 milliards de dollars (environ 11 130 milliards d’euros). Mais cette omniprésence en fait une cible privilégiée pour les attaques sur la chaîne d’approvisionnement, où des acteurs malveillants insèrent du code frauduleux dans des composants de confiance.

Les attaques sur la chaîne d’approvisionnement logicielle ciblent principalement les projets open source, au cœur de l’infrastructure numérique. Le phénomène a pris de l’ampleur au fil des années, notamment via la compromission d’outils et de modules largement utilisés dans la communauté mondiale des développeurs. L’attrait pour les composants open source s’explique par leur présence massive dans les applications, des systèmes d’exploitation aux services en ligne. Les statistiques confirment cette tendance : 77 % des applications intégrant du code open source et une valorisation de ces composants estimée à plus de 12 000 milliards de dollars (environ 11 130 milliards d’euros).

Parmi les incidents récents, plusieurs attaques retentissantes ont mis en évidence la vulnérabilité des chaînes d’approvisionnement. Dans un projet hébergé sur npm, la compromission d’un compte a permis l’ajout d’une porte dérobée destinée à dérober des clés cryptographiques. Un autre cas notable concerne l’introduction d’une action GitHub malveillante dans un dépôt populaire, provoquant la fuite de secrets. Enfin, l’attaque sophistiquée sur un projet d’archivage open source a permis l’implantation d’une porte dérobée assurant un accès distant non autorisé. Chacun de ces cas a eu un impact direct sur la confiance accordée aux écosystèmes logiciels, fragilisant à la fois la relation entre développeurs et utilisateurs et ralentissant l’innovation.

La popularité des solutions open source entraîne une diversification des techniques utilisées par les attaquants. Ceux-ci exploitent la complexité des chaînes de développement pour insérer des modifications malicieuses, parfois indétectables sans outils dédiés. Les mécanismes de contrôle traditionnels peinent à suivre le rythme et l’ampleur des évolutions, accentuant la nécessité de solutions innovantes pour restaurer la confiance.

Les conséquences de ces attaques vont au-delà de la simple compromission technique. Elles affectent la réputation des projets, l’adoption des nouvelles versions et la sécurité globale des services. Plusieurs plateformes de distribution de paquets ont déjà renforcé leurs contrôles, mais la question de la transparence du processus de compilation et de la traçabilité des modifications reste centrale.

Google présente OSS Rebuild pour restaurer la confiance

Face à ces enjeux, Google a développé un nouvel outil dédié à la transparence dans la chaîne d’approvisionnement logicielle : OSS Rebuild. Ce service propose de vérifier la correspondance entre le code source public et les paquets distribués, en s’appuyant sur des reconstructions automatisées. L’objectif affiché est de permettre à chaque membre de la communauté d’analyser l’origine des composants, de valider leur intégrité et de surveiller tout changement intervenu durant la phase de compilation.

OSS Rebuild s’inscrit dans une démarche de conformité avec les exigences de la Supply-chain Levels for Software Artifacts (SLSA), en particulier le niveau SLSA Build Level 3. Le service génère automatiquement les métadonnées associées aux processus de compilation, sans requérir l’intervention directe des auteurs des projets concernés. Cette automatisation vise à faciliter l’adoption de standards de sécurité élevés dans l’ensemble de l’écosystème open source.

Le fonctionnement du service est pensé pour répondre aux besoins de différents profils d’utilisateurs. Les spécialistes en sécurité disposent d’un accès à l’analyse détaillée des divergences éventuelles entre code et paquets. Ils peuvent ainsi identifier rapidement les incohérences, les défauts de configuration de l’environnement de compilation ou l’insertion de fonctionnalités cachées. De leur côté, les mainteneurs de projets peuvent enrichir l’historique de leurs publications en y associant des informations sur l’intégrité et la reproductibilité des versions.

Actuellement, OSS Rebuild prend en charge les paquets issus de trois grandes plateformes : PyPI pour Python, npm pour JavaScript et TypeScript, ainsi que Crates.io pour Rust. Cette compatibilité doit être progressivement étendue à d’autres environnements selon le calendrier annoncé par Google. L’accès à l’outil s’effectue via une interface en ligne de commande, permettant d’interroger l’origine d’un paquet, de consulter l’historique des reconstructions ou de lancer une recompilation à la demande.

Le recours à OSS Rebuild n’est pas limité aux seuls incidents de sécurité. Les analyses peuvent également porter sur des versions déjà publiées, offrant la possibilité de réévaluer l’intégrité de paquets antérieurs ou de vérifier la reproductibilité des versions historiques. Cette approche favorise la constitution d’une documentation exhaustive, essentielle à la gestion de la conformité et à la réponse aux exigences réglementaires croissantes.

La généralisation de ce type d’outils répond à une demande pressante du secteur, confronté à l’augmentation du nombre de vulnérabilités exploitées via la chaîne d’approvisionnement. Les grandes entreprises, tout comme les développeurs indépendants, sont encouragés à adopter ces pratiques pour garantir la sécurité de leurs dépendances et préserver la confiance des utilisateurs finaux.

À mesure que le périmètre de l’open source s’élargit, la protection de ses processus de développement revêt une importance stratégique. La mise à disposition d’outils tels qu’OSS Rebuild va-t-il contribuez à réduire les risques systémiques et à promouvoir des standards élevés dans la gestion de la chaîne d’approvisionnement logicielle ? Si la lutte contre les attaques sophistiquées requiert une vigilance constante, la transparence et la traçabilité apparaissent désormais comme des leviers majeurs pour pérenniser l’innovation dans l’univers du logiciel libre.