Am 29. Oktober haben wir über WordPress 7.1.4 geschrieben, ein Sicherheitsupdate mit über einem Dutzend Korrekturen. Eine davon führt die US-Behörde für Cybersicherheit CISA seit dem 3. November als nachweislich ausgenutzt. Die Frist, die sie US-Behörden für die Behebung setzt, ist der 6. November.
Die Lücke ist ungewöhnlich, weil sie in dem Vorgang steckt, der eigentlich schützen soll: im Update.
Angreifbar ist der Moment des Updates
Wenn WordPress ein vollständiges Update einspielt, packt es das neue Paket zuerst in einen Ordner auf dem Server aus. Bei den verwundbaren Versionen 4.7 bis 7.1.3 hatte dieser Ordner einen vorhersehbaren Namen und war aus dem Internet erreichbar. Wer genau in diesem Moment die richtige Adresse aufrief, konnte ohne Anmeldung eigenen Code auf dem Server ausführen.
Der Moment ist kurz. Laut heise lag der Ordner im Labor nur Sekunden auf dem Server. Wer angreifen will, muss also im richtigen Augenblick fragen, und genau so sehen die Angriffe aus. Die Sicherheitsfirma Wordfence hat in den ersten 21 Stunden nach ihrer Schutzregel über 18 500 solche Anfragen gezählt. Die zwei aktivsten Quellen fragten dieselben kleinen Gruppen von Websites rund 14,5 Stunden lang immer wieder ab.
Die neue Version legt den Ordner unter einem zufälligen Namen an und sperrt ihn mit einer Schutzdatei.
Was wir in unseren Protokollen gefunden haben
Wir haben am 3. November die Zugriffsprotokolle aller Websites auf einem unserer Server durchsucht, nach Anfragen auf genau diese Adressen.
45 Anfragen, alle von einer einzigen Adresse, verteilt auf zehn Websites. Keine davon bekam eine Antwort mit Inhalt: Der Server meldete «nicht gefunden» oder «verboten».
Die erste kam am 29. Oktober um 23:17 Uhr, die letzte am Abend darauf.
Alle zehn Websites hatten sich am 28. Oktober zwischen 18:40 und 19:59 Uhr selbst aktualisiert. Als die Anfragen begannen, war das Fenster dort schon seit über einem Tag zu.
In den Update-Ordnern aller Websites auf dem Server liegen keine fremden PHP-Dateien, nur die neue Schutzdatei aus dem Update selbst.
Das ist ein beruhigender Befund, aber er hat eine einfache Ursache: Wir waren früher dran als die Angreifer. Wer das Update erst Tage später einspielt, spielt es in eine Zeit, in der gezielt danach gesucht wird.
Wer jetzt noch aktualisiert
Daraus folgt keine Empfehlung, mit dem Update zu warten, im Gegenteil. Die alte Version bleibt verwundbar, und das Fenster öffnet sich bei jedem vollständigen Update, das eine verwundbare Version einspielt. Je länger man wartet, desto mehr Angreifer warten mit.
Für ältere Versionszweige gibt es eigene Korrekturen, etwa 6.8.12 oder 7.0.8. Ein Wechsel auf den aktuellen Zweig ist trotzdem die bessere Wahl.
Was jetzt zu tun ist
Die Version prüfen. Im WordPress-Backend unter «Dashboard», «Aktualisierungen». Steht dort 7.1.4, oder auf älteren Zweigen eine der Korrekturversionen, ist die Lücke geschlossen.
Den Update-Ordner ansehen. Wer Zugang zu den Dateien hat, sieht im Ordner wp-content/upgrade nach. Dort gehören keine PHP-Dateien hin ausser einer kurzen index.php. Alles andere ist verdächtig.
Nach fremden Konten sehen. Unter «Benutzer» nach Administratoren suchen, die niemand kennt, und unter «Plugins» nach Erweiterungen, die niemand installiert hat.
Bei der Agentur nachfragen. Die Frage lautet: Wann genau wurde unsere Website auf 7.1.4 gebracht, und habt ihr den Update-Ordner geprüft? Eine gute Antwort enthält ein Datum.