Mir ist die Tage - mal wieder - eine kompromittierte Maschine unter die Finger gekommen - diesmal eine Windows-Maschine; ich hatte ja schon einmal bei so einem Vorfall ein paar Infos aufgeschrieben, und da ich für den Artikel viel positives Feedback bekommen habe, dachte ich, ich mache das diesmal wieder :-) Allerdings wird's diesmal nicht so umfangreich, da ich dieses mal quasi nur als Berater hinzugezogen wurde, das eigentliche Doing jemand anderem überlassen mußte.

Aufgefallen war die Sache, daß beim Abrufen der darauf gehosteten Webseiten plötzlich Meldungen vom Virenscanner kamen. Das ganze sah nicht nach einem gezielten Hack aus, sondern eher nach der "Standard-Masche":

• Ein Skript sucht nach bekannten Lücken.
• Diese werden automatisiert exploitet, um in den Rechner einzudringen.
• Auf dem Rechner wird nach html-Dateien (und ähnlichem) gesucht und dort entsprechender Schadcode integriert.
• Optional hinterläßt das Skript noch ein "Kuckucksei" auf dem Rechner, so daß dieser seinerseits beginnt, im Netz nach verwundbaren Rechnern zu suchen.

Der JavaScript-Code (natürlich obfuscated) war schnell gefunden; bei dieser Gelegenheit habe ich zwei sehr hilfreiche Tools im Netz gefunden, um solche Skripte zu analysieren:

• Ein Converter-Tool zum unescapen der obligatorischen Prozent-Irgendwas-Encodings
• Ein online JavaScript Code Beautifier (und Entpacker). Der hat mir erfolgreich den häßlich in eine Zeile zusammengezogenen JS-Code sehr hübsch formatiert; zunächst hatte ich vor, das ganze mit einem JS-Debugger auszuführen, da wäre das sehr praktisch gewesen...
• ...der JSUNPACK hat mir das aber faktisch abgenommen :-) Hier habe ich auch bereits eine fertige Analyse des gefundenen Schadcodes gefunden - betroffene der Rechner war also kein Einzelfall ;-)

Das Skript hat im Endeffekt eine URL zusammengebaut, um von dieser den tatsächlichen Browser-Schadcode zu holen. Allerdings war ich für einen Blick hierauf zu spät 'dran - der DNS-Eintrag der Domäne war bereits gelöscht.
Allgemein blieb die Frage, ob der Rechner tatsächlich frisch kompromittiert wurde - oder ob der Vorfall einfach lange Zeit unbemerkt blieb: Die gefundene Analyse datiert auf den April diesen Jahres...

Erster Schritt war natürlich, den Schadcode für den Moment aus der Webseite zu entfernen. Dabei erlebte der zuständige Admin die erste Überraschung: Der Quelltext auf der Platte war unmodifiziert! Womöglich war der Fall doch spannender gelagert als zunächst angenommen? Ein zweiter Blick offenbarte jedoch, daß ein Verzeichnis mit blankem HTML nicht geprüft wurde; diese Dateien wurden an verschiedenen Stellen inkludiert... und siehe da: Hier wurden wir fündig. Ok, also doch eher klassich :-) Alternative Möglichkeiten zum Einschleusen des Schadcodes wäre z.B. ein zusätzliches Modul für den Webserver gewesen; desweiteren gab es auch schon Schadcode, der sich nur im RAM einnistete - dadurch würde er zwar einen Reboot nicht überleben, dafür war er durch Virenscanner, die lediglich Dateien durchsuchten, nicht zu entdecken.

Logischer zweiter Schritt: Herausfinden, wie der Angreifer auf die Maschine gekommen ist - und dann die Lücken abdichten. Die Kiste lief noch unter Windws 2000 (für welches Microsoft das "End of Life" für Juli 2010 angekündigt hat)... also potentiell reichlich Betätigungsfeld :-) Ein Portscan offenbarte folgendes:

Na prima. Mindestens einer der vermeintlichen SMTP-Server meldete sich zwar nach dem Aufbau der Verbindung mit einem SMTP-Hello, reagierte aber nicht auf weitere SMTP-Kommandos. Ein Lauf eines frischen Virenscanners auf dem infizierten System (merke: Solche Scans sind mit großer Wahrscheinlichkeit unvollständig; zum einen hinken signaturbasierte Scans den aktuellen Entwicklungen immer mindestens einen Schritt hinterher, zum anderen kann laufende Schadsoftware die Ausführung des Virenscanners sabotieren) offenbarte auch mindestens zwei Backdoors. Da sich diese nicht so ohne weiteres entfernen ließen, und unser Admin nicht herausfinden konnte, was die tatsächliche Einfallsschneise gewesen war, entschied man sich schließlich für eine komplette Neuinstallation - diesmal auf Basis von Software mit noch aktivem Support ;-) Aus diesem Grund verzichtete man auch auf tiefergehende Analysen - als Tools für weitere Untersuchungen hätten sich die Sysinternals Suite oder das Sleuth Kit angeboten.

Lessons learned:

• Updates, updates, updates. Und zwar zeitnah. Insbesondere, wenn es sich um eine Windows-Maschine handelt
• Wird der Support für eine Software eingestellt, so ist zeitnah auf eine andere umzuziehen.
• Die Zahl der exponierten Dienste so klein wie möglich halten. Was nicht gebraucht wird, sollte nicht laufen... und wenn manche Programme lokal benötigt werden, der Port aber für die weite Welt offen ist, so muß man sich eben mit einem Paketfilter behelfen.
• Der Job des Webservers ist es, die Dateien der Webseite zu lesen (ggf. zu interpretieren) und anschließend auszuliefern. Es besteht kein Grund, dem Webserver Schreibrechte auf die Dateien zu gewähren. Ohne Schreibrechte hätte im vorliegenden Fall kein Schadcode so einfach in die Webseiten eingefügt werden können (ich sage nicht, daß es unmöglich ist: Beispielsweise könnte der Webserver durch ein dynamisch dazugeladenes Modul dazu gebracht werden, den Schadcode in jede ausgelieferte Seite zu packen; aber das wäre schon ein gutes Stück kniffliger als primitives Suchen und Modifizieren von HTML-Dateien).

Für Security-Beleckte eher Binsenweisheiten - die in der Praxis doch allzu oft vernachlässigt werden.