Microsoft entdeckt VMware ESXi Auth Bypass-Schwachstelle CVE-2024-37085

Sicherheit (Pexels, allgemeine Nutzung)[English]Sicherheitsexperten von Microsoft sind einer Ransomware-Kampagne auf die Schlichte gekommen, die auf VMware ESXi-Instanzen zielt. Über eine Auth Bypass-Schwachstelle (CVE-2024-37085) ist es möglich, 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.


Anzeige

Entdeckung durch Microsoft

Im Jahr 2023 haben Sicherheitsforscher von Microsoft beobachtet, dass Ransomware-Akteure ESXi-Hypervisoren ins Visier genommen haben, um eine Massenverschlüsselung mit wenigen Klicks zu ermöglichen. Microsoft gibt an, dass Gruppen wie Storm-0506, Storm-1175, Octo Tempest, Manatee Tempest und andere ESXi-Verschlüsselungsprogramme wie Akira, Black Basta, Babuk, Lockbit und Kuiper beobachtet wurden. Es zeigte sich auch, dass Ransomware-Betreiber ihre Angriffstechniken ständig erneuern, um die Auswirkungen auf die von ihnen angegriffenen Unternehmen zu erhöhen.

VMware ESXi Auth Bypass Vulnerability CVE-2024-37085

Microsoft-Sicherheitsforscher sind kürzlich auf eine Schwachstelle in ESXi-Hypervisoren gestoßen, die bereits von mehreren Ransomware-Betreibern ausgenutzt wird. Bei einem Ransomware-Angriff kann die volle administrative Berechtigung auf einem ESXi-Hypervisor über die Schwachstelle erlangt werden. Dies ermöglicht es dem Bedrohungsakteur, das Dateisystem zu verschlüsseln, was die Ausführungs- und Funktionsfähigkeit der gehosteten Server beeinträchtigen kann. Außerdem kann der Bedrohungsakteur auf gehostete VMs zugreifen und möglicherweise Daten exfiltrieren oder sich seitlich im betreffenden Netzwerk bewegen.

Analyse der Schwachstelle CVE-2024-37085

VMware ESXi ist ja ein Bare-Metal-Hypervisor, der direkt auf einem physischen Server installiert wird und direkten Zugriff und Kontrolle über die zugrunde liegenden Ressourcen bietet. In VMware ESXi-Hypervisoren lassen sich virtuelle Maschinen aufsetzen. Häufig werden auch wichtige Server in einem Netzwerk (AD-Server etc.) per ESXi virtualisiert.


Anzeige

ESXi vulnerability CVE-2024-37085
Quelle: Microsoft

Microsoft-Sicherheitsforscher sind bei der Analyse von Angriffen auf eine Technik zur Ausnutzung der Schwachstelle CVE-2024-37085 gestoßen, die von Ransomware-Gruppen wie Storm-0506, Storm-1175, Octo Tempest und Manatee Tempest in zahlreichen Angriffen eingesetzt wird. In mehreren Fällen führte der Einsatz dieser Technik zu Ransomware-Einsätzen von Akira und Black Basta.

Die Angriffstechnik umfasst die Ausführung der folgenden Befehle, welche zur Erstellung einer Gruppe namens "ESX Admins" in der Domäne und zum Hinzufügen eines Benutzers zu dieser Gruppe führt:

net group "ESX Admins" /domain /add
net group "ESX Admins" username /domain /add

Die Bedrohungsakteure können mit diesem Befehl die Schwachstelle in domänenverbundenen ESXi-Hypervisoren ausnutzen, um die Berechtigungen auf den ESXi-Hypervisor zu erweitern und vollen administrativen Zugriff zu erlangen. Eine weitere Analyse der Schwachstelle ergab, dass VMware ESXi-Hypervisoren, die mit einer Active Directory-Domäne verbunden sind, jedem Mitglied einer Domänengruppe namens "ESX Admins" standardmäßig vollen administrativen Zugriff gewähren.

