Rootkit aufm Server - Wie kam er drauf?

[cybert]

Hi folks,

na, das war eine Ã?berraschung, als ich von einigen Tagen Geschäftsreise zurückgekommen bin: Mein Server war gehackt und ich hatte ein Rootkit (TUXKIT) drauf. Dann hat der Bösewicht noch einen shoutcast-Server installiert und natürlich mein Rootpw geändert.

Dank Rescue-System und Backup habe ich das Gerät jetzt wieder einigermaßen auf die Reihe gebracht. Nur... Das Loch, dass der Typ ausgenutzt hat, ist ja nun leider immer noch offen...

Es ist noch ein altes Suse 7.2 - bis zur Abkündigung des Supports habe ich immer brav die Security-Patches eingespielt - Ausnahme: glibc und Kernel-Teile... das war mir zu heiß.

Meine Frage: Meint Ihr, ich kann rausfinden, auf welchem Weg der Angreifer reingekommen ist? In den Firewall-Logs hab ich ja nun leider nur die abgelehnten Verbindungen geloggt - außerdem nützt das eh nicht viel..


Würde mich über Hilfe von Eurer Seite sehr freuen!

Gruß,
Tom

[gamecrash]

Mit einem aktuellen SuSE reinitialisieren lassen oder selber Debian drauf installieren...

[captaincrunch]

Meine Frage: Meint Ihr, ich kann rausfinden, auf welchem Weg der Angreifer reingekommen ist?

Mit viel Zeit und Fachwissen : ja. Das würde aber bedeuten, dass du ein bitgenaues Abbild der Festplatte benötigen würdest, das du daraufhin untersuchen könntest, während du das jetzige System komplett neu aufsetzen lassen hast (WICHTIG!!!!).

Hattest du lokale User auf der Kiste ?

[cybert]

Hattest du lokale User auf der Kiste ?

Nein, keine lokalen User. Da muss also schon ein ziemlich dickes Loch sein, dass er sofort von außen Root-Rechte hatte...

Das neu Aufsetzen wird sich vermutlich nicht verhindern lassen... Ist halt grässlich viel Arbeit - ich hab ja monatelang an dem Rechner konfiguriert, bis er so lief, wie er's jetzt tut...

Na denn... an die Arbeit.

Ach ja: Ich hab ja immerhin nen Backup gezogen. Interessanterweise haben die Binaries, die ich aus diesem Backup zurückgespielt habe, nicht funktioniert... das /sbin und /bin Directory schien irgendwie nicht zu funzen. Sämtliche Executables hatten eine andere Dateigröße und der Reboot hat natürlich nicht getan. Ich backe mit reoback up - also eigentlich nur ein tar-skript... Macht tar da noch irgendeine zusätzliche Kompression o.ä., so dass ein einfacher tar -xvzf <filename> nicht genügt, um die Binaries wieder herzustellen?

Danke nochmal für Eure Hilfe!

Gruß,
Tom

[dodolin]

Interessanterweise haben die Binaries, die ich aus diesem Backup zurückgespielt habe

Mööp!!!!

NIEMALS (!) Binaries von einem Backup zurückspielen, wenn das System kompromittiert war!!!

[cybert]

NIEMALS (!) Binaries von einem Backup zurückspielen, wenn das System kompromittiert war!!!

Ã?hm... gibt's dafür nen Grund? Bin ja gerne bereit, etwas dazuzulernen...

Gruß,
Tom

[captaincrunch]

Ganz einfach : woher weißt du, dass die Binaries nicht durch den Cracker gegen solche ausgetauscht wurden, mit denen er sich wieder Zutritt zum System verschaffen kann ? gerade im Falle eines Rootkit ist diese Möglichkeit leider nur allzu wahrscheinlich.

[cybert]

Ok, das ist schon klar. Nur kann ich ja relativ scharf eingrenzen, wann der Cracker in das System gekommen ist und muss nur einen Backup nehmen, der weiter zurückliegt.

