Skip to content

Wordpress Hack total

Autor: Marius Timmer

Wie Ihr ja sicher schon gelesen habt, ist meine Mutter selbstständig und hat daher auch eine Webseite. Der Einfachkeit halber wurde das damals mit WordPress realisiert und auch in der Vergangenheit bereits gehackt (wenn auch geskriptet).

Kein gezielter Angriff

An dieser Stelle sei noch einmal erwähnt, dass ich ungerne sage, dass die Seite gehackt wurde, weil das der Sache nicht ganz gerecht wird und zu nebulös ist. Vor allem vermittelt es dein Eindruck, dass es sich um einen gezielten Angriff handeln würde. Oft muss ich dann erst einmal erklären, dass da nicht jemand in seinem Keller saß, einen Hoodie trägt und sich vor nimmt, gezielt Webseiten anzugreifen. Viel eher sind es einfach Skripte (also Computerprogramme) von teilweise so genannten Skript Kiddies, die automatisiert und wahllos auf bekannte Schwachstellen losgelassen werden und dann dort ihr Werk verrichten. Leider ist WordPress voll mit bekannten Schwachstellen, auch wenn man es regelmäßig aktualisiert.

Neue Version

Nachdem ich besagte Installation per Cronjob alle fünf Minuten prüfte und ggf. säuberte, schien eine lange Zeit alles wieder okay zu sein. Allerdings hatte sich nun wohl eine neue Version des Skriptes installiert oder irgendein Ereignis wurde getriggert. Fakt ist auf jeden Fall, dass sich die Skripte dieses mal ganz anders verhalten haben:

  • Ein Dateibrowser (in PHP geschrieben) wurde installiert
    • So ließen sich alle Dateien auf dem Server einsehen und manipulieren
    • Da so auch Datenbank-Zugangsdaten erreichbar sind, war die Datenbank ebenfalls als kompromitiert anzusehen
    • Alle Inhalte wurden gelöscht und per .htaccess ein Forbidden-Status zurück gegeben

Als ich informiert wurde, dass “irgendetwas nicht mit der Seite stimmt” dauerte es noch ein paar Stunden, bis ich mir das näher ansah. Bis dahin ging ich davon aus, dass jemand aus Versehen die index.php-Datei gelöscht hatte. Nach wenigen Sekunden bemerkte ich, dass aber auch alles andere gelöscht war. Das überraschte mich. Zudem lagen dort nur einige Skripte, von denen ich noch nie etwas gehört hatte. direkt auf dem Server sah ich mir die Skripte genauer an: Es handelte sich um PHP-Code, der einen URL-encodierten String enthielt, der fast zwanzig mal durch eval() gejagt wurde und dann seinen eigentlichen Code ausführte. So kann man vielleicht Scannern entkommen, aber nicht mehr (bei näherer Betrachtung). Es handelte sich um einen Dateibrowser, der es dem Nutzer erlaubte, die Dateien auf dem Server per HTML-Formular zu manipulieren. Das ist natürlich ein super GAU.

Backups

Aus Sicherheitsgründen werden nächtlich Backups von den gesamten Datenverzeichnissen angelegt. Im Notfall kann man so recht einfach auf einen vorherigen Zustand zurück und einen potentiellen Schaden gering halten.

In diesem Fall wäre das Wiederherstellen eines Backups aber nicht ratsam, da ja auch der Schadcode wiederhergestellt werden würde und alles wieder von vorne beginnen würde.

Die Lösung

Meiner Meinung nach war das Sicherste in diesem Szenario auch zeitgleich die aufwändigste Lösung: Alles platt machen und neu aufziehen. Zu meiner Überraschung ging meine Mutter da voll mit und beschloss auch, einen anderen Hosting-Provider zu nutzen. Aus meiner Sicht sprach da nichts gegen und es ist nahezu ausgeschlossen, dass man den Schadecode “mit nehmen” würde.

Manch einer mag argumentieren, dass das natürlich mit Kanonen auf Spatzen geschossen sein, aber sicher ist sicher. Weder ich noch meine Mutter hätten die Muse gehabt, die Fehlerquelle zu finden, auszumärzen und anschließend alles wieder neu aufzubauen.

Im letzten Beitrag hatte ich bereits Einblicke in die Schadsoftware gegeben. Diese Schnitzeljagd war relativ interessant. Dennoch wollte ich der Sache nicht weiter gehen, da es mich am Ende auch nicht weiter bringen würde.