SPAM über das import/Export plugin ?!?

[jdlx]

Moin,
gerade bekomme ich vom Provider folgende Nachricht:

Von: technik@domainfactory.de
Datum: 3. Juni 2007 19:58:38 MESZ
Betreff: Spam über PHP-Datei //


Sehr geehrter Herr ...,

leider mussten wir feststellen, dass Ihr Script von Dritten missbraucht wurde um unerwünschte E-Mails über unsere Systeme abzusetzen.

Da wir als Webhoster jedoch Spam jeglicher Art ablehnen und dementsprechend auch nicht Ursprung von Spam sein möchten, mussten wir sofort reagieren und Ihr Script umbenennen:
/kunden/....../domain.de//redaxo/include/addons/import_export/pages/index.inc.php
Dies haben wir in Ihrem Fall getan.

Ist Ihnen die oben genannte Datei unbekannt oder sollte diese Datei niemals für einen E-Mailversand gedacht gewesen sein, so könnte dies die Folge eines Angriffs auf Ihre Webseite sein.

... etc.

Is grad ganz frisch, d.h. ich bin erst noch dran nachzuvollziehen was/wie passiert ist.. stay tuned.

*update*

Yo, wies scheint tatsächlich ein exploit über addons/import_export/pages/index.inc.php. Bei Domainfactory ist allow_url_fopen standardmäßig auf on.. Angriff erfolgte über nen include eines externen scripts das zunächst den absoluten Pfad ermittelt: http://www.dgsport.be/components/res.txt und danach über ein massmailer script das ausgeführt wird: http://tha-design.de/kmatic/v2/images/CMD.TXT

Wie die präparierten URLs konkret aussehen poste ich hier jetzt mal besser nicht.. ;-)

Werd jetzt mal flugs bei allen von mir betreuten Domains die PHP Einstellungen entsprechend anpassen und dann weitersehn..

Jan

[sandimkopf]

Hi Jean,

habe offenbar das gleiche problem mit einem 1und1 - Server.

Die Lösung kann also sein, allow_url_fopen auf off stellen zu lassen?
Verstehe ich das so richtig?

Werde es mal probieren…

Danke für Deine Dokumenrtation so weit - der Ausgang der Geschichte
interessiert mich brennend.

[Ruediger.Nitzsche]

Und bei Euch war die htaccess im include vorhanden?

Rüdiger

[zehbaeh]

Hmm...
Du hast den "include" Ordner nicht per .htaccess geschützt?
Du benutzt keine aktuelle Version von Redaxo?

[jdlx]

Die Lösung kann also sein, allow_url_fopen auf off stellen zu lassen?
Verstehe ich das so richtig?

Sollte, ja, da bei allow_url_fopen = OFF externe includes nicht mehr möglich sind. Ich bin gerade am Testen wie sich meine anderen Domains verhalten.. interessanterweise gibts da nen Scriptabbruch mit generischer 500er Fehlermeldung seitens Domainfactory. Werd mal die jeweiligen PHP Einstellungen, Rechte usw. vergleichen..

cheers,
Jan

[jdlx]

Moin,

Hmm...Du hast den "include" Ordner nicht per .htaccess geschützt?

Merkwürdig.. die hat tatsächlich gefehlt. Kann ich mir nicht recht erklären. Muß wohl ein FTP Übertragungsfehler gewesen sein, denn gelöscht hab ich sie sicher nicht..

Jan

[sandimkopf]

Hmm...
Du hast den "include" Ordner nicht per .htaccess geschützt?
Du benutzt keine aktuelle Version von Redaxo?

Tatsächlich war der Include-Ordner nicht per .htaccess geschützt.
Meine Redaxo Version ist 3.2. Habe jetzt die .htaccess aus der
aktuellen Version in den Include-Ordner kopiert – sollte es das gewesen sein? Kann leider nichts überprüfen, da die Site seitens 1und1 gesperrt ist.

[Ruediger.Nitzsche]

Ja, damit dürfte alles wieder im grünen Bereich sein.

Rüdiger

[sandimkopf]

Sehr gut - bin erleichtert! Vielen Dank für die Hilfe.

Greets

Hendrik

[jdlx]

Ja, damit dürfte alles wieder im grünen Bereich sein.

Yo, seh ich auch so..
War so frei mal aus Interesse Domains abzuklopfen die in Webseiten & Kommentare vorgestellt wurden. Bin schon bei einer weiteren fündig geworden.. Mail an den Admin geht gleich raus.

*später*

Noch ne 2. gefunden.. weiter mach ich jetzt mal nicht.. mir wird der Arm vom copy&paste langsam lahm.. ,-) Aber es scheint wohl doch ab und zu vorzukommen.. aus welchen Gründen auch immer.

Jan

[zehbaeh]

Wenn Du "allow_url_fopen" weiterhin aktiviert lässt, solltest Du UNBEDINGT auch die Redaxo Version aktualisieren. Mit 3.2 und aktivem fopen-Wrapper ist ansonsten auch ein "Einfall" über die index.php des Frontends möglich.

[jdlx]

Wenn Du "allow_url_fopen" weiterhin aktiviert lässt, solltest Du UNBEDINGT auch die Redaxo Version aktualisieren.

