Skip to content

Clickjacking gegen Flash, urchin.js und Duqu - nichts als Wiederholungen!

Wiederholungen, nichts als Wiederholungen. Nein, ich meine nicht das TV-Programm im Sommer(loch). Auch die Cyberkriminellen haben in letzter Zeit auf Bewährtes gesetzt: Clickjacking gegen Flash, Massen-SQL-Injection und Code-Recycling sind angesagt. Und in allen drei Fällen sind weitere Wiederholungen zu erwarten. Wenn das nur nicht in einer Endlosschleife endet...

Etwas Clickjacking, und Webcam & Mikrofon gehorchen dem Angreifer

Feross Aboukhadijeh hat einen Clickjacking-Angriff auf Adobes Flash Player Settings Manager beschrieben und auch eine Online-Demo dazu veröffentlicht (die aber inzwischen nicht mehr funktioniert). Während das Opfer ein kleines Spiel spielt und dabei auf hin- und herspringende Schaltflächen klickt, wird unsichtbar der Settings Manager so konfiguriert, dass der Angreifer danach Zugriff auf Webcam und Mikrofon hat. Wem das bekannt vorkommt: Ja, genau dieses Problem gab es schon mal. Mit genau diesem Angriff hat Guy Aharonovsky 2008 Clickjacking demonstriert.

Damals reagierte Adobe recht schnell und sorgte noch am gleichen Tag mit einem Framebuster dafür, dass der Settings Manager nicht mehr in einem iframe eingebunden werden kann. Dummerweise wurde dabei übersehen, dass ein Angreifer statt der kompletten Seite auch einfach nur die .SWF-Datei des Settings Manager in einem iframe öffnen kann, um darin die Einstellungen zu manipulieren. Und genau das hat Feross Aboukhadijeh nun ausgenutzt.

Wiederholungsgefahr

Diesmal hat Adobe etwas länger gebraucht, um die Schwachstelle zu beheben. Dann bin ich ja mal gespannt, wie lange sie beim nächsten Mal brauchen. Denn das wird bestimmt kommen, wenn jemand sich die Mühe macht und den Settings Manager in einem iframe mit sandbox-Attribut einbindet und dadurch den Framebuster ins Leere laufen lässt. Der einzige wirksame Schutz vor Clickjacking, der X-FRAME-OPTIONS-HTTP-Header, ist nämlich auf der Seite mit dem Settings Manager nicht gesetzt. Wenn jemand Langeweile hat: Da gibt es 5 Minuten Ruhm zu ernten. Eigentlich müsste es reichen, in Guy Aharonovskys Demo das sandbox-Attribut des iframes zu setzen.

Kommentare über die Idee, eine sicherheitsrelevante Einstellung auf einem Server im Internet und nicht auf dem lokalen Rechner vorzunehmen, verkürze ich auf ein kurzes "*sinnig". Ob der * für "Schwach" oder "Wahn" steht, darf sich jeder selbst aussuchen. Eine längere Stellungnahme dazu gibt es von Steven Bellovin, der habe ich nichts hinzuzufügen. Andererseits ist Flash sowieso schon so großer Unsinn, dass es auf einen Sargnagel mehr oder weniger auch nicht mehr ankommt. Und um einen alten Witz abzuwandeln: Ja, ich habe etwas gegen den Flash Player. Sogar etwas Wirkungsvolles: Man kann den nämlich einfach löschen oder noch besser gar nicht erst installieren. Und schon hat man sein System sicherer gemacht.

Massenangriff mit SQL-Injection auf ASP.NET-Websites, Auflage n

SQL-Injection-Massenangriffe auf ASP.NET-Websites, um die für Drive-by-Infektionen zu präparieren, sind ein altbekanntes Problem, das bisher meist im Frühling auftrat. Der bescheidene Sommer scheint die Cyberkriminellen etwas verwirrt zu haben, so dass sie ihre nächste Angriffswelle schon jetzt gestartet haben. Die aktuellen Angriffe werden anscheinend von den gleichen Cyberkriminellen durchgeführt, die bereits im Frühjahr dieses Jahres aktiv waren.

Unnötige Wiederholungen

Eigentlich sollte man doch annehmen, das es nach all den Massenangriffen keine ASP.NET-Websites mit SQL-Injection-Schwachstellen mehr gibt. Die müssten doch inzwischen alle mindestens einmal kompromittiert und danach die Schwachstellen behoben worden sein. Immerhin verraten sich diese Angriffe dadurch, dass sie ihren Schadcode in jedes erreichbare Textfeld schreiben und so z.B. auch im title-Tag landen, wodurch sich die meisten infizierten Seiten nach dem ersten Blick aufs Browserfenster und vor allem auch in den Suchmaschinenergebnissen sofort verraten. Aber anscheinend gibt es immer noch so viele Webanwendungen mit SQL-Injection-Schwachstellen, dass sich ein Angriff mit der digitalen Schrotflinte lohnt. Ich hoffe doch, Sie haben Ihre Webanwendung(en) auf Schwachstellen geprüft oder prüfen lassen und warten nicht darauf, dass es Hacker oder Cyberkriminelle für Sie erledigen?

Gut getarnt ist halb gewonnen

Sehr viel Geschickter gehen übrigens seit kurzem Cyberkriminelle vor, die es auf PHP-Webanwendungen abgesehen haben. Die geben sich große Mühe, damit ihre Manipulationen nicht entdeckt werden, so dass sie möglichst lange Schaden anrichten können. Die manipulierte Seite wird nur ausgegeben, wenn der Besucher von einer Suchmaschinen kommt. Suchmaschinen-Bots, wiederkehrenden Besuchern und allen Besuchern, die die Seite direkt oder z.B. über ihre Bookmarks ansteuern, bekommen die Originalseite zu sehen.

