Une attaque visant la chaîne d’approvisionnement logicielle a compromis Maven Central, permettant à des attaquants de distribuer un malware en usurpant l’identité d’une bibliothèque JSON Jackson de confiance.
Cette campagne montre à quel point de subtiles astuces de nommage peuvent saper la confiance des développeurs et introduire discrètement du code malveillant dans les environnements de production.
Les attaquants sont « … allés très loin pour mettre en place une charge utile en plusieurs étapes, avec des chaînes de configuration chiffrées, un serveur de commande et de contrôle distant fournissant des exécutables propres à chaque plateforme, ainsi que plusieurs couches d’obfuscation conçues pour compliquer l’analyse », ont déclaré les chercheurs d’Aikido.
Au cœur de l’attaque de typosquattage visant la chaîne d’approvisionnement de Jackson
L’attaque repose sur le typosquattage et l’usurpation d’espace de noms. Le nom du paquet malveillant ne diffère du nom légitime que par un seul élément d’espace de noms, ce qui le rend facile à négliger.
Pour légitimer davantage l’opération, les attaquants ont enregistré un domaine ressemblant à l’original, fasterxml[.]org, imitant le domaine légitime du projet, fasterxml[.]com.
Les enregistrements WHOIS montrent que le domaine a été enregistré quelques jours seulement avant la découverte du malware, une tactique couramment utilisée pour échapper à la détection précoce.
Une fois inclus comme dépendance, le malware s’exécute automatiquement dans les environnements Spring Boot.
Au démarrage de l’application, Spring recherche les classes @Configuration et déclenche JacksonSpringAutoConfiguration, ce qui permet au code malveillant de s’exécuter sans invocation explicite de la part du développeur.
Le malware recherche ApplicationRunner.class afin de confirmer qu’il s’exécute dans un environnement Spring Boot et de garantir une exécution cohérente.
Pour échapper à l’analyse, les attaquants ont fortement obfusqué le code contenu dans le fichier JAR.
Les chercheurs d’Aikido ont observé des techniques destinées à induire en erreur aussi bien les analystes humains que les outils d’analyse fondés sur l’apprentissage automatique, notamment l’utilisation abusive d’Unicode et du bruit de type injection de prompt.
Après désobfuscation, le code s’est révélé être un téléchargeur troyen qui contacte un serveur de commande et de contrôle (C2) distant pour récupérer d’autres charges utiles.
Le malware relève l’empreinte du système d’exploitation hôte et télécharge des binaires propres à chaque plateforme à l’aide de données de configuration chiffrées par AES.
L’analyse de ces charges utiles a confirmé que les variantes Linux et macOS sont des balises Cobalt Strike, un outil fréquemment détourné par les groupes de rançongiciels et les acteurs de menaces persistantes avancées (APT) pour l’accès à distance, le vol d’identifiants et les déplacements latéraux.
Réduire les risques au sein de la chaîne d’approvisionnement logicielle
Les attaques visant la chaîne d’approvisionnement logicielle ciblent de plus en plus les écosystèmes open source de confiance, faisant de l’hygiène des dépendances et de la sécurité des builds des priorités pour les équipes de développement.
Une fois qu’un paquet malveillant est introduit, il peut rapidement se propager à travers les applications, les pipelines et les environnements.
Les mesures suivantes visent à réduire le risque lié aux dépendances compromises, à améliorer la détection des comportements malveillants et à limiter l’impact des menaces visant la chaîne d’approvisionnement.
- Auditer les projets Java et les arborescences de dépendances à la recherche de paquets inconnus, supprimer les dépendances suspectes et reconstruire les applications à partir de sources réputées fiables.
- Imposer un contrôle strict des dépendances en épinglant les versions, en utilisant des listes d’autorisation, en vérifiant les sommes de contrôle ou les signatures et en limitant les builds à des miroirs de dépôts de confiance.
- Utiliser l’analyse de la composition logicielle et une surveillancecomportementale pour détecter les dépendances anormales, le chargement inattendu de classes ou une activité réseau inhabituelle.
- Renforcer les pipelines CI/CD et les environnements de développement en appliquant le principe du moindre privilège, en limitant la connectivité Internet et en surveillant l’exécution au moment du build.
- Mettre en œuvre des protections au niveau de l’exécution et des terminaux, comme EDR ou une surveillance au niveau des applications, afin de détecter l’exécution non autorisée de binaires ou les connexions sortantes.
- Renforcer la gouvernance et la préparation en testant lesplans de réponse aux incidents et en réexaminant régulièrement les dépendances.
Ensemble, ces mesures contribuent à réduire les risques liés à la chaîne d’approvisionnement, à améliorer la visibilité sur les dépendances malveillantes et à limiter le rayon d’impact en cas de compromission.
Le risque croissant lié aux chaînes d’approvisionnement open source
Cet incident met en lumière une évolution plus large de la stratégie des attaquants, qui cherchent à exploiter la chaîne d’approvisionnement logicielle et la confiance intrinsèque accordée aux écosystèmes open source.
Les pipelines de développement modernes reposent largement sur l’automatisation et introduisent fréquemment des dépendances avec un contrôle manuel limité.
Cela permet à un seul paquet malveillant de se propager rapidement à des centaines d’applications, amplifiant l’impact d’une compromission qui aurait autrement pu rester circonscrite.
À mesure que les attaques de ce type se multiplient, la sécurisation de la chaîne d’approvisionnement logicielle est devenue une priorité critique pour les organisations qui dépendent de composants open source à grande échelle.