Angriffsvektoren für Exploit-Kits – Zwischenbilanz zum Ende des ersten Halbjahres

Einleitung

Es ist äußerst interessant zu beobachten, wie gering die Lebensdauer eines Exploit-Kits ist. Manche dieser Kits waren noch vor einiger Zeit weit verbreitet und haben Tausende Rechner infiziert, doch inzwischen kommen sie überhaupt nicht mehr zum Einsatz. Noch interessanter ist die Tatsache, dass einige der älteren Kits – ausgerüstet mit frischen, neuen Exploits – ihr Comeback starten und in den Malware-Ranglisten die vorderen Plätze belegen.

Am bemerkenswertesten ist jedoch die Art und Weise, wie die aktuellen Exploits verwendet werden und gegen welche Ziele sie sich richten.

Um eine Prognose erstellen zu können, analysieren wir zunächst die Situation im Jahr 2010. Die folgenden Exploit-Kits waren im vergangenen Jahr am meisten verbreitet:

  1. Phoenix
  2. Eleonore
  3. Neosploit
  4. YESExploitKit
  5. SEOSploitPack

Gegen Ende 2010 ging die Verbreitung von Phoenix rasant zurück. Dagegen nahm die Anzahl der Server zu, über die NeoSploit verbreitet wird.

Die Exploits nutzen Sicherheitslücken in den folgenden Produkten aus:


Entscheidend hierbei ist nicht das statische Bild, sondern die dynamische Darstellung. So schafften es Java-Sicherheitslücken innerhalb eines einzigen Jahres auf den dritten Platz. 40 Prozent aller neuen, im Jahr 2010 von den Top 5 der Exploit-Kits ausgenutzten Sicherheitslücken richteten sich gegen Java. Laut meinem Kollegen Dan Guido enthielten elf der Top-15-Kits mindestens ein Java-Exploit und sieben der Top-15-Kits enthielten gleich mehrere.

Der nächste Schritt in der Analyse besteht darin, diese Daten mit weiteren Informationen abzugleichen. Laut Microsoft Malware Protection Center erreichten die Angriffsversuche, die auf die Ausnutzung einer Schwachstelle in Java abzielten, im letzten Jahr einen Höhepunkt:

(Quelle: http://arstechnica.com/business/news/2010/10/microsoft-sees-unprecedented-wave-of-java-malware-exploits.ars)

Unsere eigenen Aufzeichnungen zeigen ein ähnliches Bild. In nachstehender Abbildung lässt sich die Erstellung Java-bezogener Signaturen als Reaktion auf diese erkannten Bedrohungen ablesen:

Diese Angriffsversuche wurden ebenfalls in unserer Customer Base entdeckt:

Die Frage ist: Warum ausgerechnet Java? Eine ganze Weile grübelte ich über diese Frage, bis nach der Teilnahme an Dino Dai Zovis Keynote bei der SOURCE-Konferenz bei mir plötzlich der Groschen fiel. Eigentlich war es völlig offensichtlich! Die Sicherheitsmechanismen von Betriebssystemen lassen sich am einfachsten mit einem Java-Exploit aushebeln. Ein Bild sagt hier mehr als tausend Worte:

Die Situation im Jahr 2011

Wie sieht die Situation in diesem Jahr aus? Gab es irgendwelche Veränderungen? In der Tat hat sich manches verändert, insbesondere die Top 5 der Exploit-Kits im ersten Halbjahr 2010:

2010 2011
Phoenix BlackHole
Eleonore NeoSploit
NeoSploit Phoenix
YESExploitKit Incoginto
SEOSploitPack Eleonore

Zwei neue Akteure sind auf der Bildfläche erschienen: BlackHole und Incognito. Gegen welche Schwachstellen richten sich diese Exploits?

BlackHole:

  • CVE-2010-1885: HCP
  • CVE-2010-1423: Java Deployment Toolkit Insufficient Argument Validation
  • CVE-2010-0886: Unspezifizierte Java-Schwachstelle in der Java Deployment Toolkit Komponente in Oracle Java SE
  • CVE-2010-0842: Java JRE MixerSequencer Invalid Array Index Anfälligkeit für Remotecode-Ausführung
  • CVE-2010-0840: Java Trusted Methods Chaining Remotecode-Ausführung
  • CVE-2009-1671: Java Pufferüberlauf im Deployment Toolkit ActiveX Control in
    deploytk.dll

  • CVE-2009-0927: Adobe Reader Collab GetIcon
  • CVE-2008-2992: Adobe Reader util.printf
  • CVE-2007-5659: Adobe Reader CollectEmailInfo
  • CVE-2006-0003: IE MDAC

Mit Ausnahme der ersten beiden Anfälligkeiten CVE-2010-1885 und CVE-2010-1423 finden sich im Wesentlichen die üblichen Elemente wieder, die in fast allen Kits enthalten sind. Die letzten beiden richten sich gegen Java.

Wie sieht es bei Incognito aus? Hier die entsprechende Liste:

  • CVE-2010-1885: HCP
  • CVE-2010-1423: Java Deployment Toolkit Insufficient Argument Validation
  • CVE-2010-0886: Unspezifizierte Java-Schwachstelle in der Java Deployment Toolkit Komponente in Oracle Java SE
  • CVE-2010-0842: Java JRE MixerSequencer Invalid Array Index Anfälligkeit für Remotecode-Ausführung
  • CVE-2009-0927: Adobe Reader Collab GetIcon
  • CVE-2008-2992: Adobe Reader util.printf
  • CVE-2007-5659/2008-0655: Adobe Reader CollectEmailInfo
  • CVE-2006-4704: Microsoft Visual Studio 2005 WMI Object Broker Anfälligkeit für Remotecode-Ausführung
  • CVE-2004-0549: ShowModalDialog Methode und Modifizierung des Orts zur Codeausführung

Abgesehen von den letzten beiden Exploits (CVE-2006-4704 und CVE-2004-0549) stimmt diese Liste mit der BlackHole-Liste exakt überein.

Wie lautet nun unser Fazit? Diese beiden Kits fügen der Malware-Landschaft keinerlei Neuerungen hinzu, sondern nehmen Java immer noch mit denselben Exploits ins Visier.

Aus dieser Analyse können wir nun einige Schlussfolgerungen ableiten:

  • Der Grund, warum Java inzwischen die am häufigsten angegriffene Plattform ist, liegt darin, dass sich damit die wichtigsten Sicherheitsmechanismen von Betriebssystemen am einfachsten umgehen lassen.
  • Die Veränderungen in den Top 5 der häufigsten Exploit-Kits stehen nicht in Zusammenhang mit den jeweils verwendeten Exploits.
  • Die Ausnutzung wertvoller Zero-Day-Lücken ist nicht notwendig, da immer noch ältere Sicherheitslücken auf ungepatchten Rechnern ausgenutzt werden können.

Wieder einmal liefern die Cyberkriminellen einen klaren Beweis dafür, wie sehr sie auf die Rentabilität ihrer Machenschaften achten. Sie gehen nur so weit wie notwendig, um den IT-Schutzmechanismen stets einen Schritt voraus zu sein. Ein anderer wohl bekannter Spruch ist hier äußerst zutreffend: Die Sicherheit ist nur so stark wie das schwächste Glied in der Kette – in diesem Fall ist eben Java das schwächste Glied.

Bei Kaspersky Lab werden wir die Bedrohungslandschaft auch weiterhin untersuchen und alle interessanten Veränderungen genau im Auge behalten.

Der Artikel und Zitate daraus dürfen unter Nennung des Unternehmens Kaspersky Lab sowie des Autors frei veröffentlicht werden.

Ähnliche Beiträge

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.