Hypervisor-Sicherheit: Schutz von ESXi-Systemen vor Angriffen und Ransomware

In einem aktuellen Fall haben wir versucht, die Aktivitäten des Angreifers auf einem ESXi-Hypervisor zu rekonstruieren. Die auf dem System verfügbaren Protokolle waren sehr begrenzt, was die Analyse der Aktivitäten des Angreifers erschwerte. Gerade der ESXi-Hypervisor bietet detaillierte Protokolle, die bei entsprechender Konfiguration für die forensische Analyse genutzt werden können. Das Thema der Incident Readiness im Allgemeinen wurde in einem früheren Artikel behandelt, dessen Lektüre sehr zu empfehlen ist. Dieser Artikel konzentriert sich auf Hypervisor, die Risiken, denen sie ausgesetzt sind, und wie man sie schützen kann.

Was ist ein Hypervisor?

Hypervisor sind wesentliche Aspekte in modernen Hosting-Umgebungen. Immer weniger Anwendungen werden auf “Bare Metal”-Servern gehostet, stattdessen hostet der Server mehrere virtualisierte Server, die wiederum die Anwendungen hosten. Diese Virtualisierung bietet Vorteile in Bezug auf Flexibilität, Skalierbarkeit und Zuverlässigkeit.

Diese virtualisierten Server werden in einem Hypervisor gehostet.  Es liegt auf der Hand, dass der Hypervisor ein wesentlicher Baustein in einer modernen Hosting-Umgebung ist. Nicht nur, dass der Betrieb jedes virtualisierten Servers und jeder darin enthaltenen Anwendung von der kontinuierlichen Funktion des Hypervisors abhängt, er stellt auch einen Single Point of Failure bei der Beschränkung des Zugangs zu diesen Servern dar. Es liegt in der Natur der Sache, dass ein Hypervisor den Zugriff auf jeden in ihm gehosteten Server gewährt.

Hypervisoren als Ziele

Hypervisoren sind daher ins Visier verschiedener Ransomware-Banden geraten, die ihre Funktionalität ausnutzen wollen, um im Netzwerk eines Unternehmens Schaden anzurichten, manchmal auch durch Ausnutzung von Sicherheitslücken im Hypervisor. Angriffe, bei denen der Zugriff auf einen Hypervisor genutzt wird, um alle virtuellen Maschinen eines Unternehmens zu verschlüsseln, werden als “Big Game Hunting” bezeichnet. Daher ist es unerlässlich, den eingesetzten Hypervisor zu sichern und zu überwachen.

VMWare ESXi

ESXi von VMware ist ein Hypervisor der Klasse 1. Er umfasst nicht nur die Kernfunktionen eines Hypervisors, sondern auch grundlegende Betriebssystemfunktionen. Er wird direkt auf der Hardware installiert, ohne dass ein Betriebssystem zugrunde liegt. Sein geringer Platzbedarf von 150 MB macht ihn zu einem der kleinsten Hypervisoren der Welt. Über alle angebotenen Produkte hinweg hält VMware bis 2023 einen Marktanteil von über 61%. In dieser Publikation liegt der Schwerpunkt auf Bedrohungsakteuren und Schwachstellen. Allgemeine Empfehlungen können jedoch auch auf andere spezifische Technologien angewendet werden.

Bekannte Gruppen und Ransomwares

Es überrascht nicht, dass mehrere Ransomware-Gruppen bereits im Jahr 2021 damit begonnen haben, den Hypervisor ESXi ins Visier zu nehmen. Darunter auch die folgenden:

• Storm-0506/Black Basta
• Storm-1175/Medusa
• Octo-Tempest/Scattered Spider
• SpriteSpider/ RansomEXX/Defray777
• CarbonSpider/FIN7
• Manatee Tempest/EvilCorp
• Cicada3301
• Qilin
• Black Cat/ALPHV – ALPHV Ransomware
• Lockbit
• Kuiper/RobinHood
• ShadowSyndicate/Infra Storm/Play
• Akira
• Mallox
• Cheerscrypt/Cheers/Babuk
• BlackSuit
• Hive
• AvosLocker
• Luna
• REvil/Sodinokibi
• ViceSociety/HelloKitty
• DarkSide/BlackMatter
• GwisinLocker
• RedAlert/N13V
• Conti

Die meisten Ransomware-Kampagnen wurden durchgeführt, indem man sich privilegierten Zugriff auf den Hypervisor verschaffte und dann einfach alle darin gehosteten Rechner verschlüsselte. Dazu gehören die diesjährigen Angriffe der Play Group, Cicada3301 und der Angriff von Scattered Spider auf MGM aus dem letzten Jahr.

