[English]Sicherheitsexperten von Microsoft haben ja gerade die Auth Bypass-Schwachstelle (CVE-2024-37085) offen gelegt. Diese ermöglicht Angreifern,vollständige administrative Berechtigungen auf mit einer Domäne verbundenen ESXi-Hypervisoren zu erhalten. Die Schwachstelle wird von mehreren Ransomware-Betreibern ausgenutzt, um ESXi-Installationen anzugreifen. Es sind eine Menge VMware ESXi-Systeme weltweit mit dieser Schwachstelle in Betrieb und öffentlich erreichbar. Leider gibt es für ältere ESXi-Versionen keine Sicherheitsupdates. Zudem stellt sich die Frage, wie man solche Schwachstellen eigentlich finden kann. Hier noch eine kurze Nachlese zum Sachverhalt.
Anzeige
Die VMware ESXi Schwachstelle CVE-2024-37085
Seit 2023 beobachtet Microsoft Ransomware-Kampagnen, die auf VMware ESXi-Instanzen zielen. Nach Analyse solcher Angriffe ist man darauf gekommen, dass sich bei ESXi-Instanzen in einer Domäne eine Gruppe namens "ESX Admins" und auch Benutzer neu anlegen lassen, ohne dass es administrative Berechtigungen benötigt. Das Ganze wurde mit einem CVE 3.0-Index von 6.8 bewertet.
Dieser Befund wurde Anfang 2024 an VMware gemeldet. Ich hatte über die Details im Blog-Beitrag Microsoft entdeckt VMware ESXi Auth Bypass-Schwachstelle CVE-2024-37085 berichtet. Singlethreaded weist in diesem Kommentar darauf hin, dass VMware ESXi 7 noch bis 2025 Support erhält – es gibt wohl Support bis 2. Oktober 2025.
Aber diese Version 7 wird kein Update erhalten, um die Schwachstelle zu schließen, wie aus diesem Support-Dokument hervorgeht. Betroffene müssen die in den Supportbeiträgen beschriebenen Maßnahmen zur Abschwächung der Angriffsmöglichkeiten durchführen.
Anzeige
Über 20.000 ESXi-Systeme per CVE-2024-37085 angreifbar
Die Sicherheitsexperten der Shadowserver Foundation haben zum 30. Juli 2024 einen Scan des Internets auf über CVE-2024-37085 angreifbare VMware ESXi-Systeme durchgeführt. Nachfolgender Tweet zeigt die Verteilung – insgesamt wurden 20.275 angreifbare Instanzen gefunden. Die USA, Frankreich und Deutschland (114) sind tief rot eingefärbt und gut dabei. Aber auch China, Kanada, Russland und der Iran haben wohl eine Menge angreifbarer Systeme in Betrieb.
Da die Schwachstelle von Ransomware-Gruppen seit 2023 ausgenutzt wird, besteht eine gewisse Wahrscheinlichkeit, dass wir demnächst weitere Opfer verzeichnen können, die erstaunt feststellen, dass sich "Besucher im Netzwerk tummeln".
Schwachstellen: Die Nadel im Heuhaufen finden
Im Fall des ESXi-Servers stießen Sicherheitsexperten von Microsoft eigentlich nur durch Zufall auf die Schwachstelle CVE-2024-37085, als sie Ransomware-Vorfälle untersuchten. Der Kommentar hier deutet an, dass das Verhalten des ESXi-Servers eigentlich schon länger bekannt sein musste. Wie es auch immer sei, es stellt sich die Frage, wie solche Schwachstellen – möglichst vor einer Ausnutzung – eigentlich zukünftig gefunden werden sollten.
Richard Werner, Security Advisor bei Trend Micro, vergleicht das Auffinden von Schwachstellen "mit einer Pilzsuche" und merkt an, dass die Aufdeckung dieser Schwachstelle bereits am 25. Juni 2024 erfolgte. Beim Patch-Tuesday am 9. Juli 2024 hat Microsoft dann eine ganz ähnliche Sicherheitslücke für den firmeneigenen Hypervisor „Windows Hyper-V" geschlossen. Auch diese wird bereits von Angreifern ausgenutzt und sollte entsprechend gepatched werden. Werner fragt daher: Ist das ein Zufall? Nachfolgend sein Kommentar zum aktuellen Vorfall.
Einzelfall oder „Pattern"
Einen Einzelfall zu beschreiben ist das eine. Die Häufigkeit mit der ähnliche Sicherheitslücken in verschiedenen Programmen auftauchen, das andere. Am besten kann man die aktuelle Herausforderung im Patchmanagement mit dem Pilze sammeln vergleichen. Jeder, der das schon einmal getan hat, weiß, dass Pilze jedes Jahr am selben Fleck zu finden sind und auch, dass es eine gute Idee ist, die unmittelbare Umgebung nach weiteren Exemplaren abzusuchen.
Genauso läuft es in der Sicherheitsforschung. Wird eine spannende Sicherheitslücke entdeckt, werden ähnliche Programme durchsucht. Aber auch beim selben Programm wird nach dem erfolgreichen Patch geprüft, ob das Problem nicht doch irgendwie ausgenutzt werden kann. Sicherheitsforscher auf beiden Seiten der Ethikgrenze gehen so vor. Je mehr ein Patch als Reaktion auf einen bereits stattfindenden Angriff erfolgt (Stichwort „Zero Day"), desto wahrscheinlicher ist es, dass in seiner unmittelbaren Umgebung „noch etwas zu finden ist". Schließlich musste der betroffene Hersteller schnell reagieren, um seine Kunden zu schützen und hat dabei vielleicht etwas übersehen.
Alle Jahre wieder
Was im gewählten Beispiel relativ kurzfristig erscheint, ist keineswegs nur darauf beschränkt. So machte beispielsweise eine Sicherheitslücke in der Software „MoveIT" 2023 von sich reden. Mehr als 1000 Unternehmen weltweit verloren Daten und die dahinterstehende Gruppierung „Clop" erlangte Millionen. Fast ein Jahr später, im Juni 2024, gab es erneut Anzeichen einer Ausnutzung in MoveIT und im Juli 2024 warnte der Hersteller „Progress" vor einem weiteren Bug in seiner Software.
Auf beiden Seiten wurde geforscht und es wurden Schwachstellen gefunden – In einem Fall waren die Angreifer schneller, das andere Mal die Sicherheitsforscher. Pilzkenner werden jetzt darauf hinweisen, dass genau das der Grund ist, warum Sammelstellen „Familiengeheimnisse" sind und niemandem verraten werden. So aber funktioniert die IT-Sicherheit nicht. Gibt es Angriffe auf Schwachstellen, müssen Opfer gewarnt werden – je gefährlicher, desto lauter. Leider erfahren dadurch auch die „anderen" davon und der Fundort bleibt nicht geheim.
Risikomanagement Patchen
Der Umgang mit Sicherheitslücken wird dadurch zum dauerhaften Problem, das immer mehr Arbeitszeit verschlingt, und man bekommt das Gefühl dieselbe Software immer wieder patchen zu müssen. Darüber hinaus nimmt die Gefährlichkeit der Herausforderung zu. Laut dem „Known exploited vulnerability"-Katalog wird aktuell alle drei Tage eine neue Sicherheitslücke hinzugefügt. Patches bzw. Updates bergen dagegen eigene Risiken, ein Test ist deshalb sinnvoll und, je nach Compliance-Standard, oft auch vorgeschrieben.
Um die Sache in den Griff zu bekommen, empfiehlt sich deshalb ein risikobasierter Ansatz mit klarer Priorisierung bei der Vorgehensweise und Erkennungssystem falls Angreifer doch schneller sind. IT-Sicherheitshersteller haben darauf reagiert, indem sie Ansätze anbieten, diese Art Risikomanagement mit Werkzeugen der Angriffserkennung zu kombinieren.
Anzeige
Was mich an Patches für ESXi interessiert (solange wir nicht alles auf Proxmox umgestellt haben): geht dadurch die mit der Hardware verbundene perpetual Lizenz verloren?
Das ist Broadcom ohne weiteres zuzutrauen natürlich ein Risiko, das man erst gegen die eigentliche Sicherheitslücke abwägen muss.
Stand jetzt kann man jeden Patch gefahrlos installieren, bis 8u2c selbst probiert.
Vielen Dank für die Info, Michael!
1)
ESXi von aussen erreichbar?
Läuft dann wohl unter natürliche Auslese.
2)
Misstrauen das Broadcom mit den Patches die Lizenzen ändert. Wenn man soweit ist und ich gehe damit kann die Ansage nur sein „ab durch sie Mitte und weg von Vmware".
Nutze Vmware seit der Jahrtausendwende aber das Thema ist durch.
(1) habe ich mich auch gefragt, was für Anfänger das sein müssen. Die ESXi und vCenter gehören in separate Netze, selbst innerhalb des Unternehmens. Und nicht von Außen erreichbar!Übrigens auch die HyperV, Proxmoxx und Nutanix-Server, dicke Firewall davor, so dass nur Admins aus ihrem Admin-Netz zugreifen dürfen. Das ist Security-Best-Praxis für Tier-0-Server.
Desweiteren die Frage nach der "ESX Admins" Gruppe und Usern, scheinbar im AD, wofür es schon gewisse Rechte braucht, um diese Gruppe anzulegen. Dumm natürlich, dass ESXi (und vCenter?) diese Gruppe anhand ihres Namens automatisch zu Admin macht. Aber wenn man diese Gruppe anlegen kann, dann kann man den User auch zu der in dieser Umgebung schon verhandenen ESXi-Admingruppe hinzufügen, egal wie sie heißt, das dürfte auch etwas weniger auffallen. Oder man könnte mit diesen Rechten auch schon ganz viele andere schädlichen Sachen machen.
Sehe ich genauso. Wenn da jemand eine Gruppe in der AD anlegen kann ist es eh zu spät :D In den meisten Unternehmen zumindest mit gleichen Passwörtern an 100 Stellen…
Die 114 gehören zu Italien. ;)
Die Zahl für Deutschland ist nicht sichtbar, aber auf der Homepage der Shadowserver Foundation kann man das sehen.
Bei Deutschland sind es 2022 Instanzen.
https[:]//dashboard.shadowserver.org/statistics/combined/map/?map_type=std&day=2024-07-30&source=http_vulnerable&source=http_vulnerable6&tag=cve-2024-37085%2B&geo=Europe&data_set=count&scale=log
Was ich mich aber direkt frage: Warum in aller Welt sind die ESXi-Instanzen aus dem Web erreichbar? Das kann doch nur von Hobby-Admins so eingerichtet worden sein.
Der ESX Host muss aber einem aktiven AD Join haben. Die meisten haben nur das vCenter mit dem AD Verbunden. Zum ausnutzen müsste man eigentlich erst einmal den Host mit dem AD Joinen. Wenn man die Host Rechte dazu hat lokal esx Anmeldung und Rechte im AD. Dann braucht man die Sicherheitslücke gar nicht. Als Workaround kann man auch einfach eine AD Gruppe erstellen und die Sicherheit der Gruppe beschränken. Somit kann niemand eine Gruppe erstellen mit den gleichen Namen. Das massig ESX Host einfach so mal im Internet erreichbar sind ist natürlich blöd, aber wie soll jemand deswegen mit der AD Gruppe darauf zugriff bekommen ;)
Das Broadcom man das trotzdem nicht Patchen will für VMware 7 verstehe ich allerdings auch nicht.
Das mit den Updates für V 7 ist eine absolute redflag.
Da stinkt was gewaltig.
Ja klar, ist etwas verwunderlich, wenn die Lizenz noch gültig ist.
Kleiner Trost: Es sind nur drei Parameter anzupassen, geht nach meinem Ermessen schneller und einfacher, als einen Patch herunterzuladen und einzuspielen.
…wenn Sie jetzt ihren Leidensgenossen noch sagten, welche 3 das sind und wie sie anzupassen sind wäre ihr Kommentar ungleich wertvoller.
P.S. "Isch abe gar kein VMWare" (Stimme von Angelo)
Steht doch im von Günther verlinkten Support-Dokument drin, welche das sind. Und der Artikel ist auch ohne Zugang zum Supportportal lesbar. Warum soll er die dann nochmal hierhin schreiben?
passend dazu :
Dell meldet ein Problem in iRDAC.
Auch da gibt es genug Hirselbinden die den Zugang und andere KVM Lösungen direkt erreichbar von aussen machen.
Gruß
Kann meinen Vorrednern nur zustimmen. Unabhängig von dieser Lücke, kritische Systeme wie Hypervisor haben so mal gar nichts im öffentlichen Internet verloren. An das Management Interface muss in der Regel eine recht überschaubare Anzahl an Personen, das gehört abgesichert. Wenn man da wirklich irgendwie von außen dran muss wg. Bereitschaft, dann nur mittels gesicherter Einwahl per VPN auf einen Jumphost und von da dann weiter.
Ich hörte auf solche Aussagen hin oft "Herr B., wir sind keine Bank.". 🤷♂️
Und schon gekündigt? 🙂
Wie sagt doch eine Grundregel des Glücklichseins? "Akzeptiere, was du nicht ändern kannst!"
Sachlich habe es deshalb simpel gelöst: Mit dem Aufmerksammachen des Zuständigen ist mein Job erledigt. Sobald ich das Aufmerksammachen nachweisbar habe (deswegen sehr schnell nur noch per Mail) ist mir das sachlich egal. Ich habe sogar noch Verantwortung und Arbeit gespart (gerne wird ja Der beauftragt, der es ansprach). 👍
Na ich würde mir das nicht so einfach machen. Wenns knallt, bist du dran. Mindestens mit Reparieren und mit blöden Nervfragen, wann alles wieder läuft. Und davon abgesehen zeigen solche Aussagen ja recht deutlich, dass dem Entscheider IT nicht wichtig ist.
Wie auch immer, ist ja dein Ding.
Der Trick ist, keine Angst um seinen Job zu haben, dann kann man Vieles recht entspannt angehen.
Neben dem Fakt, dass es schlicht dumm ist, gegen Windmühlen kämpfen zu wollen gibt es aber noch einen weiteren wichtigen Aspekt: Wer die Verantwortung trägt muss auch die Entscheidungsgewalt haben. Als ihm Untergebener hat man natürlich d. Recht/Pflicht, ihm vermeintliche Fehler/Mängel nahezubringen, aber die Entscheidung ist ihm vorbehalten und der Untergebene hat sie schlicht und einfach zu akzeptieren. Wenn Sie das nicht können werden sie nirgendwo lange sein (es sei denn man ist zwingend auf ausgerechnet diese Person angewiesen) – ich würde jedenfalls solche Untergebenen nicht lange dulden, sie erzeugen zu viele Reibungsverluste.
Ich würde unter diesen Umständen gehen, deshalb habe ich ja gefragt, ob du schon gekündigt hast.
Du siehst das meines Erachtens aus der falschen Perspektive, wenn du sagst, man soll keine Angst um seinen Job haben und muss dem Verantwortlichen quasi zu Kreuze kriechen. Umgekehrt wird ein Schuh draus: Jeder Chef sollte heutzutage Angst haben, einen ITler zu verlieren. Das ist dir offenbar nicht bewusst, da bist du nicht im Hier und Jetzt angekommen. Und ich wäre mir zu schade, in einem Umfeld zu arbeiten, wo IT und insbesondere IT-Sicherheit nicht wichtig genommen wird. Wie gesagt: Am Ende bist du derjenige, der das alles fixen muss.
Aber wie gesagt: Ist ja dein Ding.
😂 "nicht im hier und jetzt angekommen" ist neuerdings ein Argument? 😂
Zum Rest sage ich mal lieber nichts, ausser: Leute mit ihrer Arbeitseinstellung wollte ich jedenfalls nicht und Reisende soll man bekanntlich nicht aufhalten.
Schon seltsam. Einer, der sagt "Mir doch egal, hab es ja gemeldet und damit Verantwortung und Arbeit gespart" (um mal den bisherigen Sermon kurz zusammenzufassen), glaubt, irgendwas über meine Arbeitseinstellung erzählen zu können. Merkst du selbst? Na ja, wahrscheinlich nicht.
Schon seltsam. Ein Besserwisser, der die Entscheidung seines Chefs nicht akzeptieren kann denkt trotzdem, man könne gut mit ihm in einem Team arbeiten.
Merkst du selbst? Na ja, wahrscheinlich nicht.
Schon seltsam. Weder das eine, noch das andere hat der Besserwisser je behauptet. Zwei klassische Strohmann-Argumente. Merkst du selbst? Na ja, wahrscheinlich nicht.
Schon seltsam, der Besserwisser stellt sich also dumm: Denn selbstverständlich sagte er das implizit (er wäre gegangen, ich bin [zensiert] es nicht zu tun).
Fluktutation kostet Geld und bringt Unruhe in die Belegschaft, auch wenn sie aus so dummen Gründen wie "der hat nicht gemacht was ich wollte!!!" passiert (== Egoist, kein Teamplayer).
Aber ich klinke mich hier aus, es ist mir zu blöd mit einem starrsinnigen Kind zu diskutieren.
Und wenn man gar nicht mehr weiterweiß, dann kommt man mit Argumentum ad hominem und schleicht dann beleidigt von dannen. Süß. 🥳
Ich Frage mich wie viele immer noch mit Broadcom kämpfen um Zugang zu der Site ID/Lizenzen zu erhalten. Wir haben bis heute keinen Zugang weil wir immer über ein automatischen Prozess abgelehnt werden.
Kann/sollte Ihr VMWare-Händler ihnen da nicht helfen?
Frage ist, ob er das kann. Es kann ja durchaus sein, dass der bisherige Händler/Partner jetzt kein direkter Partner mehr ist. Broadcom hat ja das Partner Programm massiv ausgedünnt. Zudem habe ich Zweifel, ob die Partner da überhaupt groß Einfluss drauf nehmen können, ich könnte mir sehr gut vorstellen, dass das nur Broadcom selbst kann.
Ich seit gestern nicht mehr :-)
Ich hatte schon länger irgendwo her eine SiteID, allerdings keinen Zugriff auf die vorhandene vSphere Lizenz. Gestern nochmal bei der deutschen Support Hotline angerufen (06151-2743986). Ging wie bisher immer als Weiterleitung in den englischsprachigen Support. Dort hat dann nach dem zweiten!!! Klingeln eine Mitarbeiterin abgenommen, mich per direkt anschließender Zoom-Sitzung durch die notwendigen Schritte im Support-Portal geleitet und die von mir erstellten "Request Access" Anfragen dann auch direkt serverseitig freigegeben. In einer guten Viertelstunde hatte ich Zugriff auf meine Lizenzen. Das war nach dem ganzen Schlamassal mal eine gute Erfahrung.
PS: Wie ich aber feststellen muss – es hilft mir nicht viel. Denn wir nutzen eine Essentials Plus Lizenz, die wohl nach Ablauf des Support im kommenden Januar nicht verlängert werden kann.