ESXI gehackt

[lord_icon]

Hi,

ein ESXi wurde vom Kunden gehackt.

heute früh waren alle Daten (Gäste) gelöscht.
Auf den Datenspeicher war nur eine Textdatei neu abgelegt worden, wo man aufgefordert wird Bitcoins zu überweisen. tut man das, bekommt man angeblich seine Daten wieder, da der Hacker vor dem Löschen diese angeblich gesichert habe.

Die Grundsätzliche Frage ist jetzt nur: Wie hat er Zugriff erlangt?
Die Daten selbst holen wir uns aus n Backup wieder. Nur nochmal soll das nicht passieren.
Dass Kennwort war relativ lang mit Groß und Kleinbuchstaben und Zahlen. Das haben wir jetzt nochmals erhöht... jetzt mit Sonderzeichen.

Der ESXi wird aus der Ferne mittels vCenter "überwacht".
Hierzu musste man damals ja eine Datei im ESXi geändert werden, sodass diese Maschine im vCenter verwaltbar wird.

Die Frage hierzu ist: Ist diese Kommunikation sicher ?
Sprich: Wird das Kennwort im Klartext übertragen ?

[irix]

Angriffvektoren gibts da mehrere
1. Aus dem GuestOS heraus durch den Floppy Treiber
2. Die unzaehligen APIs welche von aussen erreichbar sind
3. Passwort/Token abgefangen

Ich kann jedem nur Raten die VMware Security Liste zu abonieren und sich mit dem Hardening Guide zu beschaeftigen.

Gruss
Joerg

PS: Auf einem ESXi muss man nichts haendisch in einer Datei aendern wenn er einem vCenter beitreten soll.

[Sven_B1982]

