Alle Bedrohungen

Viren

Hacker

Spam

Alle Seiten    Viren
  
Virus Enzyklopädie
Alarme
Analysen
Nachrichten
Glossar
Weblog

 
Kalender

<< 2014  
Jan Feb Mär
Apr    
     
     
Most Popular Analysis



Finanzielle Cyberbedrohungen im Jahr 2013. Teil 2: Malware



BitGuard: das aufgedrängte Suchsystem



Finanzielle Cyberbedrohungen im Jahr 2013, Teil 1: Phishing



Entwicklung der IT-Bedrohungen im 1. Quartal 2014



Malware im dritten Quartal 2011
 
Für potentielle Autoren

Möchten Sie einer unserer Autoren werden und Ihre Texte auf der Viruslist.com lesen? Setzen Sie sich mit uns in Verbindung!

 

  Home / Analysen

Wie stopft man das schwarze Loch?

10.09.2013   |   Ihr Kommentar

Vyacheslav Zakorzhevsky
Viren-Analyst bei Kaspersky Lab
Wie stopft man das schwarze Loch? Vsyacheslav Zakorzhevsky An einem Beispiel betrachten wir den Infektionsprozess eines Computers mit Hilfe des Exploit-Packs BlackHole und erläutern die entsprechenden Abwehrmechanismen.

Heute gehört die Ausnutzung von Sicherheitslücken in legitimer Software zu den beliebtesten Methoden zur Infektion von Computern. Nach unseren Einschätzungen werden die Computer der User am häufigsten von Exploits zu Sicherheitslücken in Oracle Java angegriffen. Moderne Schutzlösungen sind in der Lage, effektiv Drive-by-Attacken abzuwehren, die mit Hilfe von Exploit-Packs umgesetzt werden. Wir beschreiben hier den Prozess einer Computerinfektion mit Hilfe des Exploit-Packs BlackHole sowie die entsprechenden Schutzmechanismen.

Exploit-Packs

In der Regel setzten Cyberkriminelle nicht ein Exploit ein, sondern eine fertige Auswahl, so genannte Exploit-Packs. Dadurch wird die Effektivität des Angriffs bedeutend erhöht, da im Rahmen der Attacke ein oder mehrere Exploits zum Einsatz kommen können, von denen jedes eine andere der auf dem angegriffenen Computer vorhandenen Software-Sicherheitslücken ausnutzt.

Während Exploits und die mit ihrer Hilfe hochgeladenen Schadprogramme früher von ein und denselben Leuten entwickelt wurden, so funktioniert dieser Zweig des Schwarzmarktes heute nach dem Prinzip SaaS (Software as a Service). Als Folge dieser Arbeitsteilung erfüllt jede Gruppe von Cyberkriminellen ihre eigenen Aufgaben: Die einen entwickeln und verkaufen die Exploit-Packs, die anderen gewährleisten, dass die Anwender auf die Startseiten der Exploits gelangen (Traffic steuern) und wieder andere schreiben die Schadprogramme, die im Zuge der Drive-by-Attacken verbreitet werden. Heute muss ein Online-Verbrecher, der Interesse daran hat, Anwendercomputer zu infizieren - z.B. mit einer Modifikation des Trojaners ZeuS - lediglich ein fertiges Exploit-Pack kaufen, es installieren und seine potentiellen Opfer auf die Startseite treiben (auch Landing-Page genannt).

Cyberkriminelle leiten die Anwender mit Hilfe verschiedener Methoden auf die Landing-Page um. Am gefährlichsten für den Nutzer ist dabei der Hack von Seiten legaler Websites und die anschließende Einschleusung von Skript-Code oder iframe. In solchen Fällen gehen die Anwender selbst auf eine bekannte Website, und das ist ausreichend, um eine Drive-by-Attacke durchzuführen, damit das Exploit-Pack seine Arbeit aufnehmen kann. Cyberverbrecher können legale Werbesysteme ausnutzen, indem sie Links auf schädliche Seiten in Bannern oder Teasern platzieren. Eine andere unter Online-Gangstern beliebte Methode ist die Verbreitung von Links auf Landing-Pages via Spam.

 
Allgemeines Infektionsschema von Anwendercomputern mit Hilfe von Exploit-Packs

