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ück geschmissen worden. Die Zugriffe auf xmlrpc.phpbleiben sehr hoch.

Stand 20.  Juni 2024: Die 6 WordPress-Instanzen weisen unterschiedliche Zustände auf. Nirgends sind unerwünscht User angemeldet worden und in allen Instanzen blieb der externe Zugriff auf xmlrpc.php gesperrt. Neu ist die Datei radio.txt, welche an unterschiedlichsten Stellen auftaucht (auch ausserhalb der WordPress-Instanzen) und nur einen ca. 20-stellige Zeichenabfolge umfasst.

• Eine ist mit den unten angeführten Schäden weiterhin verseucht, es ist jene welche die meisten Plugins einsetzt.
• In vier von sechs liegen unten genannte Schaddateien vor. Deren Anzahl ist gering, es kann theoretisch um vergessene Dateien der Säuberung von Jänner sein (ausgehend davon, dass sich die Schaddateien selber duplizieren, können Ordner befallen sein, die man zuvor überprüft hat).
• Zwei von vier haben ein neues Schadbild, nämlich Redirects von der Startseite zu Phishing- und Porno-Seiten, siehe letzten Abschnitt unten.  Der Zusammenhang mit dem Angriff über xmlrpc.php ist unklar.

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>cd ,,
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. (SHOK) 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-stellig, 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. (SHOK) *.php Dateien direkt unter unter wp-content/, wp-content/plugins/ und wp-content/themes/ sind zu löschen. Ebenso rekursiv unter wp-content/languages/, wp-content/upgrade-temp-backup/,  wp-content/upgrade/, wp-content/cache/ und wp-content/uploads/.
8. (SHOK) Unbekannte, meist 8-stellige *.php Dateien rekursiv unter unter wp-content/ sind zu löschen, ausser natürlich bekannte Plugins-und Themen-Dateien.
9. Per Name bekannte und zu löschende Dateien, in allen möglichen Bereichen zu finden:
   1. (SHOK) Die Dateien style.php, ajax.php, radio.txt und js.php sowie *.js.php sind immer und überall löschen.
   2. (SHOK)Die Datei wp-login.php immer löschen ausser im Basisverzeichnis.
   3. (SHOK) Die Datei admin-ajax.php immer ausser unter wp-admin/admin-ajax.php.
   4. (SHOK) Die Datei profile.php immer ausser unter wp-admin/user/, wp-admin/network/ und wp-admin/.
   5. (SHOK)Die Datei themes.php immer löschen ausser in wp-admin/ und wp-admin/network/.
   6. (SHOK) 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.
   7. Die Datei.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. anderen Plugins oder Themen.
   8. Die Datei css.php immer  löschen ausser in bestimmten Plugins wie zb. shortcodes-ultimate.
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.

Die oben mit “(SHOK)” können per Shellscript so gelöscht werden:

