Arch Linux : 400 paquets AUR vérolés, êtes-vous infecté ?

Oui, je suis en train de vous écrire depuis mon bureau, un café à la main, et je viens de recevoir un appel paniqué d’un client qui venait de s’apercevoir que son Arch tournait avec trois paquets AUR Arch Linux vérolés. Trois. Juste ceux dont il avait besoin pour son serveur de jeux. Le pire ? Il a mis trois jours à s’en rendre compte. Trois jours pendant lesquels il a partagé ses logins Steam et battle.net avec un inconnu. Mine de rien, c’est le genre de truc qui fait pleurer un admin système.

Alors aujourd’hui, je vais vous expliquer pourquoi cette campagne Atomic Arch n’est pas juste une petite attaque de plus. C’est un vrai piège à débutants, et même les vieux routards comme moi en ont vu des vertes et des pas mûres. Surtout quand on passe par l’AUR.

Et accessoirement, si vous avez Arch Linux sur votre machine (ou pire, sur votre serveur), lisez ça jusqu’au bout.

—

L’AUR : le Far West des paquets Linux (et des emmerdes)

Déjà, pour ceux qui ne savent pas, l’AUR (Arch User Repository), c’est ce dépôt communautaire où n’importe qui peut balancer un paquet. N’importe qui. Oui, même votre cousin qui a suivi un tuto YouTube de 2017 sur “comment compiler un kernel”. Résultat : des trucs qui marchent, des trucs qui plantent, et maintenant, des trucs qui volent vos mots de passe.

Cette fois, c’est Sonatype qui a repéré la manip’ : un seul attaquant a réussi à injecter un stealer dans 400 paquets différents. 400. Vous imaginez le bordel ? Un seul faux paquet, et hop, votre machine devient un espadon pour hackers. Autant dire que si vous avez installé un logiciel depuis l’AUR cette semaine, vous êtes peut-être déjà infecté.

D’ailleurs, mon client de la semaine dernière ? Il utilisait un paquet AUR pour gérer ses serveurs Minecraft. Un minecraft-server-manager-git ou un truc du style. Sauf que le gars qui l’a compilé (oui, en mode “git clone puis makepkg”) avait laissé traîner un petit script en Python qui récupérait ses cookies Firefox. Du coup, en trois jours, il s’est fait voler son compte GitHub, son Discord, et accessoirement, les données de ses clients. Génial.

Le pire ? Les paquets vérolés étaient signés. Oui, vous avez bien lu. Le pirate avait réussi à faire signer ses paquets par un maintainer de l’AUR. Comment ? Mystère. Mais ça prouve une chose : l’AUR est un nid à problèmes, et si vous y touchez sans savoir ce que vous faites, vous finirez comme mon client – avec un serveur compromis et trois mots de passe à changer.

—

Comment vérifier si vous êtes infecté (et que faire si c’est le cas)

Alors, concrètement, comment savoir si un de vos paquets AUR Arch Linux est vérolé ? Déjà, commencez par vérifier la liste des paquets suspects. Sonatype en a publié une liste complète. Si vous avez installé l’un de ceux-là depuis le 11 juin, foncez vérifier :

• Ouvrez un terminal et lancez : pacman -Qm (pour lister les paquets AUR installés).
• Comparez la liste avec la liste des paquets compromis sur leur dépôt GitHub.
• Si un match est trouvé, désinstallez-le immédiatement avec : yay -Rns (ou paru -Rns si vous utilisez paru).

Mais attention, ça ne suffit pas. Parce que le pire, c’est que le stealer est conçu pour persister. Il peut s’installer en tant que service, modifier vos variables d’environnement, ou même remplacer des binaires système. Du coup, la meilleure pratique ?

Au cas où, voici ce que je fais avec mes clients :

• Réinstallez tout depuis zéro. Oui, c’est violent, mais c’est le seul moyen d’être sûr. Sauvegardez vos données, mais pas vos configs si elles viennent de l’AUR.
• Changez tous vos mots de passe. Le stealer a probablement récupéré vos cookies et identifiants. Tous. Votre session GitHub, votre compte Amazon, votre banque… Tout.
• Vérifiez les processus suspects avec htop ou ps aux | grep -i python. Si vous voyez un truc bizarre qui tourne, tuez-le. Immédiatement.

Et pour finir, arrêtez d’utiliser l’AUR n’importe comment. Oui, je sais, c’est pratique. Mais c’est aussi une porte ouverte sur votre machine. Si vous devez absolument installer un paquet depuis l’AUR, faites-le comme un pro :

• Lisez le PKGBUILD avant de compiler. Oui, c’est chiant. Mais c’est la seule façon de voir s’il y a du code malveillant.
• Utilisez un outil comme namcap pour vérifier la validité du paquet.
• Installez dans un environnement sandboxé si possible. Un docker ou un bubblewrap peut limiter les dégâts.

Mon client a appris ça à ses dépens. Et moi, j’ai passé une journée à nettoyer son serveur. Ne soyez pas comme lui.

—