Derzeit wird auf dem Markt eine Vielzahl von Exploit-Packs angeboten – Nuclear Pack, Styx Pack, BlackHole, Sakura und andere. Auch wenn sie alle anders heißen, so sind sie ihrem Wesen nach doch identisch – es sind Sammlungen unterschiedlicher Exploits plus Administratoren-Steuerungspaneel. Außerdem funktionieren alle Exploit-Sammlungen praktisch nach ein und demselben Schema.

Eins der bekanntesten Exploit-Packs ist BlackHole. In ihm sind Exploits enthalten, die Sicherheitslücken im Adobe Reader, Adobe Flash Player und Oracle Java enthalten. Um eine maximale Effizienz zu gewährleisten, werden die Exploits innerhalb des Packs ständig ausgetauscht. Anfang 2013 untersuchten wir drei Exploits zu Oracle Java aus der Sammlung BlackHole. Zur Illustration der Funktionsprinzipien von Exploit-Packs in dem vorliegenden Artikel ist unsere Wahl ebenfalls auf BlackHole gefallen.

Im schwarzen Loch

Zunächst weisen wir darauf hin, dass alle Angaben über die Exploits, den Inhalt der Startseiten und andere von uns betrachteten Informationen (insbesondere die Bezeichnungen der Methoden, Klassen, Werte der Konstanten) zu dem Zeitpunkt aktuell waren, als die Untersuchung durchgeführt wurde. Denn die Cyberkriminellen arbeiten aktiv weiter an BlackHole: Um die Erkennung durch Antiviren-Lösungen zu erschweren, verändern sie den Code des einen oder anderen Exploits recht häufig, beispielsweise ändern sie die von ihnen verwendeten Entschlüsselungsalgorithmen.

Startseite des Exploit-Packs

Die Startseite des Exploit-Packs wird zur Definition der Eingangsparameter sowie zur Entscheidungsfindung über das weitere Vorgehen des Exploit-Packs verwendet. Zu den Eingangsparametern gehören die Betriebssystem-Version des Anwenders, die Version des Browsers und der installierten Plug-Ins, die Systemsprache und andere. In der Regel werden in Abhängigkeit von den Eingangsparametern die entsprechenden Exploits für den Angriff auf das System ausgewählt. Fehlt die vom Exploit-Pack benötigte Software auf dem Computer des Anwenders, erfolgt auch kein Angriff. Attacken können auch dann ausbleiben, wenn die Cyberkriminellen verhindern wollen, dass der Inhalt des Exploit-Packs Antiviren-Experten oder anderen Forschern in die Hände fällt. Die Online-Verbrecher können beispielsweise die IP-Adressen von Analyse-Unternehmen (Crawler, Robots, Proxy-Server) in ihre „schwarzen Listen“ aufnehmen, den Start von Exploits auf virtuellen Maschinen blockieren und mehr.

Auf dem folgenden Screenshot sieht man ein Beispiel für den Code einer Landing-Page des Exploit-Packs BlackHole.

 
Screenshot des Codes einer Startseite des Exploit-Packs BlackHole

Selbst bei einem flüchtigen Blick auf den Screenshot sieht man, dass der JavaScript-Code obfuskiert und ein großer Teil der Informationen verschlüsselt ist.

Eine Verbindung mit der Startseite hat zur Folge, dass Code ausgeführt wird, der ursprünglich verschlüsselt war. Um die Erkennung zu erschweren, wenden die Cyberkriminellen spezielle Techniken an (auf dem Screenshot gelb eingekreist).

Darüber hinaus wird eine Vielzahl geringster Veränderungen im Code vorgenommen, die die Signatur-basierte Detektion verhindern können. Obgleich z.B. in unserer AV-Engine ein Skript-Emulator enthalten ist und einfache Veränderungen der Konstanten und Operationen keinen Einfluss auf die Effektivität der Detektion haben. Allerdings kann auch dem Emulator die Arbeit mit Hilfe der oben beschriebenen Methoden erschwert werden.

