22 nœuds Proxmox piratés : ce que la restauration a raté

Un cluster Proxmox de 22 nœuds aurait été compromis parce qu'un environnement Proxmox VE 7.4 en fin de vie restait joignable depuis Internet sur le port 8006. L'intrusion était déjà grave, mais je trouve la suite plus instructive : la reconstruction des hôtes a laissé certains points d'appui en place, et les attaquants sont revenus une fois le service rétabli.

Tout le monde retiendra « appliquez les correctifs et n'exposez pas la gestion de l'hyperviseur sur Internet », et c'est bien ce qu'il faut retenir. Le point moins évident, c'est que remettre sur pied un système en cluster après une compromission root demande bien plus que restaurer des fichiers depuis une sauvegarde. Un noyau compromis peut mentir à vos outils de récupération, et l'état partagé du cluster peut garder en vie les identifiants de l'attaquant à travers la reconstruction d'un nœud. Les agents invités transforment un accès root sur l'hyperviseur en accès root dans les invités, et les sauvegardes peuvent sauver la plateforme alors que le plan de contrôle reste contaminé. Dans cet incident, toutes ces défaillances se sont cumulées.

Qu'est-il arrivé au cluster Proxmox de 22 nœuds ?

Le rapport d'incident publié par Netfront indique qu'au moins 33 adresses externes ont obtenu un accès root sur son cluster Proxmox VE de 22 nœuds entre le 1er et le 2 septembre 2026.

La zone touchée tournait encore sous Proxmox VE 7.4, arrivé en fin de vie en juillet 2024. Le port 8006 était accessible depuis Internet parce que les clients utilisaient l'interface Proxmox pour gérer leurs machines virtuelles.

Le point d'entrée était la CVE-2023-54391. Elle touche libpve-access-control à partir de la version 7.0-7 et jusqu'à la 8.0.4 exclue. Un attaquant qui atteint l'API de connexion peut détourner le déroulement du défi à deux facteurs pour obtenir un ticket valide pour n'importe quel compte actif sans second facteur configuré.

Le chemin de code vulnérable avait déjà disparu des paquets Proxmox plus récents en juillet 2023. Personne n'avait identifié l'impact sur la sécurité ni documenté publiquement le problème avant septembre 2026.

Netfront explique que sa première requête anormale est arrivée environ 25 minutes après la publication de l'avis de sécurité Proxmox, et que le premier shell root confirmé est apparu plus tard dans la soirée. Ensuite, tout s'est accéléré : les journaux auraient montré plusieurs sources indépendantes balayant toute la flotte. Une adresse a ouvert exactement un shell sur chacun des 22 nœuds en un peu plus d'une minute, et une autre a accumulé près de 2,000 sessions shell sur le cluster en une journée.

Le rapport dit clairement que cela ne ressemblait pas à l'action d'un seul opérateur coordonné : une fois qu'un contournement d'authentification facile est public, un plan de gestion vulnérable peut attirer plusieurs attaquants sans lien entre eux en même temps.

Pourquoi la compromission d'un seul nœud Proxmox menaçait-elle les 22 ?

Un cluster Proxmox partage par conception un état sensible du plan de contrôle entre ses nœuds.

Proxmox utilise pmxcfs, son système de fichiers de cluster distribué, monté sur /etc/pve. Il réplique la configuration du cluster pour que chaque nœud voie les mêmes utilisateurs, définitions de VM, configuration du pare-feu, certificats, paramètres HA et autres états communs au cluster. L'un des fichiers protégés est /etc/pve/priv/authorized_keys, que Proxmox utilise pour l'authentification SSH entre membres du cluster.

Selon Netfront, cela a beaucoup facilité la propagation à toute la flotte une fois que les attaquants avaient un accès root sur un hôte. Les membres d'un cluster ont besoin d'un moyen de confiance pour communiquer et partager leur configuration, ce qui n'est pas en soi un défaut de conception, mais cela change la façon de réagir. Un accès root sur un hyperviseur en cluster n'a rien à voir avec un accès root sur un serveur Linux isolé, parce que toutes les relations de confiance qui relient ce nœud au reste du cluster sont désormais en jeu.