Besondere Aufmerksamkeit sollte der Tatsache gewidmet werden, dass die meisten Ransomware-Programme virtuelle Maschinen vor der Verschlüsselung abschalten. Einige Exemplare wie BlackBasta, Luna Babuk und RedAlert (bei der der Angreifer diese Funktion manuell aktivieren muss) tun dies jedoch nicht. Dies könnte dazu führen, dass die virtuellen Maschinen beschädigt werden, was eine Wiederherstellung unmöglich macht, selbst mit den entsprechenden Schlüsseln. Dies könnte als zusätzlicher Anreiz gesehen werden, eine Infektion von vornherein zu vermeiden.

In unserem jüngsten Fall verschafften sich die Angreifer mit verschiedenen Mitteln Zugang zum Netzwerk eines Unternehmens. Dazu gehörten Anmeldedaten, die sie von Marktplätzen im Dark Web bezogen. Die Angreifer nutzten einen legitimen Fernzugriff auf das System anstelle einer speziellen Malware. Eine ihrer Aktionen in diesem Netzwerk war der Versuch, auf die im ESXi-Hypervisor gehosteten virtuellen Maschinen zuzugreifen. Dies zeigt, dass Ransomware und die Verschlüsselung ganzer Festplatten nicht die einzigen Bedrohungen für ESXi-Benutzer sind. Hand-auf-Tastatur-Angriffe, die vor dem Aufkommen gezielter Malware die Hauptbedrohung für Hypervisoren darstellten, stellen immer noch eine Gefahr dar, da ein Angreifer keine Gelegenheit auslässt, wenn sie sich ihm bietet.

Prominente Schwachstellen

Komplexe Software birgt immer Schwachstellen, und der ESXi-Hypervisor bildet hier keine Ausnahme. Zwei bekannte Schwachstellen, die in der Vergangenheit ausgenutzt wurden, werden im Folgenden beschrieben.

CVE-2021-21974

CVE-2021-21974 ist eine Heap-Overflow-Schwachstelle auf Port 427/tcp in OpenSLP, wie es in ESXi verwendet wird, die zu Remotecodeausführung führen kann. Im Jahr 2023 wurde diese Schwachstelle genutzt, um die Ransomware „ESXiArgs“ in großem Umfang auf ESXi-Servern mit direktem Internetanschluss einzusetzen. Zum Zeitpunkt der Verbreitung dieser Ransomware hätte die Infektion durch eine ordnungsgemäße Aktualisierung des ESXi-Hypervisors vermieden werden können. Weitere Informationen finden Sie in dem ausgezeichneten Artikel.

CVE-2024-37085

Am 29. Juli 2024 gab Microsoft die Entdeckung von CVE-2024-37085 bekannt. Eine Schwachstelle in domänenverbundenen ESXi-Hypervisoren, die den Zugriff mit vollen Administratorrechten ermöglichte. Zu diesem Zeitpunkt war sie bereits von den Ransomware-Akteuren Storm-0506, Storm-1175, Octo Tempest, Akira und Manatee Tempest zur Systemverschlüsselung genutzt worden.

Die Schwachstelle bestand darin, dass jeder Benutzer, der Mitglied einer AD-Gruppe namens “ESX Admins” war, volle Administratorrechte auf dem ESXi Hypervisor erhielt. Die Erstellung dieser Gruppe bzw. das Hinzufügen von Benutzern zu dieser Gruppe wird in AD-Domänen normalerweise nicht überwacht und ist relativ einfach möglich. Weitere Informationen dazu. Broadcom stufte diese Schwachstelle als mittel ein, was in Sicherheitskreisen zu einigen Kontroversen führte: https://www.theregister.com/2024/07/30/make_me_admin_esxi_flaw/

Vorbeugende Maßnahmen

Systemadministratoren von ESXi-Hypervisoren können zahlreiche Maßnahmen ergreifen, um die Angriffsfläche einzuschränken und eine schnelle Wiederherstellung im Falle einer Kompromittierung zu beschleunigen.

