[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.
Rollup ESXi70U3s-24585291 ist jetzt auf allen Nodes installiert. Keine Auffälligkeiten oder Probleme.
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…
Funktioniert diese Methode auch um Systeme welche mit einem Custom Image installiert wurden zu patchen? (In meinem Fall ein HPE Proliant…)
Ja.
Wenn Du die Links von V-Front verfolgst, siehst Du, daß die URL von VMware (hostupdate.vmware.com) ist und die originalen VIbs (die haben eine kryptographischer Signatur) verlinkt werden.
Diese kannst Du natürlich auch manuell herunterladen und mittels „esxcli software vib install“ installieren. Nicht alle wirst Du brauchen, wenn etwa kein VSAN installiert ist.
Bei einem HPE Custom-Image sollte im Lifecycle-Manager zusätzlich noch „vibsdepot.hpe.com“ eingetragen worden sein, auf diesem Wege erhalten die Server HPE-spezifische Gerätetreiber und Erweiterungen (etwa zum Fastboot oder agentless Management). Im Moment sind da die letzten Treiber-Updates für VMware 7 und 8 von 6. Februar 2025.
Danke!
Ich verwende keinen vCenter Server/Lifecycle Manager, habe bisher immer mittels ISO von HPE die Upgrades gemacht (Von CD booten und „Upgrade“). Da meine Lizenz/Wartungsvertrag (vSphere 7 Essentials) schon länger abgelaufen ist komme ich leider nicht mehr an die neuen ISOs heran…. Wenn ich die obige Methode verwende und den Patch einspiele ohne HPE spezifische Updates zu machen, was kann schlimmstenfalls passieren? Überschreibt der Patch HPE spezifische Treiber?
Habe gesehen es gibt auch ein „Security-Only“ Profil (ESXi70U3s-24585291) das man statt des Standard Profils wählen könnte, würde das die bessere Wahl sein?
Nochmals Danke für Deine/Eure Unterstützung
Ein vCenter kann man auch mal schnell nur für die Updates ausrollen, entweder als 60-Tage-Evaluation oder mit dem im vSphere Essentals Paket enthaltenen Key sogar permanent.
Ein zweiter Weg wäre das halbjährlich von HPE veröffentlichte „Service Pack for Proliant“, das kann neben Windows und Linux auch VMware-Server auf Aktualität untersuchen und erforderlichenfalls alle Komponenten (auch BIOS und Treiber) patchen. Nützt nur in diesem Fall nicht, da das letzte SPP vom Januar ist.
Was Du machen kannst:
Erstmal eine Inventarisierung der aktuellen Installation mittels „esxcli software vib list“.
Anschließend vergleichst Du die vorgefundenen Versionen mit denen, die auf v-front als aktuell gelisteten sind und aktualisierst sie bei Bedarf.
Für einen anderen Hersteller (Dell) ist das Verfahren hier mal ausführlich beschrieben: https://www.dell.com/support/kbdoc/de-de/000020020/vxrail-anleitung-zum-installieren-oder-entfernen-eines-vib-auf-esxi
Dabei sollte man wirklich nur die Pakete aktualisieren, die auch installiert sind. Bei HP(E) entsinne ich mich an mindestens zwei Treiber (LSI MegaRaid und Intel Netzwerkkarten) die Probleme machten, wenn man die von HPE angepaßte Version und den Originaltreiber des Herstellers gleichzeitig installiert hat – da haben sich dann wohl Dateien überschnitten.
Die Einstufung, ob „security“ oder nicht steht auch bei v-front, nicht-kritisch wären z.B. Aktualisierungen der VMware Tools für die Gastbetriebssysteme.
@Fritz
Das direkte einbinden von vibsdepot.hpe.com in den Lifecycle-Manager funktioniert nicht mehr.
Man beachte die Fussnote 3 in diesem Dokument:
https[://]vibsdepot.hpe.com/mapping/SPP-HPE_Custom-Image-vibsdepot-mapping-Gen9-later.pdf
„The ESXi 7.0 content published in the HPE VMware Software Depot is for offline use only. It cannot be used with VMware vSphere Image Builder, VMware Update Manager or VMware Life Cycle Manager (vLCM) as an online depot.“
Sie auch Hinweis ganz oben auf https[://]vibsdepot.hpe.com/
„HPE has removed all ESXi 7.0 U3 content from vibsdepot in alignment with the VMware announcement that ESXi 7.0 Update 3, ESXi 7.0 Update 3a, and ESXi 7.0 Update 3b were removed from all online and offline download portals on November 18th 2021.Please see KB 86398 for further details. HPE has published new ESXi 7.0 U3 content on vibsdepot based on the VMware announcement of a new ESXi 7.0 U3 release, as well as a new ESXi 7.0 U3 HPE Custom Image and AddOn and new and updated documentation. See the HPE Custom Image download page to download the latest ESXi 7.0 U3 HPE Custom Image and AddOn. See the links on vibsdepot under Current Mapping and Recipe Documents and the Documentation section for the new and updated documentation.“
Die Custom-Images-Links von HPE leiten jetzt ins Broadcom-Portal weiter. Es können nur noch Treiber und Management-SW-Bundles von der HPE-Seite heruntergeladen werden.
Falls Du einen Weg gefunden hast, die Treiber-Update trotzdem in den Lifecycle-Manager einzubinden wäre es interessant zu erfahren was es für einen Trick braucht.