Monat: Juli 2016

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:

1. Website deaktivieren
2. Backup
3. Passwörter ändern
4. Schadcode entfernen
5. Updates installieren
6. 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.