An erster Stelle steht eine rasche und umfassende Anwendung von Patches und Updates. Die oben aufgeführten Schwachstellen zeigen, welche Möglichkeiten Angreifer aus ungepatchten Schwachstellen ziehen können. Natürlich gibt es per Definition keine Möglichkeit, gegen Zero-Day-Schwachstellen zu patchen, aber CVE-2021-21974 hat gezeigt, dass schwerwiegende Schwachstellen jahrelang ungepatcht bleiben können und somit von Angreifern ausgenutzt werden. Die Gründe, warum Unternehmen keine Patches implementieren, sind vielfältig. Oft verzögert ein Mangel an Arbeitskräften den Patching-Prozess, oder es besteht kein Bewusstsein für die Anzahl und Art der Systeme, die gewartet werden müssen. Während letzteres mit einer CMDB und einem Tool zum Scannen und Verwalten von Schwachstellen behoben werden kann, ist die einzige wirkliche Lösung für ersteres die Einstellung von zusätzlichem Personal.

 Ein weiteres Problem sind die möglichen Auswirkungen auf die Produktivität. Die Aussicht, einen ganzen Betrieb wegen eines fehlerhaften Patches lahmzulegen, ist abschreckend, und die jüngsten IT-Ausfälle im Zusammenhang mit CrowdStrike haben diese Wahrnehmung noch verstärkt. Bei der Abwägung der Risiken und der Berücksichtigung der verschiedenen Verantwortlichkeiten für Ausfälle mit unterschiedlichen Ursachen sollte ein Unternehmen im Zweifel stehts seine Angriffsfläche durch die Implementierung von vom Hersteller genehmigten Patches verkleinern.

Wenn ein Patching nicht machbar oder möglich ist, z. B. weil der Angriff eine bekannte Zero-Day-Lücke nutzt, ist das so genannte virtuelle Patching eine Alternative. Virtuelles Patching ist eine Technik zur Verhinderung von Exploits, indem sie auf Netzwerkebene mit Hilfe eines IPS oder einer Next-Generation-Firewall blockiert werden. Dies leitet zum Thema Schutzmechanismen auf Netzwerkebene über. Eine einfache Firewall kann sogar anfällige Systeme vor Angreifern schützen, indem sie sie aus deren Reichweite entfernt. Natürlich sollten Hypervisor nicht für das Internet sichtbar sein. Sie sollten nur innerhalb des Unternehmensnetzes sichtbar sein. Wenn möglich, in einem hochprivilegierten Netzwerksegment. Der Fernzugriff kann über ein VPN erfolgen. Eine IPS-Lösung bietet zusätzlichen Schutz vor Bedrohungen aus dem eigenen Netz heraus.

Darüber hinaus sollte der Zugriff auf den Hypervisor auf autorisiertes Personal beschränkt werden. Es sollten personalisierte Konten mit starken, eindeutigen Passwörtern verwendet werden, und wenn möglich, sollte ein zweiter Faktor implementiert werden. Die Zugriffsberechtigungen sollten regelmäßig überprüft und widerrufen werden, wenn sie nicht mehr zutreffen. Die Relevanz dieses Grundprinzips muss bei ESXi-Hypervisoren hervorgehoben werden, da sie über keine Privilegienverwaltung verfügen. Jeder Benutzer mit Zugriff auf die Maschine hat volle administrative Rechte.

Die Bedeutung regelmäßiger Backups kann nicht hoch genug eingeschätzt werden. Es ist wichtig, dass diese Backups nicht nur regelmäßig erstellt werden, sondern auch außerhalb der Reichweite potenzieller Angreifer liegen. Die meisten Schadprogramme sind in der Lage, auch Backups zu verschlüsseln, die auf dem Hypervisor selbst gespeichert sind. Air Gapping oder die Unveränderbarkeit der Backups sind Möglichkeiten, die Löschung oder Verschlüsselung dieser Backups zu verhindern.

Nicht alle Schwachstellen liegen in der Software selbst. Auch Konfigurationsfehler können zu Schwachstellen führen. Neben Maßnahmen, die für jede Software gelten, wie die Deaktivierung von Funktionen, die nicht verwendet werden, und die Beschränkung des Zugriffs auf das System und die Konfiguration auf autorisierte Benutzer, gibt es Maßnahmen, die speziell für Hypervisors im Allgemeinen und den ESXi-Hypervisor im Besonderen gelten.