Duqu - Stuxnet-Recycling zur Backdoor

Was passiert, wenn umweltbewusste Cyberkriminelle den Stuxnet-Sourcecode recyceln? Es entsteht ein Remote Administration Toolkit namens Duqu.

Das Stichwort "Stuxnet" scheint bei einigen Medien eine Panikreaktion ausgelöst zu haben, denn "Duqu" ist eines bestimmt nicht: Ein Stuxnet-Nachfolger.

Symantec hat inzwischen das Ziel der Angriffe näher (oder besser: anders) beschrieben. Es handelt sich dabei um "industrial industry manufacturers". Außerdem wird Duqu nun nicht mehr fälschlich als Wurm eingestuft - Symantec hat bemerkt, dass ihm jede Möglichkeit zur Weiterverbreitung fehlt. Wieso Duqu jemals als Wurm eingestuft werden konnte, ist mir ein Rätsel und wirft meines Erachtens kein gutes Licht auf Symantec. Das in den Medien oft sämtliche Schädlinge als "Virus" bezeichnet werden, ist eine mit Unwissenheit oder mangelndem Problembewusstsein zu entschuldigende Ungenauigkeit. Aber ein Hersteller von Lösungen zum Erkennen von Schadsoftware sollte doch genau angeben, um was für Schadsoftware es sich handelt.

Gefährlich für wen?

Und wenn Symantec nun schreibt

"Considering the history of Stuxnet, the potential of the same attackers, and currently known targets, we urge industrial control system manufacturers and any other organizations who provide solutions to industrial facilities to audit their network for Duqu."

dann würde ich das um ein "in the Iran" vor dem "to audit..." ergänzen. Oder hatte Stuxnet es auf irgend etwas anderes als die iranischen Atomanlagen abgesehen? Alle anderen Infektionen von SCADA-Systemen waren doch wohl "Kollateralschäden" bzw. Irrläufer, nachdem der Wurm seine Aufgabe im Iran längst erledigt hatte. Wenn die Angreifer diesmal genauso vorgegangen sind, haben sie ihr eigentliches Ziel längst erreicht und wir sehen quasi nur die "Nachbeben", ohne vom eigentliche Beben überhaupt zu wissen.

Ach ja, und dann gibt es noch weitere Angriffsziele:

"We have also identified one or more targets outside the industrial industry who provide assets that would aid a future attack."

Ob das wohl die von McAfee als Ziel gemeldeten Zertifizierungsstellen sind? Könnte es sein, dass Symantec bzw. das zu Symantec gehörende VeriSign dazu gehört? Immerhin stammt das für die Signatur der Treiberkomponente verwendete Zertifikat von VeriSign...

Weitere Informationen

Symantec hat auch das Whitepaper (PDF) zu Duqu aktualisiert, dass nun auch die bisher fehlende Analyse der Entdecker von Duqu enthält. Außerdem wurde mitgeteilt, um wen es sich dabei handelt: Das Laboratory of Cryptography and System Security (CrySyS) des Department of Telecommunications der Budapest University of Technology and Economics. Dort hat man ein Statement zu Duqu veröffentlicht, das aber keine weiterführenden Informationen enthält.

Inzwischen gibt es eine weitere Analyse von Duqu sowie eine FAQ dazu, beide von Kaspersky. Auch dort berichtet man von Angriffen auf Zertifizierungsstellen, um den Schädling dann mit Hilfe erbeuteter Zertifikate besser zu tarnen. Und in der Tat besitzt ja erst die Treiber-Komponente der zweite Duqu-Variante eine gültige Signatur.

Die entscheidende Frage

Die m.E. wichtigste Information fehlt uns aber noch: Es ist immer noch nicht bekannt, wie Duqu auf die infizierten Rechner gelangt. Die Antwort auf die Frage, wie das sich nicht selbst verbreitende RAT auf die Rechner kommt, interessiert mich viel mehr als die nach den möglichen Zielen oder Urhebern. Stuxnet hat 4 0-Day-Exploits eingesetzt, wie viele der Code zum Einschleusen von Duqu wohl enthält? Oder hat da irgend ein Zoll nachgeholfen und Schwachstellen wurden gar nicht benötigt?

Carsten Eilers

Trackbacks

Dipl.-Inform. Carsten Eilers am : Lilupophilupop - Eine SQL-Injection-Welle ist unterwegs

Vorschau anzeigen
SQL-Injection-Angriffe auf ASP-Websites gibt es eigentlich ständig, meist ohne dass sie besondere Aufmerksamkeit erregen. Von Zeit zu Zeit gibt es auch größere Wellen, wie z.B. LizaMoon im Frühjahr 2011. Auch im Herbst 2011

www.ceilers-news.de am : PingBack

Die Anzeige des Inhaltes dieses Trackbacks ist leider nicht möglich.

Dipl.-Inform. Carsten Eilers am : SQL-Injection im Schnelldurchlauf

Vorschau anzeigen
Laut dem Cloud-Hosting-Anbieter FireHost ist die Zahl der erkannten SQL-Injection-Angriffe zwischen April und Juni 2012 um 69% gestiegen. Während im 1. Quartal 2012 "nur" 277.770 Angriffe abgewehrt wurden, waren es im 2. Quartal 469.983 Angr

Dipl.-Inform. Carsten Eilers am : Code Signing - Auch Schadsoftware kann signiert sein

Vorschau anzeigen
Oracles Antwort auf Javas ständige Sicherheitsprobleme: Der Einsatz von Code Signing. Vorerst gibt es nur mehr oder weniger ausführliche Warnungen vor nicht oder falsch signierten Applets, irgendwann sollen dann nur noch signierte Apple