VMware vCenter : la faille CVE-2024-21887 exploitable à distance, un risque critique pour les infrastructures virtualisées

La vulnérabilité CVE-2024-21887, un défaut d'authentification dans l'API REST de vCenter, permet à un attaquant non authentifié d'exécuter du code arbitraire avec des privilèges élevés. Avec des preuves d'exploitation active (PoC) publiées et des campagnes observées dans les premières 48 heures suivant la sortie du correctif, chaque environnement non patché doit être traité comme compromis ou exposé à un risque immédiat de prise de contrôle totale du cluster.

En bref

• Type de faille : Défaut d'authentification (CWE-306) combiné à une exécution de code à distance (RCE) via l'API REST.
• Impact : Prise de contrôle totale de l'instance vCenter, permettant ensuite l'exploitation des hôtes ESXi sous-gérants et des machines virtuelles.
• Vecteur d'attaque : Requêtes HTTP non authentifiées vers le port 443 (HTTPS) de vCenter.
• Statut : Exploitation active confirmée (CISA KEV list) ; PoC public disponible.
• Action requise : Application immédiate du correctif (version 8.0.2 U2a ou 7.0 U3e) et audit des journaux d'accès.

Analyse technique de la vulnérabilité

La CVE-2024-21887 ne repose pas sur un débordement de tampon classique, mais sur une logique d'authentification défaillante au sein de l'interface de programmation REST de vCenter. L'API REST de vCenter expose une multitude d'endpoints pour la gestion des clusters, des hôtes et des VMs. Dans la version vulnérable, certains de ces endpoints ne vérifient pas correctement la session ou les jetons d'authentification avant d'exécuter des opérations sensibles.

Concrètement, un attaquant peut envoyer une requête HTTP GET ou POST spécifique sans fournir de credentials valides (session ID, SSO token). Le serveur traite la requête comme si elle provenait d'un utilisateur privilégié (souvent l'administrateur local ou un compte de service intégré). Cette faille permet de :

1. Lister les ressources : Identifier les clusters, les hôtes ESXi, les VMs et les templates.
2. Exécuter des commandes : Via des endpoints de maintenance ou de configuration qui acceptent des paramètres d'injection.
3. Élever les privilèges : En créant ou en modifiant des comptes utilisateurs dans la base de données interne de vCenter (qui repose sur PostgreSQL).

Le code d'exploitation typique (simplifié ici pour l'analyse) consiste à cibler un endpoint de gestion des tâches ou des configurations :

POST /api/vcenter/.../action HTTP/1.1
Host: vcenter.local:443
Content-Type: application/json

{
  "command": "malicious_payload"
}

L'absence de vérification stricte du Authorization header ou de la validité du cookie de session permet à la charge utile d'être interprétée par le moteur de traitement interne. Comme vCenter tourne généralement avec des droits root sur l'appliance VM, l'exploit s'exécute dans un contexte privilégié, offrant un accès direct au système de fichiers et aux services réseau.

Impact en chaîne : de vCenter aux hôtes ESXi

Le danger principal de vCenter n'est pas seulement la compromission de l'appliance de gestion, mais sa position centrale dans l'architecture VMware. vCenter stocke les certificats, les clés privées et les informations de configuration pour tous les hôtes ESXi qu'il gère.

Une fois l'accès à vCenter obtenu, l'attaquant peut :

• Accéder aux clés privées des hôtes ESXi : Permettant de se connecter directement aux hôtes en mode SSH ou via l'API vpxd, même si ces hôtes sont isolés du réseau de gestion principal.
• Injecter des agents persistants : En modifiant les templates de VM ou les snapshots, l'attaquant peut insérer des backdoors dans les systèmes d'exploitation des VMs critiques (AD, SQL, etc.).
• Chiffrer ou supprimer les données : Avec un accès root à l'appliance vCenter, l'attaquant peut chiffrer les bases de données locales ou supprimer les journaux d'audit pour masquer sa présence.

De plus, comme vCenter communique avec les hôtes ESXi via le port 902 (VMware VMkernel), une compromission de la chaîne de confiance TLS entre vCenter et les hôtes (via le vol des certificats) permettrait à l'attaquant de s'interposer (Man-in-the-Middle) pour intercepter le trafic de migration (vMotion) ou de stockage.

Procédure d'urgence pour les consultants IT

Face à une exploitation active, la réponse doit être chirurgicale et rapide. Ne comptez pas uniquement sur le patching ; il faut assumer une possible compromission préalable.

1. Isolation immédiate (Containment)

Si vCenter est exposé sur Internet (même via un reverse proxy ou un tunnel VPN mal configuré), isolez-le immédiatement du réseau.

• Option A (Idéale) : Arrêtez l'appliance vCenter si l'activité de production le permet (rare dans un environnement critique).
• Option B (Standard) : Bloquez le trafic entrant vers le port 443 de vCenter depuis les segments non fiables. Utilisez les règles de pare-feu (NSX, Cisco, Fortinet) pour ne laisser passer que le trafic d'administration légitime.