Bei dieser Gruppe handelt es sich nicht um eine integrierte Gruppe in Active Directory, die standardmäßig nicht existiert. ESXi-Hypervisoren überprüfen nicht, ob eine solche Gruppe vorhanden ist, wenn der Server einer Domäne beitritt, und behandeln alle Mitglieder einer Gruppe mit diesem Namen weiterhin mit vollem Administratorzugriff, selbst wenn die Gruppe ursprünglich nicht vorhanden war. Außerdem wird die Mitgliedschaft in der Gruppe anhand des Namens und nicht anhand der Sicherheitskennung (SID) bestimmt. Microsoft-Forscher haben drei Methoden zum Ausnutzen dieser Schwachstelle identifiziert:

  • Hinzufügen der Gruppe "ESX Admins" zur Domäne und Hinzufügen eines Benutzers zu dieser Gruppe
  • Umbenennen einer beliebigen Gruppe in der Domäne in "ESX Admins" und Hinzufügen eines Benutzers zu der Gruppe oder Verwenden eines vorhandenen Gruppenmitglieds
  • Aktualisierung der ESXi-Hypervisor-Privilegien, denn selbst wenn der Netzwerkadministrator eine andere Gruppe in der Domäne zur Verwaltungsgruppe für den ESXi-Hypervisor ernennt, werden die vollständigen administrativen Privilegien für Mitglieder der Gruppe "ESX Admins" nicht sofort entfernt und lassen sich missbrauchen

Dieser Befund wurde Anfang 2024 an VMware gemeldet. Microsoft empfiehlt Unternehmen, die domänenverbundene ESXi-Hypervisoren verwenden, das von VMware veröffentlichte Sicherheitsupdate zur Behebung der Schwachstelle CVE-2024-37085 anzuwenden. Weiterhin gibt Microsoft im Beitrag Ransomware operators exploit ESXi hypervisor vulnerability for mass encryption Hinweise bezüglich Richtlinien, die Unternehmen außerdem  helfen, ihr Netzwerk vor Angriffen zu schützen. Die US-Sicherheitsbehörde CISA warnt Unternehmen, laut diesem Artikel, vor der Schwachstelle und gibt Behörden drei Wochen Zeit, um die ESXi-Instanzen zu patchen.


Anzeige

Dieser Beitrag wurde unter Sicherheit, Virtualisierung abgelegt und mit , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

