VMware vCenter RCE-Schwachstelle (CVE-2024-37079) — Aktive Ausnutzung in CISA KEV, Dringlicher Patch-Leitfaden
Übersicht: VMware vCenter Server hat eine kritische CVE-2024-37079 (CVSS 9.8) Heap-Overflow-Schwachstelle in der DCERPC-Protokollimplementierung, die unauthentifizierte Remote Code Execution ermöglicht. Netzwerkzugriff reicht. Im CISA KEV-Katalog; Patchfrist für US-Bundesbehörden abgelaufen. Kein Workaround verfügbar; einzige Lösung: Patch auf vCenter 8.0 U2d, 8.0 U1e oder 7.0 U3r.
Betroffene und gepatchte Versionen
| vCenter Server Version | Betroffen | Gepatchte Version | Dringlichkeit |
|---|---|---|---|
| vCenter 7.0 — < 7.0 U3r | ✅ Ja | vCenter 7.0 U3r | 🔴 Kritisch |
| vCenter 8.0 — < 8.0 U1e | ✅ Ja | vCenter 8.0 U1e | 🔴 Kritisch |
| vCenter 8.0 — < 8.0 U2d | ✅ Ja | vCenter 8.0 U2d | 🔴 Kritisch |
| vCenter 6.5 / 6.7 | ⚠️ EOL | — | Migration erforderlich |
| VMware Cloud Foundation (VCF) 4.x, 5.x | ✅ Ja | VCF 5.1.1+ | 🔴 Kritisch |
⚠️ Vor dem Patchen unbedingt erledigen
- vCenter Snapshot erstellen (File-based oder VM-Snapshot) — kritisch für Rollback
- Config-Backup via VAMI:
https://<vcenter>:5480 → Backup → Backup Now(SFTP/FTPS-Ziel) - ESXi-Hosts nicht in Wartungsmodus versetzen — vCenter-Patch berührt ESXi nicht
- In ruhigem Zeitfenster planen (Patch dauert 30-60 Min, vCenter kurz offline)
- vSphere Client-Benutzer informieren (kein Zugriff während des Patches)
Was ist die Schwachstelle? Warum 9.8?
CVE-2024-37079 ist ein Out-of-Bounds-Write (Heap-Overflow) in der DCERPC (Distributed Computing Environment / Remote Procedure Call) Protokollimplementierung im vCenter Server. Ein Angreifer sendet ein speziell gestaltetes Paket über das Netzwerk an vCenters TCP/2012 oder TCP/2014 Port; Heap-Memory-Overflow wird ausgelöst, und Remote-Code wird mit privilegiertem Benutzer (typischerweise root) ausgeführt.
Warum CVSS 9.8:
- Angriffsvektor: Netzwerk (AV:N)
- Angriffskomplexität: niedrig (AC:L)
- Benötigte Privilegien: keine (PR:N) — keine Authentifizierung!
- Benutzerinteraktion: keine (UI:N)
- Auswirkung: Vertraulichkeit + Integrität + Verfügbarkeit alle hoch (C:H/I:H/A:H)
Patch Schritt für Schritt — vCenter Server Appliance (VCSA)
- Patch vom Broadcom Support Portal herunterladen (nicht mehr VMware-Portal):
https://support.broadcom.com→ vSphere → vCenter Server → 8.0 U2d Patch ISO - Heruntergeladene
.iso-Datei auf einen Datastore eines ESXi-Hosts von vCenter hochladen - ISO an CD/DVD-Laufwerk der vCenter-VM in VM-Einstellungen mounten
- VAMI einloggen:
https://<vcenter>:5480(Benutzerroot) - Zu Update-Tab gehen → Check Updates → die CDROM-Option erscheint
- Stage and Install klicken; EULA akzeptieren
- Pre-Update-Check läuft (~5 Min); ohne Fehler Install klicken
- vCenter rebootet (~10-20 Min Downtime); vSphere Client auch kurz nicht erreichbar
- Version in VAMI nach Patch verifizieren: Build-Nummer sollte 8.0.2.00400 (U2d) oder ähnlich anzeigen
Verifizierung nach Patch
# vCenter-Version prüfen (CLI)
ssh root@<vcenter>
vpxd -v
# Sind neue DCERPC-Service-Binaries geladen?
rpm -qa | grep vmware-vpxd
# Health-Check
service-control --status --all | grep -i stopped
# Nichts darf 'Stopped' sein- Alle Cluster und Hosts in vSphere Client Web UI sichtbar bestätigen
- HA/DRS funktionsfähig: Test-VM mit vMotion auf anderen Host migrieren
- vCenter Server Logs fehlerfrei:
/var/log/vmware/vpxd/vpxd.log - External Identity Provider (AD FS, Okta) Integration funktioniert
Erkennung: bin ich ausgenutzt worden?
CVE-2024-37079 wird aktiv ausgenutzt. Bei Verdacht auf Kompromittierung vor dem Patch:
- Anomale SSH-Sitzungen prüfen:
/var/log/secure*und/var/log/auth.logder letzten 30 Tage scannen - Neu erstellte lokale Benutzer in vCenter: VAMI → Administration → SSO Configuration → Users
- Neu hinzugefügte Skripte/Binaries im vCenter VM-Dateisystem:
find / -mtime -30 -type f ( -name "*.sh" -o -name "*.py" -o -perm -u+x ) 2>/dev/null - Unerwartete ausgehende Verbindungen von vCenter in Netzwerk-Logs, besonders außerhalb 443/80
- Im Zweifelsfall vCenter komplett neu installieren und alte Config nicht wiederherstellen — könnte Backdoor enthalten
Häufige Probleme
- “Pre-Update-Check meldet ‘/storage/seat’ voll.” SEAT (Stats, Events, Alarms, Tasks) DB-Partition voll.
/storage/seatbereinigen oder erweitern (VMDK vergrößern + LVM extend). - “Update CD-ROM nicht sichtbar.” ISO-Mount prüfen. vCenter VM “Connect at Power On” — muss “Connected” sein, nicht nur ausgewählt.
- “vSphere Client öffnet nach Patch nicht.” Cache leeren (Browser-Privatmodus probieren). Bei Zertifikatswechsel Trust Store aktualisieren.
- “Performance schlechter nach VCSA-Patch.” Lang laufende Operationen in
/var/log/vmware/vpxd/profiler/prüfen. Meist DB-Defragmentierung nötig:vcenter-recovery-tool db-reindex.
Präventive Empfehlungen (für die Zukunft)
- vCenter Management-Netzwerk in separatem VLAN halten; niemals direkt aus dem Internet erreichbar
- vSphere Client-Zugriff via VPN oder Bastion-Host erforderlich
- Firewall-Whitelisting für vCenter VAMI (5480) und APIs anwenden
- Broadcom Support Portal via RSS-Feed oder Security Mailing-List verfolgen (VMSA-XXXX-XXXX Advisories)
- Automatisierten wöchentlichen Snapshot-Task ausführen (File-based Config-Backup)
VMware / Broadcom vSphere Support
Benötigen Sie Hilfe bei vCenter Patch-Planung, Kompromittierungs-Erkennung, ESXi-Cluster Health-Audit oder Broadcom Cloud Foundation Migration? Wir bieten seit 1998 Virtualisierungs-Beratung in der gesamten Türkei.
