backdoor/rootkit ?

[Gulliver]

Ein externe Kunde hat mich beauftragt seine Server zu kontrollieren.
Beim ersten blick auf 3 Rechner fiel mir sofort auf dass wenigstens folgende Programme nicht korrekt arbeiten:

tar
ps
grep/ngrep/egrep
lsof

und ls scheint ebenso modifiziert worden zu sein.

Das veränderungsdatum ist definitiv mehrere monate alt.
Keine user wirden zusätzlich angelegt.
in der Prozesstabelle ist IMMER ein "ls" zu finden. killen - ls aufruf und ls bleibt stets am laufen. Nach einem update von lsof bekomme ich folgende Ausgabe:

ls 6936 root 5u IPv4 65811094 UDP *:3049

Wobei UPD/TCP 3049 IMHO für ein kryptofilesystem "vorgesehen" ist. (ist nicht in services aufgenommen)

lsof -p 3936 bringt folgende Ausgabe
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
ls 6936 root cwd DIR 8,3 8192 3940834 /usr/lib/locale
ls 6936 root rtd DIR 8,3 4096 2 /
ls 6936 root txt REG 8,3 48455 5494491 /bin/ls
ls 6936 root mem REG 8,3 104560 2485594 /lib/ld-2.3.2.so
ls 6936 root mem DEL 0,4 65537 /SYSV46532e4f
ls 6936 root mem REG 8,3 1548424 5739716 /lib/i686/libc-2.3.2.so
ls 6936 root 0u CHR 136,0 2 /dev/pts/0
ls 6936 root 1u CHR 136,0 2 /dev/pts/0
ls 6936 root 2u CHR 136,0 2 /dev/pts/0
ls 6936 root 3r FIFO 0,5 65811093 pipe
ls 6936 root 4w FIFO 0,5 65811093 pipe
ls 6936 root 5u IPv4 65811094 UDP *:3049

und eben da bin ich überfordert.

Ich gehe mal start davon aus die die o.ä. erwähnten programme gebackdoort sind nur habe ich keinen blassen schimmer womit das geschenen ist.

chkrootkit hat übrigens nichts gefunden.

für handfeste Hilfe wäre ich sehr dankbar.

mfg
Thomas

ps: redhat 9.0, Apache 2*, ssh2, proftpd.
kein imap, pop, smtp, named, smb, nfs

 

[Gulliver]

Nachtrag:

Die Verzeichnisse

/usr/bin
/usr/sbin/
/bin
/hom/vhosts/http/
/etc

wurden komplett zurückgespiegelt.

Nun gibt er bei den o.ä. Programmen "segmentation fault" aus.

strace ls zeigt am ende:
munmap(0x40017000, 4096)
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++

nun bin ich komplett überfragt da die programme "eigentlich" ersetzt worden sind.
(und ja, der mirror war von genau diesem System, 1 woche alt)
Hardware ist definitiv ok!

Jemand ne passable Antwort?

mfg :/

 

[sieben]

Original von Gulliver
ls 6936 root 5u IPv4 65811094 UDP *:3049

Erinnert mich ein bischen an Linux.OSF.8759 oder eine Mutation daraus. Kaspersky Anti Virus sollte ihn aufspueren koennen.

Wobei UPD/TCP 3049 IMHO für ein kryptofilesystem "vorgesehen" ist. (ist nicht in services aufgenommen)

Richtig, CFS.

Nachtrag:

Die Verzeichnisse

/usr/bin
/usr/sbin/
/bin
/hom/vhosts/http/
/etc

wurden komplett zurückgespiegelt.

Nun gibt er bei den o.ä. Programmen "segmentation fault" aus.

Ich hab den boesen Verdacht das einige libs mit drin haengen.

nun bin ich komplett überfragt da die programme "eigentlich" ersetzt worden sind. (und ja, der mirror war von genau diesem System, 1 woche alt)

Vorsicht mit den Backups, solange nicht sichergestellt ist das sie nicht ebenfalls betroffen sind.

 

[DelumaX]

Das veränderungsdatum ist definitiv mehrere monate alt.

und ja, der mirror war von genau diesem System, 1 woche alt

In diesem Fall wäre die Sicherung bereits von dem Problem betroffen! Es wäre das beste den Server neu aufzusetzen und die alte Installation in Ruhe zu untersuchen um die Lücke zu finden.

 

[sieben]

Original von DelumaX

Das veränderungsdatum ist definitiv mehrere monate alt.

und ja, der mirror war von genau diesem System, 1 woche alt

In diesem Fall wäre die Sicherung bereits von dem Problem betroffen! Es wäre das beste den Server neu aufzusetzen und die alte Installation in Ruhe zu untersuchen um die Lücke zu finden.

Also ctime, mtime etc. zu modifizieren ist nicht schwer. Das ist nicht verlaesslich.

 

[DelumaX]

Gerade aus diesem Grund würde ich den Server nicht mehr in Betrieb nehmen. Es ist schwer bis unmöglich und mit viel Aufwand verbunden das System komplett zu analysieren und in den Urzustand zu versetzen...

 

[Gulliver]

Gegen Feierabend war ich dann auch der festen überzeugen das das rootkit(wovon ich ausgehe) mir den kernel zerschossen hatte. Die backups sind sauber und ein neuer server ist geordert - im ersten Monat kommt uns der provider sogar entgegen.

@Delumax
Die logs hatte ich vor ein paar monaten schon im gesamten netz auf einen internen log server gesichert.
Aber dort ist wenig zu holen - ich gehe mal von einem schwachen passwort eines users oder BO im apache aus obwohl mir für diesen Apache keine xploits "in the wild" bekannt sind.

mfg und thx

 

[Rushjo]

@Gulliver

Warum denskt Du, das der Apache-WebServer die Schwachstelle war? Laufen keine anderen möglichen
"schwache" Dienste wie sendmail, ssh, ftp etc.?? Weiterhin kann ich DelumaX und sieben nur zustimmen, das
Du den Backups nicht trauen kannst, das Du den genauen Zeitpunkt des "Compromise" nicht kennst.
"ctime" und "mtime"-Werte sind beliebig änderbar, gerade wenn man "root rechte" hat. Ausserdem hast Du
immernoch keine Gewähr, das es kein "Kernel Rootkit" ist!!! Also am Besten:

1. Logs sichern und analyzieren!!
2. Komplett formatieren und alles neu aufsetzen!!!
3. Alle Patches einspielen!!

Hier mal noch ein interessanter Link zum Thema "rootkits".

MfG Rushjo

 

[Gulliver]

kein imap, pop, smtp, named, smb, nfs

ftp muss ich anbieten, läuft aber auch chrooted und bruteforce war auch nicht zu erkennen.

Du den Backups nicht trauen kannst, das Du den genauen Zeitpunkt des "Compromise" nicht kennst.

Ok, dann ruf du bei ca 240 Kunden an und erzähle denen das mal )
Manchmal muss man es halt und kann nur verstärkt überwachen.

mfg
(server ist neu, läuft 1A - also ist mein job da zu ende und ich warte halt bis sie das nächstemal anrufen )