Kleiner Sammelbeitrag und Nachtrag rund um das Thema Virtualisierung. In Hyper-V wurde kürzlich eine Schwachstelle gepatcht – jetzt gibt es einen Proof of Concept (PoC) für diese Schwachstelle. Und bei VMware gibt es ebenfalls Schwachstellen sowie Infos, wie sich aus der VM ausbrechen lässt.
Anzeige
VMware vCenter-Schwachstelle
In VMware vCenter gibt es einen kritische Schwachstelle (CVE-2024-38812), die mit einem CVSS-Index von 9.8 bewertet wird und eine Remotecodeausführung ermöglichen kann. Die Sicherheitsplattform Hunter weist in nachfolgendem Tweet auf diesen Sachverhalt hin.
VMware by Broadcom hat dieses Security Bulletin zur Schwachstelle veröffentlicht. Ein Angreifer mit Netzwerkzugriff auf vCenter Server kann diese Schwachstelle über einen Heap-Overflow im DCE/RPC-Protokoll angreifen, indem er ein speziell gestaltetes Netzwerkpaket sendet. Das kann möglicherweise zur Remotecodeausführung führen.
Es gibt einen Patch zum Schließen dieser Schwachstelle. The Hacker News hat das Thema hier aufgegriffen. Die Sicherheitsplattform Hunter weist in obigem Tweet darauf hin, dass man über 34.000 VMware vCenter-Instanzen per Internet erreichen könne. Ich habe mal geschaut, die Hunter-Liste weist auch Instanzen in Deutschland auf.
Anzeige
PoC für Hyper-V-Schwachstelle CVE-2024-38080
Im Juli 2024 wurde die Schwachstelle CVE-2024-38080 in Hyper-V von Microsoft mittels Updates geschlossen. Es handelt sich um eine Windows Hyper-V Elevation of Privileg-Schwachstelle mit einem CVEv3-Score von 7.8 (important). Ein lokaler, authentifizierter Angreifer kann diese Sicherheitslücke ausnutzen, um SYSTEM-Rechte zu erlangen. Nach Angaben von Microsoft wurde diese Sicherheitslücke als Zero-Day ausgenutzt. Ich hatte im Blog-Beitrag Microsoft Security Update Summary (9. Juli 2024) berichtet. Wer die Juli 2024-Updates in Windows installiert hat, sollte also geschützt sein.
Sicherheitsforscher Pwndorei hat eine detaillierte Analyse sowie einen Proof-of-Concept (PoC) Exploit-Code für die gepatchte Zero-Day-Schwachstelle CVE-2024-38080 veröffentlicht, wie man bei Security Online nachlesen kann.
Die Analyse von Pwndorei zeigt, dass die Schwachstelle in der Funktion VidExoBrokerIoctlReceive auftritt. Diese Funktion ist für die Bearbeitung von Ioctl-Anfragen in Hyper-V zuständig, führt aber eine unzureichende Validierung der Daten in IRP-Strukturen (I/O Request Packet) durch. Ein Angreifer kann diesen Fehler ausnutzen, indem er bösartige IRP-Anforderungen über die Funktion VidExoBrokerIoctlSend sendet. Dies führt zu einem Integer-Überlauf im nicht ausgelagerten Pool des Kernels, der anschließend einen Pufferüberlauf verursacht und zu einem BSOD (Blue Screen of Death) führt.
Ausbruch aus Hyper-V
Abschießend noch ein Shorty: Die Sicherheitsforscher von TrueSec zeigen in ihrem Beitrag How to Break Out of Hyper-V and Compromise your Admins Methoden, wie man die weit verbreiteten Protokolle PowerShell Remoting und PowerShell Direct missbrauchen kann, um aus einer Hyper-V-Umgebung auszubrechen und auf den Host zuzugreifen.
Anzeige
Entgegen der Zusammenfassung im ersten Abschnitt bezieht sich der Hinweis, wie aus einer VM ausgebrochen werden kann, auf Hyper-V und nicht auf VMware.
Nach dem Update gibt es beim vCenter Server 8.0.3.00200 Probleme mit hängendem Management, die Lösung ist
https://knowledge.broadcom.com/external/article?articleNumber=377734
Danke 👍🏻
Top, genau mein Problem, bin nur noch nicht zur Fehlersuche gekommen.
Zur Ehrenrettung von HyperV: Gerade beim Lesen Artikels "How to break out of a HyperV VM" mit Powershell Direct sehe ich den immer die falschen und leider immer wiederkehrenden Arbeitsweisen, mit denen die typischen Windows-Wald-Wiesen-Admins Ihre Netze administrieren:
a) HyperV-Hypervisor ist Mitglied der gleichen Domain
b) Keine klare Netzwerksegmentierung mit vLANs
c) Kein Einsatz von Jumphosts. Es wird sich direkt per RDP am HV angemeldet und von dort aus "manuell" und nicht automatisiert gearbeitet.
d) Nutzung von 3rd Party Community Modulen, wo niemand weiß, was diese am Ende des Tages machen. Allein dass ein HV eine Konnektivität zum Internet hat erachte ich als grob fahrlässig.
Der Bug ist in der Welt, ja das ist schlimm aber offenbar schnell gefixt. Als viel schlimmer erachte ich die begleitenden Umstände, die erst nötig sind, damit der Bug zur Anwendung kommt.
zu a)
Eine Ausnahme gibt es wohl mit der (nicht) Domain-Mitgliedschaft.
Wenn auf dem Hyper-V Host bzw. Cluster virtuelle Desktop mit Windows 10/11 laufen und der Zugriff über RDWeb erfolgen soll und die VMs in den Sammlungen den Usern fix zugewiesen sind.
Dann müssen die Remotedesktop-Dienste in der Domain laufen.
Oder ist es dann immer noch besser die Hyper-V Host mit einer eigenen Domain zu betreiben und diese mit der Hauptdomain zu joinen?
Vielleicht gibt es ja eine bessere (sicherere) Lösung? (fällt mir keine ein)
Zum einen die Punkte a-d von TJ zu Hyper-V, zum anderen, wer im September noch mit einem Patchlevel vom Juni oder vorher unterwegs ist, hat noch ganz andere Probleme.
Stimmt.
Und bei Punkt a sagen schon seit sicher 15 Jahren die Microsoft Best Practice-Ratschläge: Hypervisor NICHT in eine Domäne aufnehmen oder in eine eigene Domäne OHNE Vertrauensstellung zu anderen Domänen aufnehmen.
Und was den Patchlevel angeht:
Man muß sich doch nur anschauen, welche Systeme aus dem Internet erreichbar sind, wieviele davon absolut unnötig aus dem Internet erreichbar sind und wieviele davon auf einem alten Patchlevel sind.
Ich habe mal vor einiger Zeit bei Exchange gesucht und da waren alleine in Deutschland hunderte Instanzen aus dem Internet erreichbar, deren Patchlevel 2021 oder älter war.
Also seit mehr als 3 Jahren keine Patches mehr!
Und da wundern sich die Leute, das die gehackt werden.
Und jedes Mal aufs neue frage ich mich, warum Managementschnittstellen, egal welche, aus dem Internet erreichbar gemacht werden. Es sollte sich doch inzwischen rumgesprochen haben, dass das eine ganz dämliche Idee ist. Wofür hat der Mensch VPN u.ä. erfunden, um einen gesicherten Zugang von außen herzustellen?
Das war auch mein erster Gedanke. Aber ich bin mittlerweile davon ab, dass man dafür die Admins verantwortlich machen sollte, denn, so lange ein Softwarehersteller für Sicherheitslücken nicht haftbar gemacht werden kann, sehe ich keinen Grund, diese auf einen Admin zu übertragen (sofern er alles nach gängiger Praxis und Sicherheitsvorgabe eingerichtet hat). Besonders und vor allem, wenn die Software kostenpflichtig ist.
Die Verantwortung muss der Hersteller am Ende des Tages tragen, der Elektriker ist ja auch nicht Schuld, wenn der Durchlauferhitzer abfackeln wegen eines technischen Defekts innerhalb des Gerätes.
Moment, weil die Tür nicht mit Schloss abgeschlossen ist, kann man bei Einbruch den Türhersteller zur Verantwortung ziehen? Echt jetzt?
Wenn der Durchlaufhitzer bei dem Elektriker gekauft wurde, hat der (oder seine Versicherung) auch den Schadensersatz zu leisten.
Aber der Elektriker kann sich das Geld vom Hersteller wiederholen, bzw. die Versicherung holt sich das dann wieder, wenn das Gerät einen internen Defekt hatte, der nachweislich für den Schaden verantwortlich ist.
Aber das Argument mit dem Türschloss passt nicht ganz, wenn du die Tür nicht abschließt, hast du die Verfügbaren Mittel nicht genutzt und bist selbst daran Schuld, da kann der Schlosshersteller nichts für, wobei seine Verfehlungen meistens durch Versicherungen kompensiert werden, aber im Groben und Ganzen passt deine Aussage, die sind auch für nichts Haftbar zu machen – so wie Softwarefirmen (zumindest ist mir dergleichen nicht bekannt),
Doch, man muß den Admin dafür verantwortlich machen.
Denn der hat in der Firmenfirewall die Ports der Managementschnittstellen auf gemacht.
Hätte er es nicht gemacht, wären die Managementschnittstellen trotz entsprechender Softwaremängel nicht aus dem Internet erreichbar.
Es ist also schlicht Vorsatz, wenn man Managementschnittstellen aus dem Internet erreichbar macht.
Und dafür ist der Admin verantwortlich.
Obacht! VPN löst keine Probleme sondern verlagert diese nur. Einer meiner Erstmaßnahmen bei Kunden ist es, VPN Verbindung abzuschaffen. Die üblicherweise eingesetzten Windows Gammelgeräte sind schlicht zu unsicher, als dass diese VPN Zugangsdaten sicher aufbewahren bzw. damit umgehen könnten. Von allen Geräten und Systemen sind Windows-Rechner die schlechtesten, die in multi-homed Umgebungen betrieben werden können. Ist jemand unberechtigt im internen Netz auch noch im Kontext eines Admins, dann war es das, siehe Beispiel SIT.
Wenn man wirklich eine kontrollierbare Schnittstelle nach außen setzen will führt kein Weg an Guacamole mit 2FA und (Terminalserver) Jumphosts, mit jeweils Ihren eigenen Anmeldungen. Alles ohne Softwareinstallationen oder hinterlegten Daten am Rechner im Webbrowser bedienbar.
https://blog.jakobs.systems/blog/20231010-supplychain-management/
Wer überlässt den bei einer VPN-Lösung Windows das Management der Credentials? Nein, man nutzt nicht die VPN-Lösung von Microsoft. Es gibt ja genug Alternativen, die neben User/Passwort noch eine ganze Reihe weiterer Kriterien abprüfen (Zertifikate, Systemstatus und Identität, Benutzeridentät, usw.).
Auf welcher Grundlage schenkst Du einer "VPN-Anwendung" dieses Vertrauen besser als das zugrundeliegende System zu sein? Woher kommt eigentlich die Unsitte, für ein simples Interface und etwas Routing, eine extra App zu benötigen, die meist noch ranziger und kaputter als das System darunter?
Eine VPN Software (unabhängig vom System) reißt an zu vielen Baustellen Sicherheitsprobleme und Risiken auf, die man nicht haben will. Und ich war da noch nicht beim zusätzlichen Administrationsaufwand und Support.
Moin Moin.
@ Tomas Jakob
Ich arbeite im Bereich der Fehleranalyse und Ausbildung, nicht des Produktiven Bereiches :-)
Die Techniker beim Kunden haben mit Drucker oder DokumentenSW Probleme bzw Probleme in der Zusammenarbeit der Systeme.
Aber wenn man nur in einem Bereich schaut, wird man schnell Betriebsblind.
Zu A meinte Ich nicht das man cert nutzen soll, sondern das Konzept der Architekturen mit unterschiedlichen Tier.
Ich finde dies von der (Erklärungs-) Eindeutigkeit für Anfänger in diesem Teil besser verständlich.
Zu B
In der Größe von 50 Clients ist häufiger ein WLAN vorhanden.
Dort aber (was Ich bei Kunden mitbekommen habe) eher ein getrenntes, zur einfachen Internet Verbindung :-)
Die Admins sind zu faul/unwissend/bekommen die notwendigen Zeiten nicht genehmigt um ein inneres / internes WLAN zu implementieren.
Problematischer sind Unternehmen mit 5 Clients.
Dort wird dann wie "Zuhause" gearbeitet. Alles ein Netz :-)
Das Konstrukt mit den Jumphosts habe Ich noch nir gehört, macht aber Sinn soweit Ich erkennen kann.
Mal anschauen wenn Ich Zeit habe ;-)
Danke