Phishing-Hack unter WordPress via xmlrpc.php und zusätzlichen Administratoren ohne Email-Eintrag

Thema: Ubuntu – MariaDB – WordPress – Apache – CleanBlogg Theme.

Betrifft WordPress bis Version mindestens inklusive 6.4.2. Letztes Update 24. Jänner 2024.

Vermutlicher ursprünglicher Zugriff über xmlrpc.php. Dadurch Anlegen von zusätzlichen Administratoren unter den Usern und verteilen von schwer lesbaren *.php und *.ccss Dateien, die sich anscheinend durch Aufrufen von aussen auch selbst duplizieren und verteilen. Dies alles scheint mit dem User www-data zu erfolgen. Somit bleibt das System aktiv solange nicht alle Dateien gefunden wurden. WordPress-Instanzen mit wie unten ausgeführten Schritten bleiben sauberer als solche wo dies nicht konsequent erfolgt ist. Einzelne *.php Dateien werden auf ausführbar gesetzt um so lokal Befehle ausführen zu können.

Stand 24.  Jänner 2024: Ich habe vor 3 Tagen alle unten angeführten Sicherungsschritte für 6 unterschiedliche WordPress-Instanzen umgesetzt, inkl. dem Löschen der Schaddateien, dies erfolgt zum Teil per shell-Script. Nun scheinen keine neuen Dateien erzeugt zu werden und Bots versuchen Passwörter zu ändern. Es scheint, als wären sie auf den Anfang zurückgeschmissen worden. Die Zugriffe auf xmlrpc.phpbleiben sehr hoch.

Diese Seite erhebt keinen Anspruch auf Vollständigkeit oder Richtigkeit!

Im Backend sichtbare Zeichen

Es werden WordPress-User mit Administrationsrechten unter den Benutzern angelegt. Sie haben keinen Email-Adresse vermerkt, sie sind also ausserhalb des Backends angelegt worden. Ende 2023 und Anfang 2024 heissen diese User meist wp_update-XXXXXXXX oder deleted-XXXXXXX, aber auch andere Namen kommen vor.

Weiters kann es sein, dass keine Beitrage angelegt oder geändert werden können. Medien können hingegen hochgeladen, aber nicht geändert werden weil die Datei wp-admin/post.php Fehler generiert, ohne dass diese direkt verändert ist. Die Fehler laufen über php-includes. Dazu unten mehr.

Mit dem Hack aufräumen

Zuerst das Anlegen falscher Benützer unterbinden. Es scheint, dass über einen externen Zugriff auf die Datei xmlrpc.php erfolgt. Diese wird für manche Plugins benötigt (wie Jetpack), stellt aber grundsätzlich immer eine Gefahrenquelle dar. Man kann das verhindern, indem man den externen Zugriff auf xmlrpc.php in der Definition des Virtual Hosts sperrt. Es schadet auch nicht, wenn man das auch für wp-config.php macht (wo das Datenbank-Passwort lesbar liegt).

# Block WordPress xmlrpc.php requests
<Files xmlrpc.php>
order deny,allow
deny from all
</Files>
<Files wp-config.php>
order deny,allow
deny from all
</Files>

Vergleiche auch:
https://wordpress.org/support/topic/unknown-user-created-2/

Weitere Symptome und Dateien die zu ändern/entfernen sind hier unten. (SH) bedeutet, dass ich ein dafür ein shell-Script zu generell löschen einsetze.

