[Englisch]Seit dem Wochenende laufen weltweit Cyberangriffe auf verwundbare ESXi-Server und es gibt wohl eine Reihe Betroffener (in Deutschland soll eine dreistellige Zahl betroffen sein). Die Angreifer nutzen dabei eine bereits 2021 geschlossene Schwachstelle. Cybersicherheitsbehörden weltweit warnen vor dieser Gefahr. Die US-CISA hat jetzt ein Recovery-Script zum Restaurieren der VMs für Opfer der ESXiArgs Ransomware-Opfer veröffentlicht.
Anzeige
Angriffswelle auf ESXi-Server
Seit dem vergangenen Wochenende wurden weltweit tausende VMware-Server von einem Ransomware-Akteur angegriffen und wohl erfolgreich infiziert. Das französische CERT-FR hat wohl am 3. Februar 2023 als erstes eine Warnung herausgegeben. Dort wurden konkret zwei Sicherheitsempfehlungen von VMware aufgegriffen, die zu beachten sind.
- VMSA-2021-0002 vom 23. Januar 2021 beschreibt mehrere Sicherheitslücken in VMware ESXi und vCenter Server, die durch Updates geschlossen wurden. Mit dabei die ESXi OpenSLP Heap-Oerflow-Schwachstelle (CVE-2021-21974) mit einem CVSSv3 Wert von 8.8. VMware empfahl seinerzeit, den OpenSLP-Dienst in ESXi zu deaktivieren, wenn er nicht verwendet wird.
- VMSA-2020-0023 vom 24. November 2020 beschreibt mehrere Sicherheitslücken, u.a. in VMware ESXi-Server. Dort wurde eine ESXi OpenSLP Remote Code Execution-Schwachstelle (CVE-2020-3992, use-after-free) thematisiert (CVSSv3-Wert von 9.8). Ein böswilliger Akteur, der sich im Verwaltungsnetzwerk befindet und Zugriff auf Port 427 auf einem ESXi-Rechner hat, kann möglicherweise eine Use-after-free-Funktion im OpenSLP-Dienst auslösen, die zu einer Remotecodeausführung führt.
Im Anschluss warnen Sicherheitsbehörden weltweit vor dieser Cyberangriffswelle, die auf VMwares ESXi-Server abzielt. Letzten Sonntag hat die italienische Cyber-Sicherheitsbehörde ACN vor der Angriffswelle auf Unternehmen und Behörden gewarnt (siehe z.B. diesen Spiegel Online-Artikel) – waren dort doch diverse Webseiten mehrerer Organisationen und Institutionen lahm gelegt worden.
Inzwischen ist bekannt, dass weltweit tausende ESXi-Server erfolgreich angegriffen und mit Ransomware infiziert wurden. Ich hatte im Blog-Beitrag Sicherheitsvorfälle und Patch-Erinnerungen für VMware-Administratoren (6. Feb. 2023) vom 6. Februar 2023 auf die stattfindenden Infektionen hingewiesen und nachfolgenden Tweet eingebunden.
Anzeige
Eine Liste betroffener VMware ESXi-Versionen findet sich hier. Mit Datum vom 6. Februar 2023 gibt es auch von VMware den Blog-Beitrag VMware Security Response Center (vSRC) Response to 'ESXiArgs' Ransomware Attacks, in der der Hersteller angibt, keine Kenntnis über eine neue 0-day-Schwachstelle als Einfallsvektor für die Angriffe zu haben.
Das BSI schreibt in seiner Warnung vom 7. Februar 2023 (siehe mein Blog-Beitrag Cyberangriffe auf Rechtsanwälte Kap), dass die regionalen Schwerpunkte der Angriffe auf Frankreich, den USA, Deutschland und Kanada lagen, bleibt sonst aber vage. Ich habe mal gesucht, die Sicherheitsfirma Census listet hier kompromittierte Server auf – nachfolgend einige Zahlen.
- Frankreich: 738
- USA: 308
- Deutschland: 243
- Kanada: 211
- Großbritannien: 78
Insgesamt ist von mindestens 3.200 kompromittierten ESXi-Servern weltweit die Rede (laut dieser Bitcoin-Liste sind es aber nur 2.803 Server). In obiger BSI-Warnung heißt es, dass die Schwachstelle CVE-2021-21974 im OpenSLP Service des ESXi-Servers als Einfallstor ausgenutzt wurde. Bei den derzeit betroffenen Systemen handelt es sich um ESXi-Hypervisoren der Version 6.x vor 6.7. Eine Warnung des Cybersicherheitsanbieters DarkFeed vom 4. Februar 2023 besagt laut dieser Quelle, dass die meisten Server, die in Frankreich und Deutschland betroffen waren, von den Hosting-Anbietern OVHcloud bzw. Hetzner gehostet wurden. Auf betroffenen Systemen werden die Konfigurationsdateien, nicht aber die virtuellen VMDK-Laufwerke, verschlüsselt und die Opfer finden folgenden Text vor:
Im Forum von Bleeping Computer gibt es diesen Diskussionsthread, gestartet am 3. Feb. 2023, wo Opfer die Infektion und die Folgen diskutieren. Dort entnehme ich, dass die VMDKs nicht verschlüsselt wurden und es sich wohl um die relativ neue Nevada Ransomware zu handeln scheint. Die Kollegen von Bleeping Computer haben in diesem Artikel noch einige Details zu den verschlüsselten Dateien zusammen getragen.
Warum wurde nicht gepatcht?
Es bleibt die Frage, warum die ESXi-Server per Internet erreichbar und nach Jahren immer noch ungepatcht waren. Tenable sieht eine "Patchmüdigkeit" in Unternehmen, so dass der aktuelle Vorfall als der bisher größte Angriff auf nicht Windows-Systeme (es waren ja ESXi-Server) gilt. Bernard Montel, EMEA Technical Director and Security Strategist, Tenable schreibt dazu: "Die traurige Wahrheit ist, dass bekannte Schwachstellen, für die ein Exploit zur Verfügung steht, oft nicht gepatcht werden. Dies bringt Unternehmen in eine unglaubliche Gefahr, erfolgreich infiltriert zu werden. In diesem Fall, bei der zwei Jahre alten VMware-Schwachstelle, ist die Bedrohung angesichts der aktiven Ausnutzung immens.
Virtualisierung ist das Herzstück der Cloud-Strategie der meisten Unternehmen – ob On-Premises, Public- oder Hybrid-Cloud, wobei der Hypervisor das Rückgrat der IT bildet. Angreifer wissen, dass sie auf diese Ebene zielen können, um ihre Privilegien zu erhöhen und Zugang zu allem zu erhalten. Wenn sie in der Lage sind, sich Zugang zu verschaffen, können sie Malware einschleusen, um die Hypervisor-Ebene zu infiltrieren und eine Masseninfektion zu verursachen." Die Administratoren in Unternehmen sind darauf angewiesen, sicherzustellen dass die Systeme auf dem aktuellen Patchstand sind.
VMs manuell wiederherstellen
Laut Darkfeed behauptet der Sicherheitsforscher Habib Karataş, dass die Verschlüsselung des Datenträgers auf die falsche Art und Weise erfolgt. Darkfeed gibt im Beitrag Schritte an, um die verschlüsselte und gelöschte config-Datei wiederherzustellen. Die beiden Sicherheitsforscher Enes Sonmez und Ahmet Aykac vom YoreGroup Tech Team haben in diesem Beitrag einen Ansatz beschrieben, mit der virtuelle Maschinen aus unverschlüsselten Flat Files wiederhergestellt werden können. Allerdings ist der Ansatz recht aufwändig.
CISA veröffentliche Recovery-Script
Um die Benutzer bei der Wiederherstellung ihrer Server zu unterstützen, hat die CISA ein ESXiArgs-Recovery-Script auf GitHub veröffentlicht, das den Wiederherstellungsprozess automatisiert. Die Kollegen von Bleeping Computer haben gerade in diesem Artikel darüber berichtet. Die CISA schreibt:
"Die CISA ist sich bewusst, dass einige Organisationen über Erfolge bei der Wiederherstellung von Dateien ohne Lösegeldzahlung berichtet haben. Die CISA hat dieses Tool auf der Grundlage öffentlich zugänglicher Ressourcen zusammengestellt, darunter ein Tutorial von Enes Sonmez und Ahmet Aykac.
Dieses Tool funktioniert, indem es die Metadaten virtueller Maschinen von virtuellen Festplatten rekonstruiert, die nicht von der Malware verschlüsselt wurden."
Die obige Erklärung und die Schritte zur Anwendung des Scripts zur Wiederherstellung von VMs sind auf der GitHub-Projektseite zu finden. Das Skript wird auf eigene Gefahr angewendet – man sollte sich also ansehen, was es macht und ggf. auf einem Testsystem ausführen. Wenn das Script erfolgreich ausgeführt werden konnte, lässt sich die virtuelle Maschine anschließend erneut in VMware ESXi registrieren.
Ähnliche Artikel:
Sicherheitsvorfälle und Patch-Erinnerungen für VMware-Administratoren (6. Feb. 2023)
Cyberangriffe auf Rechtsanwälte Kapellmann, Geomed-Klinik Gerolzhofen; Angriffe auf ESXi-Server
Anzeige
Die Sicherheitslücke wurde 2021 geschlossen…
Einfach keine Updates einspielen,na dann, …
Wird Nachlässigkeit wohl so bestraft.
Die wichtigste Frage, warum haben die einen Weg zum Internet?
Isoliert hinter einer Firewall und nur per VPN, wäre bestimmt auch ein guter Ansatz gewesen…
"Das Skript wird auf eigene Gefahr angewendet – man sollte sich also ansehen, was es macht und ggf. auf einem Testsystem ausführen."
In anbetracht dessen, dass die Patches derart lange nicht installiert wurden, bezweifle ich sehr, dass bei den betreffenden Firmen/Personen ein Testsystem existiert. Im Umkehrschluss stehen vielleicht einige der kompromittierten Server in einer Testumgebung, in denen der Angriff noch gar nicht bemerkt wurde.
Warum wurde nicht gepatcht?
Ich selbst betreue ein vSphere Cluster mit zwei ESXi Servern. Den vSphere Server auf dem neuesten Stand zu halten ist relativ einfach. Aber die beiden ESXi zu patchen ist ein immenser Aufwand, zumindest für mich in meiner Umgebung. Da ist es mit einem einfachen "sudo apt-get upgrade" nicht getan. VIB, Baseline, Images – OEM, Custom oder was weiß ich was. Ich persönlich finde es ziemlich kompliziert die ESXi zu aktualisieren und lasse es daher von einem Systemhaus machen. Nach den ersten beiden Selbstversuchen habe ich hinterher jedesmal den VMware Support gebraucht, weil mein HA kaputt war oder ein ESXi Host mich mit einem PSOD angrinste.
Ich bin hier der einzige Admin, der sich um System- und Netzwerktechnik kümmert. Ich muss mich also mit Routing und Switching auskennen, mit Servern (Windows und Linux), Druckern, PCs und Laptops, mit jeder Software, die auf allemöglichen Rechnern läuft – von der Geschäftsführung über Einkauf, Verkauf, Dispo und Lager; Office, Email, Banking, ERP, CSM etc. Außerdem muss natürlich Perfektionist sein wenn es um IT-Security geht. Email, Webserver (IIS, Apache, Nginx), (UTM-) Firewalls, (DNS-, Reverse-, Forward-) Proxies, WLAN, VLAN etc Selbstverständlich bin ich darüber hinaus auch für meine Mitarbeiter Supporter und Berater, die ständig zu allen o.g. Dingen Fragen, Sorgen, Nöte haben und gebauchpinselt werden wollen.
Ich will nicht jammern, ich liebe wirklich was ich tue! Aber wenn ich dann höre, dass viele Anwaltskanzleien und Arztpraxen ohne eigene IT, und schon gar nicht mit eigenem Sysadmin, betroffen sind, wundert mich das ganze nicht. Ich hab auch selbst vor vielen Jahren mal in einem Systemhaus gearbeitet und kenne das Klientel. Da besteht sehr häufig auch kein Wartungsvertrag mit dem Systemhaus. D.h. da kommt auch keiner regelmäßig vorbei und schaut nach dem rechten. Wenn denn mal jemand "bestellt" wird, bekommt der einen Zettel mit angefallenen Problemen der letzten drei Monate in die Hand. Da bleibt auch keine Zeit noch auf Servern die Windows Updates zu installieren und den noch gar neu zu starten. Schließlich kostet man ja 120€/Stunde und der Auftraggeber steht mit dem Finger auf seine Armbanduhr tippend neben einem. Und das gilt nicht nur für Arzpraxen und kleine Anwaltskanzleien. Das gilt für den kompletten KMU Bereich.
Also mich wundert dieser Missstand nicht wirklich.
Eine Frage treibt mich bei allen "Ausreden" trotzdem um. Warum muss ein ESXi aus dem Internet erreichbar sein? Wenn ich schon einen van Gogh im Wohnzimmer hängen habe, warum lasse ich dann auch noch während meiner Abwesenheit die Terassentür offen stehen? Vielleicht gibt es da wirklich sinnvolle Anwendungsszenarien. Ich kann mir allerdings keine vorstellen.
Da kann ich nur zustimmen.
Ich bin auch froh das ich nur Inhouse IT machen muss.
Die Updates sind wirklicher immer ein Drama.
Man kann ja über Microsoft sagen was man will, aber das normale Windowsupdate über den WSUS funktioniert bei Servern und Clients in der Regel ohne Probleme. Man kann die Updates automatisch Nachts installieren und den Server neu starten lassen. Außer CU Updates vom Exchange das auch eine Katastrophe und ohne DAG kann man die auch nur Abends oder am Wochenende machen. Bei kleinen Firmen ohne eigene IT aber mit eigenem Exchange Sever werden die nie installiert und die Firewall ist ne Fritzbox mit Portweiterleitung.
Klingt ja fürchterlich, wenn ESXi so herumzickt. Höre ich zum ersten Mal, dass das so aufwändig bzw. fehleranfällig ist. Schon Mal überlegt die Virtualisierungsplattform zu wechseln oder bist du dann sonst doch sehr überzeugt von ESXi?
Verstehe ich nicht ganz, Du hast einen ESXi-Cluster mit zwei ESXi-Hosts, das heisst; du hast zwangsläufig auch ein vCenter im Einsatz. Darüber ist das patchen der ESXi-Server ein Kindespiel, noch dazu mit einem Cluster, wo Du jeden Server zu jeder zeit in den Wartungsmodus schalten und patchen kannst, danach den anderen.
Selbiges geht dann doch auch mit der Hardware, sofern man nicht auf Eigenbauten setzt, wo man jeden Treiber und jede Firmware halt dann händisch installieren muss.
Es kann gut sein, dass die Probleme, die ich hatte noch unter 5.5. oder 6.5. waren. Aber ich bin gebranntes Kind. Und wenn es jemanden gibt, der etwas besser kann als ich, dann soll er es machen. Aber es muss halt eben auch jemand machen. Und das ist der Punkt dabei.
Ich wollte damit nur verdeutlichen, dass wir Admins uns um alles kümmern müssen, an dem ein Kabel hängt plus sämtliche Software. Und wenn es eben in einer Firma keinen gibt, oder nur hin und wieder, dann sieht auch das Netzwerk dementsprechend aus. Und Patchen ist eines der wichtigsten Tätigkeiten im Kampf gegen Cyber Kriminalität. Und da gehören auch Patches der brain.exe auch dazu ;-)
Könnte meine Arbeitsplatzbeschreibung, wenn nicht gar mein Posting sein ;)
In meinem Falle wurde vor 3 Jahren ein Systemhaus hinzugezogen das mich bei meiner Arbeit unterstützt und eben solche Arbeiten übernimmt und im Falle eines längeren Ausfall meinerseits die IT weiter betreuen kann. Ich habe entsprechend Druck gemacht weil die Verantwortung mir einfach zu groß geworden ist. Habe meinen Chef erklärt was passiert wenn es ihm oder mich mit dem Auto um einen Baum wickelt. In seinem Falle führt die Geschäftsleitung den Laden weiter, in meinem Falle aber steht mein "Nachfolger" vor einem sehr großen Problem.
Bei den ESXi muss ich aber sagen patche ich nur die Rollups und dank vMotion geht das auch im laufenden Betrieb. Aber muss zugeben das einige Dinge zu beachten sind wie zb. bei einem Upgrade die entsprechende OEM Iso zu verwenden. Wer zb. bei einer HP Proliant Umgebung das Upgrade von VMware selbst installiert kann sich da böse ins Knie schießen.
Ich kenne auch Firmen und Einrichtungen ohne Systembetreuer und mich wundert es ebenfalls nicht warum so viele Systeme ungewartet am laufen und entsprechend Anfällig für Sicherheitslücken sind.
Mein Vorgänger, damals war er der alleinige Admin für alles, hatte sich Samstag Mittag zum Schlafen hingelegt und ist nie mehr wieder aufgestanden. Daraufhin kam ich ins Unternehmen – ohne jegliche Dokumentation. ich weiß also sehr gut, was du da skizzierst ;-)
Auch bzgl der OEM Iso kann ich dir zustimmen. Ich habe Dell Server und ebenfalls OEM Iso. Da muss man aber auch erstmal wissen, was man braucht….
Warum es nicht gepatscht wurde? Wohl weil:
ISDN ist das denn nötig?
Denke: Nö, der Exploit geht ja nur Remote, und unsere ESXi sind alle nur im LAN.
Was soll da schon passieren. Die User sind alle doof, wer sollte das machen wollen? Würde es ja den eigenen Job kosten… also sparen wir die Zeit bis zum nächsten Patch…
Und wieso war das Teil dann doch Remote erreichbar?
Z.B. gab es mal eine PlasteKiste deren Klicki Bunti Interface einen Bug hatte und nicht nur den gewünschten 1 Port forwardete, sondern die nächsten 10 oder 100 auch. Wer seine Server nicht überwachte und nicht wirklich wußte was er tat, dem fiel das garnicht auf.
möglicherweise war das forwarding schon vor dem Start der ersten ESXi vorhanden, aber nicht aufgefallen, weil sich auf dem Port zu der Zeit noch nichts melden konnte.
ich kann mir einfach nicht vorstellen dass das wer mit voller Absicht gemacht haben könnte, weil ist ja ein Passwort vor…da kommt keiner ran.
Das stellt die Frage:
Warum erlaubt die ESXi einen Connect mit jedem?
Braucht man das Protokoll überhaupt jemals im Internet?
(Es gab Mal eine Zeit in der es üblich war Port 445 ins Netz zustellen.
445 war aber nie für Internet gedacht…).
https://vmware-forum.de/
das findet sich bei Bedarf Hilfe
Und nein:
Updates von ESX Hosts ist mehr als einfach.
Zur Not auch mit
https://www.vladan.fr/upgrade-vmware-esxi-to-7-0-u3-via-command-line/
Wenn es wirklich Probleme gibt müssen die halt behoben werden. Zur Not mit externen Hilfe.
Diese technischen Schulden holen einen immer ein und poppen auf wenn man es gar nicht brauchen kann.
Gruß
Kann ich so bestätigen. Als Admin ist man quasi Mädchen für alles und muss teilweise die Arbeit von Web- und Softwareentwicklern machen, weil die oft nur ihre Umgebung kennen und darüber hinaus nichts. Ist vielleicht nur ein Problem bei uns, aber das geht mir gewaltig auf die Krawatte. Und am Ende des Tages ist man immer der Buhmann, wenn etwas nicht funktioniert. Bestes Beispiel Webserver. Update von Debian in einer Testumgebung, laut Entwickler geht alles. Also gut Update auf Produktiv gemacht, ein Teil geht nicht und prompt steht der Chef bei einem und muss erklären was schief gelaufen ist. Ähm hallo keine Ahnung was der Entwickler da zusammengewurstelt hat. Also ciao, geh dort hin und frag was schiefläuft. Meist ist es dann auch noch so, dass man einfach zu wenig Manpower hat, um das alles zu stemmen, da viele Dinge auch sehr zeitintensiv sind. Da bleiben halt einfach dann Tickets liegen, da mache ich mir aber mittlerweile auch keine Gedanken mehr. Ich arbeite eh schon über 100% und Personalbeschaffung ist nicht meine Gehaltsstufe. Also muss auch mal der Chef 1 Woche warten bis seine Anfrage bearbeitet wird, wenn man an wichtigeren Dingen dran ist. Beispiel Exchange Migration von 2016 auf 2019. Aktuell dran und aktuell schon 2 Tage dran, in diesen zwei Tagen bisher keine anderen Tickets bearbeitet. Geht mit solchen Dingen los, dass sich die Clients mit dem neuen Exchange verbinden wollen, weil er ja als SCP eingetragen wird. Dann gehts weiter, dass sich manche Clients einfach gar nicht mehr zum alten verbinden können. Dann gehts weiter, dass manche Funktionen in der Koexistenz nicht so tun wie sie sollen. Man kommt also nicht voran, sondern muss Zeit aufwenden, dass alle arbeiten können. Und ja das Update wurde in einer Testumgebung ohne Probleme durchgespielt, aber im Produktivbetreib klappt es aus unbekannten Gründen nicht. Also solche Vorfälle wundern mich nicht. Gut klar VCenter öffentlich im Netz, da muss schon bei der Einrichtung irgendwas schief gehen. Vielleicht auch eine Firewallregel, die niemand mehr beachtet hat…. Oder es gibt eine höhere Stelle, die das so angeordnet hat und deshalb ist es so, auch wenn es seitens der IT bedenken gab. Perfektes Beispiel OWA von extern erreichbar. IT sagt nö, Geschäftsführer möchte aber keine VPN aufbauen und kein Geld für eine WAF ausgeben. Also gut, was willst machen. Mittlerweile holen wir für jedes Sicherheitsbedenken nach Belehrung eine Unterschrift, dass es am Ende nicht heißt wir hätten gesagt….
Ich mach meinen Job auch gerne, aber wir als Admins müssen lernen "radikaler" durchzugreifen. Probleme mit Software nach Updates auf die entsprechende Stelle verweisen, das tun was man in 8 Stunden Arbeit hinbekommt und Privatleben auch Privatlebens ein lassen, wichtige Projekte vor allem anderen durchziehen und sich nicht ablenken lassen, auch bei Personalmangel und alles was den Ratschlägen der Admins widerspricht entsprechend absegnen lassen. Ich könnte hier noch weiterphilosophieren, aber ich denke meine Adminkollegen kennen diese Wehwehchen.
Wir machen Mailserverupdates mittlerweile tagesaktuell ab 16:00.
Je nach Update war es das dann an dem Tag mit Mails aber egal.
Das habe ich mir mittlerweile auch angewöhnt. Alle Updates die nicht automatisiert werden könne, wie CUs bei Exchange werden zu meiner Arbeitszeit gemacht. Vorzugsweise, wenn die meisten Mittagspause machen.
Ich hätte es nicht besser beschreiben können!!!
Update hierzu: Angeblich wurde die Ransomware aktualisiert und verschlüsselt nun besser. Das automatisierte Wiederherstellungsscript Skript wird deshalb nicht mehr funktionieren. Quelle von heise.
Ich habe es noch auf dem Radar – aber noch keine Zeit zum Thematisieren.