CVE-2022-22948
VMware vCenter Server — VMware vCenter Server Incorrect Default File Permissions Vulnerability
Beschreibung
Der vCenter Server enthält eine Schwachstelle für die Offenlegung von Informationen aufgrund unzureichender Dateiberechtigungen. Ein böswilliger Akteur mit nicht-administrativen Zugriffsberechtigungen auf den vCenter Server kann diese Schwachstelle ausnutzen, um Zugang zu vertraulichen Informationen zu erhalten.
Behebung & Mitigation
Warum sofort handeln?
Priorisierung
CVE-2022-22948 ist trotz eines moderaten CVSS-Scores von 6.5 (AV:N/AC:L/PR:L/UI:N) mit einem EPSS-Wert im 96. Perzentil als hochrelevant einzustufen: Die Ausnutzung erfordert lediglich ein niedrigprivilegiertes vCenter-Konto — eine Hürde, die in vielen Organisationen durch Dienstkonten für Monitoring, Backup oder Drittanbieter-Integrationen bereits erfüllt ist. Die offengelegten Informationen (Credentials, Konfigurationsgeheimnisse) ermöglichen typischerweise laterale Bewegung in Richtung weiterer Infrastrukturkomponenten oder Privilege Escalation innerhalb der VMware-Umgebung. KRITIS-Organisationen mit VMware-basierter Virtualisierungsinfrastruktur sollten dieses CVE als kritisch behandeln, da ein kompromittierter vCenter-Server die gesamte virtualisierte Workload-Landschaft gefährdet. CISA hat kein bekanntes Ransomware-Kampagnen-Flag gesetzt, jedoch ist die Aufnahme in die KEV-Liste im Juli 2024 ein klares Signal für aktive Ausnutzung — Patch-Deployment hat Vorrang vor allen anderen Kompensationsmaßnahmen.
Runbook · Schritt 1
Sofort-Response (0-24 h)
- Patch einspielen: VMware Security Advisory VMSA-2022-0009 adressiert CVE-2022-22948 — betroffene Versionen sind vCenter Server 6.5, 6.7, 7.0 sowie Cloud Foundation 3.x (bis 3.11) und 4.x (bis 4.4.1). Zielversion und genaue Build-Nummern im Vendor-Advisory nachschlagen und sofort auf die gepatchte Version aktualisieren.
- Zugriff auf vCenter-Management-Interfaces (TCP 443, TCP 9443) auf dedizierte Management-VLANs und autorisierte Administrator-Workstations beschränken — keine Exposition ins allgemeine Unternehmensnetz oder ins Internet.
- Alle nicht-administrativen Benutzerkonten in vCenter inventarisieren und auf das Minimum reduzieren. Konten mit „Read-Only"-Rolle oder niedrigeren Berechtigungen, die Zugriff auf sensible Konfigurationsdateien haben könnten, temporär deaktivieren bis der Patch eingespielt ist.
- Credentials rotieren, die in vCenter-Konfigurationsdateien gespeichert sind (z. B. Datenbankpasswörter, SSO-Secrets, Extension-Passwörter) — diese sind primäre Ziele der Schwachstelle.
- Audit-Logs des vCenter Server (vpxd.log, vsphere-ui access logs) auf ungewöhnliche Dateizugriffe oder API-Aufrufe durch nicht-administrative Konten der letzten 90 Tage sichten.
Runbook · Schritt 2
Mitigation-Layer
- Netzwerksegmentierung: vCenter Server-Appliance in ein dediziertes Management-Segment isolieren. Firewall-Regeln so setzen, dass nur explizit autorisierte Quell-IPs TCP 443 und TCP 9443 erreichen dürfen — alle anderen Verbindungen DROP.
- Least-Privilege-Durchsetzung: SSO-Rollen in vCenter überprüfen. Prinzip der minimalen Rechtevergabe anwenden — keine generischen „Read-Only"-Konten für Drittanbieter-Integrationen ohne explizite Notwendigkeit.
- Dateisystem-Härtung (Workaround bis Patch): Auf der vCenter Server Appliance (VCSA) per SSH die Berechtigungen kritischer Konfigurationsdateien manuell prüfen und restriktiv setzen (chmod 600 / chown root). Konkrete Dateipfade im VMSA-2022-0009 Advisory nachschlagen.
- WAF/IPS: Eingehende Anfragen auf vCenter-Endpunkte auf anomale API-Zugriffsmuster überwachen — insbesondere GET-Anfragen auf Konfigurationspfade durch Konten ohne Administratorrolle.
- Secrets-Management: Alle in vCenter hinterlegten Credentials in ein zentrales Secrets-Management-System (z. B. HashiCorp Vault) überführen, sodass Klartextpasswörter in Konfigurationsdateien entfallen.
Runbook · Schritt 3
Detection-Regeln
- vCenter Audit-Log / vpxd.log: Zugriffe auf Konfigurationsdateipfade durch Benutzer ohne Administratorrolle — Muster:
user=<non-admin> action=FileRead path=*/vpxd*oder ähnliche Pfade. SPL-Ansatz:index=vcenter sourcetype=vmware:vcenter:log user!=administrator action=read | search path IN ("*vpxd*","*extension*","*vmware-vpx*") - Linux auditd auf VCSA:
auditctl-Regeln auf kritische Konfigurationspfade setzen (-w /etc/vmware-vpx/ -p r -k vcenter_cfg_read). Alerts aufkey=vcenter_cfg_readmitauidungleich root/vcenter-Dienstkonten. - Netzwerk-Telemetrie (Zeek/Suricata): Ungewöhnliche HTTPS-Sessions auf TCP 443 der VCSA von Quell-IPs ausserhalb des Management-VLANs — Suricata-Regel:
alert http $EXTERNAL_NET any -> $VCENTER_IP 443 (msg:"CVE-2022-22948 vCenter non-mgmt access"; flow:to_server; sid:9222294801;) - EDR/Sysmon auf Windows vCenter (falls nicht VCSA): Prozess-Ancestry-Kette
vmware-vpxd.exeodervsphere-uispawnt unerwartete Child-Prozesse oder liest Dateien ausserhalb normaler Pfade — Sysmon Event ID 11 (FileCreate) und EID 10 (ProcessAccess) auf vpxd-Prozesse. - SIEM-Korrelation: Mehrfache fehlgeschlagene und dann erfolgreiche Authentifizierungen eines nicht-administrativen Kontos innerhalb kurzer Zeit, gefolgt von Dateizugriffen — KQL-Ansatz:
event.dataset:"vmware.vcenter" AND user.roles:("ReadOnly") AND event.action:"file_access" | where @timestamp within 5m of auth_success
Metriken
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.11
vmware
cloud_foundation4.0 – 4.4.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.