Betroffen sind die WordPress-Versionen 4.7 bis 7.1.3. Bei einem Core-Update mit einem vollständigen Paket entpackt WordPress eine Kopie der neuen Version in einen temporären Ordner innerhalb von wp-content/upgrade. Diese Kopie enthält auch den WordPress-Installer, und der Webserver kann sie in der Regel ausliefern. Ein Angreifer ohne Konto, der den Ordnernamen ermitteln und den Installer erreichen kann, bevor WordPress die Kopie löscht, landet am Ende bei Codeausführung auf dem Server.

Die US-Cybersicherheitsbehörde CISA nahm die Schwachstelle Anfang dieser Woche in ihren Katalog bekannter ausgenutzter Schwachstellen auf — auf Basis von Hinweisen auf aktive Ausnutzung, ohne die Angriffe näher zu beschreiben.

WordPress hat den Fix vergangene Woche mit Version 7.1.4 sowie mit entsprechenden Updates für ältere Zweige zurück bis 4.7 veröffentlicht; alle sind im Sicherheitshinweis des Projekts aufgeführt.

Der Fix gibt dem temporären Ordner einen zufälligen Namen. Das Update, das diesen Fix installiert, entpackt seine Dateien jedoch noch mit dem bereits auf der Seite vorhandenen alten Code. Auf Installationen ab 5.9 benennt dieser alte Code den Ordner nach der heruntergeladenen Datei — der Name ist also ein letztes Mal vorhersagbar. Auf Versionen 4.4 bis 5.8 hängt der alte Code zufällige Zeichen an den Ordnernamen an; das verbirgt den Namen, sofern die Seite ihn nicht anderweitig preisgibt, etwa in einer Fehlermeldung.

Vor dem Fix konnte ein Angreifer über den Installer eine neue Konfigurationsdatei wp-config.php in die temporäre Kopie schreiben; das Update überschrieb anschließend die echte Datei der Seite damit. Dieser Teil des Fixes greift bereits während des Updates, das ihn installiert, weil WordPress die Dateien mit dem neuen Code an ihren Platz kopiert. Dennoch kann ein Angreifer, der das Zeitfenster während dieses Updates trifft, die temporäre WordPress-Kopie mit einer eigenen Datenbank einrichten, sich dort anmelden und PHP-Code mit den Rechten des Webservers ausführen, bevor die Kopie gelöscht wird. Von dort aus lassen sich Dateien der echten WordPress-Installation lesen und schreiben, schreibt Bayram in seiner technischen Analyse.

Ist 7.1.4 oder der Fix des jeweiligen Zweigs einmal installiert, verwenden spätere Updates einen zufälligen Ordnernamen, und eine wp-config.php aus der temporären Kopie wird nie über die echte Datei kopiert.

Nicht jedes Update legt den Installer offen, so der Forscher. Vollständige Pakete enthalten die Installer-Dateien immer. Ein kleineres Teilpaket, das für eine bestimmte Ausgangsversion gebaut wird, setzt eine Seite nur dann aus, wenn es die Dateien zufällig enthält. Auf Seiten mit automatischen Hintergrund-Updates installiert WordPress den Fix selbsttätig — über denselben Updater und dieselben Schritte.

Eine Abfrage des Update-Dienstes von WordPress.org für mehrere Versionen ergab: Für Updates innerhalb eines Zweiges, etwa von 7.1.3 auf 7.1.4, wurde ein Teilpaket angeboten, auch für automatische Updates. Für den Wechsel aus einem älteren Zweig, etwa von 7.0.7 auf 7.1.4, wurden ausschließlich vollständige Pakete angeboten.

Bayram ergänzte am 6. November, ob ein Teil-Update gefährdet sei, hänge davon ab, was das konkrete Paket enthalte. Ein Teilpaket umfasst nur die zwischen zwei Releases geänderten Dateien; fehlen darin die Installer-Dateien, kann die temporäre Kopie nicht als WordPress-Installation laufen, und der Installer wird nie erreichbar. Zudem erhält eine Seite nicht immer ein Teilpaket, auch wenn eines existiert: WordPress fällt auf ein vollständiges Paket zurück, wenn die Core-Dateien nicht zu den offiziellen Prüfsummen passen oder es sich um eine Neuinstallation handelt. Entscheidend sei, sagte der Forscher, „nicht Teilpaket gegen vollständiges Paket. Entscheidend ist, ob der bereits auf der Seite installierte Updater gepatcht ist."