In meinem Fall hat er übrigens die Binaries für rm, ps, netstat und pstree ausgetauscht.

Gruß,
Tom

[tic]

Frage:

Hab mir die Frage bis jetzt noch nicht so gestellt, aber

gäb's ne Möglichkeit die Basisinstallation von einer Debian Installation (weil apt da sicher schick ist) regelmäßig mit den Paketdateien md5 oder so checken zu lassen ob die Binarys noch die richtige Größe haben?

gruß

[captaincrunch]

Wie wär's denn mit http://www.cs.tut.fi/~rammer/aide.html (gibt's auch direkt als Debian-Paket) ?

[tic]

Danke

Ich zieh mir die Seite nach Feierabend rein :-)

[arnee]

Tripwire benutzen. Du solltest dir auch mal das ein oder andere Buch über Linux Security besorgen.

Ich habe hier justament "Intrusion Detection für Linux Server" (ISBN: 3-8272-6415-4) vom Markt+Technik-Verlag liegen. Auf den ersten Blick (bin leider noch nicht zum Lesen gekommen) macht's einen sehr guten Eindruck. Empfehlen kann ich dir auch: "Sichere Server mit Linux" aus dem O'Reilly-Verlag.

[darkspirit]

Wenn wir schon bei guten Büchern sind, empfehle ich mal wieder "Hacking Linux Exposed". Gibts aber nur auf englisch ;)

[tic]

@ArneE
Ja das LIDS Buch hab ich mir schon gegönnt aber da kannste halt bei einem Rechner ohne direkten Zugriff nen Haufen Scheiße [Edit: das "piep" ist herzig :) ] bauen. Bis Filesystem zerschießen.
Find ich sehr heikel.

Hab's auf meinem Rechner mal ausprobiert.
Dann hab ich noch LinuxSecurity aus der OpenSourceLibrary. Ist aus meiner Sicht nicht zu empfehlen.

[Edit: Da fällt mir noch das saugute LIDS-FAQ von Sander Klein ein. Ich hab's ausgedruckt und weiß den Link nicht mehr. Musst Googlen. ]

Tripwire ist klar.

Ich dachte eher, wenn man seine Systemdateien (natürlich nur die Binarys die sich nicht ändern) gegen die md5 aus den Original Paketen per ?Cronjob? vergleichen kann dann weiß ich recht flott ob sich was geändert hat. Wäre meiner Meinung nach ein Job für APT.

Also auch wenn der mit seinem Rootkit die selbe Dateigröße hinkriegt die checksum zu faken ist ja eher unwahrscheinlich.

Bzw. lad ich bei bedarf die entsprechende Binary vom Arbeitsrechner rauf. Für Sie aus. Lösch Sie und lad den Output runter zum ankucken.
Klingt ein bißchen umständlich ist aber ideal für paranoide.

Dachte ich.
RPM hat ja so eine Möglichkeit.

Ich hab halt Debian :-)

[captaincrunch]

Schau dir mal die letzte iX zum Thema MD5-Summen an. Dort gab es den ersten Teil einer Linux-Security-Reihe, und auch wenn ich das ganze nicht 100%ig unterschrieben hätte (siehe dazu mein Leserbrief in der aktuellen Ausgabe) fand ich den Teil eigentlich ganz witzig.

Aide oder Tripwire machen diese Job aber schon verdammt gut.

[arnee]

