noch ein hack:(

Hallo.
Auf einer mit powersite gebauten Seite wurde gestern in jede php Datei in die erste Zeile folgender ellenlanger Code geschrieben, der ein verstecktes div tag mit ewig vielen spamschlüsselwörtern diverser devisenhändlertools erzeugt hat. Kurzgesagt, sie wurde gehackt:)

Code:

<? /**/eval(base64_decode('aWYoZnVuY3R....));?>

Nun habe ich auch nach längerer Recherche noch nicht ganz verstanden:
Ist so etwas mit XSS überhaupt möglich? Wenn nein... wurde dann das FTP Passwort geknackt??
Es gibt ja kein Backend mit Passwort...

Wenn ja..
Außer dem Kontaktformular benutze ich dort gar kein anderes Formular.
Kurze Tests auf XSSanfälligkeit wurden (nicht anders zu erwarten:) nicht bestätigt.

Es läuft noch ein plugin, welches einen Ordner auf mp3s scannt und diese auf einer Seite listet.
Habe bisher aus Zeitgründen noch nicht mit einem Webscanner wie zB Nikto geprüft...

Da ich mir das zZ nicht weiter erklären kann, wollte ich hier mal nachfragen.
Es handelt sich um: http://rundsam.de

Danke für einen Hinweis.

Powersite wird in allen Versionen mit einem Profiscanner auf XSS- Anfälligkeiten und mehr geprüft - das geht natürlich nur für die Standardversion wie ausgeliefert.

Wenn - was eigentlich natürlich ist - weitere Dinge eingebunden werden entzieht sich das der Kontrolle des Programmierers.

Hat man etwas XSS anfälliges eingebunden wird sich ein Schadscript immer in den Teilen verbreiten in denen es Schreibrechte hat und das wäre in dem Fall das tmp - Verzeichnis nebst Unterverzeichnisse.

Da hier konkret die Seiten über Supercache laufen, liegen diese auch vorgefertigt im tmp/cache Verzeichnis.
Schafft ein XSS Angriff es durchzukommen, hat er da ein leichtes Spiel.

Das trifft aber auch auf bereits kompilierte Templates zu.

jede php

Was mich wundert ist das deine PHP Dateien beschreibar waren - CHMOD 644  wäre optimal.

Neben der Suche des XSS anfälligen Teiles hilft eine Absicherung der einzelnen tmp Verzeichnisse mit entsprechender htaccess.  Natürlich sind dann sämtliche Dateien im tmp zu löschen  um klar Schiff zu bekommen.

Der Rudi hatte vor langer Zeit einen solchen Fall und hat das u.a. damit geregelt.

Er könnte ja mal seine konkreten Massnahmen im Detail beschreiben.

Wenn möglich sollte man einen Blick in die access.log vom Webserver werfen - da haben aber nicht alle User einen Zugriff drauf - im Zweifelsfalle mal mit dem Provider reden.

Die Access.log sieht z.B. so aus:

127.0.0.1 - - [03/Oct/2009:12:09:29 +0200] "GET /ps10/index.php?seite=start&sprache=de HTTP/1.1" 200 291
127.0.0.1 - - [03/Oct/2009:12:09:31 +0200] "GET /ps10/index.php?seite=start&sprache=de HTTP/1.1" 200 291
127.0.0.1 - - [03/Oct/2009:12:10:01 +0200] "GET /ps10/index.php?seite=start&sprache=de HTTP/1.1" 200 291
127.0.0.1 - - [03/Oct/2009:12:10:02 +0200] "GET /ps10/index.php?seite=start&sprache=de HTTP/1.1" 200 291

kann aber auch individuell eingestellt sein, siehe http://httpd.apache.org/docs/2.0/logs.html#accesslog

Man sollte zudem alle Rechner prüfen über denen ein FTP Zugang erfolgte.

Eigene Rechner sind die häufigsten Angriffspunkte überhaupt.

Danke für deine Antwort.

Das die php Dateien beschrieben waren hat mich auch verwundert. Eigentlich achte ich auf 644 und kann es mir halt immer noch nicht erklären. Die Logs hatte ich auch schon durchgeschaut, aber zum Zeitpunkt der Änderungen der Dateien gab es merkwürdigerweise keinen Eintrag. Entweder perfekt vertuscht, kann ich mir aber auch nicht vorstellen wie...oder ich hab nicht richtig geschaut...also wahrscheinlich. Hatte mir aber Mühe gegeben und bin nicht gerade ungeübt im Logfilelesen...

Hab jetzt erstmal alle Dateien auf 444 die Ordern auf 555 und tmp weiterhin auf 755, da es eher eine statische Seite ist, läuft ja alles. Die gecachten Seiten auch auf 444 gestellt, also sollte es erstmal (in meiner Theorie zumindest:) schreibgeschützter sein. Ich werde mir die Tage die ein, zwei plugins, die ich drin habe nochmal näher anschauen. Da ich in Sachen XSS aber noch nicht viel weiß, kann ich mir immer noch nicht erklären, wo der überhaupt angesetzt hat. Der muss ja irgendeine Info ausgenutzt haben, wenn es nicht ein Formularfeld war.
Also wenn, zB einer Seite, in der ein plugin läuft über den Link eine Variable mitgegeben haben? Komisch. Wenn es mir klarer wird, schreibe ich es aus Erfahrungsgründen nochmal hier rein. Bis dann...

Beo eigenen Erweiterungen sollte man in Formularfeldern und alles was da als GET oder POST kommen sollte  unbedingt  RemoveXSS einsetzen, dann haben angehängte XSS keine Chance.