Clickjacking

Beschreibung

Als Clickjacking wird ein Angriff bezeichnet, bei dem das Opfer dazu verleitet wird, im Browser auf einer Webseite ein Element (Schaltfläche, Button) anzuklicken, das entweder unsichtbar ist oder als ein anderes Element getarnt ist. Ein solcher Angriff wird häufig auch als UI Redress Attack oder UI Redressing bezeichnet.

Vorgehensweise

Der Angreifer manipuliert die für das Opfer sichtbare Benutzeroberfläche, in dem er eine schädliche Webseite in ein unsichtbares IFrame über der vom Opfer besuchten Webseite einbettet. Mit CSS kann der Angreifer die Elemente mit dem Style-Tag „z-Index“, den absoluten und relativen Positionswerten so anordnen, dass die Elemente der Webseite und das überlagerte IFrame unabhängig von Bildschirmgröße, Browsertyp und Plattform exakt übereinander liegen. Damit stimmen die unsichtbaren Schaltelemente auf der schädlichen Seite, dem IFrame, mit den Elementen auf der legitim aussehenden Seite überein, aber lösen beim Betätigen eine andere, unerwünschte, Aktion aus. Häufig tritt Clickjacking in Kombination mit Social Engineering auf, um das Opfer auf die gefährdete bzw. böswillige Webseite zu lenken. Das Opfer erhält zum Beispiel einen Link mit einem Gewinn, um auf diese Webseite zu gelangen und seinen Gewinn einzulösen. Die Angriffe beinhalten nicht nur Schaltflächen, sondern können auch Eingabefelder betreffen, um zum Beispiel Login-Daten zu erhalten.

Varianten

Neben der „klassischen“ Form, gibt es noch weitere Varianten.

Likejacking

Beim Likejacking kann zum Beispiel ein unsichtbarer IFrame in eine Facebook-Seite oder in einem anderen sozialen Netzwerk eingebettet werden und der Benutzer dazu verleitet werden, auf einen „Gefällt mir“-Button zu klicken. Der Angreifer zielt dabei darauf ab, einen Schneeballeffekt zu erzeugen, indem Mitglieder des Netzwerkes und Freunde des Benutzers das gleiche tun und somit der Eintrag viele „Likes“ erhält. Das funktioniert unbemerkt aber nur, wenn der Benutzer auch auf der Webseite eingeloggt ist, ansonsten gelangt er zunächst auf die Login-Seite.

Cursorjacking

Unter Cursorjacking versteht man, die Veränderung der Cursorposition. Der tatsächliche Cursor wird durch einen gefälschten Cursor ersetzt und versetzt ihn in die Position des realen Cursors. Dabei sind beide Cursor sichtbar, aber es wird versucht, die Aufmerksamkeit auf den gefälschten Cursor zu lenken. Wenn der Benutzer mit der Fälschung auf ein Element klickt, welches er tatsächlich betätigen will, klickt der echte Cursor auf ein nicht sichtbares Element und löst damit eine böswillige Aktion aus. Cursorjacking basiert hauptsächlich auf einer Sicherheitslücke im Firefox-Browser in Zusammenhang mit Flash-, Javascript- und HTML-Code.

Cookiejacking

Das Opfer kann dazu gebracht werden, ein Element per Drag-and-Drop zu verschieben. Dabei wird der Inhalt der Cookies auf der eingebetteten, unsichtbaren Seite ausgewählt und an den Angreifer übergeben, der die Informationen aus dem Cookie lesen kann und sich als das Opfer ausgeben und so Aktionen auf der Webseite ausführen kann. Zum Beispiel kann die Einbettung des IFrames so aussehen [2]: <iframe src="file://C:/Users/%user%/AppData/Roaming/Microsoft/Windows/Cookies/%user%@google[1].txt">

Um zu wissen, wo die Cookies gespeichert werden, muss der Angreifer allerdings wissen, welches Betriebssystem der Nutzer hat. Der Pfad, in dem die Cookies gespeichert werden, variiert zwischen den Betriebssystemen. Für Windows Vista und Windows 7 sieht er folgendermaßen aus: C:/Users/%user%/AppData/Roaming/Microsoft/Windows/Cookies/%user%@google[1].txt

Unter Windows XP werden die Cookies unter „C:/Documents and Settings/%user%Cookies/„ gespeichert.

Filejacking

Der Angreifer nutzt die Fähigkeit des Browsers durch das Dateisystem des Computers zu navigieren. Beispielsweise beim Hochladen eines Fotos in sozialen Medien. Durch das Klicken auf die Schaltfläche „Dateien durchsuchen“ ermöglicht der Benutzer dem Angreifer auf sein lokales Dateisystem zuzugreifen.

Password Manager Attacks

Bei diesem Angriff werden gespeicherte Passwörter aus dem Passwort-Manager, beim automatischen Füllen von Passwörtern in Formularfelder auf Login-Seiten, dem Angreifer zugesendet.

