Arch Linux AUR : plus de 400 paquets compromis par un vol de comptes et un rootkit eBPF

Cette semaine, des attaquants ont compromis plus de 400 paquets dans l’Arch User Repository (AUR), la collection communautaire de paquets d’Arch Linux. Leur méthode n’a pas exploité de faille technique dans Arch Linux lui-même, mais a détourné la chaîne de confiance de l’écosystème. Les scripts de construction de ces paquets ont été modifiés pour installer un binaire malveillant lors de la compilation ou de la mise à jour. Une fois exécuté, ce binaire agit comme un voleur de secrets et peut charger un rootkit eBPF pour se dissimuler dans le système. L’attaque s’appuie sur la compromission de comptes de mainteneurs inactifs ou sur la création de faux profils pour publier des paquets modifiés. Les victimes sont principalement les utilisateurs d’Arch Linux qui installent ou mettent à jour des paquets AUR depuis le 11 juin.

Une attaque ciblant la chaîne de confiance, pas une faille logicielle

L’Arch User Repository est une plateforme communautaire où les utilisateurs partagent des paquets non officiels pour Arch Linux. Contrairement aux dépôts officiels maintenus par l’équipe d’Arch, l’AUR repose sur la contribution bénévole et la confiance dans les mainteneurs. Dans cette campagne, les attaquants ont identifié des paquets abandonnés — c’est-à-dire des projets sans mainteneur actif — et ont pris le contrôle des comptes ou créé de nouveaux profils pour adopter ces paquets. Ensuite, ils ont modifié les fichiers de construction, notamment le PKGBUILD ou les scripts .install, pour y intégrer une commande malveillante.

Cette approche ne nécessite pas d’exploiter une vulnérabilité dans Arch Linux ou dans le logiciel lui-même. Les paquets conservent leur nom, leur historique et leur apparence légitime. Seuls les scripts de construction sont altérés, ce qui rend l’attaque difficile à détecter visuellement. L’objectif est clair : exploiter la confiance que les utilisateurs accordent au système de paquets AUR pour faire exécuter du code malveillant sur leur machine au moment de la compilation ou de l’installation. Cette méthode rappelle les attaques par typosquatting ou par détournement de comptes, mais ici, le vecteur est la chaîne de confiance de l’écosystème AUR.

Le payload : un voleur de secrets en Rust et un rootkit eBPF

Une fois installé, le malware se présente sous la forme d’un binaire ELF compilé en Rust, un langage souvent utilisé pour sa performance et sa sécurité mémoire. Ce binaire, nommé deps, est téléchargé via un paquet npm malveillant, atomic-lockfile@1.4.2, qui se fait passer pour une dépendance légitime. Ce paquet npm inclut un hook preinstall qui exécute deps lors de la construction du paquet AUR. Le binaire deps agit alors comme un voleur de secrets, conçu pour cibler les environnements de développement et les systèmes de build.

Selon les analyses d’un chercheur indépendant, ce malware collecte des fichiers sensibles sur le système, notamment des clés SSH, des jetons d’API, des mots de passe stockés dans des fichiers de configuration ou des environnements de développement. Les données volées sont ensuite exfiltrées via une connexion HTTP vers un serveur temporaire hébergé sur temp.sh. Le serveur de commande et contrôle est accessible uniquement via un service onion de Tor, ce qui rend son identification plus difficile. Pour maintenir sa persistance, le malware installe un service systemd avec une politique de redémarrage automatique. Si le malware s’exécute avec les droits root, il se copie dans /var/lib/ et installe une unité système dans /etc/systemd/system/. En revanche, s’il s’exécute avec les droits d’un utilisateur normal, il utilise le répertoire personnel et installe une unité utilisateur dans ~/.config/systemd/user/.

Cette double stratégie de persistance montre que les attaquants ont conçu le malware pour survivre aussi bien sur des postes de travail que sur des serveurs de build, où les droits root sont souvent disponibles.