Nach der Entschlüsselung des Codes erscheint dieser im Arbeitsspeicher — nennen wir ihn „entschlüsseltes Skript“. Er besteht aus zwei Teilen.

Der erste Teil ist ein Modul der kostenlosen Bibliothek PluginDetect, die es ermöglicht, die Versionen und die Möglichkeiten der meisten modernen Browser und deren Plug-Ins zu ermitteln. Die Cyberkriminellen verwenden verschiedene Bibliotheken, doch dieses Modul ist eines der Schlüsselelemente jedes beliebigen Exploit-Packs. BlackHole verwendet PluginDetect, um in Abhängigkeit von der auf dem Anwenderrechner installierten Software aus der Sammlung die passenden Exploits für den Download auszuwählen. Unter passend verstehen wir die Exploits, bei denen die Wahrscheinlichkeit am höchsten ist, dass sie erfolgreich ihre Funktion ausführen und ein Schadprogramm auf einem konkreten Computer starten können.

Der zweite Teil des „entschlüsselten Skripts“ ist ein Code, der für die Verarbeitung der Ergebnisse verantwortlich ist, die aus der Ausführung der Funktionen von PluginDetect resultieren, sowie für den Download der ausgewählten Exploits und deren anschließenden Start.

Im März 2013 verwendete BlackHole Exploits zu den folgenden Sicherheitslücken:

  1. Java-Versionen von 1.7 bis 1.7.х.8 – CVE-2012-5076;
  2. Java-Versionen niedriger als 1.6 oder von 1.6 bis 1.6.х.32 – CVE-2012-0507;
  3. Java-Versionen von 1.7.х.8 bis 1.7.х.10 – CVE-2013-0422;
  4. Adobe Reader-Versionen niedriger als 8 – CVE-2008-2992;
  5. Adobe Reader-Version 8 oder von 9 bis 9.3 – CVE-2010-0188;
  6. Adobe Flash-Versionen von 10 bis 10.2.158 – CVE-2011-0559;
  7. Adobe Flash-Versionen von 10.3.181.0 bis 10.3.181.23 und niedriger als 10.3.181 – CVE-2011-2110.

Im Folgenden betrachten wir die Exploits zu den Java-Sicherheitslücken (die detaillierte technische Analyse finden Sie in der englischen Version des Artikels).

Drei in einem

Die Funktionsmechanismen dieser drei Java-Exploits sind praktisch identisch – sie erhalten die Privilegien und starten die Payload, die die Zieldatei lädt und ausführt. Auch die Java-Klassendateien, die von jedem der drei Exploits generiert werden, stimmen überein. Daher kann man durchaus behaupten, dass für die Entwicklung dieser Exploits ein und dieselbe Personengruppe verantwortlich ist, bzw. ein und dieselbe Person. Allein die Art und Weise, auf die die uneingeschränkten Privilegien für die Klassendatei empfangen werden, unterscheidet sich.

Diese Klassendatei ist in der Lage, Dateien zu laden und zu starten, indem sie die aus dem entschlüsselten Skript übermittelten Parameter dechiffriert. Um die Erkennung zu erschweren, ist die zu ladende Schaddatei üblicherweise verschlüsselt, und beginnt dementsprechend nicht mit einem PE-Header. Die geladene Datei wird im Speicher normalerweise mit Hilfe des XOR-Algorithmus entschlüsselt.

Die Übermittlung der Parameter aus dem entschlüsselten Skript ist eine bequeme Methode, die Links schnell zu ändern, über die die Payload geladen wird, da hierfür lediglich die Informationen auf der Startseite des Exploit-Packs verändert werden müssen, ohne Neukompilierung des schädlichen Java-Applets selbst.

Die drei untersuchten Sicherheitslücken sind so genannte logical flaws, d.h. Fehler in der Logik. Der Aufruf von Exploits zu solchen Schwachstellen lässt sich nicht mit automatisierten Mitteln kontrollieren, die beispielsweise die Vollständigkeit des Speichers oder die Erzeugung von Ausnahmen überprüfen. Daher können diese Exploits nicht mit Hilfe der Technologien DEP und ALSR von Microsoft und von analogen automatisierten Methoden erkannt werden. Allerdings gibt es Technologien, die in der Lage sind, mit dieser Widrigkeit fertig zu werden, unter anderem unsere Automatic Exploit Prevention (AEP).

