Aktuelles Java 0-Day-Exploit

Über die Aktivität des Java 0-Day-Exploits, die wir im Verlauf der letzten Woche beobachtet und verhindert haben, wurde unverantwortlicherweise in anderen Blogs berichtet, wobei die ersten Postings mit bekannten Sites verlinkt waren, die das Zero-Day-Exploit enthalten. Der Drang, etwas über diese 0-Day-Schwachstelle zu veröffentlichen, der die Kennzeichnung CVE-2012-4681 zugeordnet werden wird (ein Problem beim Verarbeiten der Zugriffskontrolle innerhalb von „Protection-Domains“), war an sich unverantwortlich. Würde man eine Wanderer dazu ermutigen, ohne jeglichen Schutz eine dunkle Straße mit Wegelagerern entlang zu gehen, oder würde man nicht vielmehr den richtigen Leuten den Aufenthaltsort der Wegelagerer mitteilen und diese Straße besser beleuchten oder vielleicht auch einen anderen Weg empfehlen? Würde man den Straßenräubern neue Waffen zuspielen, die sie bisher selbst gar nicht in Erwägung gezogen haben? Die hier getroffenen Maßnahmen scheinen in diesem Fall etwas fehl am Platze.
Wie dem auch sei, die Websites, die das Exploit ursprünglich gehostet haben, waren sehr vereinzelt und haben bekannte, APT-zugehörige Toolset-Komponenten verbreitet, inklusive einer Poison Ivy-Variante. Hier eine etwas überraschende Heatmap der frühen damit zusammenhängenden PIvy-Detektionen.

207319928

Und hier eine Heatmap der frühen Detektionen für zugehörige Webseiten und Javaskript, die das Java-Exploit transportieren:

207319929

Alle hiermit in Verbindung stehenden Schadprogramme, die mir bis zu diesem Zeitpunkt untergekommen sind, haben ausschließlich Windows-Systeme angegriffen. Die Exploits richten etwas gegen Java 7 aus, und seit den ersten zielgerichteten Attacken machen Neuigkeiten die Runde und die Samples verbreiten sich innerhalb der Sicherheits-Community. Die Exploits sind mittlerweile bei Metasploit-Entwicklern angekommen, die dem Open Source Framework ein PoC hinzugefügt haben. Im Gegenzug haben die Blackhole-Autoren das Exploit ihren COTS hinzugefügt. Die Angriffe sind derzeit also weit verbreitet. Die ersten Länder, die von Blackhole attackiert wurden, waren die USA, die Russische Föderation, Weißrussland, Deutschland, die Ukraine und Moldawien. Doch im Verhältnis zu den anderen Exploits, die in dem Paket enthalten sind, werden die Opfer von dem Zero-Day nur relativ selten angegriffen. Nutzer vom Internet Explorer stehen am stärksten unter Beschuss, gefolgt von Firefox, Chrome und Opera, daneben eine Vielzahl anderer Anwendungen, die URLs innerhalb ihrer Dokumente verarbeiten und die schädliche .jar schließlich an einen Java-Client weiterleiten, wie etwa Adobe Reader.

Wir setzen eine Vielzahl von Methoden und Techniken ein, um die schädlichen Sites zu identifizieren, die Webseiten eingeschlossen, den Exploit-Code und die Backdoor-Payloads, die von diesen Sites bereitgestellt werden. Obgleich dieses bestimmte Java 0day-Exploit nun gehypt wird, greifen andere, ältere Exploits in dem Blackhole Exploit-Pack die Opfersysteme in weitaus höherer Schlagzahl an. Unsere Community ist also vor den Blackhole-Sites selbst geschützt, den Blackhole-Webpages, die das Blackhole Java 0day-Exploit bereitstellen, vor kompromittierten Sites, die auf die Blackhole-Sites umleiten, vor den verbreiteteren, älteren Blackhole-Exploits und ihren Bereitstellungs-Seiten sowie vor den Trojanern, die von diesen Blackhole-Sites transportiert werden. Zusätzlich zu all dem fügt das Modul Kaspersky „Advanced Exploit Prevention“ eine weitere Verhaltens-Schutzebene gegen das 0day-Exploit mit Hilfe von „Exploit.Java.Generic“ hinzu. Diese Ergänzung ist für mich persönlich das Interessanteste – die Exploit-Pack-Autoren haben sich darauf konzentriert den serverseitigen Polymorphismus ihrer Java-Exploits zu verbessern, und dieses AEP-Feature vereitelt derartige Bemühungen. Unseren Anwendern wird also der Zugriff sowohl auf die aktuellen Blackhole-Sites, auf individuelle Blackhole-Webpages, die als Varianten von „Trojan-Downloader.JS.Agent“ detektiert werden, auf Backdoors, detektiert als „Trojan.Win32.Generic“ und andere verweigert (d.h., 61A3CE517FD8736AA32CAF9081F808B4, DEC9676E97AE998C75A58A02F33A66EA, 175EFFD7546CBC156E59DC42B7B9F969, 0C72DF76E96FA3C2A227F3FE4A9579F3) sowie auf den Code des 0day Java-Exploits, detektiert als „HEUR:Exploit.Java.Agent.gen“ (d.h. E441CF993D0242187898C192B207DC25, 70C555D2C6A09D208F52ACCC4787A4E2, E646B73C29310C01A097AA0330E24E7B, 353FD052F2211168DDC4586CB3A93D9F, 32A80AAE1E134AFB3D5C651948DCCC7D) und anderen, zusammen mit der Runtime AEP Prevention. Wenn man also einige Links zu Virustotal angezeigt bekommt, mit der unausweichlichen Beschwerde, dass ein Scanner einen speziellen Abschnitt mit modifiziertem Code übersehen hat und mit den falschen Behauptungen „AV ist defekt!“ oder „AV detektiert nicht“, sollte man dem keine Beachtung schenken. Die wahre Geschichte über clientseitige Massenausnutzung ist sehr viel komplexer als derartige Behauptungen. Einige Forscher nennen die verschiedenen Punkte im Bereitstellungsvektor eine „Killer-Kette“, und die Kaspersky-Produkte killen sie.

Gleichzeitig muss Oracle Gas geben und ein OOB-Patch bereitstellen, was sie bisher versäumt haben zu tun. Vielleicht erhöht dieser Vorfall den Druck, und Oracle beschleunigt den Update-Prozess. Sie haben einige Talente auf dem Gebiet IT-Sicherheit für sich gewinnen können, und nun sollte das Eis gebrochen sein. Besser spät als nie.

Ähnliche Beiträge

Schreibe einen Kommentar

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