Am Samstag Oktober 2 2004 21:11 schrieb Alexander Veit:

Udo Neist schrieb:

...

Auf einem von mir mitbetreuten Webserver habe ich einen cronjob von 37815 Bytes Größe gefunden, dessen Inhalt sich mir nicht erschliesst. Ich habe den betreffenden Account erstmal gesperrt und um Klärung gebeten. Den vollständigen Code kann man unter ftp://singollo.de/pub/Final2001 ansehen bzw. downloaden.

Wenn ich das richtig interpretiere, passiert ungefähr folgendes:

Das Script schreibt ein 9371 Byte großes, UPF-komprimiertes Binary nach /tmp/qtlbvtpje. Die Datei wird ausgeführt und danach wieder gelöscht.

Falls Du einen Virenscanner hast, könntest Du ihn mal über das Binary (Ausgabe per Umleiting von echo -e -n "\177\..." in Datei) drüber laufen lassen.

Sieht schon irgendwie wurm- oder virusartig aus :)

Gruß, Alex

Danke, das habe ich schon vermutet. 4GB in 5 Minuten... Ich werde das mal austesten. Gruß Udo --

...

... gibt es da nicht was fertiges ? Gibt's da nicht was von Ratiopharm? Gute Scripte, gute Besserung! -- Dominik Roettsches (auf dclp)

Hallo zusammen, da ich mich ja aus beruflichen Gründen des öfteren mit der forensischen Analyse von Hackerangriffen beschäftige, möchte ich hier auf die Schnelle meinen Senf beitragen. Zunächst muss der zusätzliche Müll aus der Datei Final2001 entfernt und die restlichen Daten in einer eigenen Datei isoliert werden (Final2001_neu enthält nur noch die UPX-gepackten Daten, z. B. \177\105\114\106\ etc.): echo -e -n `cat Final2001_neu` > /tmp/test Mit Hilfe des strings-Befehls können alle Zeichenketten aus der Datei herausgezogen werden (gekürzt): sebastian@root66:~ $ strings /tmp/test Linux $Info: This file is packed with the UPX executable packer http://upx.sf.net $ $Id: UPX 1.24 Copyright (C) 1996-2002 the UPX Team. All Rights Reserved. $ UWVSQR T$ 9 H+|$$ :ZY[^_] WVSj /prof filej UPX!u j!Xj /tmp/upxAAAAAAAAAAA [m{r n;76 nux.so.2 6*+7 t?>09 :+/5l HwN.( ]3?( ?:Od __gmon_start gjmp rcpy unsetenv waitpid memMve4npr9tf lMtol_n ernal LexEl cxa_fi izDdup2 X feoLm c\lee Die Datei ist also mit UPX gepackt und muss dekomprimiert werden: sebastian@root66:~ $ upx -d /tmp/test -o /tmp/test2 Ultimate Packer for eXecutables Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2002 UPX 1.24 Markus F.X.J. Oberhumer & Laszlo Molnar Nov 7th 2002 File size Ratio Format Name -------------------- ------ ----------- ----------- 15588 <- 9371 60.11% linux/386 test2 Unpacked 1 file. Die Datei ist also eine Binärdatei für Linux: sebastian@root66:~ $ file /tmp/test2 /tmp/test2: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.5, dynamically linked (uses shared libs), stripped Jetzt kann man sich die Zeichenketten schon besser anschauen: sebastian@root66:~ $ strings /tmp/test2 /lib/ld-linux.so.2 __gmon_start__ libc.so.6 longjmp strcpy unsetenv waitpid recv connect geteuid memmove snprintf getenv memmem __strtol_internal getpid execl __cxa_finalize dup2 getuid feof malloc sleep vsnprintf socket select readdir strncasecmp send chmod alarm uname fprintf kill __deregister_frame_info chdir strstr rand signal strncmp setpgrp unlink setenv strcasecmp sendto _IO_getc fork execlp fread inet_aton memset srand inet_ntoa time opendir gethostbyname fgetc fclose fwrite __xstat __errno_location exit fopen _setjmp _IO_stdin_used __libc_start_main open strchr execvp closedir fcntl __register_frame_info close GLIBC_2.1.3 GLIBC_2.1 GLIBC_2.0 PTRh QVhL F H< uvRj [^_] /tmp/%s ; chmod 700 /tmp/%s ; /tmp/%s x ; rm -f /tmp/%s %d * * * * /bin/echo `crontab -l|grep '.\{666\}'|sed 's/^./echo -e -n/'`|sh Vermutung: Das Ding verbindet sich mit einem Rechner im Internet (genauer gesagt in Japan, siehe IP-Adresse 210.169.91.66 [=january.medical9.gr.jp]) per HTTP und startet ne Shell an einen bestimmten Port. Vorher wird wahrscheinlich ein Ping gesendet, um zu gucken, ob die Kiste noch da ist. Also die IP-Adresse 210.169.91.66 scheint laut dshield.org schon länger gehackt und für verschiedenste Aktivitäten mißbraucht worden zu sein, vgl. http://www.dshield.org/warning_explanation.php?fip=210.169.91.66&Submit=Submit Ich teste das Ding aber gleich mal unter VMWare und gucke mal, was es wirklich macht :-) So ich hoffe, dass das hilft. Lösung: Platte kopieren für forensische Analyse und Kiste komplett neu installieren. Viele Grüße, Sebastian