1. Eine zusätzlich eingefügte Anweisung über ca. 5 Zeilen in der Datei wp-content/plugins/akismet/akismet.php. Diese ersten Zeilen löschen. Diese Datei ist auch executable gesetzt, das gehört geändert, siehe Punkt 11 unten. Die Datei einem normalen Systemuser geben und nicht www-data. Das Plugin lässt sich somit nicht mehr automatisch und nicht im Backend updaten.
2. (SH) Eine irgendwo liegende *.ccss Datei, die verhindert, dass man Posts anlegen und editieren kann. Diese Dateien im Basisverzeichnis mit find . -type f -name '*.ccss' finden und löschen. Die Datei ist jedenfalls unter akismet.php aufgerufen. Um weitere dieser Aufrufe zu suchen, kann man diesen Befehl nutzen: grep -RInw '/path/to/wordpress/' -e 'ccss' > ../temp.txt, er dauert bloss recht lang bei der Ausführung und die Ausgabedatei darf nicht die Suche umfassen.
3. Datei-Rechte strenger setzen. Problemantisch ist der Ordner wp-admin/includes den es zum Update von Plugins unter dem User www-data braucht.
4. Passwörter ändern: alle Admins unter WordPress aber auch jene der Datenbank und dort auch das Root-Passwort (siehe MariaDB statt MySQL unter Ubuntu unten). Es ist nicht erwiesen, dass die Passwörter auch gehackt/genutzt wurden, aber schaden tut dies nach einiger Zeit sowieso nicht.
5. Ggf. WordPress Updaten.
6. Zusätzliche Ordner die meist mit Ziffern (8-stllig, z.B. oo845q67) beginnen unter wp-content/plugins/ und wp-content/themes/. Innerhalb der einzelnen Ordner für Plugins und Themen können auch zusätzliche Dateien mit schwer lesbaren Inhalten liegen. Alle auffälligen löschen. Ggf. Plugins und Themen löschen und neu installieren. Siehe auch weiter unten.
7. (SH) *.php Dateien direkt unter unter wp-content/, wp-content/plugins/ und wp-content/themes/ sind zu löschen. Ebenso rekursiv unter wp-content/languages/.
8. (SH) Unter wp-content/uploads/ liegen in den Ordner verstreut einzelne *.php Dateien, die zu Phishing-Sites gehören. Dort mit find . -type f -name '*.php' suchen und löschen.
9. Per Name bekannte und zu löschende Dateien, in allen möglichen Bereichen zu finden:
   1. (SH) Die Dateien style.php und ajax.php und js.php sowie *.js.php sind immer und überall löschen.
   2. Die Datei admin-ajax.php immer ausser unter wp-admin/admin-ajax.php.
   3. Die Datei options.php immer ausser unter wp-admin/, wp-admin/includes/, wp-content/plugins/duplicate-post/src/admin/views/, wp-content/plugins/subscribe2/include/, wp-content/plugins/duplicate-post/, wp-content/plugins/duplicate-post/src/admin/,wp-content/plugins/duplicate-post/src/admin/views/ und ggf. anderem Plugins oder Themen.
   4. Die Datei image.php immer ausser unter wp-admin/includes/, wp-includes/blocks/, wp-content/themes/activello/ , wp-content/themes/twentysixteen/ und ggf. anderem Plugins oder Themen.
   5. Die Datei css.php immer  löschen ausser in bestimmten Plugins wie zb. shortcodes-ultimate.
   6. Die Datei themes.php immer löschen ausser in wp-admin/ und wp-admin/network/.
   7. Die Datei wp-login.php immer löschen ausser im Basisverzeichnis.
10. Weitere überflüssige Dateien sucht man nun am Besten in den den Server-Error-Logs. Wir haben oben viele Dateien gelöscht, einzelne Zugriffe von aussen gerieren nun Fehler, die hier erscheinen. Unter Ubuntu findet man die Fehler unter /var/log/apache2/my-server-error-log. Ggf. auch unter my-server-error-log.1, my-server-error-log.2.gz etc. schauen. Meist wird eine Funktion mit einem sehr komplizierten Namen aufgerufen welche hier Fehler generiert: PHP Fatal error: Uncaught Error: Call to undefined function \xebe85\xcdbd7dm\x88cj\xb62770\xb2\xc7c7p\xc37E529\xaf9,123\x97-0\xfb8>-`k\xa7d-8c>f2\x17302\x9737p\x13:962\x16$\xc9\xc0=\xf2<b-4a\x06;\xfdbd7\xc4-3c'f2770\xf5\x87\xfe7pC75\xf52\x964S!+\xfd2\xa2+5d\xd8\xdf() in [my-server]/wp-includes/blocks/latest-posts/tshrjquv.php:100 [...]. Namen können lauten: b9e6fac8.php, ewfeoryh.php, kbafrmzh.php, 80b549ab.php,  a2495acf.php, metrgrbl.php, fc9fe9bb.php. Sie sind also 8-stellig.
11. Unter wp-includes ist die Datei load.php auf ausführbar gesetzt: rwxrwxr-x. Das ist nur ein Zeichen des Hacks und ohne Auswirkung. Besser auf rw-rw-r-- zurücksetzen (chmod a-x laod.php). Dort kann in den ersten Zeilen auch Schadecode zu finden sein.

Russische IP-Adressen versuchen Passwortänderungen zu initieren