Ein wesentlicher Baustein der Analyse und Bereinigung von mit Malware verseuchten Webseiten ist das Sichten und Auswerten der Logdateien. Doch auch hierbei gibt es Dinge zu beachten, die auf den ersten Blick täuschen könnten.
Nehmen wir an, Sie finden auf einer Webseite eine verdächtige Datei xyz.php, welche Malware enthält. Ein erster Schritt wäre nun, sich die Dateiinformationen anzusehen.
stat xyz.php. Die Ausgabe könnte in Auszügen dann so aussehen:
Access: 2022-01-25 17:49:11.033089757 +0100
Modify: 2021-12-10 17:35:44.160789235 +0100
Change: 2021-12-10 17:35:44.184790689 +0100
Diese Datei wurde also am 10. Dezember 2021 erstellt bzw. zuletzt verändert (Doch Achtung, auch diese Informationen können gefälscht werden!).
Im nächsten Schritt schauen wir in der access.log der entsprechenden Webseite nach Aufrufen, die in dieser Zeit erfolgt sind. Bei wenig besuchten Webseiten ist es kein Problem, die ganze Logdatei Zeile für Zeile im betroffenen Zeitraum durchzugehen, bei hochfrequentierten Seiten ist das nicht (so einfach) machbar. Also grenzen wir es ein.
grep '10/Dec/2021:17:35' access.log
Auch dies könnte noch zu viele Ergebnisse liefern und unübersichtlich sein, also versuchen wir es, indem wir nur erfolgreiche Aufrufe filtern.
grep '10/Dec/2021:17:35' access.log | grep -E '" (20.|30.)'
Der Befehl sucht alle Aufrufe dieses Zeitraums heraus, die mit Code 20x oder 30x beantwortet wurden, bei denen die Url also existiert oder weiterleitet.
Doch genau hier haben wir "verloren". Schauen wir uns folgenden Logauszug an:
xx.xx.xx.xx - - [10/Dec/2021:17:35:13 +0100] "POST /wp/wordpress/wp-includes/css/dist/editor/themes.php HTTP/2.0" 404 49793 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.99 Safari/537.36"
Mit unserem Filter hätten wir diesen Eintrag nicht entdeckt, denn die Antwort vom Server war 404, also dass das aufgerufene Skript nicht existiert. 404 Fehler kommen im Log sehr häufig vor, da Hacker und Bots sehr viele Urls ausprobieren, um dadurch zufällig bekannte Eintrittspunkte für Schwachstellen zu finden. Nur müssen wir folgendes bedenken: Der HTTP Code ist NICHT ausschließlich vom Webserver festgelegt worden.
Hier ein Beispielcode aus einer PHP-Malware:
<?php
error_reporting(0);
http_response_code(404);
// malicious code follows
Oha! Dieses Skript gibt also immer einen Code 404 im Log aus, auch wenn der Aufruf erfolgreich war. Ergo dürfen wir im Filtern der Logfiles den HTTP Code nicht (als Ausschlusskriterium) beachten.
Ein Patentrezept für die Logfileanalyse gibt es nicht. Der Zeitpunkt, den ein stat filename.php ausgibt, muss nicht immer stimmen. Und auch wenn die meisten Aufrufe von Malware via POST request erfolgen, muss das nicht immer so sein. Letztendlich ist das Bereinigen einer Webseite immer eine Aufgabe, die langwierig ist und sehr gewissenhaft und konzentriert durchgeführt werden muss. Selbst ein Löschen aller betroffenen Dateien ist nicht immer die richtige Option, denn es werden oft auch bestehende Dateien so modifiziert, dass sie nur einige Zeilen Malware enthalten oder einbinden. Beim Löschen der Datei ist die Webseite dann nicht mehr funktionsfähig.
Im besten Fall existiert ein Backup mit (fast) allen aktuellen Daten, das noch keine Kompromittierung enthält. Im schlechtesten Fall ist eine Neuinstallation der kompletten Webseite mit (manueller) Übernahme der Inhalte die sicherste Option.
Marius Burkard arbeitet seit 20 Jahren als Software-Entwickler und kann auf eine mehrjährige Erfahrung als Server-Administrator zurückgreifen. Als einer der Lead-Developer des ISPConfig Control Panels und technischer Ansprechpartner für mehrere Hundert Webhosting-Kunden verfügt er über umfangreiche Erfahrungen mit Malware, gehackten Webseiten und der Analyse von Schwachstellen.