CVE-2021-21985

VMware vCenter Server — VMware vCenter Server Improper Input Validation Vulnerability

Beschreibung

Der vSphere Client (HTML5) enthält eine Schwachstelle zur entfernten Codeausführung aufgrund fehlender Eingabevalidierung im Virtual SAN Health Check-Plug-in, das standardmäßig in vCenter Server aktiviert ist. Ein böswilliger Akteur mit Netzwerkzugriff auf Port 443 kann diese Schwachstelle ausnutzen, um Befehle mit uneingeschränkten Rechten auf dem Betriebssystem auszuführen, das vCenter Server hostet.

Behebung & Mitigation

Warum sofort handeln?

Priorisierung

CVE-2021-21985 erhält CVSS 9.8 (AV:N/AC:L/PR:N/UI:N) und einen EPSS-Score von 1,0 (100. Perzentile) — das bedeutet maximale Ausnutzungswahrscheinlichkeit ohne jede Authentifizierungsvoraussetzung. CISA hat die Ransomware-Nutzung explizit bestätigt, was das Schadpotenzial für KRITIS-Organisationen erheblich erhöht, da ein erfolgreicher Angriff die vollständige Virtualisierungsinfrastruktur kompromittiert und damit alle darauf betriebenen Systeme. Typische Zielprofile sind Organisationen mit exponiertem vCenter-Management-Interface — auch intern exponierte Instanzen sind gefährdet, sobald ein Angreifer Netzwerkzugang erlangt hat. Für NIS2-pflichtige Betreiber wesentlicher Dienste ist die Behebung als kritisch einzustufen und innerhalb des kürzestmöglichen Wartungsfensters umzusetzen; bis dahin ist der Workaround (Plug-in-Deaktivierung plus Netzwerkisolation) zwingend.

Runbook · Schritt 1

Sofort-Response (0-24 h)

  • Patch sofort einspielen: VMware Security Advisory VMSA-2021-0010 behebt CVE-2021-21985. Ziel-Versionen: vCenter Server 7.0 U2b, 6.7 U3n, 6.5 U3p — Patch-Version im Vendor-Advisory unter vmware.com/security/advisories/VMSA-2021-0010.html verifizieren.
  • Netzwerkzugang auf Port 443 einschränken: Firewall-Regeln sofort so setzen, dass Port 443 (HTTPS) des vCenter-Servers ausschliesslich aus vertrauenswürdigen Management-Netzen erreichbar ist — kein direkter Internetzugang.
  • vCenter-Instanzen inventarisieren: Alle exponierten vCenter-Instanzen (on-premises und Cloud-Linked) identifizieren; besonders auf Instanzen achten, die über DMZ oder direkt aus dem Internet erreichbar sind.
  • Virtual SAN Health Check Plug-in deaktivieren (Workaround): Solange der Patch nicht eingespielt ist, das betroffene Plug-in gemäss VMSA-2021-0010 Workaround-Anleitung deaktivieren — dies reduziert die Angriffsfläche unmittelbar.
  • Kompromittierungsindikatoren prüfen: Logs auf ungewöhnliche Prozesse unter dem vCenter-Dienstkonto (vsphere-ui, vpxd) sowie auf verdächtige Netzwerkverbindungen ab Port 443 untersuchen — Zeitraum mindestens 90 Tage rückwirkend.
  • Privilegierte Zugangsdaten rotieren: Alle Service-Accounts, SSO-Administratoren und vCenter-Administratorpasswörter nach Patch-Einspielung rotieren; Annahme einer möglichen Vorkompromittierung.

Runbook · Schritt 2