Vor dem Update

Bayrams erste Empfehlung: Der Webserver sollte wp-content/upgrade überhaupt nicht mehr ausliefern. WordPress arbeitet direkt auf der Festplatte mit diesem Ordner, eine Sperre des Web-Zugriffs bricht Updates daher nicht.

  • Nginx: location ^~ /wp-content/upgrade/ { deny all; }
  • Apache: Require all denied innerhalb eines <Directory>-Blocks für diesen Ordner in der Virtual-Host-Konfiguration
  • Nur .htaccess verfügbar: RedirectMatch 403 ^/wp-content/upgrade/ in die .htaccess im WordPress-Wurzelverzeichnis, oberhalb der WordPress-Rewrite-Regeln

Keine .htaccess in wp-content/upgrade selbst ablegen: Der alte Updater löscht alles in diesem Ordner, bevor er ein Update entpackt — die Datei wäre genau dann verschwunden, wenn sie gebraucht wird. Anschließend prüfen, ob eine Anfrage an /wp-content/upgrade/ einen 403-Fehler liefert, und dann auf 7.1.4 beziehungsweise die korrigierte Version des eigenen Zweiges aktualisieren.

Der zweite sichere Weg ist ein manuelles Update außerhalb des Web-Roots: Dateien und Datenbank sichern, das neue Release in einem Ordner entpacken, den der Webserver nicht ausliefert, die Core-Dateien an ihren Platz kopieren, ohne wp-config.php und wp-content anzurühren, und danach das Datenbank-Update ausführen. So entsteht nie ein temporärer Installer in einem per Web erreichbaren Ordner. Der Befehl wp core update von WP-CLI ist kein Ersatz, da er denselben Updater verwendet und das Paket in denselben Ordner entpackt.

WordPress 4.6 und älter erhalten keine Sicherheitsupdates mehr, für sie gibt es keinen Fix. Die Schwachstelle reicht laut Bayram zurück bis WordPress 2.7 aus dem Jahr 2008; solche Seiten sollten auf eine unterstützte Version wechseln.

Angriffe und Prüfpunkte

Wordfence, das WordPress-Sicherheitsunternehmen, das die CVE-Kennung vergeben hat, registrierte am Tag der Veröffentlichung die ersten Angriffsversuche neun Minuten nach dem Ausrollen einer Firewall-Regel für die Lücke. Zwei der aktivsten Quellen prüften kleine Gruppen von Seiten rund 14,5 Stunden lang immer wieder ab — das passe, so das Unternehmen in seiner Angriffsanalyse, zu Versuchen, den Moment eines Updates abzupassen. Wordfence bewertet die Lücke im CVE-Eintrag mit 8,1 von 10 Punkten auf der CVSS-Skala; in Labortests dauerte das Zeitfenster nur Sekunden. Der Sicherheitshinweis von WordPress selbst stuft die Lücke als gering ein.

Seit Anfang dieser Woche ist in öffentlichen GitHub-Repositories Code aufgetaucht, den seine Autoren als Exploit für die Schwachstelle bezeichnen. In einem Fall heißt es, der Code funktioniere auch auf Seiten, die bei Updates mit vollständigen Paketen weiterhin einen vorhersagbaren Ordner verwenden. Ob der Code funktioniert, ist nicht belegt.

Für Seiten, die nach dem Release auf einer betroffenen Version geblieben sind, empfiehlt Wordfence die Suche nach:

  • unerwarteten Anfragen an PHP-Dateien unterhalb von wp-content/upgrade
  • Administratorkonten, die niemand kennt
  • Plugins, die niemand installiert hat
  • PHP-Dateien in wp-content/upgrade, die niemand dort abgelegt hat