Dipl.-Inform. Carsten Eilers

Während anfangs erst 80 Websites infiziert waren, waren es Ende Dezember bereits ca. 1.070.000. Oder ein paar mehr oder weniger. Oder sogar viel mehr oder weniger? Denn die verwendete Methode zum Finden infizierter Websites ist aus mehreren Gründen ziemlich ungenau. Denn dafür wird mit Google nach einem Teil des eingeschleusten Codes, "<script src="http://lilupophilupop.com/", gesucht.

Damit findet man alle betroffenen Websites, die der Google-Bot nach der Infektion indiziert hat. Die Seiten, die infiziert wurden, aber seitdem keinen Besuch von Google hatten, bleiben außen vor. Dafür werden aber auch alle Websites gefunden, die über die Angriffe berichten und so wie hier den betreffenden String im Text angeben. Nicht zu vergessen die vielen Fundstellen, die alle zur gleichen Website gehören. Wirklich interessant sind ja nur die infizierten Domains/Webserver. Auf wie vielen Unterseiten der auf dem Server eingeschleuste Code ausgegeben wird, ist doch eher nebensächlich bis völlig uninteressant.

Geht das auch genauer?

Man könnte die Berichte u.U. ausfiltern, indem man den Suchbegriff ändert. Die tatsächlich betroffenen Websites enthalten den Code nämlich oft an "falschen" Stellen, z.B. im title-Tag. Das passiert, da die Cyberkriminellen wie immer mit dem Vorschlaghammer vorgehen und ihren Code einfach in jedes Textfeld schreiben, dass sie finden können. Einige der manipulierten Felder landen dann fast immer an Stellen, an denen das script-Tag nichts zu suchen hat und verraten damit dann den Angriff. Aber um daraus eine brauchbare Suchabfrage zu basteln, müsste man erst mal eine Liste möglicher Fundstellen erstellen, und der Aufwand lohnt sich i.A. nicht.

Einen Monat Angriffe - muss das sein?

Nun stellt sich die Frage, wieso dieser Angriff so lange lief bzw. wieso er noch läuft. Immerhin reicht es ja, die im eingeschleusten script-Tag verwendete Domain aus dem Verkehr zu ziehen, um den Cyberkriminellen den Spass zu verderben: Ohne lilupophilupop.com kein geladener Code, also auch keine Verbreitung von Schadsoftware. Und wenn der eigentliche Angriff ins Leere läuft, dürften die Cyberkriminellen schnell aufhören, den JavaScript-Code über SQL-Injection zu verbreiten. Dass sie dann einfach mit einem anderen Domainnamen weiter machen, steht auf einem anderen Blatt.

Die ersten Angriffe wurden Anfang Dezember gemeldet, die Domain aber erst am 4. Januar aus dem Verkehr gezogen, wie eine Whois-Abfrage verrät:

   Domain Name: LILUPOPHILUPOP.COM
   Registrar: BIZCN.COM, INC.
   Whois Server: whois.bizcn.com
   Referral URL: http://www.bizcn.com
   Name Server: NS1.HOPERJOPER.RU
   Name Server: NS2.HOPERJOPER.RU
   Status: clientDeleteProhibited
   Status: clientHold
   Status: clientTransferProhibited
   Updated Date: 04-jan-2012
   Creation Date: 27-nov-2011
   Expiration Date: 27-nov-2012

Wieso dauert das denn so lange? Fragen wir doch mal Googles Safe Browsing, was man dort von lilupophilupop.com und dessen Hoster hält. Das erklärt wohl alles: Der Hoster hosted so viele bösartige Domains bzw. Websites, dass er mit dem Aufräumen nicht hinterher kommt. Oder kommen will?

"Schilde hoch"

Aber eigentlich ist es auch egal, ob überhaupt und ggf. wie schnell die von den Cyberkriminellen verwendete Domain aus dem Verkehr gezogen wird. Diese Aktionen stören die Cyberkriminellen immer nur kurzfristig. Die beschaffen sich einfach eine neue und machen weiter. Um sie zu stoppen, müssen die Webanwendungen abgesichert werden.

Der Angriff quasi mit der Schrotflinte, bei dem blind Webanwendungen mit dem SQL-Injection-Code gefüttert werden, funktioniert nur aus zwei Gründen: Erstens ist der eingeschleuste Code von Eigenheiten der Webanwendung unabhängig, er funktioniert auf jedem Server mit einer MSSQL-Datenbank. Der SQL-Code sucht einfach in der Datenbank nach Textfeldern und schreibt dort den HTML-Code zum Laden der JavaScript-Datei hinein. Wie das genau funktioniert, habe ich bereits bei der Beschreibung der Drive-by-Infektionen erklärt. Dagegen lässt sich kaum etwas machen, darum kommen wir zum "zweitens": Die angegriffenen Webanwendungen enthalten mindestens einen Parameter, über den SQL-Injection möglich ist. Und dagegen lässt sich etwas machen, denn SQL-Injection lässt sich verhindern. Entweder durch das korrekte Escapen aller Eingaben oder durch die Verwendung von Prepared Statements mit parametrisierten Aufruf (parameterized queries). Darin eingeschleuster SQL-Injection-Code wird von der Datenbank einfach ignoriert.

Wenn Sie eine Webanwendung betreiben, vor allem eine die auf ASP.NET oder ColdFusion basiert, sollten Sie prüfen, ob alle von einem Angreifer manipulierbaren Daten vor der Verwendung in SQL-Abfragen korrekt escaped werden oder ob für die SQL-Abfragen Prepared Statements mit parametrisierten Aufruf verwendet werden. Falls Ihre Webanwendung auf anderen Techniken basiert, sind sie zwar erst mal fein raus, trotzdem sollten Sie die gleichen Vorsichtsmaßnahmen ergreifen. Denn wenn die Cyberkriminellen keine angreifbaren ASP- und ColdFusion-Webanwendungen mehr finden, werden sie sich andere Ziele suchen. Und wer weiß, vielleicht rückt dann Ihre Anwendung in ihr Visier?

Aufräumen reicht nicht!

Falls Ihre Webanwendung bereits angegriffen wurde, denken Sie daran: Nach dem Aufräumen (was i.A. schneller durch das Einspielen des letzten sauberen Backups als durch manuelles Löschen des Schadcodes geht) müssen sie unbedingt die Schwachstelle(n) beheben, über die die Cyberkriminellen den Schadcode eingeschleust haben. Sonst haben sie nicht lange Freude an ihrem gereinigten Server, denn der nächste Angriff kommt bestimmt. Und denken Sie daran: Wo eine SQL-Injection-Schwachstelle ist, ist die nächste oft nicht weit - prüfen Sie also alle Parameter sorgfältig.

Carsten Eilers