find [PATH]/wp-content -maxdepth 1 -type f -name  '*.php' -exec rm {} +
find [PATH]/wp-content/plugins -maxdepth 1 -type f -name  '*.php' -exec rm {} +
find [PATH]/wp-content/themes -maxdepth 1 -type f -name  '*.php' -exec rm {} +
find [PATH]/wp-content/upgrade-temp-backup -type f -name  '*.php' -exec rm {} +
find [PATH]/wp-content/cache -type f -name  '*.php' -exec rm {} +
find [PATH]/wp-content/upgrade -type f -name  '*.php' -exec rm {} +
find [PATH]/wp-content/languages -type f -name  '*.php' -exec rm {} +
find [PATH]/ -type f -name '*.js.php'  -exec rm {} +
find [PATH]/ -type f -name 'js.php'  -exec rm {} +
find [PATH]/ -type f -name 'style.php'  -exec rm {} +
find [PATH]/ -type f -name 'ajax.php'  -exec rm {} +
find [PATH]/ -type f -name '*.ccss'  -exec rm {} +
find [PATH]/wp-content/uploads/ -type f -name '*.php'  -exec rm {} +
find /home/aw/www/sites/ -type f -name  'radio.txt' -exec rm {} +
find [PATH]/wp-content/ -regextype sed -regex '.*/[0-9a-z]\{8\}\.php' -not -name "activate.php" -not -name "comments.php" -not -name "category.php" -not -name "settings.php" -not -name "autoload.php" -not -name "payments.php" -not -name "checkout.php" -not -name "features.php" -not -name "nist*.php" -not -name "qr*code.php" -not -name "qrconfig.php" -not -name "donation.php" -not -name "function.php" -not -name "browscap.php" -not -name "advanced.php" -not -name "upgrades.php" -not -name "tracking.php" -not -name "singular.php" -not -name "patterns.php" -not -name "overview.php" -not -name "watchers.php"  -not -name "carousel.php"  -not -name "infinity.php" -not -name "markdown.php"  -not -name "devicepx.php" -not -name "sitemaps.php" -not -name "descript.php" -not -name "bandcamp.php" -not -name "gravatar.php" -not -name "facebook.php" -not -name "mixcloud.php" -not -name "twitchtv.php" -not -name "archives.php" -not -name "sitemaps.php" -not -name "blogroll.php" -not -name "nextdoor.php" -not -name "calendly.php" -not -name "subpages.php" -not -name "tonesque.php" -not -name "debugger.php" -not -name "checkbox.php" -not -name "template.php" -not -name "siblings.php" -not -name "document.php" -not -name "lightbox.php" -not -name "patterns.php" -not -name "overview.php" -not -name "lightbox.php" -exec rm {} +
find [PATH]/ -type f -name 'admin-ajax.php' -not -path '*wp-admin/admin-ajax*' -exec rm {} +
find [PATH]/ -type f -name 'profile.php' -not -path '*wp-admin/user/profile*' -not -path '*wp-admin/network/profile*' -not -path '*wp-admin/profile*' -exec rm {} +
find [PATH]/ -type f -name 'image.php' -not -path '*wp-admin/includes/image*' -not -path '*wp-includes/blocks/image*' -not -path '*wp-content/themes/activello/image*' -not -path '*wp-content/themes/*teen/image*' -exec rm {} +
find [PATH]/ -type f -name 'themes.php' -not -path '*wp-admin/themes*' -not -path '*wp-admin/network/themes*' -exec rm {} +
find [PATH]/ -type f -name 'wp-login.php' -not -path '[PATH]/wp-login*' -exec rm {} +

Redirect-Hacks

Seit Mai 2024 tauchen Redirects zu Phishing- und Porno-Seiten direkt ab der Startseite auf. Der Code liegt in Widgets. Man findet sie im Quellcode wenn man nach dem Tag <aside> sucht und darin verschlüsselter JavaScript-Code zu finden ist. <aside>-Tags mit lesbaren Inhalt sind eure Footer etc. Entfernen geht über das Backend unter Design>Widgets. Mit der Maus über die Widgets fahren, es erscheint dann ein Rahmen und Editiermöglichkeiten. Wenn der Rahmen völlig leer erscheint, so verbirgt sich darunter Schadcode. Diese Widgets löschen (ancklicken > drei Punkte > Löschen). Suche danach auch in nicht von dir genutzten Widget-Bereichen oder unter archivierte Widgets!

Der Zusammenhang mit dem xmlrpc.php-Hack ist nicht klar. Auffällig ist, dass bei den betroffen WordPress-Instanzen das Plugin Slimstat im Backend nicht löschbar ist und dass einen Order wp-content/uploads/wp-slimstat gibt. Beide kann man nur mit SSH-Zurgiff löschen. Ebenfalls auffällig ist, dass es nur beim Theme (Design) Activello Redirects verursacht, obwohl unter CleanBlogg der gleiche Code keine Redirects auslöst.

Russische IP-Adressen versuchen Passwortänderungen zu initieren