Comment les attaquants ont infiltré l’AUR : faux profils et métadonnées Git falsifiées

Pour publier les paquets modifiés, les attaquants ont adopté plusieurs tactiques. La première consiste à cibler les paquets abandonnés, c’est-à-dire ceux dont le mainteneur original n’est plus actif. Ces paquets sont souvent faciles à adopter par quiconque souhaite en prendre la maintenance. Les attaquants ont ensuite modifié les fichiers de construction pour y ajouter la commande malveillante. Une autre tactique consiste à créer de faux profils de mainteneurs, en imitant des comptes existants ou en utilisant des noms proches de ceux de contributeurs connus.

Une technique particulièrement sophistiquée a été observée : la falsification des métadonnées Git. Les attaquants ont modifié les commits dans les dépôts Git des paquets pour faire croire que les changements provenaient d’un mainteneur de confiance, un compte “Trusted User” d’Arch Linux. Cependant, après investigation, il a été confirmé que ce compte n’avait jamais été compromis. Les modifications semblaient légitimes, car elles étaient signées avec la clé GPG du faux compte. Cette technique illustre une attaque par usurpation d’identité, où la confiance dans la signature cryptographique est exploitée pour tromper les utilisateurs et les outils de vérification.

Impact : qui est touché et quels sont les risques ?

Les utilisateurs les plus exposés sont ceux qui installent ou mettent à jour des paquets AUR depuis le 11 juin. Si un paquet compromis est installé ou reconstruit, le binaire deps est exécuté automatiquement pendant la phase de construction. Cela signifie que même un utilisateur prudent, qui vérifie les sources et les signatures, peut être piégé si le paquet lui-même est compromis en amont. Les systèmes de build automatisés, comme ceux utilisés dans les environnements CI/CD ou les machines de développement partagées, sont particulièrement vulnérables, car ils exécutent souvent des commandes avec des droits élevés.

Une fois installé, le malware peut voler des secrets sensibles, notamment des clés de chiffrement, des jetons d’accès à des services cloud ou des identifiants de base de données. Ces informations peuvent ensuite être utilisées pour accéder à des infrastructures critiques, lancer des attaques par rebond ou exfiltrer des données supplémentaires. Le rootkit eBPF, bien que plus complexe à déployer, permet au malware de se cacher des outils de détection standard, comme les commandes ps ou top, en manipulant les appels système au niveau du noyau. Cette capacité à rester invisible rend l’attaque particulièrement dangereuse, car elle peut persister pendant des semaines ou des mois avant d’être détectée.

Que faire si vous avez installé un paquet AUR depuis le 11 juin ?

La première étape consiste à vérifier si vous avez installé l’un des paquets listés comme compromis. Arch Linux et la communauté publient des listes mises à jour régulièrement, mais ces listes peuvent encore évoluer. Même si un paquet n’apparaît pas dans les listes actuelles, il est recommandé de le désinstaller et de le reconstruire à partir des sources officielles si possible. Si vous avez utilisé un gestionnaire de paquets comme yay ou paru, vérifiez les journaux d’installation pour repérer toute commande suspecte, notamment l’installation de dépendances npm inattendues.

Ensuite, inspectez votre système à la recherche de processus ou de services inconnus. Utilisez des outils comme systemctl list-units --all pour lister tous les services systemd, ou journalctl pour consulter les journaux système. Recherchez des unités liées à deps, atomic-lockfile ou tout autre nom suspect. Si vous suspectez une infection, redémarrez votre machine en mode sans échec et supprimez manuellement les fichiers et services suspects. Enfin, changez tous vos mots de passe et jetons d’API, en particulier ceux utilisés sur des machines où des paquets AUR ont été installés.

Pourquoi cette attaque est un signal d’alerte pour l’écosystème Linux

