Une attaque chaîne logistique Rust a récemment ciblé l’écosystème du langage Rust. Selon l’éditeur de sécurité Wiz, des pirates liés à la Corée du Nord auraient exploité une faille de confiance propre aux dépendances open source en modifiant des paquets avant leur publication sur crates.io.
L’événement, survenu le 20 août, illustre une menace persistante : quand un composant largement utilisé devient le point d’entrée, le risque se propage vite à travers tout un parc d’applications. Dans ce cas précis, le mécanisme a reposé sur des versions empoisonnées de crates et sur une étape de compilation détournée.
Un crate majeur au cœur de l’incident
Le point de départ de l’opération est un utilitaire de conversion de tableaux appelé arrayref. Avec plus de 245 millions de téléchargements, ce crate se retrouve dans environ 75 % des environnements où Rust est utilisé.
Le 20 août, un paquet malveillant portant le libellé [email protected] a été publié sur crates.io. L’intrusion n’a pas consisté à introduire un nouveau projet, mais à pousser une version à partir du compte du mainteneur légitime.
Publication en cascade de versions empoisonnées
La stratégie a été conçue pour maximiser la probabilité d’impact. Environ 20 minutes après la publication du premier paquet empoisonné, des versions contaminées d’autres crates ont également été mises en ligne : internment et append-only-vec.
Ces deux projets provenaient du même propriétaire. Ce détail compte : au lieu de viser uniquement une dépendance isolée, l’attaque a exploité une zone de confiance plus large, liée à des comptes et des sources déjà considérés comme fiables.
Des paquets contrôlés par l’attaquant et une dépendance commune
Au-delà de arrayref, plusieurs crates détenus par l’attaquant — notamment aovine, arone, aronenao et tinymember — ont aussi été observés. Leur rôle, d’après les analyses rapportées, était de pointer vers la même dépendance malveillante : [email protected].
Cette dépendance malveillante se présentait comme si elle était le paquet légitime proc-macro2. Autrement dit, l’attaque a reposé sur une imitation d’un composant courant de l’écosystème Rust, afin de tromper les mécanismes d’instanciation des dépendances.
Le cœur du détournement : build.rs et récupération d’un second stade
Dans la dépendance contaminée, les observateurs décrivent un fichier conçu pour agir au moment de la compilation : build.rs. L’objectif du script était de récupérer une charge utile de deuxième étape adaptée à la plateforme, via un téléchargement sur TLS.
La particularité inquiétante est la façon dont le canal sécurisé a été contourné : le code aurait procédé à la désactivation de la validation des certificats avant de récupérer le binaire.
En clair, l’attaque a profité du fait que les scripts de build et les dépendances sont exécutés au cours du processus d’intégration, offrant une opportunité directe d’exécution de code malveillant.
Réaction rapide du Rust Security Response Team
La correction a été menée rapidement. Les paquets malveillants auraient été supprimés environ 86 minutes après la publication initiale. Le Rust Security Response Team aurait également confirmé la nature du compromis.
Selon les éléments rapportés, une nouvelle version de arrayref a été publiée avec une dépendance directe vers un paquet de type proc-macro1 susceptible d’exécuter un script de build malveillant. Cette explication permet de relier la chaîne des événements : de la publication frauduleuse jusqu’à l’exécution au moment de la compilation.
Suppression totale et absence de preuves d’usage
Peu après, l’équipe de sécurité Rust a indiqué que tous les paquets malveillants avaient été retirés. Les versions propres auraient été restaurées.
Important pour l’évaluation du risque : les analyses menées par l’équipe ne signaleraient aucune preuve d’utilisation réelle des crates compromis. Autrement dit, l’incident semble s’être heurté à une détection et à une remédiation avant qu’il ne se transforme en campagne à grande échelle chez des utilisateurs.
Le mainteneur n’aurait pas été le responsable direct
Les informations disponibles suggèrent que l’auteur initial de arrayref n’aurait pas agi de manière malveillante. Les conclusions indiquent plutôt que l’ordinateur ou les identifiants du mainteneur auraient probablement été compromis.
Le message transmis par l’équipe de sécurité Rust précise qu’ils tentaient de contacter le mainteneur. Ce point est crucial : dans les attaques de chaîne logistique, la compromission des comptes est un levier aussi courant que l’exploitation technique.
Une préparation minutieuse selon des analyses externes
Des analyses attribuées à StepSecurity mettent en avant un niveau de planification élevé. L’attaque aurait consisté à créer des versions typosquattées de proc-macro2 et à préparer un compte imité juste avant la publication empoisonnée de arrayref.
Cette chronologie renforce l’idée d’un scénario orchestré en plusieurs étapes, avec des fenêtres de publication courtes et une coordination visant à réduire la probabilité de détection.
Attribution à Sapphire Sleet : recoupements d’infrastructure
Wiz affirme que l’incident serait probablement l’œuvre de l’acteur Sapphire Sleet, déjà associé à d’autres attaques de chaîne logistique dans l’écosystème JavaScript, notamment contre NPM via Axios et Mastra.
L’attribution s’appuie sur des chevauchements d’infrastructure. Par exemple, les charges utiles auraient été conçues pour beacon (signaler périodiquement) vers un endpoint utilisé lors d’une attaque Mastra, et des flux de commande et contrôle (C&C) auraient été observés vers des adresses liées à la campagne Axios.
De plus, le même bloc d’adresses associé à l’infrastructure de Hostwinds LLC aurait été employé dans plusieurs incidents. Ces recoupements techniques servent à établir un lien probable entre les opérations.
Pourquoi cette attaque chaîne logistique Rust est un signal d’alerte
Même sans preuve d’exploitation massive, l’affaire met en évidence un risque structurel. Les dépendances open source sont conçues pour faciliter le développement, mais elles créent aussi une surface d’attaque : un composant très utilisé, lorsqu’il est compromis, peut servir de relais.
Dans le cas d’une attaque chaîne logistique Rust, le danger est renforcé par l’exécution de scripts de build comme build.rs. Tant que le code source et les artefacts téléchargés ne sont pas correctement vérifiés, une chaîne d’approvisionnement altérée peut franchir plusieurs couches du système.
Conclusion : vigilance et hygiène de dépendances
L’incident autour de arrayref montre comment des pirates peuvent exploiter la confiance accordée aux paquets publiés sur crates.io. Grâce à une action rapide du Rust Security Response Team, les versions malveillantes auraient été retirées et les itérations saines restaurées, limitant l’impact potentiel.
Pour les équipes qui déploient Rust, la leçon est claire : surveiller les dépendances, appliquer des vérifications rigoureuses et renforcer l’hygiène de la chaîne logicielle reste essentiel, surtout lorsque des mainteneurs peuvent être touchés par des compromissions de comptes.
Source: https://www.securityweek.com/rust-supply-chain-attack-linked-to-north-korean-hackers/