Eigentlich sollte doch in den Logfiles stehen wer sich von wo aus angemeldet hat am ESXi, beim vSphere Client sieht das z.B. so aus:
Benutzer root@192.168.1.26 abgemeldet
(Anmeldezeit: 11.06.2015 02:02:33, Anzahl der
API-Aufrufe: 0, Benutzer-Agent: gSOAP/2.
Info
11.06.2015 02:02:33
root

kann ja sein das ihr irgend einen Benutzer habt der noch zugriff auf den ESXi hat mit simplen passwörtern dann bringt das ändern des Adminpasswortes wenig. Das andere ist das was irix schon gesagt hat, so wenig Ports wie möglich auf lassen, am besten den ESXi überhaupt nicht direkt aus dem Internet erreichbar machen und über eine verschlüsselte VPN-Lösung drauf zugreifen(selbst ne Fritzbox kann VPN also daran sollte das nie scheitern).

[Supi]

Mal unabhängig davon wie der Angreifer das mache konnte würde ich auch dieses Vcenter aus der Ferne übers Internet in Frage stellen.

Kann mich daher nur Sven anschließen:

Portfreigaben für den ESXI löschen und ein VPN Router angeschlossen.
Das ist am Ende wesentlich einfacher als sich durch so einen "Hardening Guide" zu wühlen.

Wieso lässt der Kunde den Vcenter nicht bei sich laufen? Das Vcenter kann so doch trotzdem den ESXI "überwachen" und euch im Notfall eine Mail schicken?
Ihr wählt euch dann bei Ihm per VPN ein und verwaltet Remote das Vcenter.

[2-D]

Hi,
ich finde das Thema wirklich spannend, ich würde gerne Wissen wie das wohl funktioniert hat, wenn ich natürlich mein Beileid ausspreche. in der Situation wünscht sich niemand zu sein.

Aber zu deinen Fragen: Im Prinzip finde ich schwierig zu erkennen was du genau wissen möchtest? Möchtest du Wissen wie und wo man nach Spuren suchen kann? Möchtest du mögliche Angriffvektoren wissen und und und...
Denn zur Beantwortung solcher Fragen oder möglicher Einstiegspunkte müsstest du schon deutlich mehr Info bzgl. der Infrastruktur geben.

Zu deinen Fragen:
Ist die Kommunikation sicher?
Nein, nichts ist sicher. Eine nicht helfende Antwort, aber es ist so. Sofern du nicht nachgebessert hast, ist die vCenter - ESXi Kommunikation eine SSLv3 gesicherte Verbindung, die der Security-affine Virtualisierer sowieso mit Argwohn betrachtet.
Werden Passwörter im Klartext übertragen?
Nein werden sie nicht. Aber es gibt eine ganze Reihe Möglichkeiten an diese ran zukommen. Der Angreifer muss sich nicht der vCenter / ESXi Kommunikation bedient haben.


Zum Thema: Die letzten großen Guest-to-Host escapes gab es mit Cloud Burst und VMDK has left the building. ABER, die zerodayinitiative hat eine CVSS10 Sicherheitslücke gelistet (http://www.zerodayinitiative.com/advisories/upcoming/). die zuvor genannten Sicherheitslücken sind ebenso eingestuft worden, es existiert also möglicherweise wieder eine derartige Lücke.

An deiner Stelle würde ich mir die Mühe machen und...
... den Angriff nach zu voll ziehen sofern möglich, mit Hilfe von Logs, Konfigurationen und research, diese dann auch publik machen
... mich ganz ganz ganz dringend mit dem Hardening Guide auseinandersetzen. Den VPN hin oder her, es ist nicht nur die Welt da draussen, die böse ist. Manchmal möchte man nicht meinen wie leicht es für einen Menschen sein kann an interne Systeme eines Unternehmens zu kommen....
.... mich ganz ganz dringend mit der eigenen ESXi / vCenter Architektur auseinandersetzen und unter Sec Gesichtspunkten umkrempeln.
.... Wenn kurzfristig ermittelt werden kann, dass der Angriff von aussen (Internet) stattgefunden hat, eine Anzeige bei der Polizei schalten und mit dieser dann beim Netzbetreiber die Zugriffe auf die IP des angegriffenen Systems beantragen. Muss nicht hilfreich sein, kann es aber.

Alles andere wäre aus meiner Sicht fahrlässig.

[Martin]

Was für ein Datastore ist das, lokal oder im Netz, VMFS oder NFS?
Um direkt auf ein VMFS schreiben zu können, müsste ja über die SSH Shell des ESXi eingebrochen worden sein.

[lord_icon]

huii... hier sind aber reichlich Antworten eingetrudelt. schön schön.

Also: Backup ist durch und es läuft wieder. Kennwörter wurden erhöht.
Mit VPN ist eine gute Idee. Muß ich nur mal sehen, wie ich das mit n Draytec umsetze.
Denn eine Filiale hat ne fritte... die andere n draytec. nervt dann irgendwie x-tools drauf zu haben. aber ok. die alternative wieder gehackt zu werden ist wohl um einiges schlimmer.

Ein paar Antworten zu euren Fragen... die die ich noch so im Kopf habe:
Datastore ist local und vmfs.
Logs sind alle gelöscht worden.
Floppy hab ich in den gästen immer aus der konfig rausgelöscht

Oki. habt Dank

[UrsDerBär]

Würde mich schon sehr wundern, wenn der ESXi selber angegriffen worden wäre. Ich denke eher das war via vCenter.
Das Ding ist mittlerweile dermassen aufgeblasen, dass das Teil quasi unmöglich fehlerfrei sein kann und eine recht grosse Angriffsfläche bietet. Da nützt es meiner Meinung nach auch herzlich wenig, wenn der ESXi mit einem schmalen Footprint beworben wird - der ziemlich sicher verhältnissmässig wenig Fehler aufweist - , wenn via vCenter dennoch alles gemacht werden kann. Oder sehe ich das falsch?

[irix]

Syslog nicht konfiguriert?

- Unzaehlige VMware Produkte sind und waren in der Vergangenheit anfaellig gegen URL Traverselangriffe und man konnte ueber vCenter/Orchestrator beliebige Dateien aus dem OS fischen. In den unzaehligen Logs findet man dann SessionID/Tokens

- Das Problem mit dem Floppy ist eigentlich ein altes und war vor 2? Jahren mal nen Problem. Die anderen Hypervisor waren im Fruehjahr(siehe Heise) betroffen und es reichte wenn der Treiber installiert war

Gruss
Joerg

[lord_icon]

Hi joerg,

syslog war nicht auf einen exteren Logger geschaltet. somit kann ich es nicht mehr rückverfolgen. steht jetzt aber auf meiner ToDo-Liste.

VCenter schließe ICH mal aus. Denn wenn der Angreifer auf VCenter drauf war, dann hätte er auch Zugriff auf alle anderen beiden Systeme gehabt. Glücklicherweise sind hier aber alle Daten vorhanden.

Ärgerlich ist, das ESXi sowas überhaupt zulässt. Das Kennwort war zwr mit 8 Zeichen nicht sonderlich lang ... aber mit BruteForce offensichtlich dennoch knackbar.
Blöd, dass ich im Web nix finde, dass ich ESXi sagen kann = 10 mal failed Login = IP Banned oder so.

[Dayworker]

Der ESXi ist kein ESX und demzufolge läßt sich über die "busybox" des ESXi nicht alles abbilden. Eine Bannfunktion läßt sich daher so nicht umsetzen.


Wenn der DS komplett geleert wurde, müssen vorher auch sämtliche auf diesem Host laufende VMs beendet worden sein. Solange eine VM läuft, haben die damit eingespannten VMDKs einen Lock. Erst nach einem Host-Reboot oder einem für den Notfall laut der VMware-KB abgesetzten Befehl kann man diesen Lock überhaupt lösen. Oder lauf "dd" auf dem ESXi einfach trotzdem los?


Je nach Grösse der VMDKs und vor allem eurer Inet-Anbindung wage ich eine Sicherung durch den Angreifer stark zu bezweifeln. Ich würde in jedem Fall von einem kompromittierten Gesamtsystem ausgehen.


Du hattest ein Paswort mit nur 8 Stellen. Blättere mal auf http://www.1pw.de/brute-force.html durch. Ich fand es erschreckend, wie schnell sich inzwischen Paßwörter knacken lassen. Dein 8-stelliges Paßwort, beispielsweise nur mit Groß- und Kleinschreibung (52 Buchstaben) abgebildet, wäre nach nur 425min komplett durchprobiert. Geht man davon aus, daß Rainbow-Tables mit im Spiel waren, zeigt der ZDnet-Artikel http://www.zdnet.de/41544658/rainbow-tables-windows-passwoerter-nicht-mehr-sicher/3/ ein verheerendes Ergebnis.

[monster900]

Moin,
auch wenn es hier bereits mehrfach geschrieben wurde kann man es nicht oft genug wiederholen:
Ich würde NIEMALS einen Host direkt über das Internet erreichbar machen. Der Zugriff sollte per VPN abgesichert sein.
VPN bietet zwar auch keinen 100%igen Schutz, zumindest aber erschwert es dem pot. Angreifer seine Arbeit.

Gruß
Dirk

[pertzschc]

Vielleicht hängt es auch damit zusammen:
http://www.heise.de/newsticker/meldung/ ... 19041.html

Gruß, Christoph

[Dayworker]

@pertzschc
Der Gedanke ist ja nicht verkehrt, trifft aber in dieser Form nur für die VMware-Desktopprodukte zu.

[UrsDerBär]

Schon krass wie kreativ manche Leute sind. Auf solche Ideen wie im Link muss man erstmal kommen...

[2-D]

Schon krass wie kreativ manche Leute sind. Auf solche Ideen wie im Link muss man erstmal kommen...

naja es gibt Leute und Firmen, die sich das zur Hauptaufgabe gemacht haben
Aber es gibt ja immernoch den Unterschied zwischen dem was "möglich" ist und dem was man tatsächlich als Angriffsvektor bedenken sollte....