Ransomware auf Hypervisoren
Neue Ziele im Visier
Veröffentlicht in Ausgabe 10/2022 - PRAXIS
In vielen Fällen lesen Sie von den Vorteilen der Virtualisierung, welche zusätzliche Sicherheit die Isolation der einzelnen Maschinen bieten kann und wie einfach es ist, mit Snapshots jederzeit zu vorherigen Versionen zurückzukehren. Die moderne Ransomware und das Verhalten der dahinterstehenden Gruppierungen haben sich dieser Argumentation und den Techniken angepasst. Vor allem führt der betriebene Aufwand bei der Analyse angegriffener Infrastrukturen zu einem deutlichen Vorteil der Angreifer. Diese kennen alle Systeme, die eingesetzte Software inklusive der Security-Suites und der eingesetzten Backupanwendungen, die Logindaten und Verantwortungsbereiche der Mitarbeiter sowie deren Urlaubsplanung. Die Installation von Schadsoftware findet heute mit einem großen Vorlauf vor dem eigentlichen Schadensereignis statt.
Angriffe auf Hypervisoren
Gegenüber dieser Professionalisierung auf Seiten der Kriminellen stehen heute die IT-Abteilungen kleiner und großer Unternehmen, die neben Security vor allem den kontinuierlichen Betrieb der Infrastruktur als Aufgabe haben. Hypervisoren für den Betrieb virtueller Maschinen stehen dabei neben den Betriebssystemen der VMs selbst schon länger im Fokus der Angreifer. Zuletzt hat Mitte dieses Jahres die Ransomware namens Cheerscrypt [1] auf sich aufmerksam gemacht. Diese basiert auf der Linux-Variante der Schadsoftware Babuk und befällt VMware-ESXi-Server über bereits bekannte Schwachstellen und verschlüsselt sukzessive die von VMware genutzten Dateien.
Dabei erfolgt der Angriff meist über die Gäste des Hypervisors und eine Verwundbarkeit in der Hardwareabstraktion beziehungsweise Isolation des Hypervisors. Allerdings bietet ESXi selbst auch Angriffsflächen. Die Liste der CVEs ist zwar nicht so lang wie für andere Software, enthält aber auch Schwachstellen mit dem höchsten Schweregrad und der Möglichkeit, als entfernter Angreifer eigenen Code im Kontext der Serversoftware auszuführen.
In vielen Fällen lesen Sie von den Vorteilen der Virtualisierung, welche zusätzliche Sicherheit die Isolation der einzelnen Maschinen bieten kann und wie einfach es ist, mit Snapshots jederzeit zu vorherigen Versionen zurückzukehren. Die moderne Ransomware und das Verhalten der dahinterstehenden Gruppierungen haben sich dieser Argumentation und den Techniken angepasst. Vor allem führt der betriebene Aufwand bei der Analyse angegriffener Infrastrukturen zu einem deutlichen Vorteil der Angreifer. Diese kennen alle Systeme, die eingesetzte Software inklusive der Security-Suites und der eingesetzten Backupanwendungen, die Logindaten und Verantwortungsbereiche der Mitarbeiter sowie deren Urlaubsplanung. Die Installation von Schadsoftware findet heute mit einem großen Vorlauf vor dem eigentlichen Schadensereignis statt.
Angriffe auf Hypervisoren
Gegenüber dieser Professionalisierung auf Seiten der Kriminellen stehen heute die IT-Abteilungen kleiner und großer Unternehmen, die neben Security vor allem den kontinuierlichen Betrieb der Infrastruktur als Aufgabe haben. Hypervisoren für den Betrieb virtueller Maschinen stehen dabei neben den Betriebssystemen der VMs selbst schon länger im Fokus der Angreifer. Zuletzt hat Mitte dieses Jahres die Ransomware namens Cheerscrypt [1] auf sich aufmerksam gemacht. Diese basiert auf der Linux-Variante der Schadsoftware Babuk und befällt VMware-ESXi-Server über bereits bekannte Schwachstellen und verschlüsselt sukzessive die von VMware genutzten Dateien.
Dabei erfolgt der Angriff meist über die Gäste des Hypervisors und eine Verwundbarkeit in der Hardwareabstraktion beziehungsweise Isolation des Hypervisors. Allerdings bietet ESXi selbst auch Angriffsflächen. Die Liste der CVEs ist zwar nicht so lang wie für andere Software, enthält aber auch Schwachstellen mit dem höchsten Schweregrad und der Möglichkeit, als entfernter Angreifer eigenen Code im Kontext der Serversoftware auszuführen.
Größeres Schadenspotenzial
Im Gegensatz zum Angriff auf einzelne VMs lässt sich mit der Kontrolle über den Hypervisor unmittelbar ein noch größerer Schaden anrichten. Außerdem gibt es im Grunde keine für ESXi verfügbaren Produkte zum Schutz vor Schadsoftware auf dem Hypervisor selbst. VMware hält Antivirus-Programme für den ESXi-Server auch für nicht notwendig [2]. Daraus resultiert nicht nur ein unzureichender Schutz vor Angriffen, sondern eben auch eine fehlende Detektion erfolgreicher Angriffe. Somit ergibt sich auch, dass aus Sicht der Administrations-Teams von ESXi-Clustern die Sicherheit nur eine begrenzte Rolle im Alltag spielt.
Die Absicherung der laufenden VMs gehört nicht zu den Aufgaben. Dieser kommen zumeist eigene Administratoren nach, die den individuellen Schutz der Betriebssysteme innerhalb der VMs verantworten. Die VMs bieten ja vor allem Dienste über das Netzwerk an und gelten damit natürlich als verwundbar. Leider bleiben Sie dadurch eigentlich immer einen deutlichen Schritt hinter den Angreifern – wenn die betriebenen VMs nicht mehr erreichbar sind, ist eine Reaktion der ESXi-Administratoren notwendig.
Ist ein ESXi-Hypervisor direkt von Schadsoftware betroffen, verschlüsselt diese sogar relevante Teile der betriebenen VMs, sind solche VMs meist nicht mehr zu betreiben. Läuft ESXi in Ihrem Unternehmen als Cluster, sind im Falle eines erfolgreichen Angriffs auch die anderen Server des Clusters sowie der angeschlossene Storage betroffen.
Unmittelbare Reaktion auf Angriffe
Bei der Reaktion auf einen Sicherheitsvorfall liegt der Fokus in der Administration zunächst auf der Wiederverfügbarmachung der Dienste innerhalb der betroffenen VMs. Je nach Dimension des Clusters kommen da einige VMs zusammen, die fast gleichzeitig ausfallen. In den besten Fällen gibt es für diese umfangreiche und sichere Backups, sodass die Maschinen selbst schnell wieder einsatzfähig sind. Ob in dieser Situation die Kontrolle und Sicherung des Hypervisors beachtet wird, ist von der Reaktion der Administratoren abhängig.
Um das System schnell wieder einsatzbereit zu machen und damit im Zweifel das Überleben des eigenen Unternehmens zu sichern, erwägen Verantwortliche durchaus, das geforderte Lösegeld an die Kriminellen zu bezahlen. Ende Juni gab es einen öffentlichen Brief von IT-Sicherheitsexperten aus Wissenschaft und Wirtschaft, in dem die Zahlung von Lösegeld gesamtgesellschaftlich diskutiert und kritisiert wurde [3]. Viele Versicherungen übernehmen heute zwar noch die Zahlung des Lösegelds, allerdings gibt es bereits erste Anbieter, die eine Zahlung explizit ausschließen.
Auch Kriminelle reagieren natürlich auf solche Entwicklungen und bessere Backupstrategien in den Unternehmen. Sie fordern daher zum Teil doppeltes Lösegeld: Bevor die Daten verschlüsselt werden, werden diese nämlich noch im Klartext auf die Server der Angreifer kopiert. Unternehmen sollen anschließend einmal bezahlen, um die verschlüsselten Daten wieder entschlüsseln zu können – so die Kriminellen das tatsächlich vorgesehen haben – und einmal, um die Veröffentlichung sensibler Unternehmensdaten zu verhindern.
Wiederaufbau des Clusters
Selbst wenn Sie kritische VMs aus den vorhandenen Backups auf anderen Servern schnell wieder einsatzbereit haben, muss der ESXi-Cluster komplett neu aufgebaut werden. Das ist mitunter eine Herausforderung, denn häufig handelt es sich um dynamisch gewachsene Infrastrukturen. Manchmal ist der Kollege, der die erste Konfiguration erstellt hat, gar nicht mehr im Unternehmen oder die Dokumentation ist entsprechend spärlich. Gibt es hingegen bereits vorbereitete Skripte für eine automatische Installation des Clusters, sogenannte Kickstart-Dateien, gelingt der Wiederaufbau deutlich einfacher und schneller [4].
Verfügen Sie über eine Enterprise-Plus-Lizenz, können Sie die Konfigurationsprofile Ihres Clusters sowie die Konfiguration der virtuellen Switches automatisch im Backup sichern lassen. Falls nicht, können Sie das Backup manuell ausführen beziehungsweise mit eigenen Tools automatisieren. Mit den folgenden Befehlen auf der ESXi-Kommandozeile synchronisieren Sie zunächst die Konfiguration und erstellen anschließend eine "tar.gz"-Datei, die Sie über Ihren Browser herunterladen können:
vim-cmd hostsvc/firmware/sync_config
vim-cmd hostsvc/firmware/backup_config
Die Ausgabe des zweiten Kommandos enthält die URL zum Herunterladen der Datei. Wenn Sie lieber die VSphere-CLI verwenden möchten oder das für Sie zur Automatisierung einfacher ist, öffnen Sie diese und navigieren in das Verzeichnis "C:\Program Files\VMware\VMware vSphere CLI\bin". Starten Sie dort das Backupprogramm mit folgendem Befehl:
vicfg-cfgbackup.pl --server=esxi --username=root -s latest_backup.tgz
Anschließend werden Sie aufgefordert, das Passwort des Root-Benutzers einzugeben. Um diese Abfrage beispielsweise aus Ihren automatischen Skripten heraus zu umgehen, können Sie das Passwort direkt mit "--password=<Passwort>" übergeben. Die Backupdatei finden Sie anschließend in Ihrem aktuellen Arbeitsverzeichnis.
Um die Konfiguration wieder einzuspielen, müssen Sie zunächst die Version mit derselben Build-ID installieren, mit der das Backup angefertigt wurde. Kopieren Sie die Backupdatei auf das System oder den angebundenen Datenspeicher und verbinden Sie sich nun auf die Konsole. Dort versetzen Sie das System in den Wartungsmodus, bevor Sie die Wiederherstellung starten:
vim-cmd hostsvc/maintenance_mode_enter
vim-cmd hostsvc/firmware/ restore_config /<Verzeichnis>/latest_backup.tgz
Falls sich zwischenzeitlich die UUID des Hostsystems geändert hat, müssen Sie vor der Angabe der Backupdatei noch eine "1" hinzufügen. Dann wird die UUID entsprechend überschrieben. Das funktioniert allerdings nur, wenn das Backup nicht verschlüsselt angelegt wurde. Das ist seit der Version 7.0 U2 von vSphere möglich. Allerdings bleibt der Schlüssel im TPM der Hardware und die Datei kann nur auf demselben Hostsystem wiederhergestellt werden. Anschließend sollten Sie natürlich alle empfohlenen Updates installieren und die Backups der VMs wieder einspielen.
Fazit
Der Security-Tipp in diesem Monat hat Ihnen gezeigt, welche Folgen der Befall von Ransomware mit einer spezialisierten Variante auf dem ESXi-Server haben kann und wie Sie sich, wenn Sie sich schon nicht zuverlässig schützen können, zumindest auf die Wiederherstellung vorbereiten können.
(dr)
Link-Codes
[1] Info zu Linux-Ransomware Cheerscrypt: https://www.trendmicro.com/vinfo/de/threat-encyclopedia/malware/Ransom.Linux.CHEERSCRYPT.A/
[2] Antivirenschutz auf Hypervisoren: https://kb.vmware.com/s/article/80768/
[3] Ransomletter: https://ransomletter.github.io/
[4] Kickstart-Dateien für VMware vSphere: https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.esxi.install.doc/GUID-00224A32-C5C5-4713-969A-C50FF4DED8F8.html/