Die Erstellung und Härtung der AD-Gruppe “ESX Admins” schützt vor CVE-37085. Kein Benutzer sollte in dieser Gruppe sein oder die Möglichkeit haben, sie zu ändern. Selbst wenn alle Systeme bereits gepatcht sind, kann es ratsam sein, diese Maßnahme zu ergreifen, um gegen Schatten-IT, übersehene Systeme und Systeme, die in Zukunft installiert werden, gewappnet zu sein. Die beste Lösung ist natürlich, den Hypervisor vollständig vom Active Directory des Unternehmens zu trennen.  Dadurch wird nicht nur verhindert, dass Angreifer infolge eines erfolgreichen Angriffs auf die Domäne des Unternehmens Zugang zum Hypervisor erhalten, sondern auch die Verfügbarkeit erhöht, da der Zugriff auf den Hypervisor nicht vom Betrieb des Domänencontrollers abhängt, der häufig selbst in einer virtuellen Maschine gehostet wird.

UEFI Secure Boot auf dem physischen Server und TPM 2.0 tragen zum Schutz des Systems bei, indem sie die Integrität der Boot-Dateien und des beim Booten geladenen Codes durch Codesignierung sicherstellen, wodurch der Hypervisor vor Manipulationen an den Boot-Dateien geschützt wird. In vSphere 7.0 U2 und neuer wird TPM 2.0 auch zur Verschlüsselung der Konfiguration des ESXi-Hosts verwendet, um sie vor Manipulationen zu schützen.

Der Schutz des Boot-Prozesses eines Systems ist in jedem Fall eine gute Idee. Bei ESXi-Systemen ist dies von zusätzlicher Bedeutung, da sich das Betriebssystem nicht auf einem permanenten Dateisystem befindet. Stattdessen wird das Dateisystem jedes Mal beim Booten aus VIB-Dateien neu erstellt. Um Persistenz auf dem System zu erreichen, muss der Angreifer also den Boot-Prozess angreifen.

Die Option execInstalledOnly=true ist eine Option, die verhindert, dass fremder Code auf dem Hypervisor ausgeführt wird. Es wird dringend empfohlen, sie zu nutzen. Man muss sich jedoch darüber im Klaren sein, dass die Verwendung dieser Option als Laufzeiteinstellung wenig bis gar keine Konsequenzen hat. Angesichts des bereits erwähnten Fehlens einer Privilegienverwaltung in ESXi besitzt jeder Benutzer mit Zugriff auf die Maschine automatisch die Fähigkeit, diese Einstellung zu deaktivieren. Andererseits bedeutet die Konfiguration der Option execInstalledOnly im Kernel, dass sie bis zum nächsten Neustart aktiv bleibt, selbst wenn sie geändert wird.

Angreifer, die auf den Hypervisor zugreifen können, tun dies routinemäßig über ssh. Durch die Deaktivierung von ssh werden diese Angriffe im Keim erstickt. Da der ESXi über die Weboberfläche verwaltet werden kann, gibt es keinen guten Grund, ssh dauerhaft aktiviert zu lassen.

Schließlich sollten Hypervisor streng überwacht werden. Glücklicherweise bieten die meisten Hypervisor-Lösungen umfangreiche Protokollierungsfunktionen. Natürlich müssen diese Protokolle aktiviert und konfiguriert werden, damit sie von Nutzen sind. Für Windows-basierte Hyper-V-Lösungen verweisen wir noch einmal auf unseren Artikel zur Incident Readiness. Hypervisors, die auf Linux und ESXi basieren, können Syslog verwenden. Aus mehreren Gründen ist es empfehlenswert, diese Protokolle an ein SIEM weiterzuleiten. Dadurch werden die Protokolle dem unmittelbaren Zugriff eines Angreifers entzogen, der sich bereits Zugang zum Hypervisor verschafft hat. Darüber hinaus ermöglicht ein SIEM die Korrelation mit Ereignissen aus anderen Protokollquellen sowie die Überwachung der Ereignisse und die Alarmierung bei abnormalen oder bösartigen Ereignissen. Auf ESXi-Systemen ist die Überwachung noch wichtiger als auf anderen Systemen, da kein EDR vorhanden ist und jeder Benutzer automatisch vollen Zugriff auf das System hat.

Alarme könnten bei Ereignissen wie Anmeldungen, (spezifischen) Änderungen der Konfiguration oder Neustarts ausgelöst werden. Natürlich müssen eine 24/7-Überwachung sowie im Voraus geplante Reaktionspläne vorhanden sein, um einer Verschlüsselung im Falle einer Kompromittierung zuvorzukommen.

Die Befolgung dieser Empfehlungen wird die Sicherheit des Hypervisors Ihres Unternehmens erheblich verbessern und ihn vor Verschlüsselung schützen. Für weitere Hinweise und Ratschläge zum Schutz eines ESXi-Hypervisors empfehlen wir auch diese Präsentation vom diesjährigen Security Fest.