CVE-2024-37085 - VMware EXSi

CVE-2024-37085 – VMware EXSi

Celia Catalán


Am 30. Juli veröffentlichte Microsoft in seinem Threat-Intelligence-Blog einen Artikel, in dem er vor der Entdeckung einer neuen Sicherheitslücke warnte. Dies betrifft die EXSi-Hypervisoren von VMware und sie geben an, mehrere Ransomware-Betreibergruppen entdeckt zu haben, die davon ausgenutzt haben.

Schwachstellenanalyse

Es wurde als CVE-2024-37085 identifiziert und ist eine Sicherheitslücke zur Umgehung der Active Directory-Integrationsauthentifizierung, die VMware EXSi-Hypervisoren betrifft. 

ESXi-Hypervisoren hosten virtuelle Maschinen, die wichtige Server in einem Netzwerk umfassen können. Bei einem Ransomware-Angriff kann die vollständige Administratorberechtigung für einen ESXi-Hypervisor bedeuten, dass der böswillige Agent das Dateisystem verschlüsseln kann, was sich auf die Ausführung und Funktion gehosteter Server auswirken kann. Es ermöglicht dem Angreifer außerdem, auf gehostete virtuelle Maschinen zuzugreifen und möglicherweise Daten herauszuschleusen oder sich seitlich innerhalb des Netzwerks zu bewegen.

Es ist zu beachten, dass ESXi nicht dem Internet ausgesetzt werden sollte. Daher müssen Angreifer zuvor Zugriff auf die Zielumgebung haben, um die Sicherheitslücke ausnutzen und Berechtigungen erweitern zu können.

Mehrere Ransomware-Betreiber wie Storm-0506, Storm-1175, Octo Tempest und Manatee Tempest setzen bei ihren Angriffen Ransomware namens Akira und Black Basta ein. Die Angriffstechnik umfasst die folgenden Befehle:



Terminal

                Netzgruppe „ESX Admins“ /Domäne /add
		Netzgruppe „ESX Admins“ Benutzername /Domäne /Add


      
Eine detaillierte Analyse des Angriffs ergab, dass VMware ESXi-Hypervisoren, die mit einer Active Directory-Domäne verbunden sind, jedes Mitglied einer Domänengruppe namens „ESX-Administratoren“ standardmäßig als uneingeschränkten Administratorzugriff betrachten. Diese Gruppe ist keine in Active Directory integrierte Gruppe und existiert standardmäßig nicht. ESXi-Hypervisoren überprüfen die Existenz einer solchen Gruppe nicht, wenn der Server einer Domäne beitritt, und behandeln jedes Mitglied einer Gruppe mit diesem Namen weiterhin mit vollem Administratorzugriff, auch wenn die Gruppe ursprünglich nicht existierte. 

Bei der Untersuchung wurden drei Ausbeutungsmethoden identifiziert:
  1. Hinzufügen der Gruppe „ESX Admins“ zur Domäne und Hinzufügen eines Benutzers: Diese Methode wird von den oben genannten Bedrohungsakteuren aktiv ausgenutzt. Wenn bei dieser Methode die Gruppe „ESX-Administratoren“ nicht vorhanden ist, kann jeder Benutzer in der Domäne, der die Möglichkeit hat, eine Gruppe zu erstellen, seine Berechtigungen auf vollständigen Administratorzugriff auf die der Domäne beigetretenen ESXi-Hypervisoren erweitern, indem er eine solche Gruppe erstellt und dann hinzufügt Sie können sich selbst oder andere Benutzer unter Ihrer Kontrolle zur Gruppe hinzufügen.
  2. Benennen Sie eine beliebige Gruppe in der Domäne in „ESX-Administratoren“ um und fügen Sie der Gruppe einen Benutzer hinzu oder verwenden Sie ein vorhandenes Mitglied der Gruppe: Diese Methode ähnelt der ersten, aber in diesem Fall benötigt der Bedrohungsakteur einen Benutzer, der dazu berechtigt ist Benennen Sie einige beliebige Gruppen um und benennen Sie eine davon in „ESX-Administratoren“ um. Der Bedrohungsakteur kann dann einen Benutzer hinzufügen oder einen bereits in der Gruppe vorhandenen Benutzer verwenden, um die Berechtigungen auf vollständigen Administratorzugriff zu erweitern. Microsoft hat diese Methode in der Praxis nicht beachtet.
  3. Aktualisierung der ESXi-Hypervisor-Berechtigungen: Selbst wenn der Netzwerkadministrator eine andere Gruppe in der Domäne als ESXi-Hypervisor-Verwaltungsgruppe zuweist, werden die vollständigen Administratorrechte von Mitgliedern der Gruppe „ESX-Administratoren“ nicht sofort entfernt und Bedrohungen durch Sicherheitsakteure könnten sie weiterhin missbrauchen. Microsoft hat diese Methode in der Praxis nicht beachtet.