Mitigation-Layer

  • Netzwerksegmentierung (Perimeter): vCenter-Management-Interface in ein dediziertes Management-VLAN isolieren; Zugriff nur über Jump-Host oder VPN mit MFA erlauben — kein direkter Zugriff aus Produktions- oder Nutzer-VLANs.
  • WAF/IPS-Regel: HTTP-Anfragen mit Pfad /ui/h5-vsan/rest/proxy/service/ oder /vsanhealth/ auf dem vCenter-Endpunkt blockieren bzw. alarmieren — diese Pfade sind bekannte Angriffsvektoren für CVE-2021-21985.
  • Suricata/Snort-Signatur: Alert auf POST-Requests an /ui/h5-vsan/ mit ungewöhnlich grossen Body-Payloads (>4 KB) oder mit Sonderzeichen-Mustern, die auf Serialisierungs-Exploits hindeuten.
  • Least-Privilege für vCenter-Dienstkonten: Sicherstellen, dass vCenter-Dienstkonten keine lokalen Administratorrechte auf dem Betriebssystem des vCenter-Hosts besitzen — Exploit führt Befehle mit OS-Rechten aus.
  • Plug-in-Verwaltung härten: Nicht benötigte vCenter-Plug-ins (insbesondere Virtual SAN Health Check, wenn vSAN nicht genutzt wird) dauerhaft deaktivieren — Angriffsfläche strukturell reduzieren.
  • Backup-Integrität sicherstellen: vCenter-Konfigurationsbackups auf einem isolierten, nicht domänengebundenen System aufbewahren; sicherstellen, dass Backups vor dem frühesten möglichen Kompromittierungszeitpunkt erstellt wurden.

Runbook · Schritt 3

Detection-Regeln

  • Web-Server-Accesslog (vCenter): Einträge mit POST /ui/h5-vsan/rest/proxy/service/ oder HTTP-500-Antworten auf /vsanhealth/-Endpunkte — insbesondere von externen oder unbekannten Quell-IPs — als Exploit-Versuch werten.
    SPL: index=vcenter_access uri_path="*/h5-vsan/rest/proxy*" method=POST | stats count by src_ip, status
    
  • Prozess-Ancestry (EDR/Sysmon EID 1): Kindprozesse von vsphere-ui.exe oder java.exe (vCenter-Dienst) die Shell-Prozesse spawnen (cmd.exe, powershell.exe, bash, sh) — starker Indikator für RCE-Ausnutzung.
    Sigma shape: process_creation | where ParentImage endswith 'vsphere-ui.exe' AND Image endswith ('cmd.exe','powershell.exe')
    
  • Netzwerktelemetrie (Zeek/Suricata): Ausgehende Verbindungen vom vCenter-Host zu externen IPs auf ungewöhnlichen Ports (z. B. 4444, 8080, 1337) nach eingehenden HTTPS-Anfragen — Hinweis auf Reverse-Shell oder C2-Beacon.
  • Windows Event ID 4688 / Linux auditd execve: Prozessstart-Ereignisse auf dem vCenter-OS mit unbekannten Binaries oder Base64-kodierten Kommandozeilenargumenten, die vom vCenter-Dienstkonto ausgeführt werden.
  • Authentifizierungsanomalien (SSO-Logs): Neue SSO-Administratorkonten oder Rollenänderungen im vCenter-Audit-Log (vpxd-audit.log) ohne korrespondierendes Change-Management-Ticket — Indikator für Post-Exploitation-Persistenz.

Metriken

Severity
critical
Aktiv ausgenutzt
aktiv ausgenutzt (KEV)
9.8
Quelle: nvd-v3
100.0 %
Kritisch — CVE liegt im obersten Fünftel aller heute bewerteten CVEs (Rang ≥ 80 %).
100.0 %
Hoch — Modell schätzt ≥ 50 % Chance auf reale Ausnutzung in 30 Tagen.
Veröffentlicht
2021-11-03 00:00 UTC

Betroffene Produkte

Aus der Hersteller-/CERT-Meldung extrahierte Produkte und Versionsbereiche. Ein Version-Range wie „<4.14.6“ impliziert die Update-Empfehlung „auf 4.14.6 oder höher aktualisieren“.

  • vmware

    cloud_foundation3.0 – 3.10.2.1

  • vmware

    cloud_foundation4.0 – 4.2.1

  • vmware

    vcenter_server

Öffentliche Exploit-Referenzen

Öffentliche Proof-of-Concepts und Detection-Templates für diese Schwachstelle. Die Reife reicht von gemeldeten PoCs über funktionsfähige Detection-Skripte bis hin zu vollständig waffenfähigen Exploit-Modulen. NEOSEC mirrort den Code intern für forensische Analysen; nach außen verlinken wir ausschließlich auf die Original-Quellen.

Quellen & Referenzen

IDCVE-2021-21985