[English]Die Woche hat VMware by Broadcom Sicherheitsupdates für diverse Produkte, u.a. VMware ESXi-Server herausgegeben, um Sicherheitslücken zu schließen. Eine Schwachstell wurde bereits als 0-day ausgenutzt. Nun warnt The Shadowserver Foundation, dass über 37.000 VMware ESXi-Server über CVE-2025-22224 angreifbar seien. Deutschland ist auch mit einigen Tausend Installationen vertreten.
Rückblick: VMware Sicherheitswarnung und -updates
VMware by Broadcom hatte am 4. März 2025 einen Sicherheitshinweis veröffentlicht, um vor drei Zero-Day-Schwachstellen CVE-2025-22224, CVE-2025-22225 und CVE-2025-22226) zu warnen. Eine dieser Schwachstellen wurde möglicherweise bereits in freier Wildbahn ausgenutzt, patchen wurde dringend angeraten.
Dem Advisory VMSA-2025-0004 zufolge betreffen die Schwachstellen VMware ESXi, Workstation und Fusion. Die Schwachstelle CVE-2025-22224 in VMware ESXi (und Workstation) ist ein Time-of-Check Time-of-Use (TOCTOU) Bug, die zu einem Out-of-bounds-Write führt. VMware hat den Schweregrad dieses Problems, mit einer maximalen CVSSv3-Basisbewertung von 9.3, als kritisch eingestuft. Ich hatte zeitnah im Blog-Beitrag 0-day-Schwachstellen in VMWare ESXi, Workstation und Fusion über den Sachverhalt berichtet.
37.000 ESXi-Server über CVE-2025-22224 angreifbar
Nun warnt The Shadowserver Foundation, dass über 37.000 VMware ESXi-Server über CVE-2025-22224 angreifbar seien. Ich bin über nachfolgenden Post auf diesen Sachverhalt aufmerksam geworden.
Die Suche von The Shadowserver Foundation hat laut deren Seite für Deutschland zum 4. März 2025 um die 2.800 ungepatchte VMware ESXi-Server gefunden.
Ich habe mal die nachfolgenden Tage angesehen – da sinkt die Zahl, um dann bis zum 7. März 2025 wieder anzusteigen. Die in obigem Screenshot gezeigte Kurve des zeitlichen Verlaufs des Patch-Stands bildet diese Delle ebenfalls ab.
Das ist etwas, was für nicht so richtig logisch erklärbar ist. Wie kann die Zahl der angreifbaren Server kurz abnehmen, um einen Tag später wieder anzusteigen? Eine Erklärung, die mir einfällt, wäre, dass die Administratoren ihre VMware ESXi-Server nach der Warnung durch Broadcom für einen Tag offline genommen haben.
Aber dann würde man doch die betreffenden Instanzen durch die Sicherheitsupdates, die durch VMware bereitgestellt werden, patchen? Hat jemand von euch eine Erklärung dazu?
Wo ist das Problem?
man hängt doch seinen esxi nicht direkt ins Netz. Wer es doch tut, dem ist ohnehin nicht mehr zu helfen
Gerade ist mir ein Kinderbuch vor die Füße gefallen und die Seite mit „Vogel Strauß steckt den Kopf in den Sand, und sieht nix mehr“ wurde komischerweise sichtbar. Jetzt rätsele ich, wieso mir diese Seite gezeigt wurde … möglicherweise hängt es damit zusammen, dass „ein Problem nicht per Definition ‚macht man nicht‘ einfach weg geht“ – aber ich bin noch am Nachdenken …
1. Genannte Zahl ungepatchter Systeme = jene die scanbar am Internet.
2. deutlich mehr betroffene Systeme. Sehr viele KMUs haben seit VMWare zu Broadcom keinen Zugriff mehr auf Updates – trotz lizenz. Andere warten seit MONATEN auf neue Lizenz u haben keine. Ich selber beziehe Updates und ISOs v Dienstleister bei dem immerhin 3 von 10 AccountÜbernahmen funktionierten. Kenne anderen kleinen Dienstleister da haben 5 v 5 Wechsel nicht funktioniert. Der hat sich Updates aus dubiosen Quellen besorgt (dumme Idee). Der wird aber jetzt durch anderen Dienstleister der noch an Updates kommt versorgt. Betrifft vor allem vSphereISOs. Aber auch ESXi-ISOs bekommt man nicht einfach so.
Es geht doch bei der Lücke eher um VMs, aus welchen man auf den Host kommt? Und da kann es schon sein, dass die irgendwie am Netz hängen.
Ein typischer Kandidat wäre ein virtualisierter Exchange, der dann über eine präparierte Mail angegriffen wird.
Das Problem ist, dass es sich hier um einen Escape aus einer VM handelt. Ein User welcher z.B. auf einem Terminal-Server arbeitet, könnte Code auf dem ESXi-Host ausführen und damit faktisch den Hypervisor kompromittieren. Das ist vor allem für Cloudanbieter ein Problem. Was sollte einen Angreifer davon abhalten sich eine VM in der Cloud zu mieten und von dort Angriffe auf den Host zu starten? Vielleicht kommt man ja an andere VMs auf dem gleichen Host, welche die Daten anderer Kunden beinhaltet. Dafür muss der eigentlich ESXi-Host nicht aus dem Internet erreichbar sein.
Der Gedanke ist ja grundsätzlich richtig. Jedoch gehe ich davon aus, das es keine Möglichkeit gibt, aus der Ferne zu erkennen, ob dieser Server auf einem ungepatchten ESX Host läuft. Somit würde dies auch die oben genannten Scandaten nicht beeinflussen.
Moin,
bestimmt hängen die Leute die Server jetzt ans Internet, damit ein Dienstleister diese updatet 😂
MfG,
Blackii
Du wirst lachen.
Tatsächlich schon Kunden gehabt, die lieber die Server exposed haben anstatt da für die Dienstler ein VPN einzurichten. *Facepalm*
Dann aber bei HPE-Servern bitte auch gleich die iLOs mit ins Netz hängen. Wie soll ich sonst die HCL sicherstellen, wenn ich auf dem Server nicht bequem neue Firmware flashen kann. ;-)
Wird doch fleißig gemacht?
https://www.borncity.com/blog/2022/01/29/ber-20-000-hpe-proliant-server-mit-veraltetem-ilo-per-internet-erreichbar/
Natürlich gibt es einen Dummen der selbst das macht. Mein Kommentar war ironisch gemeint. ;-)
Im Grunde hat das Broadcom zu verantworten. Die haben immerhin sehr viele Installierte Instanzen von einem Tag auf den Nächsten von der Möglichkeit auf Updates abgeschnitten.
Und dann ist wie immer die Methodik zu hinterfragen woher die Zahlen kommen.
Kann nur zustimmen: Broadcom hat für die ehemals „perpetual“ (und OEM) Lizenzen irgendwann mal den weiteren Zugang auf reine Sicherheitsupdates versprochen, um danach im Support Center sämtlich Zugänge einfach stillzulegen.
Ohne aktiven Abovertrag lassen sich diese Patches (fast) nur aus irgenwelchen mehr oder weniger dubiosen Quellen im Netz herunterladen (außer natürlich, man hat Zugang zu den Downloads von aktiven Verträgen anderer).
Lizenzrechtlicher Aspekt beiseite (fast alle, die ich kenne, haben Produkt gewechselt oder sind auf dem Weg dahin): viele trauen sich auch gar nicht mehr, weitere Patches zu installieren, da sie befürchten, die OEM-Lizenzen von deren Servern würde damit invalidiert. Die wollen das bis zur Migration aussitzen. Das wird natürlich keine großen Unternehmen betreffen, aber unzählige kleinere Betriebe, bei denen ESXi „mit dem Server“ mitbestellt wurde.
Meiner Erfahrung nach aber eine unberechtigte Sorge: die Patches innerhalb derselben „u“ und möglicherweise auch Minor-Version (nicht getestet) fragen die aktive Abo-Lizenz nicht ab.
Rechtlich bleibt es aber dabei: ohne Abo gibt’s keine Berechtigung.
Kann ich so nicht bestätigen. Das VIB-Depot von VMware (https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/esx/vmw/vmw-esx-index.xml) ist weiterhin ohne Eingabe von Zugangsdaten verfügbar und letzten Dienstag hat der Lifecycle-Manager brav drei Updates angekündigt, die sich auch problemlos installieren ließen.
„The number of patch definitions downloaded (critical/total): ESX: 3/3 ID: ESXi70U3s-24585291 Impact: Critical Release date: 2025-03-04 Products: embeddedEsx 7.0 VMware ESXi 7.0.3 Patch Release ID: ESXi_7.0.3-0.135.24585291 Impact: Critical Release date: 2025-03-04 Products: embeddedEsx 7.0 ESXi Component – core ESXi VIBs ID: esx-update_7.0.3-0.135.24585291 Impact: Critical Release date: 2025-03-04 Products: embeddedEsx 7.0 ESXi Install/“
Um das zu erklären, wäre es sicher wichtig zu wissen, wie dieser Check überhaupt funktioniert. Was wird denn herangezogen um zu sagen das System ist anfällig. Da schweigt sich der Anbieter aber sicher aus. Auch gibt es die Möglichkeit, das diese Checks auf andere Versionen angepasst wurden, welche anfangs nicht berücksichtigt wurden. Und zu guter letzt setzt man auch Honeypots auf um die Ausnutzung festzustellen.
Die Methodik ist in der Tat unklar. Ein Scan aus dem Internet dürfte in diesem Fall kaum korrekte Ergebnisse liefern. In der Regel sind ESXi-Hosts, Virtual Center & Co. nicht aus dem Internet erreichtbar. Selbst innerhalb einer Firma sollte nur die IT, nicht aber jeder Arbeitsplatzrechner dort hingelangen können (Netzsegmentierung). Falls die Werte also durch einen Online-Scan ermittelt wurden, so dürfte die Dunkelziffer entsprechend hoch sein. Eine andere Möglichkeit wären noch Telemetrie-Daten z.B. aus Virtual Center. Zumindest Broadcom wird einen ungefähren Überblick über die Versionsstände bei seinen Kunden haben. Ob sie diese Daten weitergeben ist aber auch unklar.
Ein Kollege hatte die Server in einer Einrichtung gepatcht und musste die danach wegen Problemen aus dem Backup wieder herstellen. Was genau war weiß ich nicht aber er war vermutlich einer, bei dem die Sicherheitslücke nur kurz mal geschlossen war.
Mit Lifecycle Manager das Rollup ESXi70U3s-24585291 erfolgreich auf einer Node installiert. Warte nun 24h und ziehe dann die anderen Nodes nach.
Jo, man nehme einfach die Seite https://esxi-patches.v-front.de/ und installiert darüber (Verweis auf das offene Repo hostupdate.vmware.com) die Updates, auch ohne laufende Subscription, das kann nicht schwierig sein.
Aber ja, wer seinen ESXi ins Netz hängt, sollte besser umschulen…