Beispiel

Aus [6]:

Das ist die ursprüngliche Seite, auf der eine DVD zum Kauf angeboten wird

Die Seite, die das Opfer sieht, die überlagert wird. Hiermit wird das Opfer dazu verleitet, auf den Button zu klicken und seinen Preis abzuholen.

Hier sieht man wie die ursprüngliche Seite von dem iFrame überlagert wird.

Häufige Angriffsarten

Häufige Angriffsarten sind [1]:

Änderungen von Konfigurationen von Systemeinstellungen
Änderungen von Einstellungen bzw. Zugriff auf Mikrofon und angeschlossene oder integrierteWebcam
Diebstahl von Anmeldedaten
Einladung zum Herunterladen von Malware
Autorisierung von Geldtransfers
Tätigen von unaufgeforderte Produktkäufe
Standortidentifizierung

Ähnlichkeiten und Abgrenzung

Clickjacking-Angriff ähneln einem CSRF-Angriff. Bei einem solchen Angriff sendet der Angreifer mithilfe einer aktiven Session einen Request an den Zielserver. Der Angreifer sendet ein http-Request und nutzt die Benutzer-Session aus, um diese an den Server zu senden und damit eine Aktion auszulösen. Beim Clickjacking dagegen interagiert der Benutzer mit der Webseite. Hier handelt es sich um einen legitimen Benutzer-Request, beim CSRF-Angriff dagegen geschieht der gesamte Prozess ohne Wissen des Benutzers bzw. ohne, dass der Benutzer eine Eingabe oder Aktion tätigt.

Schutzmöglichkeiten und Gegenmaßnahmen

Clientseitige Schutzmöglichkeiten: Der Browser kann mit dem Intersection Observer API erkennen, ob ein IFrame auf einer Seite sichtbar ist oder ausgeblendet ist. Andere Möglichkeiten sind im Browser das Add-on „noScript“ zu nutzen, welches verhindert, dass Nutzer auf nicht sichtbare oder manipulierte Webseitenelemente klicken oder das Add-on „noClickjack“ welches das Anzeigen aller Frames auf einer Webseite erzwingt. Dennoch können clientseitige Lösungen leicht umgangen werden. Serverseitige Schutzmöglichkeiten: Eine Webseite kann über verschiedene HTML-Elemente, frame, iFrame, object, embed etc. in andere Webseiten eingebettet werden. Mit X-Frame-Options gibt es die Möglichkeit dem Browser in einem HTTP-Response einen HTTP-Header mitzugeben und festzulegen, wie sich dieser verhalten soll, wenn die Webseite in eine andere eingebettet wird. Die X-Frame-Options Direktive ist kein Standard, wird aber von vielen gängigen Browsern unterstützt, ist allerdings in den meisten Browsern veraltet. Der Header hat folgende Richtlinien-Optionen: DENY: Diese Option ist die sicherste Variante, da sie die Verwendung der aktuellen Seite in einem Frame verhindert. Der Browser blockiert das Laden und somit auch das Anzeigen der Seite in einem Frame und das unabhängig davon, welche Seite diese Anforderung stellt. Es wird generell jeder Domain untersagt. ALLOW-FROM URI: ermöglicht die Einbettung einer Seite in einem Frame von einer bestimmten URI, die mit angegeben wird. Die Option wird von den meisten Browsern nicht unterstützt. SAMEORIGIN: Die Direktive SAMEORIGIN ermöglicht das Laden der Seite in einem Frame innerhalb der aktuellen Domain. Das Einbetten der Seite auf externen Webseiten wird hiermit unterbunden. Auf einer Seite kann allerdings nur eine Option verwendet werden.

CSP (Content Security Policy) ist eine weitere Variante, die dem Browser das Einbetten von iFrames von anderen Domänen untersagt. Damit kann sichergestellt werden, dass der Nutzer nur die Elemente betätigen kann, die er tatsächlich sieht und kein für den Nutzer nicht sichtbares iFrame die Seite überlagert.

Einige mögliche Direktive von CSP sind: default-src: definiert welche Quellen für alle Direktive, die mit scr Enden, erlaubt sind script-src: definiert, welche Quellen für JavaScript erlaubt sind style-src: definiert, welche Quellen für Stylesheets erlaubt sind img-src: definiert, welche Quellen erlaubt sind, um Bilder zu laden

Wertangaben für die Direktive können sein: ‚Self‘: lässt das Einbetten von Seiten der eigenen Domain zu, aber verhindert das Einbetten von anderen Domains und lässt sich mit der X-Frame-Option SAMEORIGIN vergleichen ‚None‘: verhindert das Einbetten von iFrames und ist mit der X-Frame-Options DENY zu vergleichen Bei der Kombination von CSP und X-Frame-Option haben die CSP-Direktive Vorrang [17].