Server gehackt - brauche Hilfe

[Unifex]

Offensichtlich wurde ein Server von mir gehackt.
Ich bin noch nach der Suche wie das geschehen konnte.

Offensichtlich wurde dort der mempodipper.c installiert.

Jetzt werden massig Daten transferiert.

Im tmp Verzeichnis, waren zwei Dateien neu die darauf hinweisen.
Die habe ich gelöscht.

Im Htop wird mir aber noch was anderes angezeigt. Ich habe das Bild mal angehängt.

Leider ist das Verzeichnis für mich nicht zu sehen, so dass ich es nicht einfach löschen kann.

Ich wollte damit erst mal anfangen.
Kann mir jemand helfen?

 

[Jesaja]

Jetzt werden massig Daten transferiert.

Leider ist das Verzeichnis für mich nicht zu sehen, so dass ich es nicht einfach löschen kann.

Für eine brauchbare Forensik fehlen dir wohl (wie den meisten) die Fachkenntnisse. Demnach ist es nicht so wichtig, dass der Server bis zur Analyse weiterläuft.

Als erstes startest du den Server also im RescueSystem, dadurch wird verhindert, dass weiterhin "massig Daten transferiert" werden, du also unter Umständen noch andere Server angreifst. Im Rescue solltest du dann auch die Verzeichnisse löschen können.

Der user elasticse deutet auf Elasticsearch, eine verteilte Suchmaschine hin.
Nutzt du diese bewusst?