Schutz vor Java-Exploits

Ungeachtet aller Anstrengungen seitens der Cyberkriminellen, sind moderne Schutzlösungen in der Lage, Drive-by-Attacken, die mit Hilfe von Exploit-Packs durchgeführt werden, effektiv abzuwehren. In der Regel wird zum Schutz vor Exploits ein ganzes Set von Technologien eingesetzt, die es ermöglichen, derartige Angriffe auf den verschiedenen Etappen abzuwehren.

Oben haben wir die Funktionsprinzipien des Exploit-Packs BlackHole betrachtet. Wenden wir uns nun am Beispiel der Lösungen von Kaspersky Lab dem Schutz vor Angriffen unter Verwendung von Java-Exploits aus BlackHole auf jeder einzelnen Etappe zu. Da andere Exploits-Packs nach einem analogen Schema funktionieren wie BlackHole, kann das von uns betrachtete Schema als allgemeingültig angesehen werden.

 
Schema des Etappen-Schutzes vor Drive-by-Attacken

Schauen wir uns nun einmal an, welche Schutzkomponenten zu welchem Zeitpunkt mit dem Schadcode interagieren.

Erste Etappe: Blockierung des Übertritts auf die Landing-Page

Die Attacke beginnt in dem Augenblick, in dem der Anwender die Landing-Page des Exploit-Packs besucht. Allerdings kann die Webkomponente des Antivirus‘ eine Attacke bereits vor deren Beginn verhindern, d.h. bis zum Start des Skripts der Landing-Page. Diese Schutz-Komponente überprüft die Adresse der Webseite, auf der der Übertritt vollzogen werden soll. Im Grunde handelt es sich um eine einfache Überprüfung, ob die URL in der Datenbank der schädlichen Links vorhanden ist, doch dadurch kann der Übergang des Anwenders auf die Startseite des Exploit-Packs blockiert werden, wenn die entsprechende Adresse bereits als schädlich bekannt ist.

Die Aufgabe der Antiviren-Unternehmen besteht in diesem Zusammenhang darin, die schädlichen Links so schnell wie möglich der Datenbank hinzuzufügen. Die Datenbanken mit den schädlichen URL können auf dem Computer des Anwenders gespeichert sein oder in der Cloud (d.h. also auf einem entfernten Server). In letztgenanntem Fall ermöglichen es die Cloud-Technologien, das Zeitintervall auf ein Minimum zu verkürzen, in dem das Schutzprodukt beginnt, die neuen schädlichen Links zu blockieren. Die Reaktionszeit wird deswegen verringert, weil die Schutzlösung auf dem Computer des Anwenders Informationen über neue Bedrohungen sofort nach dem Erscheinen des entsprechenden Eintrags in der Datenbank mit den gefährlichen Links erhält, und nicht erst bis zum nächsten regulären Update der AV-Datenbanken gewartet werden muss.

Die Cyberkriminellen versuchen ihrerseits, die Domains schnell zu ändern, auf denen sich die Startseiten der Exploit-Packs befinden, um eine Sperrung dieser Seiten durch Schutzsoftware zu verhindern. Im Endeffekt verringert das die Rentabilität ihrer Geschäfte.

Zweite Etappe: Detektion durch den Datei-Antivirus

