ActualitésCryptoUne attaque sur la chaîne d'approvisionnement Rust touche des crates largement utilisées, avec une exposition potentielle de l'écosystème Solana

Une attaque sur la chaîne d'approvisionnement Rust touche des crates largement utilisées, avec une exposition potentielle de l'écosystème Solana

Auteur: Hokanews·

Points clés

  • Des chercheurs en sécurité ont signalé des versions malveillantes de arrayref@0.3.10, internment@0.8.7 et append-only-vec@0.1.9 dans l'écosystème Rust.
  • Les paquets compromis utilisaient une dépendance contrefaite ressemblant à proc-macro1, et son script de build pouvait télécharger et exécuter une charge utile distante lors de la compilation.
  • Comme Cargo exécute automatiquement les scripts de build, les développeurs et les environnements de CI ont pu être exposés simplement en compilant les versions affectées.
  • L'équipe de sécurité de Rust a supprimé les versions malveillantes et verrouillé le compte du mainteneur associé aux paquets.
  • Les crates affectées apparaissent dans certaines chaînes de dépendances liées à Solana, mais le rapport ne montre pas que Solana ou des projets en aval aient été compromis.
Une attaque sur la chaîne d'approvisionnement Rust touche des crates largement utilisées, avec une exposition potentielle de l'écosystème Solana

Une attaque coordonnée sur la chaîne d'approvisionnement a touché plusieurs paquets Rust largement utilisés, suscitant l'inquiétude des développeurs et des projets dont les chaînes de dépendances incluent des composants associés à l'écosystème Solana. Des chercheurs en sécurité de SlowMist, Socket et StepSecurity ont signalé que des versions malveillantes affectaient arrayref@0.3.10, internment@0.8.7 et append-only-vec@0.1.9.

Les versions compromises introduisaient une dépendance typosquattée ressemblant au paquet légitime proc-macro1, dont le script de build téléchargeait et exécutait une charge utile distante lors des builds Cargo. En conséquence, les développeurs et les systèmes d'intégration continue (CI) ont potentiellement pu être exposés simplement en compilant un projet dépendant de l'une des versions affectées. Selon les informations partagées par @WuBlockchain sur X, l'équipe de sécurité de Rust a supprimé les versions malveillantes et verrouillé le compte du mainteneur affecté.

Des paquets malveillants diffusés via la chaîne de dépendances

L'incident touche l'écosystème de paquets de Rust, dans lequel les développeurs s'appuient couramment sur des crates tierces pour fournir des fonctionnalités au sein d'applications et de projets logiciels. En l'occurrence, les chercheurs ont identifié des versions malveillantes de trois crates : arrayref@0.3.10, internment@0.8.7 et append-only-vec@0.1.9.

Les versions malveillantes contenaient une dépendance conçue pour ressembler au paquet légitime proc-macro1. Cette technique, connue sous le nom de typosquatting, consiste à faire passer un paquet malveillant pour une dépendance légitime. Il s'agit d'une tactique récurrente dans les registres open source, y compris npm et le PyPI de Python, où des noms similaires ont été utilisés à plusieurs reprises pour introduire du code malveillant via des mises à jour de dépendances de routine.

L'attaque a pris une importance particulière car la dépendance malveillante incluait un script de build capable de télécharger et d'exécuter une charge utile distante lors de la compilation du paquet affecté. Le risque de sécurité n'était donc pas nécessairement limité aux utilisateurs ayant installé ou exécuté manuellement un programme manifestement suspect : un poste de développeur ou un environnement de CI pouvait potentiellement être affecté dans le cadre du processus normal de compilation logicielle.

Le processus de build a créé un risque de sécurité potentiel

Cargo est le gestionnaire de paquets et le système de build de Rust, et les développeurs l'utilisent couramment pour récupérer les dépendances et compiler des projets. L'attaque signalée a exploité ce flux de travail. Comme Cargo exécute automatiquement le script de build d'une crate dans le cadre de la compilation, un tel script s'exécute avec les permissions de l'utilisateur ou du compte de CI effectuant le build.

Lorsqu'une dépendance affectée était compilée, le script de build malveillant pouvait télécharger et exécuter une charge utile distante. Cela créait un chemin potentiel permettant à un attaquant d'exécuter du code sur la machine d'un développeur ou sur un hôte de CI.

Les systèmes de CI sont particulièrement importants dans le développement logiciel moderne, car ils construisent, testent et déploient automatiquement du code. Un environnement de build compromis peut donc présenter des risques allant au-delà d'un simple poste de travail de développeur, étant donné que les machines de build et les postes de développeurs détiennent fréquemment des identifiants tels que des jetons d'API, des clés de déploiement et des éléments de signature. C'est pourquoi les équipes de sécurité considèrent généralement l'exécution de code au moment du build comme un motif de rotation de tous les secrets présents sur les systèmes affectés.

