WordPress – ein Follow-up - Brechtholds Blog

WordPress wurde gehackt. Das ist zunächst ein Zustand, keine Ursachenanalyse.

Seit unserem technischen Artikel „Insight wp2shell“ liegen erste öffentliche Opfermeldungen vor. Der BeNe-Betreiber erklärt, dass die beiden WordPress-Core-Schwachstellen für den unbefugten Zugriff genutzt wurden. Unberechtigte Administratoren, nachträglich installierte Plugins und möglicher Datenabfluss passen zum sichtbaren Ende der von uns rekonstruierten Angriffskette. Weitere Meldungen zeigen ähnliche Spuren, sind aber deutlich schwächer dokumentiert.

wp2shell war kein theoretisches Laborproblem. Trotzdem ist nicht jeder derzeit entdeckte WordPress-Hack automatisch wp2shell.

Jetzt gibt es reale Opfermeldungen

Die EKD beschreibt den Sicherheitsvorfall bei BeNe ungewöhnlich deutlich: Die beiden WordPress-Schwachstellen seien für einen unbefugten Zugriff genutzt und dabei unberechtigte Administratorkonten angelegt worden. Nach Betreiberangaben sind mit hoher Wahrscheinlichkeit Daten in größerem Ausmaß aus der Datenbank abgeflossen. Muster und Umfang sprächen mit sehr großer Wahrscheinlichkeit für einen automatisierten Bot-Angriff und nicht für einen gezielten Angriff auf BeNe.

Das ist der bislang belastbarste öffentlich benannte Fall. Es bleibt eine Betreiberfeststellung ohne veröffentlichte Requests, Datenbankauszüge oder Payloads. Aber es ist mehr als ein verdächtiger Scan oder eine bloß verwundbare Installation: Der Betreiber bestätigt den unbefugten Zugriff und ordnet ihn den WordPress-Schwachstellen zu.

Der Borncity-Beitrag zu den ersten wp2shell-Fällen sammelt weitere Meldungen. Ein Betroffener berichtet von einem unbekannten Administrator mit der Adresse wpsvc_59ef9db7ebe0@wordpress-svc.internal und den am selben Tag installierten Plugins Database Repair Assistant und wp2s-606aa615. Zum Zeitpunkt der späteren Prüfung lief die Installation bereits mit WordPress 7.0.2.

Die Artefakte passen zu einer Exploitkette, die am Ende einen Administrator anlegt und über ein Plugin PHP-Code ausführt. Unabhängig bestätigt sind sie bislang nicht. Öffentlich fehlen Plugin-Dateien, Hashes, Serverlogs und Datenbankartefakte. Aus einem detaillierten Leserbericht wird durch häufiges Zitieren noch keine forensische Rekonstruktion.

RCE beschreibt das Ergebnis, nicht den Mechanismus

wp2shell wird meist als Pre-Auth Remote Code Execution bezeichnet. Als Beschreibung der maximalen Schadenswirkung ist das richtig: Ein anonymer Angreifer kann die Kette bis zur serverseitigen PHP-Ausführung treiben. Der erste Request führt aber weder unmittelbar PHP noch ein Betriebssystemkommando aus.

anonymer REST-Batch-Request
→ Route Confusion
→ SQL-Injection
→ gefälschte WordPress-Objekte
→ persistierte oEmbed-/Customizer-Datensätze
→ privilegierter Re-Entry
→ Anlage eines echten Administrators
→ Anmeldung
→ regulärer Plugin-Upload
→ PHP-Ausführung

Die SQL-Injection führt keinen direkten INSERT in wp_users aus. Sie bringt WordPress dazu, manipulierte Objekte weiterzuverarbeiten und eigene Datensätze anzulegen. Über die nachfolgenden Stufen wird schließlich die reguläre REST-API in einem privilegierten Kontext erreicht und ein Administrator erzeugt.

Danach braucht es keine zweite spektakuläre Sicherheitslücke. Ein WordPress-Administrator kann in einer üblichen Single-Site-Konfiguration Plugins installieren und aktivieren. In Multisite-Installationen ist diese Fähigkeit grundsätzlich dem Super-Admin vorbehalten. Das hochgeladene Plugin enthält PHP-Code, den die Anwendung anschließend ausführt. Konfigurationen wie DISALLOW_FILE_MODS, eingeschränkte Dateisystemrechte oder ein kontrolliertes Deployment können diesen letzten Weg zusätzlich begrenzen. In der untersuchten Standardkonfiguration war der reguläre Plugin-Upload verfügbar.

Die RCE folgt aus der erlangten administrativen Berechtigung. Sie ist nicht der unmittelbare Mechanismus der SQL-Injection. Für den Betreiber endet die Kette trotzdem in der vollständigen Übernahme der WordPress-Installation. Die Unterscheidung erklärt, warum neue Administratoren, anschließende Logins und hochgeladene Plugins zu den erwartbaren Spuren gehören.