Wenn der Anwender trotzdem auf der Startseite gelandet ist, so kommen die Komponenten des Datei-Antivirus ins Spiel – der statische Detektor und der heuristische Analyser. Sie überprüfen die Landing-Page des Exploit-Packs auf Schadcode. Schauen wir uns einmal das Funktionsprinzip sowie die Vor- und Nachteile jeder der Komponenten an.

  • Der statische Detektor verwendet statische Signaturen zur Erkennung von Schadcode. Diese Signaturen beziehen sich streng auf bestimmte Code-Fragmente bzw. auf konkrete Byte-Folgen. Diese Methode zur Erkennung von Bedrohungen wurde bereits in den ersten Antiviren-Programmen eingesetzt und ihre Vorteile sind bestens bekannt – die Arbeitsgeschwindigkeit und die einfache Speicherung der Signaturen. Um ein Urteil fällen zu können, muss der Detektor lediglich die im Laufe der Analyse erhaltene Kontrollsumme oder die Byte-Folge mit den entsprechenden Einträgen in der Antiviren-Datenbank vergleichen. Die verwendeten Signaturen belegen je einige Dutzend Byte und werden gepackt, daher sind sie problemlos zu speichern. Der größte Nachteil des statischen Detektors liegt darin, dass es relativ einfach ist, die Signaturen zu „umgehen“. Cyberkriminelle müssen zu diesem Zweck lediglich einen der maßgeblichen Bytes austauschen und das Objekt wird nicht mehr detektiert. Aus dem ersten Nachteil ergibt sich der zweite – um eine große Menge Dateien abzudecken, ist auch eine große Menge an Signaturen erforderlich, was wiederum zu einer bedeutenden Vergrößerung der Datenbanken führt.
  • Der heuristische Analyser verwendet ebenfalls Signaturen, doch er funktioniert nach einem vollkommen anderen Prinzip. Ihm liegt eine Analyse des eingehenden Objekts zugrunde: Das Sammeln und die intelligente Verarbeitung von Angaben über das Objekt, das Herausarbeiten von Gesetzmäßigkeiten in ihnen, das Erstellen von Statistiken und mehr. Wenn die aufgrund der Analyse erhaltenen Daten den Bedingungen der heuristischen Signatur entsprechen, so wird das Objekt als schädlich detektiert. Der wichtigste Vorteil der heuristischen Signatur liegt in der Möglichkeit, auf einen Schlag eine große Zahl von gleichartigen Objekten zu erkennen, die sich nur unwesentlich voneinander unterscheiden. Der Nachteil gegenüber der Verarbeitung statischer Signaturen besteht darin, dass der heuristische Analyser langsamer arbeitet und die Systemfunktionen ausbremsen kann. Wenn eine heuristische Signatur beispielsweise nicht effektiv programmiert ist, so äußert sich das in einer großen Zahl von Operationen, die zur Ausführung des Überprüfungsalgorithmus‘ unerlässlich sind, was sich wiederum negativ auf die Handlungsgeschwindigkeit des Systems auswirken kann, auf dem der Antivirus läuft.

Um die Detektion eines Objektes mit Hilfe statischer Signaturen zur verhindern, sind Cyberkriminelle gezwungen, so oft wie möglich minimale Veränderungen im Code des Objekts vorzunehmen (Skript, ausführbare Programme, Dateien). Dieser Prozess kann bis zu einem gewissen Grad automatisiert werden.

Um die heuristische Detektion zu verhindern, muss der Virenschreiber herausfinden, aufgrund welcher Kriterien das Objekt erkannt wird. Ist der Algorithmus teilweise oder vollständig ausgewertet, so müssen in den Code des schädlichen Objekts Veränderungen eingebracht werden, die die Funktion der heuristischen Signaturen behindern.

Auf die „Umgehung“ der heuristischen Signatur müssen die Cyberkriminellen also eindeutig mehr Zeit verwenden als auf die Verhinderung der Erkennung mit Hilfe statischer Signaturen. Und das bedeutet, dass die „Lebenszeit“ einer heuristischen Signatur von längerer Dauer ist. Hat der Virenautor bei einem detektierten Objekt Veränderungen vorgenommen, um die heuristische Erkennung künftig zu verhindern, so müssen andererseits die AV-Anbieter ebenfalls Zeit auf die Entwicklung einer anderen Signatur verwenden.