Gelesen am Samstag Oktober 2 2004 21:16:

Gut so. Der Server ist IMHO komprimittiert.

Am besten setzt ihr den Server neu auf und spielt die Backups von _VOR_ dem 27. wieder ein.

-dnh

[1] Was man z.B. erkennt, wenn man die ersten Zeichen (das sind oktale Escapesequenzen) mal mit 'echo -e' ausgibt, wenn man unsicher ist, was da alles dabei ist, dann sollte man das evtl. an 'hex' oder 'od' pipen. $ echo -en '\177\105\114\106' | hex 00000000 7F 45 4C 46 .ELF

Der Server wurde vom Provider direkt von Netz genommen, konnte also nicht weiter Daten versenden. Zugriff nur noch über Remote-Console. Ich habe direkt erstmal alle temporären Daten gelöscht, Logfiles gescannt und cronjobs überprüft. Die User mit direkten Shell-Zugang (per ssh) konnte ich erstmal ausschliessen, da ich keine Shell-Scripts entdecken konnte. Mir ist dann aber dieses File aufgefallen. Tja, der User hatte danach erstmal Pech. Da unsere Webserver alle gehosteten Scripte nur mit den Rechten der User ausführt, hatte ich einen Scan nach Files dieses Users ausgelöst. Bis auf seine regulären Dateien auf dem Webspace wurde dann nichts mehr gefunden. Ich hatte u.a. nach manipulierten Zeitstempel suchen lassen. Seit gestern abend ist der Server wieder am Netz, seit vielleicht 15 Minuten ist auch der Account freigeschaltet, aber ohne Shell-Zugang. Der User muss seine Passwörter ändern, ansonsten wird dieser gelöscht. Gibt es irgendeine Möglichkeit bei Linux ab einem gewissen Traffic ein irgendwie gearteten Alarm gesendet zu bekommen? Wir könnten solche Meldungen auch über zwei unabhängige Server weiterleiten. Gruß Udo -- "If a machine couldn't run a free operating system, we got rid of it." -- Richard Stallman (Open Sources, 1999 O'Reilly and Associates)

Am Samstag Oktober 2 2004 21:55 schrieb Michael Schachtebeck:

Udo Neist schrieb am 10/02/2004 09:49 PM:

...

Seit gestern abend ist der Server wieder am Netz, seit vielleicht 15 Minuten ist auch der Account freigeschaltet, aber ohne Shell-Zugang. Der User muss seine Passwörter ändern, ansonsten wird dieser gelöscht.

Ich würde, wenn der Server schon nicht neu aufgesetzt wird, zumindest chkrootkit laufen lassen...

Michael.

Ich habe gerade den Systemcheck der Verwaltungssoftware durchführen lassen. Suche im Ordner /bin: Keine verdächtigen Dateien! Suche im Ordner /sbin: Keine verdächtigen Dateien! Suche im Ordner /usr/bin: Keine verdächtigen Dateien! Suche im Ordner /usr/sbin: Keine verdächtigen Dateien! Suche im Ordner /lib: Keine verdächtigen Dateien! Suche im Ordner /usr/lib: Keine verdächtigen Dateien! chrootkit hat ebenso ein negatives Ergebnis angezeigt. Die einzigsten Meldungen betreffen Perl-Module, die ich aber nicht weiter prüfen brauch. Gruß Udo -- /* Am I fucking pedantic or what? */ 2.2.16 /usr/src/linux/drivers/scsi/qlogicpti.h

Am Samstag Oktober 2 2004 22:19 schrieb Sebastian Wolfgarten:

Hallo,

ich habe die Erfahrung gemacht, dass die ganzen Programme zur Erkennung von rootkits etc. nicht sonderlich hilfreich sind und vielfach die Schädlinge nicht erkennen. Da hilft nur ne manuelle Analyse des Systems, deshalb würde ich aufhören, die Beweise noch zu verändern und die Platte mit dd kopieren sowie schnellstmöglichst mit Sleuthkit etc. analysieren.

Viele Grüße, Sebastian

Die Server stehen in einem RZ, da kommen wir gar nicht dran. Jedenfalls sieht es jetzt so aus, dass wir den Server komplett neu aufsetzen - damit werden wir auch von SuSE 8.1 auf 9.0 umgestellt - und ein Backup zurückspielen. Wir sind uns nur noch nicht ganz im klaren, wie und wo wir die Datenbanken sichern sollen. Visas ist leider nicht in der Lage, ein komplettes Datenbankbackup einzulesen und die Accounts wieder herzustellen. Die anderen Daten sind kein Problem. Gruß Udo -- "...and scantily clad females, of course. Who cares if it's below zero outside" (By Linus Torvalds)