Die Spuren passen. Eindeutig sind sie nicht.

Ein unbekannter Administrator plus verdächtiges Plugin passt gut zu wp2shell. Beides beweist wp2shell trotzdem nicht. Sobald ein Angreifer administrative Rechte oder PHP-Ausführung besitzt, sehen unterschiedliche Angriffe am Ende schnell gleich aus.

Der Einstieg kann über wp2shell erfolgt sein. Er kann aber ebenso über ein verwundbares Plugin oder Theme, gestohlene Zugangsdaten, eine übernommene Session, eine bereits vorhandene Webshell, den Hosting-Kontext oder einen kompromittierten Deployment-Zugang erfolgt sein. Danach stehen dem Angreifer dieselben WordPress-Funktionen zur Verfügung: Benutzer anlegen, Plugins installieren, Dateien verändern und weiteren Code nachladen.

Post-Exploitation-Artefakte beweisen eine Kompromittierung. Sie beweisen nicht automatisch deren Eintrittspfad.

Auch wiederkehrende .htaccess-Dateien, überschriebene index.php-Dateien oder erneut auftauchende Schadkomponenten ändern daran nichts. Sie sprechen für Persistenz, einen verbliebenen Wiederzugriff oder eine unvollständige Bereinigung. Ohne zeitliche Verbindung zu den wp2shell-spezifischen Requests und Datenbankwirkungen belegen sie wp2shell nicht als Initial Access.

Diesen Endzustand hatten wir schon – ohne wp2shell

Dass Administratoren, Plugins und mehrschichtige Persistenz nicht automatisch eine Core-RCE bedeuten, haben wir bereits im Mai in „Der gefährlichste Angriff ist oft schon eingeloggt“ an einem anderen realen WordPress-Vorfall beschrieben.

Dort sprach die verfügbare Telemetrie eher für die Nutzung funktionierender Zugangsdaten. Auf verdächtige erfolgreiche Anmeldungen folgten Admin-Pfade, REST-Nonce, Plugin-Bereich, Upload, Aktivierung und Dateimanager-Funktionen. Der untersuchte Schadcode enthielt außerdem WordPress-native Benutzeranlage sowie Datenbank- und Trigger-Logik als Persistenz- beziehungsweise Wiederzugriffspfad.

Der sichtbare Endzustand ähnelt jenen Spuren, die nun im Umfeld von wp2shell gemeldet werden: Administratoren, Plugins, PHP-Code und mehrere Wiederzugriffswege. Der wahrscheinliche Eintrittspfad war jedoch ein anderer. Der Fall zeigt, warum Rückwärtsdiagnose aus Post-Exploitation-Spuren schnell schiefgeht.

Der Core ist nur eine der Türen

WordPress ist kein isoliertes Binärpaket, sondern ein über Jahre gewachsenes Ökosystem. Zum Core kommen Plugins, Themes, individuelle Anpassungen, Zugangsdaten, Sessions, Datenbank, Dateisystem, Cronjobs, externe Integrationen und der Hosting-Kontext. Ein erheblicher Teil der alltäglichen Angriffsfläche liegt außerhalb des Core.

Eine anonym ausnutzbare Kette in den damals verwundbaren WordPress-Core-Versionen, die in einer Standardinstallation bis zur Administratoranlage und PHP-Ausführung reicht, ist deutlich ungewöhnlicher als eine weitere Schwachstelle in einem Plugin oder Theme. Schwachstellendetails und PoC waren öffentlich. BeNe bestätigt einen realen, nach Betreiberangaben automatisierten Angriff. Providerhinweise und weitere Meldungen zeigen passende Spuren.

BeNe spricht für automatisierte Ausnutzung. Die IONOS-Hinweise und weitere, schwächer dokumentierte Meldungen sind mit einer breiteren Nutzung vereinbar, erlauben aber keine belastbare Quantifizierung. Aus wenigen Berichten wird weder eine lückenlose Weltkampagne noch ein bloßes Missverständnis.

WordPress 7.0.2 ist kein forensischer Freispruch

Der gemeldete IONOS-Fall ist auch deshalb interessant, weil die Installation bei der Prüfung bereits WordPress 7.0.2 anzeigte. Das widerspricht der technischen Gegenprobe nicht. Der aktuelle Versionsstand verrät zunächst nur, was zum Prüfzeitpunkt installiert beziehungsweise angezeigt wurde. Er verrät nicht, welche Version beim Initial Access lief.

Gegen einen intakten, hashverifizierten WordPress-7.0.2-Core ließ sich die zuvor positiv validierte wp2shell-Kette mit denselben entscheidenden Payloads nicht mehr ausführen. Patchanalyse und Gegenprobe bestätigen damit, dass genau dieser untersuchte Pfad geschlossen ist. Sie beweisen nicht, dass jede denkbare abweichende Exploitvariante ausgeschlossen wäre.

Wer auf einem heute mit 7.0.2 laufenden System passende Artefakte findet, muss deshalb mindestens drei Fragen trennen:

Patch-Timeline: Wurde 7.0.2 erst nach der Kompromittierung installiert?
Core-Integrität: War das Update vollständig, und waren die Core-Dateien beim fraglichen Zugriff tatsächlich unverändert?
Alternativer Pfad: Kam der Angreifer über ein Plugin, Theme, Zugangsdaten, eine bestehende Webshell, den Hosting-Kontext oder eine bislang nicht untersuchte Exploitvariante?

Ein Core-Update entfernt außerdem keine bereits angelegten Benutzer, hochgeladenen Plugins, Webshells, Datenbanktrigger oder gestohlenen Zugangsdaten. Patchen schließt einen Einstieg. Es stellt nicht rückwirkend Vertrauen her.

Was eine wp2shell-Zuordnung tragen muss

Zuerst muss die Kompromittierung selbst belegt werden. Unbekannte Administratoren, nicht autorisierte Plugins, Webshells, veränderte Dateien, ungewöhnliche Prozesse und ausgehende Verbindungen können dafür reichen. Die Frage nach dem Initial Access beantworten sie noch nicht.

Wiederkehrende Benutzernamen, Maildomänen, Plugin-Namen, Dateipfade und identische Hashes können Fälle miteinander verbinden. Der einzelne öffentlich berichtete Wert wp2s-606aa615 macht das Schema wp2s-<hex> aber noch nicht zu einem bestätigten kampagnenweiten IOC.

Eine starke Zuordnung zu wp2shell entsteht durch eine zeitlich konsistente Kombination möglichst vieler Stufen: anonyme Requests auf /wp-json/batch/v1 oder ?rest_route=/batch/v1, passende Payload-Merkmale, Auffälligkeiten in oembed_cache und customize_changeset, Administratoranlage, nachfolgender Login und Plugin-Upload. Exploit-spezifische Requests und Datenbankwirkungen wiegen dabei schwerer als generische Post-Exploitation-Spuren. Ein fehlender Plugin-Upload widerlegt den Initial Access nicht.

Die IONOS-Hinweise zu wp2shell nennen genau solche Prüfrichtungen. Der Provider bietet Kunden, bei deren Installation Auffälligkeiten festgestellt wurden, außerdem die Wiederherstellung eines Backups vom 16. Juli an. Öffentlich nennt IONOS jedoch weder Fallzahlen noch die konkrete Erkennungslogik. Nützlich, aber keine veröffentlichte Forensik.

Ein Scanner innerhalb von WordPress kann WordPress nicht freisprechen. Ein Prüfplugin kann belastbare Teilbefunde und Hunt Leads liefern. Aus derselben Vertrauenszone kann es aber keinen forensischen Clean-Status attestieren.

Das Plugin läuft im selben PHP- und WordPress-Kontext wie mögliche Malware. Ein Angreifer mit PHP-Codeausführung – oder mit Administratorrechten in einer Konfiguration, die Codeinstallation zulässt – kann seine Sicht manipulieren, Artefakte außerhalb seiner Reichweite ablegen oder den Scanner gezielt umgehen.

Nach bestätigter Codeausführung gehören Webroot, Datenbank, Logs, Benutzerkonten, Sessions, Secrets, Cronjobs, Hosting-Nachbarn und ausgehende Verbindungen in die Untersuchung. Verdächtige Artefakte sollten vor dem Löschen gesichert werden. Wo die Vertrauensbasis fehlt, ist ein Neuaufbau aus vertrauenswürdigen Quellen mit anschließender Rotation der relevanten Zugangsdaten belastbarer als kosmetisches Aufräumen im bereits kompromittierten System.

Der Exploit war real. Die Zuordnung bleibt Arbeit.

wp2shell war öffentlich dokumentiert, wurde von uns unter den beschriebenen Laborbedingungen praktisch reproduziert und offenbar automatisiert gegen erreichbare WordPress-Systeme eingesetzt. Die ersten Opfermeldungen passen technisch zur bekannten Kette. Das sollten wir weder kleinreden noch mit dem Hinweis auf das ohnehin verwundbare WordPress-Ökosystem wegmoderieren.

Nicht jeder fremde Administrator, jedes dubiose Plugin und jede wiederkehrende index.php beweist wp2shell. Diese Spuren zeigen, dass jemand drin war. Wie er hineinkam, beantworten erst Requests, Datenbankartefakte, Integritätsprüfung und eine belastbare Patch-Timeline.

„Wir haben 7.0.2 installiert, also kann nichts passiert sein“ ist falsch. „Wir haben einen fremden Administrator gefunden, also war es wp2shell“ ist ebenfalls falsch.

Zwischen diesen beiden bequemen Irrtümern liegt Incident Response. Leider ist sie arbeitsintensiver als eine Versionsnummer oder ein Malware-Plugin. Dafür hat sie gelegentlich den Vorteil, tatsächlich etwas zu erklären.