So verwenden AV-Lösungen für die Überprüfung der Landing-Page eine ganze Sammlung von Signaturen. Die Virenschreiber produzieren ihrerseits auf der Startseite des Exploit-Packs Modifikationen der Objekte, die es ermöglichen, die Signatur-basierte Erkennung beider Typen zu umgehen. Während die Cyberkriminellen zur Umgehung der statischen Signaturerkennung lediglich die Zeilen in Symbole zerlegen brauchen, so müssen sie zur Umgehung der Heuristik die Feinheiten der Sprache JavaScript ausloten – ungewöhnliche Funktionen, Vergleiche, logische Ausdrücke und mehrs. Ein Beispiel für eine entsprechende Obfuskation haben wir im ersten Teil des Artikels gegeben. Auf dieser Etappe erfolgt häufig die Erkennung, insbesondere wegen außergewöhnlicher Obfuskation des Codes, die als Merkmal für ein schädliches Objekt angesehen werden kann.

Neben den Datenbanken, die auf der Festplatte gespeichert sind, gibt es auch in der Cloud Signaturen. Für gewöhnlich sind solche Signaturen äußerst simpel, doch die extrem kurze Reaktionszeit auf neue Bedrohungen (bis 5 Minuten ab Erstellung der Signatur bis zum Erscheinen in der Cloud) gewährleistet einen qualitativ hochwertigen Schutz des Anwendercomputers.

Dritte Etappe: Signatur-basierte Erkennung von Exploits

Ist es der Schutzlösung nicht gelungen, die Startseite des Exploit-Packs zu identifizieren, so nimmt dieses seine Arbeit auf. Es checkt die im Browser installierten Plug-Ins (Adobe Flash Player, Adobe Reader, Oracle Java, usw.) und legt dann fest, welche Exploits geladen und gestartet werden. Dabei überprüft die Schutzlösung jedes zu ladende Exploit genauso wie die Startseite des Packs – mit Hilfe des Datei-Antivirus und den Signaturen in der Cloud. Die Cyberkriminellen ihrerseits wenden Methoden zur Umgehung der Detektion an – dieselben wie oben bereits beschrieben.

Vierte Etappe: proaktive Erkennung von Exploits

Für den Fall, dass keine der reaktiven Schutz-Komponenten (Signatur-basiert) bei der Überprüfung des Inhalts des Exploit-Packs etwas Verdächtiges entdeckt hat und ein Exploit gestartet wurde, so nehmen sich die Module des proaktiven Schutzes der Sache an. Sie verfolgen in Echtzeit, wie die einen oder anderen Anwendungen sich im System verhalten und stellen so schädliche Aktivität fest.

Jede Anwendung wird auf der Grundlage einer heuristischen Analyse, aufgrund von Informationen aus der Cloud oder aufgrund anderer Merkmale als „vertrauenswürdig“, „mit geringen Beschränkungen“, „mit hohen Beschränkungen“ oder als „nicht vertrauenswürdig“ klassifiziert. Die „Programmkontrolle“ beschränkt die Aktivität einer Anwendung in Abhängigkeit von dem ihr zugeteilten Status. Anwendungen mit dem Status „vertrauenswürdig“ sind alle Aktivitäten erlaubt, Programmen der Klasse „geringe Beschränkungen“ ist beispielsweise der Zugriff auf den Passwortspeicher verboten, Anwendungen der Kategorie „hohe Beschränkungen“ ist es verboten, Veränderungen in den Systemverzeichnissen vorzunehmen usw. Alle gestarteten und laufenden Anwendungen werden mit Hilfe eines Moduls analysiert, das in unseren Produkten die Bezeichnung Anwendungskontrolle (Application Control) trägt. Diese Komponente kontrolliert die Ausführung von Programmen im System mit Hilfe von Low-Level-Abfängern.

Zur Identifizierung von gefährlichem Verhalten eines Programms werden zudem spezielle Verhaltenssignaturen eingesetzt, die schädliche Aktivität beschreiben. Die Verhaltenssignaturen werden von Virenanalysten geschrieben und mit dem Verhalten einer laufenden Anwendung verglichen. Dadurch können die proaktiven Schutzkomponenten auch neue Malware-Versionen erkennen, die nicht in die Kategorien „nicht vertrauenswürdig“ oder „hohe Beschränkungen“ fallen. Diese Art der Detektion ist am effektivsten, da die Daten über die reale Programmaktivität zum aktuellen Zeitpunkt analysiert werden, und keine statische oder heuristische Analyse durchgeführt wird. Das hat zur Folge, dass die von Cyberkriminellen eingesetzten Methoden, wie etwa Obfuskation oder Verschlüsselung des Codes völlig ineffektiv werden, da sie keinerlei Einfluss auf das Verhalten eines Schadprogramms haben.