Bei meinen selbst gehosteten Domains hab ich einfachen Zugriff auf die php.ini.. und aufgrund der Geschehnisse heut vormittag auch für alle abgeschaltet. Anders siehts bei einigen Kunden aus wo direkter Zugriff auf die php.ini nicht möglich is.. da werd ich jetzt schnell mal wo noch nicht geschehen das 3.2.2 update drüberbügeln.. das geschnürte update Pack zum schmerfreien Sync hab ich hinterlegt, siehe:

http://forum.redaxo.de/ftopic5740.html

greets,
jan

[Oliver.Kreischer]

Hallo,

wie schütze ich eine Seite uf derem Server ich keine Möglichkeit habe eine .htaccess Datei zu schreiben?

Gruß
Oliver

[Dr KillerJoe]

Hi.

Ist es ein IIS oder Apache Server?

mfg
Flo

[Oliver.Kreischer]

Hm.

so auf die Schnelle weiß ich das nicht. Sind verschiedene Server.
wie finde ich das raus (ohne besondere rechte zu haben?

Gruß
Oliver

[Ruediger.Nitzsche]

Das sagt Dir schon eine simple info.php

Rüdiger

[Oliver.Kreischer]

Ok. Danke. Gucke ich heute Abend. Und was wenn ich die Info habe??

Gruß
Oliver

[c_reiter]

Bezüglich der .htaccess

Es kommt nicht nur darauf an, DASS man eine hat, sondern WELCHE.

Die aktuelle hat kein "LIMIT GET" Statement und ist damit sicher: Sie ist auch gegen POST Angriffe gefeit (Versionsbezeichnung 3.2.2, Änderungsdatum der .htaccess im ZIP ist 10.07.2007, entspricht CVS Revision 1.5
http://cvs.berlios.de/cgi-bin/viewcvs.c ... cvs-markup

Hatte mir aber am 20.6. schon einmal Redaxo 3.2.2 gezogen. Release von R3.2.2. war ja der 15.05.2007

Dort war auch eine .htaccess drin, aber sie hatte ein LIMIT GET Statement und war somit NICHT sicher gegen POST Angriffe.

Änderungsdatum im ZIP war hier der 05.08.2005 und vom Inhalt entspricht dies der CVS Revision 1.1
http://cvs.berlios.de/cgi-bin/viewcvs.c ... cvs-markup

Das heisst, wer ein ZIP namens Redaxo 3.2.2 irgendwann heruntergeladen, ausgepackt und installiert hat ist NICHT automatisch sicher, da es Unterschiede gab zwischen dem was direkt nach dem Release und dem was heute heruntergeladen werden kann, obwohl die Versionsnummer die gleiche ist.

Das CVS zeigt auch, dass es aktuell am Releasedatum 15.05.2007 keinen Weg gab an eine Version ohne das gefährliche LIMIT zu kommen, da zu dieser Zeit noch die Version 1.3 aktuell war, welche das Limit enthält.
http://cvs.berlios.de/cgi-bin/viewcvs.c ... cvs-markup

Das LIMIT flog erst in der Version 1.4 heraus, welche es erst seit dem 06.07 gibt, also sozusagen ein undokumentiertes Redaxo 3.2.2.1 Upgrade.
http://cvs.berlios.de/cgi-bin/viewcvs.c ... cvs-markup

Also in jedem Fall mal die .htaccess prüfen. Wer sein Redaxo 3.2.2 vor dem 6.7. eingespielt hat, hat eventuell eines, welches gegen die beschriebenen POST Angriffe verwundbar ist, obwohl eine htaccess vorliegt.

Das gleiche Problem gab es letztlich bei mysqldumper.

[iwerstler]

Bezüglich der .htaccess

Es kommt nicht nur darauf an, DASS man eine hat, sondern WELCHE.
.
.
.
Das CVS zeigt auch, dass es aktuell am Releasedatum 15.05.2007 keinen Weg gab an eine Version ohne das gefährliche LIMIT zu kommen, da zu dieser Zeit noch die Version 1.3 aktuell war, welche das Limit enthält.
http://cvs.berlios.de/cgi-bin/viewcvs.c ... cvs-markup

Das LIMIT flog erst in der Version 1.4 heraus, welche es erst seit dem 06.07 gibt, also sozusagen ein undokumentiertes Redaxo 3.2.2.1 Upgrade.
http://cvs.berlios.de/cgi-bin/viewcvs.c ... cvs-markup
.
.
.
Also in jedem Fall mal die .htaccess prüfen. Wer sein Redaxo 3.2.2 vor dem 6.7. eingespielt hat, hat eventuell eines, welches gegen die beschriebenen POST Angriffe verwundbar ist, obwohl eine htaccess vorliegt.

Bin eben fast vom Stuhl gefallen als ich beim freien durchforsten der Foren von diesem Problem gelesen habe.

Wieso wird sowas denn eigentlich nicht auf der Homepage angekuendigt? Mal eben schnell eine Info sollte nicht so problematisch sein, wenn wichtige neue Updates existieren. Und eine korrigierte .htaccess findet man anscheinend auch nur im kompletten zip, korrekt?




Ingo