WordPress gehackt: richtig bereinigen und das Einfallstor finden

Ursache

Eine Hintertür erzeugt Seiten nur für den Suchmaschinen-Crawler und liefert allen anderen Besuchern normale Inhalte aus. Der Code sitzt häufig in einer umgeschriebenen .htaccess, in der functions.php des Themes oder in einer unauffällig benannten Datei in wp-includes und lädt die Inhalte von einem fremden Server nach. Google beschreibt genau diese Kategorie: Ein Hacker hat neue Seiten mit Spam-Wörtern oder Links auf eurer Seite erstellt.

Lösung

Prüfe die Seite mit dem URL-Prüftool der Search Console, das die Seite so abruft wie der Googlebot. Sichere danach .htaccess und Theme-Dateien, vergleiche den Core mit wp core verify-checksums und suche nach Dateien, die in den letzten Wochen geändert wurden. Nach der Bereinigung und dem Schließen des Einfallstors beantragst du die Überprüfung mit einer Beschreibung dessen, was gefunden und entfernt wurde.

Ursache

Eingeschleuster JavaScript-Code prüft Referrer, Gerät oder ein Cookie und leitet nur bestimmte Besucher um, damit die Betreiber es möglichst lange nicht bemerken. Der Code liegt in Theme-Dateien wie header.php oder footer.php, in einem Plugin oder in der Datenbank, etwa in den Optionen siteurl und home, in Widgets oder direkt in Beiträgen.

Lösung

Rufe die Seite aus einem privaten Browserfenster über einen Suchmaschinenlink und vom Smartphone auf, um das Verhalten zu reproduzieren. Durchsuche die Datenbank nach script-Tags und verschleierten Zeichenketten in wp_options, wp_posts und wp_postmeta; mit WP-CLI geht das über wp db search. Prüfe die Werte von siteurl und home. Danach leere alle Caches, auch die des Hosters und eines CDN.

Ursache

Entweder wurden Zugangsdaten gestohlen, über Phishing, einen infizierten Rechner oder ein wiederverwendetes Passwort aus einem fremden Datenleck, oder ein Plugin mit einer Schwachstelle erlaubte es, ohne Anmeldung ein Konto mit Administratorrechten zu erzeugen. Meist legt der Angreifer ein zweites, unauffälliges Konto an.

Lösung

Liste alle Konten mit administrativen Rechten mit wp user list --role=administrator und gleiche sie mit den tatsächlichen Personen ab; entferne fremde Konten und setze bei allen übrigen das Passwort zurück. Ersetze die Sicherheitsschlüssel in der wp-config.php, damit alle Sitzungen enden. Prüfe auch Konten mit anderen Rollen, denn ein Redakteurskonto mit Upload-Recht genügt für viele Angriffe. Aktiviere für alle Konten eine zweite Anmeldestufe.

Ursache

Ein hochgeladenes PHP-Skript, meist im Upload-Verzeichnis oder in einem Plugin-Ordner, arbeitet als Mailer oder als Werkzeug für Angriffe auf Dritte. Das Upload-Verzeichnis ist beschreibbar, weil WordPress dort Bilder ablegt, und wenn der Server dort PHP ausführt, genügt eine einzige Upload-Lücke. Die WordPress-Dokumentation weist auf die Sperrlisten-Folge ausdrücklich hin, weil der Mailversand oft über denselben Server läuft.

Lösung

Lass dir vom Hoster die Protokolle und die beanstandeten Dateien nennen, denn er sieht den ausgehenden Verkehr. Suche alle PHP-Dateien unterhalb von wp-content/uploads und entferne sie; dort gehört keine hin. Unterbinde die Ausführung von PHP in diesem Verzeichnis per Serverkonfiguration. Prüfe, ob weitere Installationen auf demselben Account liegen, denn eine infizierte Nachbarinstallation steckt die bereinigte wieder an.

Ursache

Eine Hintertür wurde übersehen oder das Einfallstor nie geschlossen. Typische Verstecke sind ein Plugin, das nicht in der Plugin-Liste erscheint, eine Datei im Verzeichnis mu-plugins, das WordPress ohne Aktivierung lädt, ein Eintrag bei den geplanten Aufgaben, der den Code nachlädt, ein zweites Administratorkonto oder ein weiterhin verwundbares Plugin.

Lösung

Gehe das Dateisystem vollständig durch statt gezielt: Core mit wp core verify-checksums, Plugins mit wp plugin verify-checksums --all, dazu mu-plugins, das Upload-Verzeichnis und das Wurzelverzeichnis mit der Option, die auch fremde Dateien dort meldet. Prüfe die geplanten Aufgaben mit wp cron event list auf unbekannte Einträge. Vergleiche die Zugriffsprotokolle beider Vorfälle, dann zeigt sich das Einfallstor meist an derselben URL. Lass die Rechner der Redaktion prüfen, bevor neue Passwörter gesetzt werden.

Ursache

Jeder Angreifer mit Ausführungsrechten auf dem Server kann die Datenbank mit den Zugangsdaten aus der wp-config.php auslesen. Ob er es getan hat, lässt sich aus den Spuren oft nicht sicher sagen. Für die DSGVO zählt aber bereits die Möglichkeit eines unbefugten Zugriffs auf personenbezogene Daten als Verletzung, die zu bewerten ist.

Lösung

Beziehe die Datenschutzbeauftragte oder einen Juristen sofort ein, nicht nach der Bereinigung. Art. 33 DSGVO verlangt die Meldung an die Aufsichtsbehörde binnen 72 Stunden nach Bekanntwerden, es sei denn, die Verletzung führt voraussichtlich nicht zu einem Risiko für die Betroffenen; diese Einschätzung muss begründet und dokumentiert sein. Halte fest, welche Tabellen welche Daten enthalten, wann der Zugriff frühestens möglich war und welche Belege für oder gegen einen Abfluss vorliegen.