Cette campagne met en lumière plusieurs faiblesses structurelles de l’écosystème des paquets communautaires. D’abord, la confiance dans les mainteneurs et les dépôts communautaires est souvent implicite, sans vérification approfondie des modifications. Ensuite, les outils de construction, comme PKGBUILD, exécutent du code arbitraire par conception, ce qui en fait une cible idéale pour les attaquants. Enfin, l’absence de sandboxing strict pendant la construction des paquets expose les systèmes à des risques élevés.

Cette attaque rappelle des incidents similaires dans d’autres écosystèmes, comme les attaques par typosquatting sur npm ou PyPI, où des paquets malveillants sont publiés sous des noms proches de bibliothèques populaires. Cependant, la différence ici est que les attaquants n’ont pas eu besoin de créer de faux paquets : ils ont compromis des paquets existants et de confiance. Cela montre que la menace ne vient pas seulement des nouveaux dépôts, mais aussi de l’intérieur des écosystèmes établis.

Comment Arch Linux et la communauté peuvent renforcer la sécurité

Pour limiter les risques futurs, plusieurs mesures peuvent être envisagées. D’abord, renforcer la vérification des comptes de mainteneurs, notamment pour les paquets abandonnés. Arch Linux pourrait mettre en place un processus de validation plus strict pour les nouvelles maintenances ou les transferts de paquets, avec une vérification manuelle des modifications significatives. Ensuite, introduire des mécanismes de sandboxing pendant la construction des paquets, par exemple en utilisant des conteneurs ou des machines virtuelles éphémères pour isoler la phase de build.

Une autre piste est l’amélioration des outils de détection des modifications suspectes dans les dépôts Git. Par exemple, des alertes automatiques pourraient être déclenchées si des commits sont ajoutés à des paquets inactifs depuis longtemps, ou si des métadonnées de signature semblent falsifiées. Enfin, la communauté pourrait promouvoir l’utilisation de signatures de paquets plus robustes, ou même l’adoption de systèmes de réputation pour les mainteneurs, afin de mieux évaluer leur fiabilité.

Que surveiller à l’avenir ?

Cette attaque marque probablement le début d’une série de campagnes similaires ciblant les écosystèmes de paquets communautaires. Les attaquants ont montré qu’ils pouvaient exploiter la chaîne de confiance sans avoir besoin de compromettre les infrastructures centrales. À l’avenir, il est probable que d’autres dépôts communautaires, comme ceux de Debian, Fedora ou Gentoo, soient ciblés de la même manière. Les développeurs et les administrateurs système doivent donc rester vigilants et adopter des pratiques de sécurité strictes, notamment en vérifiant régulièrement les dépendances et en limitant les droits des utilisateurs.

Il est également important de surveiller l’évolution des techniques utilisées par les attaquants. L’utilisation d’un rootkit eBPF montre qu’ils cherchent à améliorer leur furtivité et leur persistance. À l’avenir, nous pourrions voir l’adoption de techniques encore plus avancées, comme l’exploitation de vulnérabilités dans le noyau Linux ou l’utilisation de contournements des outils de détection basés sur eBPF.

Conclusion

Cette attaque contre l’Arch User Repository illustre une menace croissante pour les écosystèmes de logiciels libres : l’exploitation de la confiance plutôt que l’exploitation de failles techniques. En détournant des paquets abandonnés et en falsifiant des métadonnées, les attaquants ont réussi à installer un voleur de secrets et un rootkit sur des machines cibles, sans avoir besoin de compromettre les infrastructures centrales d’Arch Linux.

Pour les utilisateurs d’Arch Linux, la vigilance est de mise. Vérifiez vos installations récentes, inspectez vos systèmes et adoptez des bonnes pratiques de sécurité. Pour la communauté et les mainteneurs, cette attaque doit servir de signal d’alerte pour renforcer les mécanismes de vérification, de sandboxing et de détection des modifications suspectes. Enfin, cette campagne rappelle que la sécurité des écosystèmes de logiciels libres repose sur la confiance, et que cette confiance doit être constamment réévaluée pour résister aux attaques toujours plus sophistiquées.