Durch die Ausnutzung der Schwachstelle können Angreifer mit ausreichenden Active Directory (AD)-Berechtigungen vollen Zugriff auf einen ESXi-Host erhalten, der zuvor für die Verwendung von AD für die Benutzerverwaltung konfiguriert war, indem sie die konfigurierte AD-Gruppe (standardmäßig „ESXi-Administratoren“) danach neu erstellen wurde aus Active Directory entfernt


Leitlinien zur Schadensbegrenzung

Die von dieser Sicherheitslücke betroffenen Produktversionen sind:
  • VMware ESXi 8.0 (behoben in ESXi80U3-24022510)
  • VMware ESXi 7.0 (keine Patches geplant)
  • VMware Cloud Foundation 5.x (korrigiert auf 5.2)
  • VMware Cloud Foundation 4.x (keine Patches geplant)

Zur Schadensbegrenzung wird empfohlen, das von VMware veröffentlichte Sicherheitsupdate anzuwenden, es wird jedoch auch empfohlen, die folgenden Richtlinien zu befolgen:
  • Wenn Sie die Software nicht aktualisieren können, können Sie die folgenden Empfehlungen befolgen, um das Risiko zu verringern:
    • Überprüfen Sie, ob die Gruppe „ESX Admins“ in der Domäne vorhanden und geschützt ist.
    • Verweigern Sie dieser Gruppe manuell den Zugriff, indem Sie die Konfiguration auf dem ESXi-Hypervisor selbst ändern. Wenn Sie nicht möchten, dass die Active Directory ESX-Administratorgruppe vollständigen Administratorzugriff hat, können Sie dieses Verhalten mithilfe der erweiterten Hosteinstellungen deaktivieren: 

Terminal

                „Config.HostAgent.plugins.hostsvc.esxAdminsGroupAutoAdd“.


      
    • Ändern Sie die Verwaltungsgruppe in eine andere Gruppe auf dem ESXi-Hypervisor.
    • Fügen Sie benutzerdefinierte Erkennungen in XDR/SIEM für den neuen Gruppennamen hinzu.  
    • Konfigurieren Sie das Senden von ESXi-Protokollen an ein SIEM-System und überwachen Sie es auf verdächtigen vollständigen Administratorzugriff.
  • Bereinigung von Anmeldeinformationen: Um die verschiedenen Schwachstellenmethoden nutzen zu können, müssen Bedrohungsakteure einen berechtigten Benutzer in der Organisation kontrollieren. Daher empfehlen wir Ihnen, sicherzustellen, dass Sie erhöhte Konten in Ihrer Organisation schützen, insbesondere solche, die andere Domänengruppen verwalten können:
    • Erzwingen Sie die Multi-Faktor-Authentifizierung (MFA) für alle Konten, entfernen Sie von der MFA ausgeschlossene Benutzer und setzen Sie die MFA auf allen Geräten, an allen Standorten und zu jeder Zeit strikt durch.
    • Aktivieren Sie kennwortlose Authentifizierungsmethoden (z. B. Windows Hello, FIDO-Schlüssel oder Microsoft Authenticator) für Konten, die die kennwortlose Authentifizierung unterstützen. Für Konten, die weiterhin Kennwörter erfordern, verwenden Sie Authentifizierungs-Apps wie Microsoft Authenticator für MFA. 
    • Isolieren Sie privilegierte Konten von Produktivitätskonten, um den administrativen Zugriff auf die Umgebung zu schützen.
  • Verbessern Sie den Status kritischer Assets: Identifizieren Sie Ihre kritischen Assets im Netzwerk, wie z. B. ESXi-Hypervisoren und vCenter (eine zentrale Plattform zur Steuerung von VMware vSphere-Umgebungen), und stellen Sie sicher, dass Sie sie mit den neuesten Sicherheitsupdates schützen und Verfahren sowie geeignete Sicherungs- und Wiederherstellungspläne überwachen .
  • Identifizieren Sie anfällige Assets: Implementieren Sie authentifizierte Scans von Netzwerkgeräten mithilfe von SNMP über das Microsoft Defender-Portal, um Schwachstellen in Netzwerkgeräten wie ESXi zu identifizieren und Sicherheitsempfehlungen zu erhalten.

Abschluss

Abgesehen von all diesen Richtlinien warnte das Unternehmen Broadcom (Eigentümer von VMware) in einer Erklärung vor der Sicherheitslücke, in der es einen Link zu einer alternativen Lösung enthält, die mehrere erweiterte ESXi-Konfigurationen modifiziert, um sie sicherer zu machen; Auf der Problemumgehungsseite wird darauf hingewiesen, dass für alle Versionen von ESXi (vor ESXi 8.0 U3) „mehrere erweiterte ESXi-Einstellungen Standardwerte haben, die standardmäßig nicht sicher sind.“ Der AD-Gruppe „ESX-Administratoren“ wird automatisch die VIM-Administratorrolle zugewiesen, wenn ein ESXi-Host einer Active Directory-Domäne beitritt.

Javier Muñoz , Cybersicherheitsanalyst bei Zerolynx
Zurück zum Blog

Hinterlasse einen Kommentar

Bitte beachten Sie, dass Kommentare vor der Veröffentlichung genehmigt werden müssen.