Hôtes VMWare vCenter (web-ui) sur Internet
CVE-2023-34048(VMSA-2023-0023) est une vulnérabilité de VMWare vCenter dans leur implémentation du protocole DCERPC, qui est présent dans les produits VMWare vSphere et Cloud Foundation. Il n'y a pas eu beaucoup de détails publiés sur la vulnérabilité réelle, mais il a été signalé que toutes les versions de vSphere, à l'exception de la dernière, sont vulnérables.
À l'heure où nous écrivons ces lignes, il n'y a pas d'exploits publics disponibles, ni de campagne de piratage de masse, mais un rapport de Mandiant indique que cette vulnérabilité a été utilisée dans le cadre d'une attaque ciblée. Ce rapport indique également qu'un groupe d'espionnage avancé chinois utilise cette vulnérabilité depuis la fin de l'année 2021.
Censys Requêtes de recherche :
Censys Requêtes ASM :
- VMWare vCenter : host.services : (software.vendor : vmware and software.product : vcenter) or (web_entity.instances.software.vendor : vmware and web_entity.instances.software.product : center)
- VMWare vCenter avec DCERPC : (host.services : (software.vendor : vmware and software.product : vcenter)) et host.services.service_name=DCERPC
VMWare a vérifié avec une note mise à jour dans leur avis pour VMSA-2023-0023 qu'ils ont "confirmé que l'exploitation de CVE-2023-34048 s'est produite dans la nature". Mandiant a suivi avec un court billet détaillant la méthodologie utilisée par ces attaquants "très avancés", qu'ils considèrent comme directement liée à CVE-2023-34048.
"L'analyse du core dump de "vmdird" par Mandiant et VMware Product Security a montré que le blocage du processus est étroitement lié à l'exploitation de CVE-2023-34048, la vulnérabilité d'écriture hors limites de vCenter dans l'implémentation du protocole DCE/RPC corrigée en octobre 2023, qui permet l'exécution de commandes à distance non authentifiées sur les systèmes vulnérables." - Mandiant
Note: "vmdird", également connu sous le nom de VMWare Directory Service, interagit apparemment directement avec l'implémentation vulnérable de DCERPC d'une manière ou d'une autre. Bien que les détails ne soient pas clairs pour l'instant.
Ce groupe, dont le nom de code est UNC3886, était connu pour être à l'origine de diverses attaques visant VMWare ESXi en juin 2023, et il est désormais clair qu'il utilise une vulnérabilité qui n'a pas encore fait l'objet d'une démonstration de faisabilité publique.
Alors que Censys a des informations sur les hôtes avec VMWare vCenter exécutant l'interface d'administration web, le problème sous-jacent est leur implémentation de DCERPC, un protocole complètement différent en dehors de HTTP, que l'on trouve généralement sur le port TCP 135.
À l'heure où nous écrivons ces lignes, Censys a observé environ 3 541 hôtes avec le service d'administration web vCenter en cours d'exécution ; parmi eux, seuls 293 hôtes (8,2 %) avaient le service DCERPC en cours d'exécution sur la même interface de réseau public sur le port par défaut (TCP/135).
Il convient de noter que ce n'est pas parce que DCERPC s'exécute sur le même hôte que l'interface web vCenter qu'il est vulnérable à cette attaque. Censys ne dispose pas d'informations sur les versions spécifiques des services qui s'exécutent, et nous ne savons pas non plus si l'implémentation DCERPC observée est celle de VMWare (l'interface vCenter peut se trouver derrière un proxy sur un hôte qui exécute une implémentation différente de DCERPC ; nous n'avons aucun moyen de différencier ces types de configurations).
D'autre part, si un hôte exécute publiquement DCERPC mais n'a pas d'interface d'administration web vCenter exposée à l'internet, nous ne pouvons pas déterminer si le service DCERPC interagit avec un système VMWare sous-jacent.
 |
| Top 10 des services VMWare vCenter par système autonome |
| Système autonome |
Les hôtes vCenter n'exécutent pas DCERPC |
Hôtes vCenter exécutant DCERPC |
Total des hôtes |
| HETZNER-AS |
241 |
15 |
256 |
| CHINANET-BACKBONE |
153 |
5 |
158 |
| OVH |
137 |
12 |
149 |
| ANEKANET-AS-ID |
79 |
0 |
79 |
| PIP-AS-AP |
71 |
0 |
71 |
| CHINA169-BACKBONE |
54 |
0 |
54 |
| KIXS-AS-KR |
52 |
0 |
52 |
| ATT-INTERNET4 |
27 |
1 |
28 |
| SAS en ligne |
26 |
1 |
27 |
| ERX-TANET-ASN1 |
26 |
0 |
26 |
|
Dans les mesures ci-dessus, nous remarquons que les suspects habituels, comme Amazon AWS et Microsoft Azure, ne sont même pas dans la course. Les expositions ici semblent isolées des fournisseurs de télécommunications et des FAI SOHO comme AT&T Internet. Comme nous l'avons déjà mentionné, seule une fraction des hôtes exécutant l'interface web vCenter exécutent également un service DCERPC sur le port TCP 135.
 |
| Pays |
Les hôtes vCenter n'exécutent pas DCERPC |
Hôtes vCenter exécutant DCERPC |
Total des hôtes |
| États-Unis |
467 |
32 |
499 |
| Chine |
362 |
18 |
380 |
| Allemagne |
167 |
18 |
185 |
| Russie |
156 |
21 |
177 |
| Turquie |
152 |
12 |
164 |
| France |
142 |
17 |
159 |
| Finlande |
153 |
3 |
156 |
| Indonésie |
127 |
13 |
140 |
| L'Iran |
116 |
5 |
121 |
| Corée du Sud |
117 |
2 |
119 |
|
VMWare a publié ce diagramme d'état utile pour permettre aux utilisateurs de vérifier s'ils sont vulnérables à cette vulnérabilité spécifique.
En résumé, si vous utilisez une version du serveur VMWare vCenter antérieure ou égale à 8.0.2 ou 7.0 U3o, l'installation de vCenter doit être corrigée. VMWare indique également dans sa FAQ que vous êtes concerné par cette vulnérabilité si vous utilisez n'importe quelle version de vSphere à l'exception des dernières mises à jour (6.5, 6.7, 7.0 ou 8.0).
