La trahison de l'AUR : comment une attaque contre la chaîne d'approvisionnement a transformé les paquets orphelins en un vol de lettres de créances et une persistance cachée

La dernière vague contre l'Arch User Repository (AUR) nous force à repenser la façon dont nous faisons confiance aux paquets communautaires : les attaquants ont pris le contrôle de centaines de paquets « orphelins », ont modifié seulement leurs instructions de construction (PKGBUILD / .install) et ont réussi à obtenir des machines de développement pour exécuter un binaire Rust conçu pour voler des identifiants. La partie clé de l'attaque n'était pas un échec dans Arch ou un jour zéro, mais l'exploitation du modèle de confiance de l'AUR : nom et histoire intacts, changement de responsable.

Ce qui s'est passé en termes techniques: les adversaires ont adopté des paquets abandonnés, des appels insérés tels que npm installer atomique-lockfile ou bun installer js-digest pendant la compilation et ainsi traîné un paquet npm malveillant qui exécute un ELF appelé deps dans le processus de construction. Ce binaire collecte des jetons de navigateurs et d'applications électroniques, des clés SSH, des identifiants de conteneur, des données Vault et même du matériel OpenAI / ChatGPT, et des exfiltres aux services publics (temp.sh). Si vous exécutez avec des privilèges root, vous pouvez installer un service persistant et charger en option un module eBPF qui masque les processus, les noms et les sockets; le rootkit-eBPF est accessoire mais augmente la gravité car il complique le nettoyage. Pour l'analyse technique et l'ensemble des indicateurs, voir le rapport communautaire et l'analyse médico-légale de l'échantillon: Sonatype - Arche atomique et ioctl.fail - analyse et signaux.

Incidences pratiques : si vous avez construit ou mis à jour un paquet de l'AUR depuis le 11 juin, il ne suffit pas de croire que la suppression du paquet du gestionnaire laisse le système propre. Une fois la charge utile exécutée avec des privilèges suffisants, l'agresseur peut laisser la persistance, voler des secrets et, dans le pire des cas, cacher sa présence avec eBPF. Le nombre initial de paquets engagés a atteint des centaines et continue de fluctuer: la voie d'exposition n'était pas le téléchargement direct du paquet npm (atomic- lockfile avait très peu de téléchargements hebdomadaires), mais le canal de construction sur l'AUR.

Que vérifier immédiatement sur une équipe suspecte : vérifier le log et les caches de makepkg / build (recherche de traces de npm installer atomique-lockfile, bun installer js-digest ou des itinéraires tels que src / hooks / deps), inspecter les unités système à la fois au niveau du système et de l'utilisateur pour des services inconnus, explorer / var / lib / par artefacts et / sys / fs / bpf / par des cartes nommées comme cachées _ péds, cachées _ noms ou cachées _ inodes. Surveiller les connexions sortantes inhabituelles, en particulier aux nœuds Tor ou services de montée, et comparer binaire suspect avec des haches publiés par les chercheurs. Si le binaire a couru avec racine, la chose sage est de faire l'engagement de la machine et de réinstaller des moyens de confiance.. Les repos officiels de l'AUR et de l'Arche sont différents; les repos officiels n'ont pas été affectés, mais cela ne nettoie pas un système local compromis.

Mesures de confinement et de rétablissement : Si une compilation a exécuté l'une des charges utiles, lancez immédiatement tout secret que les logiciels malveillants peuvent avoir lu : sessions et cookies de navigateur, jetons GitHub et npm, clés SSH, identifiants Vault, identifiants Docker / Podman, profils VPN et clés Cloud. Récupérer et régénérer les clés et les jetons d'une autre machine propre connue. Rechercher et supprimer des services et fichiers système inconnus dans des endroits persistants; toutefois, rappelez-vous qu'une rootkit capable de se cacher pourrait empêcher une détection fiable. Par conséquent, lorsqu'il y a un signe d'exécution avec des privilèges, le seul moyen sûr de retrouver confiance est de réinstaller le système des moyens vérifiés et de restaurer les données des sauvegardes précédentes et examinées.

Prévention à moyen et à long terme: traiter les paquets nouvellement adoptés ou qui sont restés endormis comme potentiellement risqués. Ne pas construire AUR aveuglément: lire le PKGBUILD et les crochets .install avant d'exécuter makepkg, et si vous ne comprenez pas les étapes de construction s'abstenir. Valore construit des paquets dans des environnements isolés : machines virtuelles éphémères, conteneurs ou chroots sans accès à des identifiants sensibles. Pour les projets maintenus par la communauté, observez l'historique de l'entretien et les signes d'adoption récente; les agresseurs exploitent précisément cette fenêtre de confiance. Les ressources officielles et les guides de sécurité en AUR sont disponibles dans la documentation Arch : AUR et le Wiki of Arch sur la politique de paquetage et la sécurité.

Enfin, la leçon est structurelle : les chaînes d'approvisionnement qui délèguent confiance dans les noms et l'histoire sans valider l'identité et l'intention du mainteneur sont fragiles. Les équipes devraient intégrer des contrôles qui réduisent le rayon d'explosion d'un bâtiment peu fiable : séparation des rôles, environnements de compilation dédiés, examen humain des scripts de construction et rotation fréquente des secrets. Pour les indicateurs techniques, les hachages et la liste récapitulative des paquets concernés suivent la recherche publique (l'analyse et l'ensemble des CIO sont collectés par la communauté et par des chercheurs comme ceux liés ci-dessus).