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?
Trackbacks
Dipl.-Inform. Carsten Eilers am : Lilupophilupop - Eine SQL-Injection-Welle ist unterwegs
Vorschau anzeigen
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
Dipl.-Inform. Carsten Eilers am : Code Signing - Auch Schadsoftware kann signiert sein
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Kommentare zu Webcam-Spannern, EMET 4.0 und einer neuen 0-Day-Schwachstelle
Vorschau anzeigen