Backups sind eine gute Sache. Dabei muss man aber aufpassen dass der Schuss nicht nach hinten losgeht und man einem Hacker die Tür öffnet. Da die Backups alle wichtigen Daten enthalten müssen sie sorgfältig geschützt sein.

Für mein Blog wollte ich regelmäßige Backups haben. Da das Erzeugen von einem Backup von Hand doch ziemlich nervig ist will ich das in einem Cron-Job automatisiert haben.
Für WordPress habe ich das Plugin Backup gefunden das als Ziel mein Google Drive verwenden kann. Klingt eigentlich ganz gut. Unglücklicherweise ist da ein Haken an der Sache. Das Plugin legt auch eine lokale Kopie vom Backup an. Und diese Kopie ist über das Netz erreichbar. Damit kann jeder „Hacker“ eine Kopie von meiner Datenbank bekommen. Da es ein einfacher ungeschützter Download ist dürfte da später auch rechtlich nur schwer dagegen anzukommen sein.

Was geht schief?

In der Grundeinstellung legt das Backup Plugin seine Dateien unter http://<site-name>/wp-content/backup an. Als Dateiname wird der epoch-Zeitstempel vom Backup verwendet. Ein Backup das am 1. Juli um 2:47:28 GMT angelegt wurde bekommt damit den Namen 1341110848.zip und ist unter der öffentlichen Adresse http://<site-name>/wp-content/backup/1341110848.zip ganz ohne Passwortschutz zu erreichen.

Hacken für Kleinkinder

Ein Hacker würde jetzt vermutlich ein Script schreiben das entweder die Zeitstempel durchprobiert oder alle paar Sekunden die aktuellen Zeitstempel probiert, da wenige 404 Fehler pro Sekunde im Logfile eher untergehen als mehrere Dutzend Anfragen pro Sekunde. Eventuell würden die Dateien auch nicht chronologisch durchprobiert sondern etwas zufälliger verteilt.

Ganz ohne Script-Kentnisse geht es auch mit dem DownThemAll! Plugin für Firefox. Dort legt man einfach einen Download an der variable URL-Bestandteile enthält. Mit dieser Syntax würden die Zeit vom 1. Juli 2:47:28 bis 1:47:28 durchprobiert:

Bei einem Treffer hat man das Backup.

Diese Einstellungen durchsuchen ein Verzeichnis nach einer bestimmten Datei

Immer noch zu kompliziert?

Es geht noch einfacher. Das Plugin schreibt auch noch eine Logdatei. Diese wird ebenfalls in diesem Verzeichnis abgelegt, ist öffentlich einsehbar und enthält direkt den Dateinamen den man braucht:

In diesem Beispiel wäre es dann http://<site-name>/wp-content/backup/1341138425.zip.

Unser Hacker muss also nur prüfen ob die Datei http://<site-name>/wp-content/backup/backup.log vorhanden ist. Und schon hat er Zugriff auf eine Kopie der ganzen Datenbank.

Was kann man dagegen tun?

Die Schwachstelle bei diesem Plugin liegt darin dass an einem bekannten und zugänglichen Platz Dateien mit bekannten (oder leicht zu ratenden) Dateinamen erzeugt werden.
Die Default-Einstellungen sind einfach schlecht. In den Einstellungen des Plugins lässt sich der Local folder path ändern. Da gehört eigentlich ein individueller Bestandteil rein dar nicht erraten werden kann. Leider scheint sich der Autor des Plugins dafür nicht zu interessieren. Eine entsprechende Meldung im Support Forum liegt schon eine ganze Weile unkommentiert herum.