Tja, normale Rootkits lassen sich i.d.R. ja noch gut aufspüren, aber Kernel-basierte modulare Rootkits scheinen ja doch welche der übleren Sorte zu sein. :-(

P.S.: Korrigiert mich, wenn ich falsch liege. Ich habe mein neuestes Exemplar nur eben angefangen, zu überfliegen, und habe zu obigem keine Schutzhinweise gefunden.

[dea]

samhain (http://la-samhna.de/samhain) ist mein persönlicher Favorit :)

[wusel]

Du kannst die benötigten Module fest in den Kernel reinlinken und dann den Module- Support im Kernel deaktivieren. Dann geht auch ein modprobe nicht mehr.

Wusel :-D

Tja, normale Rootkits lassen sich i.d.R. ja noch gut aufspüren, aber Kernel-basierte modulare Rootkits scheinen ja doch welche der übleren Sorte zu sein. :-(

P.S.: Korrigiert mich, wenn ich falsch liege. Ich habe mein neuestes Exemplar nur eben angefangen, zu überfliegen, und habe zu obigem keine Schutzhinweise gefunden.

[arnee]

Du kannst die benötigten Module fest in den Kernel reinlinken und dann den Module- Support im Kernel deaktivieren. Dann geht auch ein modprobe nicht mehr.

Wusel :-D

Sorry, dass ich dir widersprechen muss, aber das stimmt definitiv nicht. Es gibt leider Rootkits, die auch monolithische Kernel (= ohne Modul-Support) einnehmen können. :x

P.S.: Der Smilie hat natürlich nichts mit dir persönlich zu tun, sondern ist gegen die Leute gerichtet, die so einen Mist programmieren.

[wusel]

Das interessiert mich. Ich habe bisher nur davon gelesen, daß man sich an den Kernel über die Modulschnittstelle hängen kann.

Wie dies an einen Kernel ohne Modul- Support von der Theorie her gehen soll, ist mir unklar. Das können ja dann nur Bug's im Kernel selbst sein ?

Hast Du dazu nähere Infos? Ausführbarer Code muß ja angesprungen werden, sonst wird er nicht ausgeführt.

Wusel

[captaincrunch]

Ganz simpel, "Anleitungen" dazu gibt's wie Sand am Meer. Zum Glück sind diese nicht allzu einfach von jedem x-beliebigen Scriptkiddie nutzbar. ;)
Beispiel : http://www.phrack.org/show.php?p=58&a=7 (was einen weiteren Vorteil von GRSecurity zeigt, mit dem sich /dev/kmem ein wenig besser schützen lässt).

[dea]

Drum auch mein Hinweis auf samhain was auch derartige Säuereien erkennen kann (wahrscheinlich können andere das auch, nur ist's mir nicht bekannt weil ich sie nicht nutze ;) )

Allerdings sollte einem schon klar sein, dass es bereits zu spät ist, wenn das HIDS die Warnung losschickt, denn dann war der Exploit bereits erfolgreich ...

[wusel]

Prinzip erkannt. Die biegen einfach die System- Calls um.

Da stellt sich mir die Frage, ob es bei Open BSD auch diese Problematik gibt. Die haben ja einen anderen eigenen, oft verifizierten Kernel. Aber System- Calls werden die wohl auch haben.

Hat hier im Forum jemand Erfahrungen mit RootKit- Angriffen unter dem vermeintlich sicheren OpenBSD?

Ist schon eine Sauerei, daß in dem Artikel die RootKit- Entwicklung als "gute Arbeit" bezeichnet wird.

[wusel]

OK. Habe gerade bei Samhain auch gelesen:

It is incorrect to assume that disabling support for loadable kernel modules protects against runtime kernel modifications. It is possible to modify the kernel via /dev/kmem as well.

Aber ich denke, man sollte Beides tun. Das Deaktivieren der Module bringt zusätzlichen Schutz.

[captaincrunch]

Hat hier im Forum jemand Erfahrungen mit RootKit- Angriffen unter dem vermeintlich sicheren OpenBSD?

Auch OpenBSE ist kein Garant für ein sicheres System. Beispiel : http://www.guninski.com/msuxobsd2.html

Ist schon eine Sauerei, daß in dem Artikel die RootKit- Entwicklung als "gute Arbeit" bezeichnet wird.

Es ist gute Arbeit, da dadurch manche erst richtig aufmerksam und empfänglich für Sicherheit werden.

Wie gesagt, GRSecurity bietet einen besonderen Schutz für /dev/kmem, daher laufen die meisten mir bekannten Rootkits ins Leere.