Atomic Arch : une attaque trop bien organisée

Alors, cette campagne Atomic Arch, c’est du grand art. Ou du grand n’importe quoi, selon comment vous voyez les choses. Les chercheurs de Sonatype ont découvert que le pirate avait réussi à compromettre plusieurs maintainers de l’AUR. Comment ? Mystère. Mais une fois à l’intérieur, il a pu introduire son code malveillant dans des paquets légitimes.

Le truc qui m’a fait tiquer ? Le stealer était modulaire. Il pouvait récupérer des mots de passe, des cookies, des clés SSH, voire même des fichiers de configuration. Autant dire que si vous aviez un paquet vérolé, vous étiez bon pour une session de “changer tous mes identifiants” de trois heures.

Et le pire ? Le pirate a utilisé des techniques de stéganographie pour cacher son code. Certains paquets vérolés contenaient des scripts Python qui décodaient des payloads cachés dans des images ou des fichiers audio. Oui, vous avez bien lu. Un paquet AUR a pu installer un stealer en vous faisant croire que c’était un simple script de configuration.

D’ailleurs, je me souviens d’un client il y a deux ans qui avait installé un paquet pour son bureau GNOME. Le paquet s’appelait gnome-themes-extra-git. Sauf que derrière, il y avait un script qui récupérait ses clés WiFi et les envoyait à un serveur en Russie. Du coup, pas besoin d’être un génie pour comprendre que l’AUR, c’est un champ de mines.

Alors pourquoi cette attaque est différente ? Parce que cette fois, le pirate a ciblé des paquets populaires. Pas juste des trucs obscurs utilisés par trois personnes sur Terre. Non. Il a touché des paquets qui servaient à des milliers de gens. Et ça, c’est le rêve pour un hacker.

—

L’AUR est-il mort ? Faut-il fuir Arch Linux ?

Alors là, je vais vous faire une réponse de technicien : ça dépend. Oui, je sais, c’est chiant. Mais c’est la vérité.

Si vous êtes un utilisateur lambda qui installe trois paquets par an depuis l’AUR, vous êtes en danger. Parce que le moindre faux paquet peut vous infecter. Et le pire, c’est que vous ne vous en rendrez peut-être même pas compte.

Mais si vous êtes un admin système qui prend le temps de vérifier chaque PKGBUILD, vous pouvez continuer à utiliser l’AUR. À condition de suivre quelques règles strictes :

D’abord, ne jamais installer un paquet AUR sans savoir ce qu’il fait. Oui, c’est chiant. Oui, ça prend du temps. Mais c’est la seule façon d’éviter les emmerdes.

Ensuite, utilisez un gestionnaire de paquets fiable. yay ou paru sont bien, mais ils ne vous protègent pas à 100%. Pour ça, il faut aller plus loin :

• Vérifiez les signatures : gpg --verify .sig .pkg.tar.zst
• Lancez les paquets dans un conteneur : bwrap --ro-bind / / --dev /dev --proc /proc --unshare-all --die-with-parent ./install.sh
• Surveillez les processus suspects : journalctl -xe ou auditd

Et enfin, envisagez de migrer vers les dépôts officiels. Oui, c’est moins flexible. Oui, il y a moins de choix. Mais au moins, vous êtes sûr que les paquets ont été vérifiés par l’équipe d’Arch. Du coup, si vous n’avez pas vraiment besoin de l’AUR, allez-y carrément.

Moi, perso, je conseille à mes clients de supprimer l’AUR de leurs machines si ils ne savent pas ce qu’ils font. Parce que le jeu n’en vaut pas la chandelle. Un paquet vérolé, et c’est l’infection garantie.

Et puis, franchement, Arch Linux sans AUR, c’est toujours Arch Linux. Juste un peu moins customisable. Mais au moins, vous garderez vos mots de passe.

—

Conclusion : et maintenant, on fait quoi ?

Alors, que retenir de tout ça ?

D’abord, l’AUR est dangereux. Pas toujours, pas pour tout le monde, mais assez pour que vous preniez des précautions. Si vous l’utilisez, faites-le en conscience. Vérifiez, relisez, testez. Ne faites pas confiance aveuglément.

Ensuite, vérifiez vos machines. Si vous avez Arch Linux, lancez un pacman -Qm et comparez avec la liste des paquets vérolés. Si vous avez un match, agissez vite.

Et enfin, réfléchissez à deux fois avant d’utiliser l’AUR. Est-ce que vous en avez vraiment besoin ? Si la réponse est non, restez sur les dépôts officiels. C’est moins fun, mais c’est bien plus sûr.

Moi, je vais retourner à mon atelier. Un client vient de m’appeler pour un problème similaire. Mine de rien, les attaques par paquets AUR, c’est devenu mon pain quotidien. Et chaque fois, je me dis que Windows n’a même pas besoin de faire de mise à jour pour tout casser. Linux, lui, se casse tout seul.

Alors, prenez soin de vos machines. Et surtout, ne faites pas n’importe quoi avec l’AUR.

Source : article original