Für eine noch sorgfältigere Kontrolle von Anwendungen, in denen Sicherheitslücken von Exploits ausgenutzt werden könnten, setzten wir die Technologie AEP, Automatic Exploit Prevention, ein. Die Komponente AEP kontrolliert den Start jedes Prozesses im System, d.h. sie untersucht den Aufrufstapel auf Anomalien, überprüft den Code, der den Start des Prozesses verursacht und anderes. Darüber hinaus überprüft diese Komponente punktuell die dynamischen Bibliotheken, die im Prozess geladen werden.

Mittels aller dieser beschrieben Aktionen ist es möglich, den Start von schädlichen Prozessen infolge der Ausnutzung einer Sicherheitslücke durch ein Exploit zu verhindern. Praktisch ist das die letzte Verteidigungslinie, die einen Schutz vor Exploits in dem Fall gewährleistet, wenn alle andere Schutzkomponenten nicht gegriffen haben. Wenn eine Anwendung, beispielsweise Oracle Java oder Adobe Reader, sich aufgrund eines Exploit-Starts verdächtig verhält, so wird die angreifbare legitime Anwendung von dem Antivirus blockiert, so dass auch das Exploit nicht ausgeführt werden kann.

Da auf dieser Etappe das Verhalten des Programms untersucht wird, müssen die Cyberkriminellen an dieser Stelle äußerst komplexe und aufwändige Methoden zum Einsatz bringen, wollen sie den proaktiven Schutz außer Gefecht setzen.

Fünfte Etappe: Erkennung von geladenen Schadprogrammen (Payload)

Bleibt ein Exploit trotz allem unbemerkt, versucht es, Payload auf den Computer des Anwenders zu laden und zu starten.

Um die Erkennung zu erschweren, ist – wie bereits oben erwähnt - die schädliche Datei, die von einem Exploit geladen wird, meist verschlüsselt und beginnt dementsprechend nicht mit einem PE-Header. Die geladene Datei wird im Speicher meist mit Hilfe des XOR-Algorithmus‘ dechiffriert. Daraufhin wird die Datei entweder aus dem Speicher gestartet (üblicherweise ist das eine dynamische Bibliothek) oder auf die Festplatte transferiert und von der Festplatte gestartet.

Durch den Trick mit dem Laden der verschlüsselten PE–Datei kann der Antivirus außer Gefecht gesetzt werden, da ein solcher Download für ihn aussieht wie ein gewöhnlicher Datenstrom. Doch wichtig ist, dass das Exploit auf dem Anwenderrechner die bereits entschlüsselte ausführbare Datei startet. Und der Antivirus jagt diese Datei durch alle verfügbaren Schutztechnologien, die wir oben beschrieben haben.

Fazit

Exploit-Packs sind komplexe Systeme zum Eindringen in den Opfer-Computer. –Cyberkriminelle verwenden viel Mühe darauf, die Effektivität von Exploit-Packs zu verbessern und die Erkennung zu verhindern. Die Antiviren-Anbieter wiederum perfektionieren ihre Schutzsysteme. Heute steht den AV-Unternehmen eine Auswahl an Technologien zur Verfügung, die es ermöglichen Drive-by-Attacken auf allen Etappen zu blockieren, unter anderem auch zu dem Zeitpunkt, zu dem die Exploits zu den Sicherheitslücken aufgerufen werden.

Quelle:
Kaspersky Lab
 

Copyright © 1996 - 2014
Kaspersky Lab
Industry Leading Antivirus Software
Alle Rechte vorbehalten
 

Email: webmaster@kaspersky.com
Datenschutzbestimmungen