Wenn eine Website den Anbieter wechselt, braucht es ein Werkzeug, das alles einpackt und am neuen Ort wieder auspackt. Bei WordPress heisst das meistgenutzte davon All-in-One WP Migration, und es läuft auf über fünf Millionen Websites.
Ende August wurde darin eine Lücke bekannt, die mit 8,8 von 10 Punkten bewertet ist. Sie steckt ausgerechnet in der Wiederherstellungsfunktion.
Was die Lücke erlaubt
Beim Einspielen einer Sicherung setzt das Plugin Datenbankabfragen aus Angaben zusammen, die es nicht ausreichend prüft. Ein Angreifer kann darum eigene Abfragen anhängen und die Datenbank auslesen. Besonders unangenehm: Auf diesem Weg lässt sich ein interner Schlüssel des Plugins abgreifen — und mit dem in der Hand rückt die Ausführung eigenen Programmcodes in Reichweite.
Wichtig für die Einschätzung ist, wer das ausnutzen kann — und die Antwort fällt unangenehm aus: jeder, ohne Konto.
Der Angreifer hinterlässt an einem beliebigen öffentlichen Beitrag einen präparierten Trackback. Das ist eine automatische Verweis-Meldung, wie sie Websites einander seit zwanzig Jahren schicken, wenn eine auf die andere verlinkt. Sie wird ungeprüft gespeichert und liegt danach unauffällig in der Datenbank. Sie tut nichts.
Ausgelöst wird sie erst, wenn der Betreiber selbst eine Sicherung erstellt und wieder einspielt. Beim Einspielen schreibt das Plugin sämtliche Adressen in der Datenbank um — und dabei werden die eingeschleusten Zeichen zu einer eigenen Abfrage. Die legt den internen Schlüssel des Plugins in einem freigegebenen, öffentlich sichtbaren Kommentar ab. Mit diesem Schlüssel spielt der Angreifer anschliessend sein eigenes Archiv ein und übernimmt die Website.
Das Bemerkenswerte daran ist der Auslöser: Die Wiederherstellung ist der Angriff. Nicht ein Einbruch von aussen, sondern der Handgriff, zu dem in jedem Notfallratgeber geraten wird.
Betroffen sind alle Fassungen bis einschliesslich 7.109. Die aktuelle Fassung ist 7.110.
Der Teil, über den kaum jemand schreibt
Wer nun im Verwaltungsbereich nachsieht, warum er aktualisieren soll, findet im Änderungsprotokoll von 7.110 zwei Einträge: eine Korrektur bei der Suchen-und-Ersetzen-Funktion und eine falsche Warnmeldung beim Verlassen der Seite. Von einer Sicherheitskorrektur steht dort kein Wort.
Das ist kein Vorwurf an den Hersteller — es ist üblich, eine Lücke erst zu schliessen und dann bekanntzugeben. Für den Betreiber heisst es aber: Sie können einem Update nicht ansehen, wie dringend es ist. Wer nach der Devise verfährt «Sicherheitsupdates sofort, Fehlerkorrekturen bei Gelegenheit», trifft die Entscheidung auf einer Grundlage, die schlicht nicht stimmt.
Und der Teil, der über dieses Plugin hinausgeht
Ein Umzugswerkzeug braucht man einmal. Man installiert es für den Wechsel, schiebt die Website hinüber, freut sich, dass es geklappt hat — und deinstalliert es nie.
Danach sitzt es jahrelang auf der Website. Es tut nichts, es fällt niemandem auf, es taucht in keiner Besprechung auf. Aber es ist da, es wird mitgeladen, und jede Lücke, die künftig darin gefunden wird, ist Ihre Lücke.
Dieselbe Sorte finden wir bei Kundenübernahmen regelmässig: das Wartungsmodus-Plugin von der Erstellung, der Datenbank-Aufräumer von der einen grossen Aktion, das Import-Werkzeug für die alten Beiträge, der Duplikator vom Testsystem. Jedes davon war einmal richtig. Keines davon wird noch gebraucht.
Was zu tun ist
Wenn Sie All-in-One WP Migration einsetzen: auf 7.110 aktualisieren.
Und dann die Frage stellen, die wichtiger ist: Steht bei Ihnen ein Umzug an? Wenn nein, gehört das Plugin nicht aktualisiert, sondern deaktiviert und gelöscht. Ihre Sicherungen macht es ohnehin nicht — dafür braucht es ein Verfahren, das ohne Klick im Verwaltungsbereich läuft und das regelmässig geprüft wird.
Gehen Sie bei der Gelegenheit die Plugin-Liste einmal von oben nach unten durch. Bei allem, was Sie nicht binnen zehn Sekunden erklären können, lautet die Antwort meistens: weg damit. Ein gelöschtes Plugin bekommt keine Lücken.
Bei den Websites in unserer Wartung machen wir genau das. Und wenn tatsächlich ein Umzug ansteht: Was dabei der Reihe nach zu tun ist, steht in unserer Checkliste für die Migration.
Korrektur vom 11. September
In der ersten Fassung dieses Beitrags stand, die Lücke lasse sich nur mit einem angemeldeten Konto ausnutzen, und eine Firmenwebsite mit wenigen Redaktionskonten sei deshalb kaum gefährdet.
Das war falsch — und es war in die beruhigende Richtung falsch.
Die ausführlichen Analysen vom 3. September beschreiben den tatsächlichen Weg, und sie stimmen darin überein: Der Angreifer braucht kein Konto. Er nutzt eine Funktion, die jedem Besucher offensteht. Wir haben den betreffenden Abschnitt ersetzt.
Damit ändert sich die Einschätzung in zwei Punkten. Betroffen sind nicht nur Webshops und Mitgliederbereiche, sondern auch die reine Firmenwebsite ohne jedes Besucherkonto. Und der Auslöser ist eine Handlung des Betreibers, nicht des Angreifers — wer aktualisiert, bevor er das nächste Mal eine Sicherung einspielt, entschärft die schon eingeschleuste Fracht.
Warum die Funktion, über die das läuft, auf den meisten Websites bis heute offensteht, obwohl sie seit Jahren niemand mehr braucht, haben wir gesondert aufgeschrieben: Die Tür, die seit zwanzig Jahren offen steht.
Plugin-Bestand prüfen lassen