Seit Anfang Oktober läuft eine Angriffswelle gegen zwei WordPress-Erweiterungen. Die wichtigere davon ist Ninja Forms mit über 500 000 aktiven Installationen; betroffen sind die Fassungen bis 3.15.3, behoben ist es in 3.15.4. Die zweite ist WPC Product Bundles for WooCommerce mit rund 30 000 Installationen.
Wer eines davon einsetzt, aktualisiert jetzt. Der Rest des Beitrags erklärt, warum dieser Fall auch für alle anderen lehrreich ist.
Der Angriff beginnt mit einem ausgefüllten Formular
Ein Angreifer schickt eine ganz gewöhnliche Formulareinsendung ab. Keine Anmeldung, kein Trick an der Anmeldung vorbei — er benutzt das Formular so, wie es gedacht ist.
Im Textfeld bricht er aus der Darstellung aus und hinterlässt dort Programmcode.
Danach passiert zunächst nichts. Der Code liegt in der Datenbank wie jede andere Einsendung auch.
Ausgelöst wird er von Ihnen
Der Code läuft in dem Moment, in dem jemand mit Administratorrechten die Einsendung im Verwaltungsbereich öffnet, um sie zu lesen.
Dann läuft er in der angemeldeten Sitzung dieser Person. Es wird kein Passwort gestohlen und keine Anmeldung umgangen — die bestehende Sitzung genügt, und sie gehört jemandem, der alles darf.
Das ist dasselbe Muster wie bei der Elementor-Lücke im August: Die Lücke wartet, bis die richtige Person hinsieht. Die gefährliche Handlung ist eine, die man ohnehin täglich macht — eine Einsendung lesen, einen Upload ansehen, eine Liste öffnen.
Was danach angelegt wird
Das Skript erzeugt ein neues Administratorkonto. Der Benutzername stammt aus einer kurzen Wortliste und klingt nach Werkzeug statt nach Person: support, updater, maintenance.
Dann kommt der Teil, der diesen Fall von anderen unterscheidet.
Das Skript legt zusätzlich ein sogenanntes Must-Use-Plugin ab — eine Erweiterung, die WordPress ohne Zutun lädt und die in der normalen Plugin-Liste nicht auftaucht. Diese Erweiterung hängt sich in die Datenbankabfragen und filtert das neue Konto aus der Benutzerübersicht heraus.
Das Konto existiert. Es hat alle Rechte. Und wer im Verwaltungsbereich unter «Benutzer» nachsieht, findet es nicht.
Vier Wege zurück
Die Angreifer belassen es nicht bei einem Zugang. Patchstack zählt vier:
ein sichtbares Administratorkonto
das versteckte Konto hinter dem Must-Use-Plugin
eine Anmeldeadresse mit Token, /wp-login.php?_wplogin=…
ein Datei-Manager-Plugin, das keine Anmeldung verlangt
Wer nur den sichtbaren Benutzer löscht, hat drei Wege übersehen. Das ist der Grund, warum eine Bereinigung nach so einem Fall mehr ist, als einen Haken zu entfernen.
Wie man nachsieht
Der wichtigste Punkt zuerst: Die Benutzerübersicht im Verwaltungsbereich taugt dafür nicht. Genau sie wird ja manipuliert.
Nachsehen muss man eine Ebene tiefer, direkt in der Datenbank. Diese Abfrage listet alle Konten mit Administratorrechten, unabhängig davon, was die Oberfläche anzeigt:
SELECT u.user_login, u.user_email, u.user_registered
FROM wp_users u
JOIN wp_usermeta m ON m.user_id = u.ID
WHERE m.meta_key = 'wp_capabilities'
AND m.meta_value LIKE '%administrator%'
Vergleichen Sie das Ergebnis mit dem, was Ihnen WordPress anzeigt. Jede Zeile, die nur in der Datenbank steht, ist eine zu viel.
Dazu kommen drei Stellen im Dateisystem, die in den beobachteten Fällen auffielen:
wp-content/mu-plugins/class-wp-query-*.php
wp-content/mu-plugins/class-wp-token-validate.php
wp-content/plugins/wp-smart-thumbnails/
Und zwei Einträge in der Optionstabelle: fz_emer_done_v1 und fz_emer_login_tokens.
Ein Hinweis zur Einordnung: Diese Namen stammen aus den bisher beobachteten Fällen. Sie können sich ändern — der Mechanismus bleibt. Wer nur nach diesen Zeichenketten sucht und nichts findet, hat damit noch keine Entwarnung.
Als weitere Anhaltspunkte nennt Patchstack Administratorkonten mit einer Adresse bei wordpress.org sowie Anfragen mit dem Parameter _wplogin in den Serverprotokollen.
Was daraus folgt
Ein verwaistes Plugin ist kein harmloses Plugin. Ninja Forms steht auf vielen Seiten, weil irgendwann jemand ein Kontaktformular brauchte. Dass es seither keiner mehr angefasst hat, macht es nicht ungefährlicher — es macht nur weniger wahrscheinlich, dass jemand das Update bemerkt.
Und die eigene Oberfläche ist keine Quelle der Wahrheit. Wer Administratorrechte auf einem Server hat, kann auch bestimmen, was die Oberfläche zeigt. Das ist der unbequeme Teil dieses Falls, und er gilt über WordPress hinaus: Nach einem Vorfall wird nicht im Programm nachgesehen, sondern darunter.
Wir haben im August einen Fall beschrieben, bei dem alles aktuell war und trotzdem eine Hintertür entstand. Dieser hier ist das Gegenstück: Das Update war verfügbar, und entscheidend ist, wer es eingespielt hat, bevor jemand eine Einsendung öffnete.
Wenn Sie nicht sicher sind, was auf Ihrer Website installiert ist und ob dort ein Konto steht, das niemand angelegt hat: Das sehen wir mit Ihnen durch.