L'incident met en évidence le défi de sécurité plus large associé aux chaînes d'approvisionnement logicielles, où du code malveillant peut entrer indirectement dans un projet via des dépendances que les développeurs n'ont pas nécessairement écrites ou examinées eux-mêmes.

Les chaînes de dépendances liées à Solana attirent l'attention

La crate arrayref est largement utilisée dans l'écosystème Rust et apparaît dans des chaînes de dépendances impliquant des composants associés à Solana. Le logiciel de validateur de Solana et une grande partie de ses outils environnants sont écrits en Rust, ce qui explique pourquoi des crates à usage général comme arrayref peuvent apparaître dans des arbres de dépendances liés à Solana, même si ces crates ne sont pas elles-mêmes spécifiques à la blockchain. Toutefois, la présence d'une crate affectée dans une chaîne de dépendances ne signifie pas que les projets liés à Solana en aval ont été compromis.

Cette distinction est importante car les logiciels open source s'appuient fréquemment sur plusieurs couches de dépendances. Un paquet vulnérable ou compromis peut apparaître quelque part dans l'arbre de dépendances d'un projet sans nécessairement entraîner la compromission effective de l'application ou du réseau final.

Les chercheurs en sécurité distinguent donc l'exposition à une dépendance malveillante des preuves que le code malveillant a réellement été exécuté au sein d'un projet ou d'un environnement en aval particulier. L'incident signalé établit que les versions affectées contenaient du code malveillant, mais il n'établit pas que chaque projet utilisant des dépendances liées a été compromis.

L'équipe de sécurité de Rust supprime les versions malveillantes

L'équipe de sécurité de Rust a réagi en supprimant les versions malveillantes et en verrouillant le compte du mainteneur associé aux paquets. Selon les informations rapportées, la machine du mainteneur ou ses identifiants de publication ont probablement été compromis.

Un compte de publication compromis peut présenter un risque important dans les écosystèmes open source, car des attaquants peuvent être en mesure de distribuer des logiciels malveillants sous l'identité d'un mainteneur légitime. La suppression des versions affectées limite toute diffusion ultérieure au sein de l'écosystème de paquets, tandis que le verrouillage du compte empêche la publication de nouvelles versions via les identifiants compromis. Les avis de sécurité concernant les crates Rust compromises sont suivis dans la base de données d'avis RustSec, maintenue par la communauté, l'un des canaux que les développeurs peuvent surveiller en parallèle du registre crates.io.

L'incident démontre également l'importance de surveiller les dépendances et d'examiner les mises à jour de paquets inattendues, en particulier lorsque les projets reposent sur des arbres de dépendances volumineux et complexes.

Des implications plus larges pour les développeurs Rust

Les attaques sur la chaîne d'approvisionnement sont devenues une préoccupation majeure de sécurité dans le développement logiciel, car elles ciblent l'infrastructure et les dépendances utilisées pour construire les applications plutôt que l'application finale elle-même. En l'espèce, le code malveillant était intégré dans des versions de paquets et s'activait pendant le processus de build. Ce schéma a des précédents bien documentés, notamment la porte dérobée XZ Utils révélée en mars 2024, dans laquelle un attaquant a exploité la position de mainteneur dans une bibliothèque open source fondamentale de compression, ainsi que la compromission du paquet @solana/web3.js sur npm en décembre 2024, qui a touché une bibliothèque JavaScript largement utilisée par les développeurs Solana. Ces deux épisodes, comme le présent incident, montrent comment la confiance accordée à un compte de mainteneur ou à l'identité d'un paquet peut devenir une surface d'attaque.

Les développeurs travaillant sur des projets Rust peuvent réduire leur exposition à des incidents similaires en surveillant les versions des dépendances, en examinant les changements inattendus et en utilisant des outils de sécurité capables d'identifier des paquets suspects ou des comportements de dépendances anormaux. Pour cet incident précisément, cela se traduit par la recherche des trois versions affectées dans les fichiers de verrouillage tels que Cargo.lock, la vérification des journaux de CI et de build à la recherche d'une activité réseau sortante inattendue, et la rotation des identifiants sur toute machine où les versions affectées ont été compilées. Les organisations qui s'appuient sur des environnements de CI automatisés doivent également tenir compte de la sécurité de leur infrastructure de build, car des dépendances malveillantes peuvent potentiellement exécuter du code avant le déploiement d'une application.

La réponse de l'écosystème Rust démontre l'importance d'une surveillance de sécurité coordonnée et d'une suppression rapide des paquets compromis. Bien que les crates affectées soient liées à des chaînes de dépendances impliquant des composants liés à Solana, les informations disponibles n'établissent pas que Solana lui-même ou des projets en aval spécifiques aient été compromis. L'incident rappelle plutôt que des dépendances open source largement utilisées peuvent devenir un vecteur d'attaque potentiel lorsque des identifiants de publication ou des environnements de mainteneurs sont compromis.

Source : Hokanews