Arch Linux : de faux paquets AUR lancent un malware en root

Un acteur malveillant a publié sur l'Arch User Repository (AUR) des paquets piégés qui se faisaient passer pour yay et paru, deux outils d'assistance très répandus. Une fois installés, ces paquets exécutaient un script shell distant avec les privilèges root.

Les paquets ont été repérés le 13 octobre. Ils avaient été mis en ligne par un utilisateur nommé "marchos1as" sous des noms de typosquatting très proches de ceux des outils légitimes.

Ce qu'est l'AUR et pourquoi les assistants comptent

L'AUR est un index de paquets maintenu par la communauté pour Arch Linux et les distributions qui en dérivent. Il n'héberge pas de binaires prêts à l'emploi. Il héberge des scripts de compilation, appelés PKGBUILD, que les utilisateurs exécutent pour compiler et installer eux-mêmes les logiciels. Ces scripts couvrent des outils tiers et propriétaires, des versions bêta et d'anciennes versions qui ne sont plus disponibles par les canaux officiels de la distribution.

Des outils comme yay et paru sont appelés des assistants AUR. Ils facilitent la recherche et l'installation des paquets proposés par les utilisateurs, si bien que de nombreux utilisateurs d'Arch les installent très tôt, souvent parmi les tout premiers ajouts sur un nouveau système. C'est ce qui en faisait un déguisement idéal pour les attaquants.

Du vrai code avec un script d'installation malveillant

Les utilisateurs ont été alertés par un fil de discussion sur la liste de diffusion d'Arch Linux intitulé "hundreds of aur packages were mass uploaded with malware". En quelques minutes, des membres de la communauté avaient examiné les paquets et confirmé leur contenu.

Les paquets embarquaient le code authentique du projet d'origine, mais y ajoutaient un script d'installation malveillant. Ce script téléchargeait et exécutait un script shell distant avec les privilèges root.

Andreas Reichel, mainteneur de l'AUR, a décrit l'un des paquets en détail.

"Le paquet se présente comme un simple réempaquetage de l'assistant AUR légitime 'yay' (même URL source, même archive source), mais le nom du paquet, 'yyay', et le scriptlet d'installation malveillant révèlent qu'il s'agit d'une usurpation piégée par un cheval de Troie, conçue pour se fondre dans le paysage aux côtés du vrai paquet", a averti Reichel.

Comme l'URL source et l'archive correspondaient au vrai projet, un rapide coup d'oeil au script de compilation n'aurait rien révélé d'anormal. La partie malveillante se trouvait dans le scriptlet d'installation, qui s'exécute pendant l'installation du paquet.

Un autre mainteneur, Emiliano Gandini Outeda, a publié une liste de paquets malveillants qui avaient déclenché des alertes sur son propre système. Les détections provenaient de règles de TrustSight, un outil open source de sécurité applicative qu'il développe.

L'équipe de l'AUR a banni le compte marchos1as et retiré les paquets malveillants du dépôt.

Une charge utile acheminée via la Wayback Machine

Selon Reichel, la charge utile n'était pas récupérée directement sur un serveur de l'attaquant. Le script d'installation la téléchargeait plutôt via une URL de la Wayback Machine. Cette URL pointait vers un dépôt personnel nommé hellscripter/install-scripts, hébergé sur GitFlic, un service russe d'hébergement de code.

Passer par un service d'archivage comme étape intermédiaire permet aux attaquants de faire transiter le trafic par un domaine de confiance, ce qui peut rendre le téléchargement moins suspect.

Un lien possible avec un ver npm

Le nom du dépôt n'est pas inconnu. L'entreprise de sécurité applicative SafeDep a récemment documenté une campagne npm qu'elle a baptisée "DirtyBlanket". Cette campagne récupérait du code depuis un dépôt portant le même nom, hellscripter/install-scripts, mais hébergé sur Codeberg.

Les chercheurs de SafeDep ont découvert un ver Linux dans cette activité. Il déployait le cheval de Troie d'accès à distance CHAOS, déguisé en service de polices de caractères, et injectait également un chargeur dans des paquets AUR.

Un avis OSV consacré à DirtyBlanket mentionne aussi le même domaine Wayback Machine et GitFlic que celui observé dans les derniers paquets AUR.

Ces recoupements sont notables, mais rien ne confirme pour l'instant que les deux opérations soient liées.

Une nouvelle attaque dans une série visant l'AUR

Ce n'est pas la première fois cette année que l'AUR est pris pour cible. En juin, 400 paquets ont diffusé un malware voleur d'identifiants doté de fonctions de rootkit. Une autre campagne, en juillet, a conduit l'équipe d'Arch à désactiver temporairement l'adoption de paquets, le mécanisme qui permet aux utilisateurs de reprendre des paquets orphelins.

Les utilisateurs d'Arch qui ont installé l'un des paquets suspects doivent considérer leur système comme compromis et prendre immédiatement des mesures correctives. Comme le script malveillant s'exécutait en root, l'attaquant a pu modifier n'importe quoi sur la machine touchée.

Notre analyse

Il s'agit de la troisième campagne visant l'AUR en quatre mois environ, ce qui laisse penser que les attaquants voient désormais le dépôt comme une porte d'entrée fiable vers les systèmes Linux. Le modèle qui fait l'utilité de l'AUR, avec des publications ouvertes et des paquets compilés par les utilisateurs, laisse aussi l'essentiel du contrôle à la communauté. Ici, la communauté a réagi vite, mais la détection reposait tout de même sur des bénévoles lisant les fils de la liste de diffusion et faisant tourner leurs propres outils.

Le choix des cibles en dit long. Les assistants AUR sont installés tôt et largement considérés comme fiables, et associer du code authentique du projet d'origine à un scriptlet d'installation dissimulé vise à passer un examen superficiel. Le même procédé, qui consiste à cacher des étapes malveillantes dans des scripts d'installation, se retrouve dans des campagnes comme l'opération malware npm MALFEX et dans des dépôts GitHub malveillants conçus pour paraître légitimes.

Pour les utilisateurs d'Arch, la leçon pratique est de vérifier soigneusement les noms des paquets et de lire les scripts d'installation, pas seulement les URL sources. Il faudra surveiller si le lien présumé avec DirtyBlanket se confirme, et si l'équipe d'Arch renforce les contrôles sur les nouvelles publications après cette dernière vague.