Vorgeschichte
Neulich stand ich vor der Situation, drei gehackte Joomla Installationen wiederherstellen zu müssen. Die Content-Management-Systeme befanden sich mehr als 1,5 Jahre nach Ende des Supports noch in der Version 2.5.28 und lagen auf dem gleichen Webspace.
Nicht nur, dass sich das Aktualisieren schwierig gestaltete, da der Auto-Updater nicht funktionierte und direkte Updates auf Joomla 3.6 nicht möglich waren, stand ich nun vor der Herausforderung die veränderten Dateien zu finden und zu bereinigen. Der Hack wurde über mehrere Monate nicht bemerkt und das System war zu weiten Teilen infiziert, Backups lagen keine vor.
Eins vorab: Es ist unwahrscheinlich alle kompromittierten Dateien zu finden und es stellt einen großen Aufwand dar. In den meisten Fällen ist es besser, die Software komplett neu aufzusetzen und die Website von Grund auf neu zu erstellen.
Hier möchte ich nun darlegen wie ich zur Bereinigung und Wiederherstellung vorgegangen bin. Gute Dienste haben mir vorwiegend die Tools grep
und sed
geleistet. Diese Anleitung lässt sich natürlich auch auf andere Content-Management-Systeme übertragen, ein gehacktes WordPress lässt sich auf die gleiche Art wiederherstellen.
Alle genutzten Tools sind Bordmittel einer jeden vernünftigen Linux-Distribution. Windows Nutzer können ein Live-System, eine Virtuelle Maschine oder ihren Webserver nutzen.
Disclaimer: Obwohl ich im folgenden häufiger den Begriff „Hacker“ benutze, meine ich damit keinesfalls die ethischen Hacker, sondern den umgangssprachlichen „bösen“ Cracker.
Gehacktes CMS wiederherstellen
Schritt 1: Website offline nehmen
Sperren Sie mittels .htaccess oder ähnlicher Methoden sämtliche Verzeichnisse für Besucher oder richten Sie eine Weiterleitung ein. Sie können dazu folgende htaccess-Regeln nutzen:
Options +FollowSymlinks RewriteEngine on RewriteCond %{REMOTE_ADDR} !=123.45.67.89 RewriteRule index.php$ /fehler.php [R=301,L]
Ersetzen Sie die IP-Adresse „123.45.67.89“ durch Ihre Eigene. Alle anderen Besucher werden nun auf die Seite „fehler.php“ weitergeleitet.
Schritt 2: Backup der Daten
Nachdem eine Joomla Installation gehackt und dies bemerkt wurde, sollten Sie unbedingt und schnellstmöglich ein Backup der Daten und Datenbank anlegen. Hierzu eignet sich zum Beispiel die Software Akeeba Backup. Bereinigt man die Dateien, ohne vorher eine Sicherung zu erstellen, besteht zu jeder Zeit die Gefahr dass der/die Hacker versuchen alle Ihre Spuren zu verwischen und sämtliche Daten löschen. Auch für eventuelle Strafanzeigen ist es wichtig ein Backup mit allen infizierten Daten zu haben.
Sollte ein Backup der Daten mit Akeeba nicht möglich sein, bleibt noch ein manuelles Sichern über FTP, MySQL, phpMyAdmin o.ä.
Schritt 3: Ändern aller Passwörter
Ändern Sie alle Passwörter. Das beinhaltet Passwörter von Benutzern, FTP Passwörter, SSH Passwörter, MySQL Passwörter etc.
Informieren Sie alle Nutzer über die Probleme und zwingen Sie diese, wenn möglich, ihr Passwort zu ändern.
Schritt 4: Analyse des Schadens
Wie Sieht der Eingeschleuste Schadcode aus?
Möchte man Probleme beseitigen, muss man sie erkennen: der eingeschleuste Schadcode kann die unterschiedlichsten Formen annehmen, ist aber meist auf den ersten Blick ersichtlich. Im Folgenden finden sich ein paar Beispiele. Im Interesse der Sicherheit werde ich hier nur Ausschnitte aus Dateien als Bilder einfügen:





Fall 1:Backup Vorhanden
Für die Analyse des Schadens sollte man sich viel Zeit nehmen. Sollte die Möglichkeit bestehen die Dateien mit einem Backup vergleichen zu können, bietet sich hier ein rekursiver diff
an.
Dafür erstellt man am Besten einen Ordner mit den gehackten Daten, einen Ordner mit dem entpackten Backup und führt folgendes Kommando aus:
diff -r ordner_mit_gehackten_daten/ backup/ | sed '/Binary\ files\ /d' >hacked.txt
In der Datei hacked.txt
finden sich jetzt sämtliche Änderungen in allen Unterordnern und Dateien. Anhand der Daten lässt sich eine Beseitigung des eingeschleusten Codes durchführen, auch wenn zwischen Backup und Hack schon Änderungen gemacht wurden.
Fall 2: Kein Backup vorhanden
Hier lässt sich nur manuell prüfen, wo Schadcode eingeschleust wurde. Findet man eine Datei, sollte man versuchen das Muster zu erkennen und sämtliche anderen Dateien nach dem Muster zu durchsuchen. Hierfür nimmt man am besten grep
. Dieses Kommando durchsucht alle Dateien und Unterordner des aktuellen Verzeichnisses nach einem gegebenen Muster:
grep -r "Muster" .
Hilfreiche Kommandos um Infizierte Dateien zu finden
Finden die in den letzten n-Tagen verändert wurden:
find . -mtime 0
Dieses Kommando listet alle Dateien und Ordner auf, die in den letzten 24 Stunden verändert wurden. Die Anzahl der Tage lässt sich über den Parameter mtime
einstellen.
Finden aller PHP-Dateien die nicht mit einem Kommentar beginnen
In meinem vorliegenden Fall wurde viel Schadcode direkt hinter das PHP-Start-Tag injiziert. Das ergibt natürlich Sinn, denn es ist davon auszugehen, dass die meisten PHP Dateien mit <?php
beginnen und eine blinde Injektion von Schadcode nach diesem Tag geht fast immer gut. Außerdem liegt einem böswilligen Hacker meist nichts daran, den Code zu erklären den er eingeschleust hat 😉 .
grep -rvlz $'^[[:space:]]*<?php\n/\*' --include='*.php' | xargs head -v -n 10 > hacked.txt
Dieses Kommando listet alle php-Dateien auf, die nicht mit einem Kommentar beginnen, gibt die ersten 10 Zeilen der Datei sowie den Dateinamen aus und schreibt alles in die Datei hacked.txt
. Vielen Dank an anubhava für den RegEx.
Finden verdächtiger Dateien
Suche anhand verwendeter Funktionen
Auch hier leistet grep
wieder wahre Wunder. Durchsuchen Sie Dateien, wie oben beschrieben und prüfen Sie diese auf folgende häufig von Hackern verwendete Funktionen:
mail()
fsockopen()
pfsockopen()
stream_socket_client()
exec()
system()
passthru()
shell_exec()
eval()
base64_decode()
str_rot13()
ord()
chr()
hexdec()
Eine Suche nach diesen Funktionen wird bei einem Content-Management-System sehr viele Resultate liefern und es ist sehr aufwändig alle zu analysieren.
Auch die Variablen $_COOKIE, $_GET, $_POST und $_REQUEST sollte man auf jeden Fall prüfen.
Häufig findet man auch einen @-Operator in der manipulierten Zeile, der das Logging unterbinden soll.
Gute Dienste leistet in diesem Kontext auch jamms (nicht nur für Joomla!).
Suche anhand von Dateinamen
Oft wählen Angreifer Dateinamen unauffällige Dateinamen die in Log-Dateien nicht auffallen. Prüfen Sie Ihre Unterverzeichnisse auf Dateinamen wie:
- 404.php
- admin.php
- ajax.php
- cache.php
- contacts.php
- controller.php
- config.php
- configuration.php
- css.php
- defines.php
- dump.php
- do.php
- error.php
- file.php
- functions.php
- global.php
- help.php
- list.php
- model.php
- index.php (dort wo diese nicht hingehört)
- solo.php
- test.php
Die Dateinamen enthalten häufig auch Zahlen. Finden Sie also eine Datei wie index14.php, error26.php
oder cache7.php
sollte sofort allerhöchste Alarmstufe herrschen.
Schritt 5: Installation von Updates
Installieren Sie alle verfügbaren Updates, prüfen Sie jede Erweiterung von Hand auf neue Versionen. Trennen Sie sich von nicht länger unterstützten Erweiterungen und suchen Sie Ersatz für veraltete Plugins, Komponenten und Module.
Schritt 6: Analyse der Log-Files
Wird der Angriff zeitnah bemerkt, sollte zunächst versucht werden, den Angriff anhand der Log-Dateien nachzuvollziehen. Dies gibt einen Einblick in eventuell weiterhin vorhandene Sicherheitslücken. Oft sind die problematischen Codezeilen jedoch so gut versteckt, dass der Provider keine Log-Dateien für den Angriffszeitpunkt mehr zur Verfügung stellt. Sind die Hacker nicht auf Daten oder blinde Zerstörung aus, ist Ihnen oft daran gelegen, möglichst unbemerkt zu bleiben um den Server so lange wie möglich nutzen zu können.
Ist der Schadcode (teilweise) beseitigt, ist die Arbeit lange noch nicht getan. Nun heißt es überwachen der Logs und das am besten mehrmals täglich. Eine Anfrage an den Webserver sieht in den Log-Dateien in der Regel wie folgt aus:
173.208.198.50 - - [20/Jul/2016:04:55:42 +0200] "POST /modules/modules/modules.php HTTP/1.1" 200 440 "website" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:41.0) Gecko/20100101 Firefox/41.0" "website"
Erklärung der Anfrage: Typ der Anfrage, Angefragte Seite der Domain, HTTP Status Code, Größe der Anfrage in Bytes
Interessant sind vor allem POST-Requests die nicht auf die Datei index.php
, sondern gezielt auf andere Dateien gehen und mit Status 200 beantwortet werden. Diese Dateien sind in jedem Fall manuell zu prüfen und das nach jeder Anfrage am besten mehrere Wochen lang.
Nach dem Hack ist vor dem Hack
Achten Sie immer darauf, dass System und Erweiterungen stets auf dem neusten Stand sind. Installieren Sie Zusatzsoftware für besseres Logging, zum Schutz gegen Angriffe und zum Prüfen der Datei-Integrität. Und am wichtigsten: erstellen Sie regelmäßig Backups, wenn möglich automatisiert.
Zusammenfassung:
- Website deaktivieren
- Backup
- Passwörter ändern
- Schadcode entfernen
- Updates installieren
- Logs prüfen
Ist das alles erledigt, stehen die Chancen gut, dass die Angreifer in die Flucht geschlagen wurden. Eine Garantie dafür gibt es aber keinesfalls.