Un nouveau cas d’une cyberattaque de la chaîne d’approvisionnement. Elle a frappé l’Arch User Repository (AUR), un dépôt de paquets pour la communauté de la distribution Arch Linux.
Les attaquants ont compromis des centaines de paquets en prenant le contrôle de projets abandonnés par leurs mainteneurs, pour y injecter discrètement un code malveillant. Une offensive baptisée Atomic Arch qui ne repose pas sur une faille technique.
Comment cette attaque a-t-elle pu se propager ?
La méthode des attaquants, révélée notamment par les chercheurs de Sonatype, est particulièrement insidieuse. Ils ont ciblé des paquets orphelins pour en revendiquer la maintenance, un processus légitime au sein de l’AUR.
Une fois le contrôle obtenu, ils ont modifié les scripts de construction pour y ajouter une commande qui télécharge et installe un paquet npm malveillant nommé atomic-lockfile durant le processus de compilation.
Cette technique a permis au code malveillant de contourner la vigilance des utilisateurs, car le paquet AUR lui-même semblait authentique et conservait son nom et son historique de confiance.
L’attaque a connu une seconde vague en utilisant une méthode similaire, mais avec un autre paquet malveillant, js-digest. Pour tromper davantage les utilisateurs, les attaquants ont usurpé les métadonnées des commits Git afin de faire croire que les modifications provenaient de mainteneurs de longue date et de confiance.
Quels sont les risques pour les systèmes infectés ?
Le paquet atomic-lockfile déploie un binaire Linux écrit en Rust, agissant comme un voleur de données conçu pour les environnements de développement.
Le malware vise une large gamme d’informations : cookies et tokens des navigateurs basés sur Chromium, données de session des applications Electron comme Slack, Discord et Microsoft Teams, les clés SSH et les tokens d’accès pour GitHub, npm ou encore HashiCorp Vault.
Si le paquet a été installé avec des privilèges root, le malware peut activer un rootkit eBPF. Cette technologie lui permet de s’exécuter directement dans le noyau Linux pour dissimuler ses propres processus, fichiers et connexions réseau, rendant sa détection extrêmement difficile avec les outils standards.
Le malware assure sa persistance en créant un service systemd configuré pour se relancer automatiquement à chaque redémarrage.
Les mesures en cas de compromission
Pour Arch Linux, il est recommandé de considérer tout système affecté comme entièrement compromis.
La première étape consiste à vérifier la liste des paquets installés depuis l’AUR et de la comparer aux listes des paquets touchés compilées par la communauté. Il est impératif de procéder à la rotation de toutes les informations d’identification ciblées : mots de passe, clés SSH, jetons d’API, etc.
Si un paquet suspect a été exécuté avec les privilèges root, la présence du rootkit doit être présumée. Dans ce cas, la seule solution fiable est une réinstallation complète du système à partir d’un support de confiance.