Ansonsten wäre noch relevant, welches OS/welche Distribution du nutzt (ist das wirklich ein FreeBSD?), welche Anwendungen und (ganz wichtig wann du das letzte mal Updates gemacht hast.

Wenn nicht klar ist, wie der "Gast" in dein System gekommen ist und was er dort hinterlassen hat, wirst du den Server wohl neu aufsetzen müssen und baust dabei hoffentlich die gleiche Lücke nicht nochmal ein.

 

[Alderon]

Ist Mempodipper nicht ein uralter Exploit aus dem Jahre 2012? Oder wurde der mittlerweile aktualisiert?

 

[Unifex]

Also den Transfer konnte ich erst mal killen.
Ich vermute die sind über einen Bug in Elasticsearch gekommen. Den Dienst habe ich erst mal beendet und dann war es vorbei mit dem Datentransfer.

Das ist natürlich nur der erste Schritt.

Ich denke da ist jetzt ein Kit drauf. Gibt es eine Anleitung, wie ich das entfernen kann oder einen anderen sinnvollen Vorschlag, was ich machen kann?

 

[Alderon]

Rein hypothetisch kann man ein Rootkit dann entfernen, wenn man genau weiß welches es ist, sicher sein kann, dass keine Modifikationen am Kit selbst vorgenommen wurden und man von einem sicheren Drittsystem aus auf das eigentliche System zugreift, zum Beispiel per Recovery Modus.

Das ist für Dich wahrscheinlich eher nicht zu leisten und selbst Spezialisten sind da recht lange beschäftigt. Ein vernünftiges Vorgehen wäre die Sicherung des jetzigen Systems, damit man später noch an die Daten kommt und sich zu fragen, wie es überhaupt so weit kommen konnte.
Dann hat man auch gleich noch eventuelle Beweise gesichert in Form des Images, weil gar nicht klar ist, was mit der Kiste alles gemacht wurde.
Danach sollte man das System neu aufsetzen (wenn klar ist was vorgefallen ist).

Wenn es wirklich um Mempodipper geht, dann wäre das ein Exploit aus dem Jahre 2012, daher stellt sich die Frage, wann der Kernel das letzte mal ein Update bekommen hat?

 

[Unifex]

Der Kernel ist: 3.2.0-4-amd64

Ich hatte letztens noch über einen Hack über Elasticsearch gelesen, wenn bestimmte Einstellungen nicht vorhanden sind und wollte das eigentlich nächste Woche einmal prüfen.

Bevor ich jetzt aber das System neu aufsetze, möchte ich den Vorgang erst noch etwas verstehen.

Beispielsweise habe ich jetzt einmal das auth.log gescheckt.

Da gibt es kein gültiges Login. in der Zeit.
Wird das nicht für die Installation eines Kits benötigt.
Brauch es nicht ebenfalls einen Benutzer mit root Zugang?

 

[Alderon]

Das ist ein Widerspruch in sich: wenn ich schon Rootzugang habe benötige ich auch keinen Exploit auf Kernelebene mehr.
Der Reihe nach:
Solche Exploits benötigen tatsächlich Shellzugriff. Diesen kann man aber auch erlangen, wenn man beispielsweise einen User für eine bestimmte Software anlegt, diesem aber nicht den Shellzugriff entzieht, bzw. manchmal wird dieser natürlich auch benötigt.
Dann kann es passieren, dass in der Software selbst ein Exploit möglich ist, über diesen erhält man Zugriff auf die Shell und dort kann man dann - wenn der Kernel verwundbar ist - mit einem Exploit Rootrechte erlangen.

Auth.logs sind wertlos, wenn der Angreifer erst einmal Rootrechte hat. Im Endeffekt kann man dem kompletten System nicht mehr trauen, weil praktisch alle zurückgegebenen Werte/logs falsch sein können. Was auch der Grund ist, warum eine Untersuchung aus dem laufenden System heraus praktisch sinnlos ist.

Jetzt kommt aber die andere Seite: wenn der Kernel aktuell ist und derzeit kein exploit grasiert, kann es sehr gut sein, dass "nur" der Shelluser gehackt wurde, dann wäre das System nicht per se kompromittiert. Dafür muss man aber wiederum sehr genau analysieren was eigentlich vorgefallen ist.

Ps: Ich kann jetzt natürlich auch nur fröhlich mitraten was genau passiert ist. Von daher solltest Du Dir hier jemanden suchen, der das professionell untersucht. Unabhängig davon: hast Du das System mittlerweile in den Rescuemode gebootet?

 

[Unifex]

Jetzt kommt aber die andere Seite: wenn der Kernel aktuell ist und derzeit kein exploit grasiert, kann es sehr gut sein, dass "nur" der Shelluser gehackt wurde, dann wäre das System nicht per se kompromittiert. Dafür muss man aber wiederum sehr genau analysieren was eigentlich vorgefallen ist.

Das versuch ich ja gerade. Danke für die Hilfe bis hier hin.

Ich hatte ja Elasticsearch beendet und erst mal Ruhe.
Nun schaue ich gerade und der Zugriff sieht wieder genau so aus wie auf dem Bild von oben.

Das bedeutet doch, dass der User elasticse momentan das Problem ist oder?

 

[Alderon]

Warum läuft die Kiste denn immer noch? Du wirst so nicht weiterkommen, egal was Du machst. Bitte boote das Ding endlich in den Rescuemodus.

Und ja, der "User" ist wohl das Problem aber deswegen ist noch lange nicht bekannt, was der/die Angreifer sonst noch so getrieben haben.

 

[Unifex]

Ich ziehe gerade noch letzte Backups. Dann fahre ich den Server runter.

 

[Alderon]

Das macht man im Rescuemodus, es macht überhaupt keinen Sinn "backups" zu ziehen, während die Kiste läuft, weil Du nicht einmal sicher sein kannst, dass das Backup dann funktioniert, weil nicht klar ist, was der/die Angreifer angerichtet haben.

 

[Unifex]

Und was wäre dann im Rescue Mode besser?

 

[Alderon]

Du kannst beim derzeitigen Zustand nicht wissen ob Dein Toolset befallen ist oder nicht. Die Programme arbeiten alle high level, sind also darauf angewiesen, dass die API/der Kernel nicht manipuliert wurden, da sie nur aufgrund der Returnwerte vorgehen.

Ich versuche es mal eher bildhaft:
Du kannst nicht sicher sein ob der Kernel/die API Dich nicht belügt.
In einem Rescuesystem bootest Du über einen sauberen Kernel in ein sauberes System und kannst mit an Sicherheit grenzender Wahrscheinlichkeit davon ausgehen, dass dort nichts manipuliert wurde.

Genau deshalb ist es auch sinnlos ein befallenes System von sich heraus zu untersuchen, weil Du nicht sicher sein kannst, ob bestimmte API calls nicht umgeleitet werden, damit man beispielsweise Malware nicht finden kann.

Eine Vereinfachung fällt mir ein, um das vielleicht etwas transparenter zu machen, damit Du verstehst worum es geht:
Die Programme im Userland holen sich ihre Informationen nicht direkt vom Dateisystem, der CPU oder der GPU sondern sie "fragen" beim Kernel nach, was er ihnen darüber zu sagen hat. Sie geben ihre "Wünsche" auch wieder über den Kernel weiter.
Wenn der Kernel manipuliert wurde, kann er beispielsweise auf die "Frage" ob eine bestimmte Datei vorhanden ist "antworten": "nein, ist sie nicht", obwohl sie eigentlich vorhanden ist.

 

[Unifex]

Wow, danke für deine ausführliche Erklärung.
Ja da hast du wohl recht.

Schlussendlich werde ich heute wohl den Server neu aufsetzen müssen und dieses mal mir das Elasticsearch erst mal schenken.

Sicherlich wird der Angreifer es weiter probieren aber ich bin mir ziemlich sicher, dass die darüber rein gekommen sind.

 

[s24!]

Wenn du den Server komplett (am besten wirklich als Image der Platte) sicherst, kannst du ja hinterher immer noch das Problem in Ruhe analysieren (lassen). Da die Prozesse unter diesem bestimmten User liefen, wird das mit einiger Sicherheit auch Teil der Lücke sein, sofern da nicht jemand bewusst was verschleiern wollte.

 

[Unifex]

Wenn du den Server komplett (am besten wirklich als Image der Platte) sicherst, kannst du ja hinterher immer noch das Problem in Ruhe analysieren (lassen). Da die Prozesse unter diesem bestimmten User liefen, wird das mit einiger Sicherheit auch Teil der Lücke sein, sofern da nicht jemand bewusst was verschleiern wollte.

Dieses Image ziehen ist auch noch so ein Problem. Gibt es dafür eigentlich eine ansehnliche Anleitung= Der Server steht bei Hetzner.
Ich vermute um ein Image Backup zu machen, muss der Server in einem speziellen Modus gestartet werden?

 

[s24!]

Naja...

dd if=/dev/DEVICE of=image

Wird halt groß. Kannst du aber noch durch gzip/bzip jagen, womit es natürlich ggf. noch mal länger dauert.

 

[Unifex]

Danke.
Das werde ich mir mal genauer anschauen.

Der Fall ist eigentlich gelöst. Habe einen neuen Server aufgesetzt. Trotztem würde ich gerne noch mehr darüber erfahren.

Hätte einem z.B. ein on access Virenscanner vor der Installation eines Kit´s verhindern können?

Also klar mit Root Access kann jeder so einen Scanner wohl ausschalten aber ich könnte mir auch gut vorstellen, dass da vieles automatisiert ist.

 

[infinitnet]

Danke.
Das werde ich mir mal genauer anschauen.

Der Fall ist eigentlich gelöst. Habe einen neuen Server aufgesetzt. Trotztem würde ich gerne noch mehr darüber erfahren.

Hätte einem z.B. ein on access Virenscanner vor der Installation eines Kit´s verhindern können?

Also klar mit Root Access kann jeder so einen Scanner wohl ausschalten aber ich könnte mir auch gut vorstellen, dass da vieles automatisiert ist.

Scanner sind nicht unbedingt der richtige Ansatz. Wenn es bereits möglich ist, schädlichen Code auf dem Server auszuführen oder darauf zu plazieren, ist es im Grunde schon zu spät. Trotzdem kannst du natürlich maldet im Monitor-Mode verwenden und rkhunter per Cron laufen lassen. Viel wichtiger wäre aber:

- Regelmäßige Updates jeglicher Software
- Ein mindestens 24-stelliges root-Passwort, sofern Passwortauthentifizierung überhaupt genutzt werden muss
- Ggf. gresecurity.net ansehen
- Einen Spezialisten deinen Server absichern lassen

In deinem Fall hätte bspw. gresecurity und/oder schlichtweg das Mounten von /tmp mit noexec und nosuid Schlimmeres verhindern können, oder auch schon das aktuell-Halten deines Systems.

 

[Unifex]

- Einen Spezialisten deinen Server absichern lassen

Wo treibt man die auf und was mag das kosten?


Auch mal vielen Dank wegen der guten Erklärungen hier. Das war ich in der Vergangenheit hie rauch schon anders gewohnt.

Wie der Einbruch geschah ist mir relativ klar.

Ich frage mich, ob das grundsätzlich so läuft.

Also Schwachstelle des Servers nutzen. Ein Benutzerkonto kapern und sich mit dem dann am Server anmelden und die Schadsoftware installieren.

Wenn dem dann so ist, könnte man dann nicht dem Angreifer in die Suppe spucken und eine Anmeldung am Server (SSH) auf eine feste IP (die eigene) beschränken?
Ein Anmelden auf dem Server wäre dadurch doch unmöglich oder läuft das alles ganz anders ab?