Wie sichert man ein produktives Shopsystem nach einem Angriff ?

Früher oder später wird es jedem passieren der eine Webseite, ein Forum oder ein Shopsystem im Internet betreibt: Man schaut auf die eigene Seite und die Startseite ist eine andere (Defacement) oder der Betreiber des Servers schickt einem eine Mail mit dem saloppen Hinweis das man gerade 100.000 Spam emails verschickt habe.

Bei einer privaten Webseite ist das alles noch nicht so schlimm, auch wenn man natürlich für das was man dort tut verantwortlich ist, und darum gehört auch die Vorsorge gegen solche Angriffe sprich Patches. Mehr können die meisten Anwender garnicht tun.

Bei einer kommerziellen Webseite sieht das anders aus:

• Einkommensausfall
• Imageschaden
• Datendiebstahl von Kundendaten

Generell werden Webpräsenzen oder Server aus verschiedenen Gründen angegriffen. Das Reicht vom „simplen“ email Spam, über Datendiebstahl und endet dabei das der vormahls eigene Server als Plattform für weitere Angriffe verwendet wird.

Nun ist also der Angriff passiert nun sollte festgestellt werden :

• Wann genau das passiert ist
• welche Dateien geändert wurden
• welche Dateien neu abgelegt wurden

Hierbei hilft normalerweise das Apache Log. Dafür muss man aber wissen wann der Einbruch ca stattgefunden hat, sonst sucht man sehr lang. Aber wonach sucht man ?

Idealerweise nennt einem der Provider das spammende Script, die Suche nach dem Scriptnamen in den Logfiles nennt einem dann sehr viele Details. Wann der erste aufruf war, von wo die aufrufe kamen und wie oft darauf zugegriffen wurde. Ein löschen des scriptes ist obligatorisch, aber vorher sichern, diese rootshells sind höchst interessant !

Generell den Provider über den Vorfall informieren ! Hat man was übersehen achten die nach dem Hinweis verstärkt darauf und blocken die entsprechenden scripte sehr schnell. Das verhindert weitere Schäden. Manchmal kommt auch vom Provider bei Nachfrage noch ein guter Tip oder entprechende Log-auszüge die weiterhelfen.

Meistens findet sich nach so einem Vorkommnis mindestens 2 scripte, eins zum spammen und die eigentlich rootshell über die das spamscript hinterlegt wurde. Die Namen variieren und sind frei erfunden, gliedern sich aber meist recht nahtlos in das infiltrierte System ein damit sie beim bloßen darüber hinwegschauen nicht identifiziert werden können.

Was tun wenn die Seite übernommen wurde oder ein Defacement abgebracht wurde ?

Jetzt heisst es wühlen in den Details, feststellen von Änderungen und beseitigen derselben.

Hier hilft es sehr zu wissen wie denn so eine rootshell aussieht, damit man weiss wonach man sucht.
Beispiel aus php:

<?php // This file is protected by copyright law and provided under license. Reverse engineering of this file is strictly prohibited.

