Wie kann man WordPress Schadcode finden und daraufhin entfernen? In wpDiscuz gibt es aktuell eine kritische Sicherheitslücke. Jeder, der das Plugin in der entsprechenden aktuellen Version einsetzt ist damit gefährdet.
Zehntausende WordPress-Websites mit dem Plugin wpDiscuz könnten Schadcode auf Web-Server lassen.
https://www.heise.de/news/Kritische-Luecke-mit-Hoechstwertung-in-WordPress-Plugin-wpDiscuz-4858657.html
Betroffen sind die Versionen 7.0.0 bis 7.0.4. […] Wer wpDiscuz verwendet, der sollte dringend Version 7.0.5 einspielen, um die Sicherheitslücke zu schließen.
https://t3n.de/news/kritische-sicherheitsluecke-mehr-1305308/
Wie habe ich die Infektion festgestellt?
Beim zufälligen anschauen der Webserver Log Dateien sind mir kryptische Dateinamen aufgefallen. Die Dateinamen hießen beispielsweise bscrkehz.php oder auch fwm7xypo.php. Diese Dateien waren auch tatsächlich auf meinem Webserver vorhanden. Da alle meine Webseiten unter einem einzelnen Nutzer laufen, konnte sich die Malware über alle meine Domains verteilen. Betroffen waren dabei nicht nur WordPress Installationen, sondern auch statische PHP Dateien, welche ich selbst programmiert hatte. Teilweise wurden nicht nur neue Dateien mit den erwähnten kryptischen Dateinamen neu erstellt, sondern auch bestehende Dateien um einen Schadcode erweitert.
Beispielshafte Datei mit Schadcode
Der Schadcode war irgendein hochgradig verschachteltes Geflecht. Nach etwas Entschlüsselung bin ich auf folgende Seite gestoßen. Hier hat jemand in etwa das selbe Problem. Der Code ist in etwa identisch. Dort wird auch erklärt, was der Schadcode macht. Über HTTP Post Requests werden bestimmte Befehle ausgeführt.
Welche Dateien wurden angelegt?
Der Schadcode legte hunderte kryptische Dateien an. Interessant ist hierbei, dass auch ein eigener „_old“ Ordner infiziert wurde, der öffentlich überhaupt nicht auffindbar ist. Dies bedeutet, dass der Schadcode das eigene Dateisystem lokal scannt und sich in zufälligen Ordnern einnistet.
Auch interessant ist, dass die Malware nicht nur in Ordnerhierarchie 1 liegt, sondern auch verschachtelt in unzähligen Unterordnern. Beispielsweise wp-content/uploads/astra/ oder auch wp-includes/blocks/.
Wie kann der WordPress Schadcode lokalisiert werden?
Zu aller erst suchte ich nach Gemeinsamkeiten der einzelnen Schadcode Dateien. Mir viel auf, dass immer ein „return @“ darin vorkam in Verbindung mit einer PHP „function“ und einem abschließenden „exit()“ Befehl. Durch folgendes SSH Kommando können alle Dateien, die diesen Kriterien zutreffen, angezeigt werden.
Des weiteren legte er nicht nur die kryptischen diiynxfr.php Dateien an, sondern auch öffentlich sichtbare .ico Dateien, sowie versteckte .ico Dateien. Einmal /dateiname.ico, welche direkt anzeigbar sind und zum anderen /.dateiname.ico Dateien, welche standardmäßig ausgeblendet sind.
rgrep -l basename * | grep "ico" | grep "\/\."Eine andere Art von Dateien beinhaltete ein DOCUMENT_ROOT, GLOB_ONLYDIR und ein HTTP_HOST. Durch diesen Befehl sind auch alle Dateinamen anzeigbar.
rgrep "DOCUMENT_ROOT" * | grep "GLOB_ONLYDIR" | grep "HTTP_HOST"Eine andere Schadcode Datei beinhaltete ein @include und eine Deklaration von Variablen. Javascript Dateien und welche die das Wort formatter enthalten, blendete ich aus, da diese nicht vom Schadcode betroffen waren.
rgrep "@include" * | grep var | grep -v ".js" | grep -v formatterDes weiteren stellte ich fest, dass immer die IP Adresse 176.9.4.210 die infizierten PHP Dateien von außerhalb aufgerufen hat. Durch folgenden Code können alle erfolgreichen Versuche der IP Adresse angezeigt werden. HTTP 301, 401, 404 und 500 Fehler werden nicht beachtet. HTTP 200 Aufrufe sind wichtig und werden auch aufgerufen.
cat /var/log/nginx/access.log | grep 176.9.4.210 | grep -v "HTTP/1.1\" 404" | grep -v "HTTP/1.1\" 401" | grep -v "HTTP/1.1\" 500" | grep -v "HTTP/1.1\" 301"Eine andere Datei beinhaltete ein @include und ein @unlink Befehl. Dadurch lassen sich die infizierten Dateien auch auffinden.
rgrep "@include" * | grep "@unlink"Das selbe gilt auch für @include und wp-config.
rgrep "@include" * | grep "wp-config"Ebenso wurden im Schadcode eval Befehle aufgerufen und GLOBALS als String eingebaut.
rgrep eval * | grep GLOBALSNachdem ich alle diese Dateien manuell auffindbar gemacht habe und anschließend entfernte, kamen allerdings von der IP Adresse immer noch erfolgreiche Aufrufe auf infizierte Dateien. Bei hunderten von neu erstellten und vorhandenen infizierten Dateien ist dies etwas schwieriger.
Wordfence Plugin
Durch das Wordfence Plugin lässt sich eine WordPress Installation auf Schadcode überprüfen. Bei mir hat Wordfence einige WordPress eigene Dateien gefunden, welche durch den Schadcode erweitert wurden. Da ich nur einen Webserver Nutzer auf allen aufgeschalteten Domains hatte, musste ich Wordfence bei unzähligen Seiten installieren und alles durchsuchen lassen.
Wordfence wurde fündig und machte einige infizierte Dateien aus. Diese können mit einem Klick wiederhergestellt werden. Damit wird der Schadcode entfernt und die originale offizielle nichtinfizierte WordPress Datei eingefügt. Manche Dateien müssten aber noch manuell angepasst werden, da Wordfence diese nicht ersetzen kann.
Fazit
wpDiscuz habe ich natürlich komplett deinstalliert und entfernt, damit der Angreifer nicht nochmal in das System kommt. Des Weiteren habe ich noch einige Sicherheitsmaßnahmen getroffen, die auch über WordPress hinausgehen. Ich wartete etwas ab, ob der Angreifer noch auf irgendwelche Dateien zugreifen kann und sah, dass permanent 404 Fehler kamen. Dies bedeutet, dass die Dateien nicht mehr existieren. Hoffentlich habe ich auch alle erwischt. Sonst werden direkt wieder hunderte nicht nachvollziehbare Dateien infiziert. Nach einem halben Tag überprüfte ich wieder die Logs um zu sehen, ob der Angreifer irgendwo durch kommt. Danach sendete ich bei Hetzner eine Abuse Meldung ab, sodass der entsprechende angreifende Server auch abgeschaltet wird.