Si vous concevez ou auditez un cluster, le hub Proxmox de Mr.PlanB explique comment le réseau, le stockage, la HA et l'état du cluster interagissent, ce qui est plus utile que d'examiner chaque hôte séparément.

Pourquoi les hôtes ressemblaient-ils à du matériel défaillant ?

D'après le rapport d'incident, un rootkit eBPF faisait si mal fonctionner les nœuds compromis que l'équipe a d'abord cherché des problèmes matériels. Parmi les symptômes : des charges moyennes entre 30 et 160 sur des systèmes par ailleurs inactifs, des commandes qui s'arrêtaient sans raison et des outils comme top qui plantaient.

La vérification des paquets n'a pas révélé la cause tout de suite, parce que les binaires légitimes n'avaient pas forcément été remplacés. L'interception se faisait dans le noyau. Le rootkit aurait intercepté des appels système pour cacher des processus et des fichiers, bloquer l'inspection, protéger ses propres processus et modifier ce que voyaient les outils en espace utilisateur. Netfront a rattaché une partie de ce rootkit à du code de preuve de concept eBPF public et ne l'a pas décrit comme un rootkit privé sophistiqué.

Ce point me met mal à l'aise. Les attaquants n'ont plus besoin d'inventer leurs techniques de furtivité, car le code de recherche public permet de construire à peu de frais quelque chose de difficile à analyser depuis l'intérieur de l'hôte. Inutile de vous mettre à scanner chaque serveur chargé à la recherche de rootkits exotiques, mais vous devez cesser de croire ce qu'un hôte dit de lui-même dès qu'une compromission au niveau du noyau est plausible.

Comment les attaquants ont-ils atteint les VM des clients ?

Netfront indique que les attaquants ont utilisé le QEMU Guest Agent depuis les hôtes Proxmox compromis, et je placerais ce détail parmi les premiers à retenir.

L'agent invité gère la communication entre l'hôte et l'invité. Proxmox s'en sert pour l'arrêt des invités, le gel et le dégel des systèmes de fichiers, la remontée des adresses IP et l'exécution de commandes. Après la compromission d'un hôte, cette commodité donne beaucoup de pouvoir à l'attaquant.

Selon le rapport, les journaux de l'API montraient des commandes exécutées dans les VM invitées via agent/exec, avec une sortie récupérée via agent/exec-status. Aucun mot de passe invité n'était nécessaire, car l'hyperviseur avait déjà l'autorité de demander ces actions à travers l'agent. Les invités où le QEMU Guest Agent était activé ont été touchés, et ceux qui ne l'avaient pas n'ont pas été atteints de cette manière.

Je n'y verrais pas un conseil de désactiver l'agent invité partout, puisqu'il fait un vrai travail d'exploitation. Reste qu'un accès root sur l'hyperviseur occupe une position extrêmement privilégiée sur chaque invité, et que des mots de passe invités solides ne forment pas une vraie frontière de sécurité face à un hyperviseur entièrement compromis. Protégez le plan de gestion en gardant cela en tête.

Pourquoi la première restauration a-t-elle échoué ?

L'équipe a restauré le système de fichiers alors que le noyau compromis tournait encore. Netfront indique que sa première tentative de récupération utilisait :

rsync -aHAX --delete

pour restaurer des données saines par-dessus un hôte infecté. La commande s'est terminée, et le rootkit y a survécu.

Le rapport explique pourquoi. Le rootkit interceptait le listage des répertoires, et rsync --delete doit lister les fichiers de la destination pour déterminer quoi supprimer. Si le noyau cache un fichier malveillant dans ce listage, rsync ne sait jamais que le fichier existe et ne le supprime donc pas. Une sauvegarde parfaitement saine peut quand même aboutir à une restauration ratée, parce qu'un système d'exploitation compromis dicte à l'outil de récupération ce qui existe sur la destination.

Netfront a changé de méthode : supprimer le rootkit, redémarrer, restaurer, redémarrer encore, puis valider. Les hôtes qui ne démarraient pas de façon fiable ont été reconstruits depuis un support externe, où le noyau compromis ne tournait pas du tout. Après une compromission profonde d'un hôte, passer par un support externe est le modèle le plus sûr. Si vous avez des raisons de penser que le noyau a été détourné, méfiez-vous de toute restauration effectuée depuis ce noyau.

