WordPress-Security #02

In der Beitrags-Reihe „CycleSEC WordPress-Security“ befassen wir uns im CycleSEC-Blog mit Härtungsmaßnahmen, die Sie bei entsprechendem Schutzbedarf Ihrer WordPress-Webseite umsetzen können.

WordPress begann 2003 als Blog-Software. Heute liegt das Content Management System (CMS) in der Verbreitung unangefochten auf Platz 1 [1, 2, 3]. Grund genug, sich mit erweiterten Sicherheitsfunktionalitäten für WordPress zu beschäftigen.

Die meisten Content Management Systeme besitzen eine Konfigurationsdatei, in der zentrale Einstellungen vorgenommen werden und u.a. auch das Datenbank-Passwort abgelegt ist. Darüber hinaus können hier einige Sicherheitseinstellungen vorgenommen werden. Die Konfigurationsdatei ist daher besonders kritisch und sollte durch zusätzliche Maßnahmen geschützt werden. Bei WordPress handelt es sich um die Datei wp-config.php, die standardmäßig im Wurzelverzeichnis der WordPress-Installation liegt.

Schwachstelle

Bei fehlerhaft konfiguriertem Webserver werden die PHP-Dateien nicht vom PHP-Präprozessor interpretiert, sondern direkt ausgeliefert und der Quellcode – inklusive Datenbank-Passwort – im Browser angezeigt. Eine passende Google-Anfrage für derartige Dateien lautet:

inurl:wp-config -intext:wp-config „‚DB_PASSWORD'“

Bei falscher Dateiendung oder bei fehlendem oder fehlerhaftem PHP-Tag am Anfang der Datei wird die Datei ebenfalls nicht interpretiert sondern bei Aufruf direkt dargestellt. Das passiert z.B. dann, wenn Sie von der wp-config.php eine „Sicherung“ anlegen, indem Sie die Datei kopieren und in wp-config.bak o.ä. umbenennen.

Die eigentliche Schwachstelle besteht jedoch darin, dass die wp-config.php ungeschützt im Webspace, also im Wurzelverzeichnis der WordPress liegt und das kein passender Ort für so sensible Dateien ist.

Angriffsszenario

Information Disclosure: Angreifer suchen gezielt nach abrufbaren wp-config-Dateien oder „stolpern“ zufällig über die (zeitweise) abrufbare Datei und greifen so das Datenbank-Passwort ab. Dadurch wird die gesamte Datenbank kompromittiert.

Privilege Escalation: Die Kompromittierung der Datenbank ist gleichbedeutend mit einer Komprimierung der gesamten WordPress-Instanz – nicht nur der in der Datenbank enthaltenen Informationen. Ein Angreifer kann sich so über die Datenbank einen eigenen Admin-User anlegen.

Defacement, Malware: Über die WordPress-eigenen Quellcode-Editoren im Dashboard kann über das gekaperte Admin-Konto neben allen Artikeln in der Datenbank auch der PHP-Quellcode des Themes und der Plugins geändert werden. Hierdurch kann das Frontend der Webseite beliebig verändert und zur Bereitstellung von beliebigem Code missbraucht werden.

Härtungsmaßnahme

Machen Sie immer Backups und regelmäßige Recovery-Tests, bevor Sie Einstellungen an Ihrer WordPress verändern. Die wichtigste Härtungsmaßnahme sind häufig aktuelle und funktionstüchtige Backups!

Die Härtung Ihrer WordPress gegen das beschriebene Szenario umfasst vier Schritte. Erstens sollte die wp-config.php aus dem Wurzelverzeichnis an einen sichereren Ort außerhalb des Webspace verschoben werden. Zweitens sollte die wp-config.php zusätzlich davor geschützt werden, überhaupt ausgeliefert zu werden – auch bei fehlerhafter Serverkonfiguration. Drittens sollten die WordPress-eigenen Quellcode-Editoren im Dashboard deaktiviert werden, um zu verhindern, dass über ein gekapertes WordPress-Admin-Konto Änderungen an den PHP-Quelldateien vorgenommen werden können. Die PHP-Quelldateien der Themes und der Plugins können dann nur noch durch einen manuellen Upload – z.B. via SFTP – angepasst werden. Änderungen, die im Online-Quellcode-Editor vorgenommen werden, gehen bei einem Update der Seite ohnehin wieder verloren und müssten bei jedem Update nachgepflegt werden. Diese manuellen Anpassungen könnten für Administratoren ein Hinderungsgrund für Updates sein. Der für WordPress bessere Weg ist die Erstellung eines sogenannten Child-Themes [4], was wir im Rahmen dieses Beitrags jedoch nicht näher betrachten. Viertens sollte zuletzt ein Funktionstest durchgeführt werden, da insbesondere die Deaktivierung der Editoren mit einigen Plugins Probleme verursachen kann [5].

Umsetzung

Die Härtungsmaßnahmen lassen sich wie folgt umsetzen:

1. Verschieben der wp-config.php aus dem Webspace der Domain in das übergeordnete Verzeichnis. WordPress sucht automatisch auch an diesem Ort, so dass Sie weiter nichts ändern müssen. Sollte es kein übergeordnetes Verzeichnis geben, müssten zunächst alle WordPress-Dateien und Verzeichnisse in einen neuen Unterordner verschoben werden und dieser als neuer Webspace der Domain konfiguriert werden. Danach kann die wp-config.php schließlich in das übergeordnete Verzeichnis verschoben werden.
   
2. Die wp-config.php sollte dann zusätzlich mit einer .htaccess-Datei durch die folgende Deny-Allow-Regel geschützt werden:
   
   Zusätzlich sollten die serverseitigen Zugriffsrechte für die Datei auf 440 bzw. r – – r – – – – – geändert werden, um unerwünschte Lese- und Schreibzugriffe zu verhindern. Je nachdem, mit welchen Berechtigungen Sie die neuen Rechte setzen, können diese mit 400 bzw. r – – – – – – – – auch restriktiver gesetzt werden.
   
3. Nun können die Online-Quellcode-Editoren über einen DISALLOW_FILE_EDIT-Eintrag in der wp-config.php deaktiviert werden. Fügen Sie dazu die folgende Zeile ein:
   
   
4. Zuletzt steht ein Funktionstest der Webseite und des Dashboards an. Hierzu gehört insbesondere auch die Prüfung aller Plugins.

Quellen

[1] W3Techs.com, Historical yearly trends in the usage of content management systems for websites

[2] WEBKALKULATOR, CMS Marktanteile & CMS Budgets

[3] CMSCrawler, Statistics for Germany

[4] WordPress.org, Child Themes

[5] WordPress.org, Editing wp-config.php