$OOO0O0O00=__FILE__;$O00O00O00=__LINE__;$OO00O0000=42896;eval(gzuncompress(base64_decode(‚eNplj8duwkAYhF/G0u4qRlmI44AsH+idpbdL
5PK7gBu7LsDTBxREhKKZ02jmk0ZilFJ2E9WdOIEIS4yx30BG3EREKzw/AFwqSex
evJs4LqQCS8+pXKYVhWj/YoXWVKLdiI+l7l6zyIrDhIMQ2DQEqMq3DVZsAxYpTz
l2OBj2C6JKiYzaUQ

usw. in der Regel sind diese Shells mittels base64 verschleiert, oft (wie im beispiel) noch gepackt. So schlimm die angerichteten Schäden sein können, immerhin kann man die scripte dadurch recht einfach finden sobald man weiss das eins auf dem Server liegt.

Download des gesamten inhalts des Webspaces ausführen (bei ssh zugang vorher eine zip datei erstellen dann gehts schneller). Ausgeklammert werden können hier Ordner die keine ausführbaren (*.php, ..) Dateien enthalten, sofern sichergestellt ist das diese Ordner auch wirklich keine ausführbaren Dateien enthalten.

Wird ein „normales“ Shopsystem oder Blog eingesetzt lädt man sich die gleiche Version die installiert ist vom Anbieter noch einmal herunter und führt einen Datei und Inhaltsvergleich durch. Hierfür gibt es viele Tools (Total Commander, Winmerge, …).

Eine suche nach geänderten Dateien nach Datum. Meist weiss man wann die letzte eigene Änderung war! (Achtung, das Änderungsdatum von Dateien kann leider verändert werden)

Ebenfalls nicht schaden kann ein Virenscann der downgeloadeten Dateien. Rootshells und Spamscripte werden in den meisten fällen gefunden.

Im Falle von php alle Dateien durchsuchen nach:

• Packroutinen (gzuncompres,…)
• Verschleierung/Verschlüsselung (base64_decode,…)
• eval

Führt man diese schritte Nacheinander aus, sollte die suche nach den Packroutinen/base64/eval keine ergebnisse in den Originaldateien mehr zutage fördern die dort nicht hingehören.
Bleiben noch Dateien die von einem selbst verändert wurden. Glücklicherweise erkennt man (hoffenltich) seinen eigenen Code und kann dort die änderungen recht schnell finden bzw. ausschliessen.

Der Code sollte nun sauber sein. Wie gehts weiter ?

Nun ist die Datenbank an der Reihe, bzw die Datenbanken. Hier kann man nun keine wirklich Anleitung geben da das alles zu sehr vom eingesetzten System abhängt. Aber ein paar generelle Dinge gibt es trotzdem:

• Benutzer überprüfen (insbesondere Administratorzugänge)
• Passwörter ändern!
• Überall wo Content aus der Datenbank in der Webseite geladen wird prüfen ob dort von fremden Quellen Code nachgeladen wird

Die Datenbank wäre auch geschafft. und nun ?

Das hängt nun leider davon ab wie die erste Schadhafte Datei auf den Server gelangen konnte. Gibt es eine Lücke durch die man in den Adminbereich kommt? (SQL-Injections?)
Ein absichern des Adminbereichs mit .htaccess umgeht dieses Problem effektiv.

SQL-Injections können immer dann auftreten wenn Daten aus Eingabefeldern verarbeitet werden, das kann auch versteckte Felder in Formularen betreffen. Kennt man sich mit der Materie nicht aus kann man nur hoffen das es bereits einen Patch gibt der dieses Problem behebt. Das ist meistens der Fall wenn man sich als Privatanwender nicht dauernd um aktualisierung der Software bemüht.

Hierbei darauf achten das Zusatzmodule (Gästebücher, wikis) genauso die Schwachstelle sein können wie das Hauptsystem das im endeffekt verändert wurde !

Hat man eine Lücke oder sogar mehrere gefunden und behoben hilft in Zukunft nur sich darum mehr zu kümmern und sie zu schliessen bevor sie ausgenutzt werden, hier ist die Zeit leider meist sehr sehr knapp.

Alles ist wie vorher aber keine Schwachstelle gefunden ?

Das ist so ungefähr die unangenehmste Situation. Es ist zwar alles hinterher aufgeräumt, aber theoretisch könnte, wer auch immer es war, jederzeit wieder dasselbe passieren. Der einzige unterschied ist das man vorgewarnt wäre. Mit etwas Glück passiert garnichts mehr und es kommt in ein paar Tagen ein Patch der das Problem behebt von dem man nichtmal etwas weiss.
Im schlimmstenfall passiert das nun immer wieder bis man den Fehler findet, die Software wechselt oder aufgibt.

Tritt der Fall ein das das Problem weiterbesteht aber unbekannt ist kann man nur mit eingrenzen anfangen. Als ersten Schritt empfehle ich alle zusatzmodule die nicht unbedingt gebraucht werden zu notieren, alle nebenher laufenden scripte zu notieren, sprich ein Inventar an laufender Software zu erstellen.
Inklusive der aktuellen Version selbstverständlich.

Als nächstes befragt man die gängigen Suchmaschinen für jede Software nach Lücken, Updates evtl zusätzlicher inoffizieller security patches etc.
Für alle die XTcommerce einsetzen: es gibt xtc:modified ! Der Quasie-Nachfolger mit hunderten gepatchten Stellen.
Oft gibt es für die eingesetzten Module bereits Nachfolgeprojekte die diese ersetzen und fortführen, hier heisst es Updaten wenn möglich.

Hat man hierbei etwas geändert/verbessert kann das schon die Lücke gewesen sein die man nicht gefunden hat.

Nun gibt es noch die möglichkeit das der Server eine Schwachstelle hat.

Das kann im Betriebssystem liegen, an installierten (z.b. Apache) Paketen, Zusatzmodule für diese Pakete, sprich den ganzen Server betreffen selbst wenn man selbst dort keinen Zugang zu hat. Hier wäre dann der Hoster in Pflicht.
Ist es der eigene muss man das alles selbst prüfen, im Falle von rootshells können auch programme modifiziert worden sein aber wer einen Server sein eigenen nennt den er selbst verwaltet der sollte sowieso wissen was er tut sonst gibt das eine Bauchlandung.

Nachsorge und Vorsorge

Spätestens jetzt sollte man sich überlegen was man besser machen kann. Oder nicht ? Regelmässige automatisierte Backups der Datenbanken und ein Backup des Webroot. Wer eine saubere Sicherung hat kann im Notfall auch einfach mal den Ordner auf dem Server löschen und frisch hochladen. Vielleicht nicht die eleganteste Lösung aber einfach und effektiv. Und sofern man sicher ist das das Backup sauber ist auch eine sichere Lösung gegen modifizierte Dateien.

Regelmässig auf updates und patches achten, die Liste mit der laufenden Software hat man ja nun und diese kann man gut als Anhaltspunkt dafür nehmen.

Auch ab und an die eigene Seite besuchen kann nicht schaden, Kunden beschweren sich selten weil „irgendwas auf der Seite komisch ist“, die schliessen lieber das Browserfenster…