Pourquoi les attaquants sont-ils revenus après la reconstruction ?

Les hôtes ont été reconstruits, mais le plan de contrôle partagé du cluster contenait encore des identifiants créés par les attaquants. Pour moi, c'est la partie la plus utile de l'histoire.

Netfront dit avoir renouvelé les mots de passe, les clés SSH et le contenu d'une partie de /etc/pve/priv/. Au départ, l'entreprise n'a pas recensé tous les jetons API ni vérifié chaque compte contre une liste de référence des identités censées exister. Ce trou comptait, parce que /etc/pve est le système de fichiers du cluster Proxmox en production, répliqué entre les nœuds : reconstruire un hôte ne change rien à un état malveillant que le cluster continue de recopier.

L'audit mené plus tard par l'entreprise aurait trouvé 42 jetons API associés à root@pam et dix comptes illégitimes nommés pour ressembler à des comptes légitimes. Le 7 septembre, après la remise en service de la plateforme, des identifiants qui avaient survécu à la reconstruction ont de nouveau servi.

Un nœud propre peut rejoindre un plan de contrôle sale. Quand une plateforme en cluster est compromise, la récupération exige donc un audit à part de la configuration partagée, des identifiants, des jetons, des ACL, des comptes d'automatisation, des certificats, de la confiance SSH et de tout ce qui est répliqué en dehors du système de fichiers de l'hôte.

Un Proxmox Health Check peut repérer les problèmes de configuration ordinaires, mais une revue après compromission exige un audit des identités et de la confiance bien plus poussé.

Qu'est-ce que la conception des sauvegardes a bien fait ?

De toute l'architecture, c'est la séparation entre la production et l'infrastructure de sauvegarde qui a le mieux tenu.

Netfront explique que ses systèmes de sauvegarde tiraient les données depuis les hôtes de production, si bien que la production n'écrivait jamais vers la destination de sauvegarde et ne l'administrait pas. La zone touchée ne disposait donc d'aucun identifiant capable de supprimer ses copies de récupération distantes. L'entreprise conservait aussi des copies inter-zones dans des bâtiments distincts.

Cela correspond aux recommandations de Proxmox Backup Server. Proxmox conseille des copies hors site et des permissions de sauvegarde restrictives, met explicitement en garde contre l'octroi de droits de suppression aux clients de sauvegarde et recommande des tests de restauration réguliers plutôt que de supposer que des tâches de sauvegarde réussies prouvent que vous pouvez restaurer.

La réplication n'est pas automatiquement une sauvegarde. Si un système de production compromis peut s'authentifier auprès de la copie, la modifier et la supprimer, l'attaquant peut effacer d'un coup la production et les données de récupération. Une sauvegarde digne de ce nom se trouve derrière une frontière de confiance que la production ne peut pas franchir à la légère, de sorte que la récupération, même si elle reste un gros travail, part de quelque chose de fiable.

La vraie erreur était-elle de faire tourner Proxmox VE 7.4 ?

C'était une erreur parmi d'autres. Les réactions de la communauté ont été remarquablement unanimes sur deux points : l'environnement tournait sur une version d'hyperviseur en fin de vie, et son interface de gestion était accessible publiquement. Chacun de ces points augmente le risque, et ensemble ils le multiplient.

Des participants à la discussion ont aussi soulevé une remarque juste sur les raisons pour lesquelles les équipes de production hésitent devant les mises à niveau majeures d'hyperviseur. Une infrastructure stable, bien connue et qui sert des clients ne se met pas à niveau à la légère. Mettre à niveau immédiatement sans tester est risqué aussi, il faut donc un processus de correctifs qui permette de tester les mises à niveau majeures avant que la version actuelle, devenue non supportée, ne tourne à l'urgence.

