Des centaines de paquets AUR touchés par une attaque de malware voleur d’informations
(lists.archlinux.org)- Une attaque de la chaîne d’approvisionnement a visé l’AUR (Arch User Repository) avec l’insertion de nombreux commits malveillants, modifiés pour exécuter
npm install atomic-lockfilependant l’installation des paquets - Une recherche dans un miroir en lecture seule a confirmé la même commande malveillante dans les fichiers PKGBUILD,
.installet.hookd’environ 408 paquets - Les commits malveillants utilisent une méthode de falsification de commit qui usurpe le nom et l’e-mail du commit précédent pour se faire passer pour le mainteneur légitime, indépendamment d’un éventuel piratage de compte
- Côté Arch, des opérations de réinitialisation/suppression des commits malveillants et de blocage des comptes sont en cours, avec demande de signaler tout paquet malveillant supplémentaire dans un seul et même fil
- Des membres de la communauté signalent successivement les commits de paquets concernés, dans le cadre d’une réponse collaborative à un incident majeur affectant l’ensemble de l’écosystème des paquets AUR
Vue d’ensemble de l’incident et appel à réaction
- Des indices d’une insertion massive de commits malveillants dans l’AUR ont été partagés, et les opérations de réinitialisation/suppression des commits malveillants ainsi que de blocage des comptes sont en cours
- En cas de découverte d’autres paquets malveillants, il est demandé de les signaler en répondant à cet e-mail afin de les regrouper dans le même fil
- La personne chargée de la coordination a répondu avoir bien consulté tous les signalements reçus et a remercié les participants pour le temps consacré aux remontées
Schéma du code malveillant — atomic-lockfile
- Les paquets altérés exécutent tous
npm install atomic-lockfile, suivi de noms d’autres paquets npm commeora,fast-glob,glob,minimist,axios,commander,execa,chalk,debug, entre autres - Types de fichiers où se trouvait la commande malveillante
- scripts d’installation de type
*-deps.install - scripts d’installation de paquet
*.install - fichiers
*.hook— par exemple sous la formeExec = /bin/sh -c 'cd /tmp && npm install atomic-lockfile ... 2>/dev/null; exit 0', exécutée depuis/tmppuis terminée en masquant les erreurs - dans certains cas, incluse dans des fichiers associés comme
install.sh
- scripts d’installation de type
- Un exemple de nouveau paquet malveillant,
exodus-wallet-bin, a été signalé ; il s’agissait d’un paquet tout juste créé, apparu environ 4 heures plus tôt au moment du premier commit
Méthode de détection et étendue de l’impact
- La détection a été effectuée en inspectant directement un miroir en lecture seule
- après
git clone https://github.com/archlinux/aur.git, parcours de toutes les refs puis exécution degit grep 'atomic-lockfile' - cela a permis d’obtenir une longue liste d’environ 408 paquets installant
atomic-lockfile, exploitable pour un nettoyage automatisé
- après
- Exemples de paquets mentionnés comme affectés
runescape-launcher,oracle-bin,tesseract-gui,python-starsessions,bitcoin-core-git,apple-music-desktop,exodus-wallet-bin,anythingllm-appimage,arm-linux-gnueabihf-binutils, entre autres- y compris de vastes familles de paquets comme
cutefish-*,python2-*etpython-*
- Face au grand nombre d’e-mails générés par les signalements individuels, il a été recommandé de regrouper plusieurs cas dans un seul message, et une liste consolidée des paquets a aussi été partagée séparément sur IRC
Méthode d’usurpation/falsification
- Pour des paquets liés à un compte donné (
arojas), des questions ont été soulevées sur un éventuel piratage de compte ou une falsification de commit - Il a été confirmé que les commits malveillants usurpaient le nom et l’adresse e-mail du commit précédent (
impersonate) — autrement dit, une falsification des métadonnées du commit - Il a aussi été signalé que d’autres paquets du même utilisateur avaient déjà été corrigés
État de la réponse
- Les commits de paquets signalés ont été traités progressivement, et certains éléments ont reçu une réponse corrigé (Done)
- À mesure que de nouveaux signalements arrivaient, la personne chargée de la coordination a vérifié l’ensemble des remontées, en parallèle des opérations de blocage et de réinitialisation en cours
- De nombreux participants ont signalé des paquets individuels avec des liens vers les commits, dans le cadre d’une réponse collaborative pilotée par la communauté
1 commentaires
Avis sur Lobste.rs
J’ai l’impression que cet incident va presque achever la confiance qui subsistait encore dans les contributions anonymes et non vérifiées de la communauté
On a l’impression de voir la confiance se faire grignoter en temps réel
Nous confions beaucoup trop de données personnelles et sensibles à nos ordinateurs, qui sont devenus le centre de la vie moderne. Quand un ordinateur personnel est infecté, c’est un événement vraiment catastrophique, et au mieux il ne reste qu’à espérer que je ne sois pas assez intéressant pour qu’un hacker veuille s’acharner spécifiquement sur moi
Et pourtant, pour une raison ou une autre, nous avons normalisé le fait d’exécuter n’importe quel programme aléatoire avec les pleins pouvoirs[1], puis nous faisons semblant d’être surpris chaque fois que cela se révèle être une mauvaise idée
[1] Du point de vue des privilèges de l’utilisateur actuel. Dans la plupart des configurations, root est pratiquement dénué de sens
J’imagine un système qui proposerait ce type d’options lors de l’installation ou de la mise à jour d’un paquet AUR : attendre une semaine pour qu’un paquet récemment mis à jour « refroidisse », prendre soi-même quelques minutes pour examiner le paquet et laisser une revue signée liée à sa réputation, ou s’appuyer sur des revues signées d’autres personnes en qui l’on a suffisamment confiance
Une période de refroidissement n’est peut-être pas techniquement compatible avec la politique d’Arch consistant à garder tous les paquets à jour ensemble. Mais les paquets AUR ne relèvent de toute façon pas du support officiel
Plusieurs heures ont passé, et le paquet NPM n’a toujours pas été retiré : https://www.npmjs.com/package/atomic-lockfile
Pour vérifier si des paquets installés sont affectés, vous pouvez utiliser ce petit script avec le fichier
aur_pkg_list.txtJ’ai mis des points-virgules, donc c’est facile à transformer en commande sur une seule ligne :-)
On dirait que ça attrape aussi les sous-chaînes. Par exemple,
kteacorrespond aussi àkteatimeCette version semble fonctionner
Il est possible que cela dure depuis assez longtemps. Cet e-mail d’il y a 18 jours semble montrer qu’une charge utile malveillante similaire a été utilisée, mais le commit malveillant semble avoir été entièrement supprimé du dépôt
À ce sujet, existe-t-il une bonne comparaison de la posture de sécurité de la chaîne d’approvisionnement des distributions Linux populaires ? Jusqu’ici, la plupart des articles que j’ai trouvés ressemblaient soit à du marketing déguisé, soit à des textes bâclés générés par IA. Je vais peut-être devoir faire les recherches moi-même
Ce qui est déprimant, c’est que tout en appréciant l’idéal du développement communautaire, les inquiétudes liées à la chaîne d’approvisionnement me poussent à regarder de plus près des options fermées, voire des logiciels propriétaires