Gestern ist mir aufgefallen, dass mein vServer angegriffen wurde.
Es wurden unter /var/kunden/webs in jedem Verzeichnis, dass html-Dateien enthielt, eine Datei namens default.php erstellt. Nach dem 21. decoding kam dann Schadcode zum Vorschein.
Allen html-Dateien wurde ein iframe mit einer Weiterleitung auf ein (wahrscheinlich, Ziel gibt inzwischen 404) Schadscript hinzugefügt. Weiterhin wurden .htaccess-Dateien mit einer rewrite-Rule zum selben Schadscript erstellt.
Inzwischen habe ich die php-dateien umbenannt, ebenso die .htaccess Dateien. Für die desinfektion der htm(l)-Dateien bastle ich ein Script.
EDIT: Hier das Script, wenn man in seinen html-Dokumenten keine iframes verwendet:
for i in $(find |grep htm);do sed -i -e 's/<iframe.*<\/iframe>//' $i;doneBei vhosts, die nicht unter /var/kunden/webs liegen und in allen anderen Verzeichnissen, wurden - so weit ich das bisher beurteilen kann - keine Dateien erstellt und/oder geändert.
Mit ProFTPd habe ich nur zugriff auf dieses Verzeichnis. Auch wurden nach dem letzten Update von ProFTPd am 13. Jan keine weiteren Dateien verändert.
Einzig und allein PhpGedView 4.2.3 ist im Standardpfad /phpgedview ohne http-user/pass installiert. Für das gibt es zwei remote vulnerabilities, die allerdings zu keinem Zugriff führen. Für ProFTPd gab es auch eine Lücke, die allerdings auch nur lokal auszunutzen war.
Möglicherweise war es eine Kombination aus beiden Lücken.
Als nächstes werde ich den Server komplett sichern und dann nachsehen, ob etwas außerhalb von /var/kunden/webs geändert wurde. Falls ja, wird ein Backup eingespielt oder der Server neu installiert. Falls nein, gebe ich dem Server noch eine Chance und werde die Sache täglich beobachten. Dann phpgedview auf die aktuelle Version bringen und dann das Verzeichnis umbennen und zusätzlich per http-user/pass sichern.
Hat jemand ähnliches bei seinem (v)Server festgestellt?