16 Antworten zu Microsoft entdeckt VMware ESXi Auth Bypass-Schwachstelle CVE-2024-37085

  1. TBR sagt:

    Ich sage doch immer – die Jungs sind gut.

  2. Singlethreaded sagt:

    Obwohl ESXi 7 noch bis 2. April 2025 Support hat, wird es dafür keinen Patch geben.

    https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/24505

    Es bleibt nur der Workaround, wenn man aus irgendwelchen Gründen (noch) nicht von ESXi 7 auf ESXi 8 kann:

    https://knowledge.broadcom.com/external/article/369707/

    • Daniel A. sagt:

      Oder auch, wenn man noch nicht die 8U3 installieren kann, denn das ist kein Patch sondern ein Minor-Release Upgrade, was diverse Änderungen mitbringt. Und z.Bsp. Veeam unterstützt 8U3 noch nicht, nur 8U2.

      • Singlethreaded sagt:

        Guter Punkt. Auch die HCL kann zum Haar in der Suppe werden, weil die Hardware noch keine Freigabe für die 8U3 hat. Im Labor okay, aber wer möchte schon ohne Support in der Produktivumgebung fahren.

    • MOM20xx sagt:

      also ich hab jetzt im broadcom portal eingeloggt, eben weil wir auch esxi 7.0 noch einsetzen. Gemäß Broadcom ist sogar noch bis 2. Oktober 2025 support. Ich hoffe nicht, dass das nun gängige Praxis wird und auf Patches verzichtet wird bei dem Produkt und nur noch workarounds kommen um so die Leute zum Updaten zu zwingen.

      • Daniel A. sagt:

        Ja ich finde das auch sehr bedenklich. Als es zuletzt eine Sicherheitslücke gab (allerdings mit höherem Score) wurden alle Versionen bis runter zur 6.7 noch mit einem Patch versehen. Zu dem Zeitpunkt war 8U2 aktuell und sie hatten sogar einen Patch für 8U1 veröffentlicht, also sogar für die verschiedenen Minor Release Stufen.
        Das lässt für die Zukunft nichts Gutes erahnen.

  3. CR sagt:

    Ich musste vor Jahren mal das verloren gegangene root Kennwort eines ESX Test Servers zurücksetzen und bin damals beim googlen auf den Hinweis gestoßen.
    AD Gruppe mit dem Namen erstellen, User dieser Gruppe hinzufügen –> Admin Rechte.
    Zum Beispiel erläutert hier:
    https://vmcloud.pl/2023/05/15/how-to-reset-esxi-root-password/

  4. Bjoern sagt:

    Sorry, aber verstehe die Aufregung überhaupt nicht. Das ganze ist schon so, seit es möglich ist ESX/ESXi in die AD Domäne aufzunehmen. Ist/war auch so in den offiziellen Dokumentationen dazu dokumentiert. Warum das jetzt als "Hack des Jahrtausends" gefeiert wird ist mir absolut unverständlich.

  5. Monarch sagt:

    Ich empfehle, ESXi-Server überhaupt nicht mit der Domäne zu verbinden. Man muss schon ziemlich verrückt sein, um so etwas überhaupt zu tun.

    • Joerg sagt:

      nein, nicht verrückt: dumm.

      Core-Infrastruktur (darunter fällt neben Hypervisoren auch so etwas wie Backup und einiges anderes) gehört nicht in die Domäne, wenn diese mal kompromittiert sein sollte wäre alles verloren. Ebensowenig haben solche Server was im Regulären Netz zu suchen, das gehört abgeschottet und der Zugriff sollte max via Jumphosts möglich sein.

      Aber es soll ja durchaus Idioten geben, die ein vCenter oder ESXi vom Internet direkt erreichbar machen, denen ist eh nicht mehr zu helfen :-)

      • Mitch sagt:

        Ob deine Core-Infrastruktur an der Domäne hängt oder peng! Wenn sich Jemand unerwünschter Weise erfolgreich Zugriff auf dein AD verschafft hat und auch noch Admin-Rechte erlangt hat dann brennt es sowieso schon lichterloh…

  6. Fred sagt:

    man könnte ja fast sagen, Microsoft hat momentan einen Lauf:
    – Ausfall letzte Woche: MS kann nichts dafür
    – jetzt: MS findet Lücke in ESXi
    Also innerhalb 1 Woche gleich 2 Sachen wo MS "unschuldig" ist… Wenn das nicht ein Lauf für MS sein soll, dann weiss ich ja auch nicht (Azure-Probleme von gestern lassen wir mal ausser Acht)
    ;-)

  7. Sebastian sagt:

    Workaround: https://knowledge.broadcom.com/external/article/369707/

    Haben die ESXi Server nicht in der Domäne, Einstellungen aber trotzdem mal gesetzt

  8. Fritz sagt:

    Nochmal für mich zum Verständnis:

    * Gibt es eine AD-Gruppe "ESX Admins", sind deren Mitglieder (bei vorliegender AD-Anbindung) Admins auf dem ESX
    * …und auch nur deren Mitglieder (kann ja leer sein). Um das zu ändern brauche ich Rechte zum Administrieren von Benutzern und Gruppen im AD (Code-Schnipsel oben).
    * Das Ganze ist (mehr oder weniger gut, aber offensichtlich seit Jahren findbar) dokumentiert.
    * Wenn der ESX-Admin dem AD-Admin nicht traut (etwa im Rahmen einer Zero-Trust-Policy, muß nichts persönliches sein) kann er die Interpretation dieser Gruppe im Hostagent ausschalten (Sebastians Link).

    Worin besteht da jetzt die Sicherheitslücke?

    Was macht der Patch in 8.0U3 anders? Nur den Default ändern?

    Übersehe ich was?

    • Daniel A. sagt:

      Grundsätzlich richtig verstanden. Die Lücke zielt darauf ab, dass jemand der keinen Zugriff auf den ESX hat, aber entsprechenden Zugriff aufs AD hat (entweder berechtigt oder unberechtigt) diese Gruppe anlegen kann und dann beliebige User hinzufügen kann, weil der Name der Gruppe im ESX hardcoded ist. Die sind damit automatisch auf dem ESX vollberechtigt und können entsprechend Schaden anrichten.
      Das vCenter macht es anders, hier muss man die gewünschte Gruppe explizit definieren, es gibt keine "Standardgruppe" die Hardcoded ist und im AD abgefragt wird. Daher gilt diese Lücke nur für ESX.
      Was genau die Version 8U3 hier ändert weiß ich nicht, da es nicht in den Release Notes erwähnt wird.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.

Du findest den Blog gut, hast aber Werbung geblockt? Du kannst diesen Blog auch durch eine Spende unterstützen.