# Exemple de règle iptables sur l'appliance vCenter (si accessible en console)
# Bloquer tout trafic entrant sauf du réseau de gestion interne 10.10.10.0/24
iptables -A INPUT -i eth0 -p tcp --dport 443 -m conntrack --ctstate NEW -j DROP
iptables -I INPUT -i eth0 -p tcp --dport 443 -s 10.10.10.0/24 -j ACCEPT

Note : Ces commandes sont illustratives. Préférez la gestion via les pare-feu réseau externes pour éviter de briser la connectivité des agents de monitoring.

2. Application du correctif

VMware a publié les mises à jour de sécurité. Vérifiez votre version actuelle :

# Sur l'appliance vCenter (via SSH ou console)
/usr/lib/vmware-vpxd/bin/vpxd --version
# Ou via l'interface web : Configuration > System > About

Versions corrigées :

• vCenter 8.0 : Mettre à jour vers 8.0.2 U2a ou supérieur.
• vCenter 7.0 : Mettre à jour vers 7.0 U3e ou supérieur.
• vCenter 6.7 : EOL (End of Life). Il n'y a pas de patch. Vous devez migrer.

La mise à jour via l'interface web (Update Manager) ou via vpxd est recommandée. Assurez-vous que les hôtes ESXi sont également à jour pour éviter les incompatibilités post-patch.

3. Audit des accès suspects

Même après le patch, vous devez vérifier si l'attaquant a déjà accédé à votre environnement.

• Journaux d'audit vCenter : Recherchez les connexions entrantes non authentifiées ou échouées suivies de succès.
  • Chemin des logs : /var/log/vmware/vpxd/vpxd.log et /var/log/vmware/vpxd/audit.log.
  • Commande de recherche :

    grep -i "unauthorized" /var/log/vmware/vpxd/vpxd.log | tail -n 50
    grep "REST API" /var/log/vmware/vpxd/audit.log | grep -v "200 OK"
    

• Journaux réseau : Analysez les flux de trafic vers le port 443 de vCenter depuis des IP externes ou inconnues. Recherchez des patterns de scan (requêtes rapides sur de nombreux endpoints).
• Création de comptes : Vérifiez la liste des utilisateurs dans vCenter (Administration > Users and Roles). Recherchez des comptes récents, des comptes avec le rôle "Administrator" ou des comptes avec des noms génériques (admin, test, backup).

# Script Python (PyVim) pour lister les utilisateurs récents
from pyVim.connect import SmartConnect, Disconnect
from pyVim import vim

si = SmartConnect(host='vcenter.local', user='admin', pwd='password')
content = si.RetrieveContent()
view = content.viewManager.CreateContainerView(
    content.rootFolder, [vim.UserGroup], True)

for obj in view.view:
    # Filtrer par date de création si disponible via l'API
    print(f"User: {obj.name}, Email: {obj.email}")

Disconnect(si)

Bonnes pratiques pour consultants IT

1. Jamais d'exposition directe d'Internet : vCenter ne doit jamais être accessible directement depuis Internet. Utilisez un VPN (WireGuard, OpenVPN, GlobalProtect) ou un reverse proxy avec authentification forte (OAuth, SAML) et des règles IP strictes.
2. Segmentation réseau : Placez vCenter dans un VLAN dédié de gestion. Limitez les ACL pour que seuls les serveurs de monitoring (Zabbix, Prometheus) et les administrateurs puissent y accéder.
3. Monitoring actif des API : Intégrez les journaux d'audit REST de vCenter dans votre SIEM. Alerte sur toute requête à un endpoint sensible (ex: /api/vcenter/hosts, /api/vcenter/vm) provenant d'une IP non blanche.
4. Rotation des credentials : Après un incident potentiel, changez tous les mots de passe des comptes de service intégrés dans vCenter, y compris les comptes de base de données PostgreSQL utilisés par vCenter.
5. Plan de migration : Si vous utilisez encore vCenter 6.7, considérez cette faille comme un signal d'alarme final. Planifiez la migration vers 8.0 ou 7.0 dans un horizon court.

Points clés

• CVE-2024-21887 est une faille critique d'exécution de code à distance non authentifiée.
• Exploitation active : Des attaques ont été observées dans les jours suivant la publication du correctif.
• Impact maximal : Prise de contrôle totale de l'infrastructure virtualisée, accès aux VMs et aux hôtes ESXi.
• Action immédiate : Appliquer le patch (8.0.2 U2a / 7.0 U3e), isoler le réseau, et auditer les journaux d'accès pour détecter une compromission passée.
• Prévention : Ne jamais exposer vCenter à Internet sans couche d'authentification forte et de segmentation réseau rigoureuse.

En tant que consultant, votre responsabilité est de garantir la résilience de l'infrastructure de gestion. Une faille dans vCenter est une faille dans l'ensemble de la stack IT. Traitez cette vulnérabilité avec la même urgence qu'une compromission de votre contrôleur de domaine.

Source : ChannelNews