AUR (Arch Linux) infecté ! Synthèse de l'attaque et réponses aux questions !

SYNTHÈSE STRUCTURÉE

Contexte de l’attaque : des paquets orphelins ciblés

Le 11 juin 2026, un attaquant utilisant le pseudonyme « Aroras » a méthodiquement adopté des paquets abandonnés sur l’AUR. En quelques heures, plus de 400 paquets étaient compromis, puis 1 621 le lendemain. L’attaquant a automatisé la découverte de paquets orphelins très populaires (nombreux votes, bonne réputation) pour maximiser l’impact tout en minimisant les soupçons. Comme le souligne l’intervenant : « ils ont pas pris les paquets où il y avait juste un vote et puis rien du tout. Ils ont pris dans l’ordre des paquets des plus voté, des plus populaires au moins populaires qui étaient sans mainteneur. »

Fonctionnement de l’AUR et point faible exploité

L’AUR est un dépôt communautaire d’Arch Linux contenant plus de 100 000 paquets. Un paquet AUR ne distribue pas de binaires précompilés (sauf suffixe -bin) mais fournit un fichier PKGBUILD : une recette de construction avec les sources, dépendances et instructions de compilation (prepare(), build(), package()). Le point faible est l’adoption sans délai ni audit : quand un mainteneur abandonne un paquet, n’importe quel compte AUR peut le reprendre et hérite instantanément de toute sa confiance accumulée. L’intervenant insiste : « ce nouveau mainteneur va hériter instantanément de toute la confiance accumulée par ce paquet au fil des années. »

Premier vecteur : injection via npm dans le PKGBUILD

L’attaquant a modifié les PKGBUILD des paquets adoptés en ajoutant une dépendance npm et un script post_install. Ce script exécute npm install qui va chercher le paquet malveillant atomic-lock-file depuis le registre npm officiel. L’intervenant explique : « visuellement, le paquet AUR semble relativement propre parce qu’on ignore que le npm install va installer des paquets malveillants. » L’utilisateur qui installe ou met à jour le paquet via yay, trizen ou pamac déclenche cette chaîne.

Deuxième vecteur : obfuscation via Bun

Le lendemain, un second vecteur utilisant Bun (un runtime JavaScript) est apparu pour contourner les premières détections. Les commandes sont obfusquées avec du découpage de chaînes shell, des guillemets mixtes et des séquences hexadécimales. L’intervenant montre un exemple : « on a un cd /tmp && bun add et ça va installer le next-file.js. » Cette double stratégie a permis à l’attaque de continuer à se propager pendant que la communauté se concentrait sur le premier vecteur.

Capacités du malware : vol de données étendu

Le malware, écrit en Rust et précompilé en 64 bits (3 Mo), vole :

• Clés SSH
• Profils Chromium (cookies de session, stockage local) – ce qui permet de contourner la MFA
• Bases SQLite de Firefox (mots de passe)
• Tokens GitHub et API
• Identifiants npm, Docker, Podman
• Fichiers de configuration VPN
• Informations depuis HashiCorp Vault
• Données des applications basées sur Electron (Slack, Teams, Discord)

L’intervenant prévient : « si vous contribuez à des paquets npm ou à des images Docker, et ben si l’attaquant reprend vos identifiants et fait des modifications sur les images Docker, ben c’est votre système qui peut être compromis. »

Persistance via systemd et rootkit eBPF

Le malware s’installe de façon persistante :

• En tant que root : copie dans /var/lib et création d’un service systemd dans /etc/systemd/system/
• En tant qu’utilisateur : service systemd utilisateur dans ~/.config/systemd/user/
• Redémarrage automatique : si le processus est tué, il se relance au bout de 30 secondes

Si exécuté avec les droits root, un rootkit basé sur eBPF est activé. L’intervenant détaille : « il va intercepter les appels systèmes de listage de fichiers et de processus. Si vous exécutez un ps, top, htop, nett, ss, il va obfusquer les résultats. » Les commandes standard ne montrent donc ni les processus, ni les fichiers, ni les connexions réseau du malware.

Exfiltration des données

Les données collectées sont envoyées via le service temp.sh (HTTP), puis les métadonnées sont postées vers une adresse .onion (Tor). L’intervenant précise que tout est obfusqué dans le binaire.

Détection : commande et script dédié

Pour vérifier si un paquet AUR a été installé ou mis à jour depuis le 11 juin 2026, l’intervenant recommande d’utiliser la commande suivante (adaptée pour un système en français) :

pacman -Qi $(pacman -Qqm) | grep -E "Nom|Installation"

Il faut ensuite consulter le PKGBUILD de chaque paquet suspect sur l’AUR et vérifier l’absence de dépendances npm ou bun et de scripts post_install. Un script de détection spécialisé est également disponible sur GitHub, développé par la communauté Arch Linux. Il vérifie les paquets installés dans la fenêtre de tir, les services systemd persistants, la présence du rootkit et les paquets connus comme compromis.

Procédure d’analyse sur système potentiellement infecté

L’intervenant met en garde : « si vous suspectez une infection de votre machine, ne faites pas ces vérifications depuis le système compromis puisque le root kit va masquer tout. » Il faut démarrer depuis un live USB Arch, monter le système de fichiers et analyser depuis un chroot. Cela garantit que le rootkit n’est pas actif.

CONCEPTS CLÉS

• AUR (Arch User Repository) : dépôt communautaire d’Arch Linux contenant des paquets non officiels, maintenus par les utilisateurs. Les paquets sont distribués sous forme de PKGBUILD (recette de compilation) et non de binaires précompilés.
• PKGBUILD : fichier de construction d’un paquet Arch Linux. Il contient les métadonnées (nom, version, dépendances) et les fonctions prepare(), build() et package().
• Paquet orphelin : paquet AUR dont le mainteneur a abandonné la maintenance. Il reste disponible et peut être adopté par n’importe quel utilisateur sans délai ni audit.
• eBPF (extended Berkeley Packet Filter) : technologie du noyau Linux permettant d’exécuter des programmes sandboxés dans le noyau. Détournée ici pour masquer les processus, fichiers et connexions réseau du malware.
• Rootkit : ensemble de programmes ou de modifications du système conçu pour masquer la présence d’un logiciel malveillant (processus, fichiers, connexions réseau).

CONCLUSION

L’attaque « Atomic Arch » n’est pas une faille de sécurité d’Arch Linux elle-même, mais une exploitation du modèle de confiance hérité de l’AUR. L’adoption sans vérification d’un paquet orphelin permet à un attaquant d’hériter instantanément de toute sa réputation. Comme le résume l’intervenant : « ce modèle, Arch Linux, il va devoir changer. » Pour tout administrateur utilisant Arch Linux ou une dérivée (Manjaro, EndeavourOS, Garuda), il est impératif de vérifier les paquets AUR installés depuis le 11 juin 2026, d’analyser leurs PKGBUILD et, en cas de doute, d