Un environnement de test ou un miroir représentatif, des procédures de retour arrière documentées, des fenêtres de maintenance, des vérifications de compatibilité matérielle, des tests des invités et des mises à niveau des nœuds par étapes prennent du temps. Reconstruire 22 hyperviseurs compromis aussi. Faire l'impasse sur le processus de mise à niveau, c'est payer ce coût plus tard, selon un calendrier que l'organisation ne maîtrise plus.

Le port 8006 de Proxmox doit-il être exposé sur Internet ?

Évitez l'exposition directe, sauf raison exceptionnellement solide accompagnée d'une architecture de sécurité compensatoire.

L'interface Proxmox est le plan de gestion de l'hyperviseur, et rien n'y relève du faible privilège. C'est pourquoi les critiques les plus vives de la discussion visaient l'exposition directe du port 8006 à des réseaux non fiables, et non Proxmox lui-même. Parmi les meilleures options : un VLAN de gestion, un VPN, un hôte de rebond dédié, un proxy tenant compte de l'identité, des règles de pare-feu très restrictives et du MFA.

Le libre-service client complique les choses, car des utilisateurs externes peuvent avoir légitimement besoin de certaines fonctions de gestion. Ils n'ont pas pour autant besoin d'un accès réseau direct à tout le plan de contrôle de l'hyperviseur. Un portail client séparé utilisant des permissions de l'API Proxmox au périmètre étroit est une option, un proxy d'accès avec de solides contrôles d'identité en est une autre.

Quel que soit votre choix, partez du principe que le code d'authentification peut contenir des bugs, et concevez l'ensemble pour qu'un seul contournement d'authentification ne suffise pas à obtenir un accès root sur tous les hyperviseurs.

Que doit contenir une checklist de récupération Proxmox après une compromission root ?

L'incident mène à une checklist bien plus large que « restaurer depuis la sauvegarde » :

• Reconstruire depuis un support de confiance quand une compromission du noyau est possible.
• Considérer comme suspect chaque nœud du domaine de confiance.
• Auditer /etc/pve comme un plan de contrôle partagé à part entière.
• Recenser chaque utilisateur et chaque jeton API.
• Confronter les ACL à une conception de référence saine.
• Renouveler les mots de passe, les clés SSH, les certificats et les identifiants de service.
• Examiner l'activité de l'agent invité, et inspecter les systèmes invités si l'hyperviseur compromis pouvait y exécuter des commandes.
• Vérifier les sauvegardes depuis un environnement que les hôtes compromis ne pouvaient pas modifier.
• Envoyer les journaux hors du cluster pour que les attaquants ne puissent pas effacer le seul historique utile.
• Tester l'interface de gestion depuis Internet et confirmer qu'elle n'est pas joignable, sauf si elle est volontairement protégée.

Surtout, ne limitez pas la recherche au mécanisme de persistance que vous avez déjà vu. Le rapport de Netfront décrit des dizaines de jetons et de comptes implantés, dont beaucoup n'ont jamais servi, et une porte dérobée dormante reste une porte dérobée.

Une reconstruction impressionnante qui n'aurait pas dû être nécessaire

Le travail de récupération mené dans cet incident a une vraie valeur technique. L'enquête a relié le comportement étrange des hôtes à un rootkit eBPF, et l'équipe a découvert un mode de défaillance de la récupération rsync sur place. Elle a aussi récupéré des hôtes qui ne démarraient plus, conservé des copies exploitables grâce à l'architecture de sauvegarde inter-zones, puis reconstitué assez finement l'activité des attaquants à partir des journaux.

Reste qu'une récupération héroïque est une piètre stratégie de sécurité. Vingt-deux hyperviseurs en fin de vie avec un plan de gestion public ont permis à un seul contournement d'authentification de devenir un incident touchant toute la flotte, et la restauration des hôtes sans audit complet des identifiants partagés du cluster a ouvert une seconde porte.

La meilleure configuration est ennuyeuse : des logiciels supportés, un accès de gestion restreint, du MFA, des sauvegardes indépendantes, une journalisation hors cluster, des mises à niveau testées, un inventaire complet des identités et des procédures de récupération qui partent du principe qu'un hôte compromis peut mentir. Rien de tout cela ne donne une histoire palpitante à raconter, et c'est très bien ainsi.