Dipl.-Inform. Carsten Eilers

Ryan Barnetts Vortrag auf der Black Hat DC 2011 hatte den Titel
“XSS Street-Fight: The Only Rule Is There Are No Rules”.
Nach einer Einführung in Cross-Site Scripting und einem
ausführlichen Beispiel (den Angriff auf Apache.org im
April 2010)
geht es um die Abwehr von XSS-Angriffen. Konkret: Strategische oder
Taktische Ansätze. Während strategische Ansätze das Problem
an der Wurzel packen und z.B. entsprechende Schwachstellen in der
Webanwendung verhindern sollen, wird bei taktischen Ansätzen eine
entdeckte XSS-Schwachstelle kurzfristig z.B. durch den Einsatz einer Web
Application Firewall (WAF) korrigiert. Danach geht es um den Einsatz einer
WAF: Um das “virtuelle Patchen” mit Hilfe von ModSecurity, bei dem die
Ausnutzung einer bekannten Schwachstelle gezielt durch entsprechende
Filterregeln verhindert wird. Virtuelles Patchen ist immer dann
notwendig, wenn die Schwachstelle in der Webanwendung selbst nicht oder
zumindest nicht kurzfristig behoben werden kann, z.B. weil der Quellcode
nicht vorliegt oder eine Änderung aufgrund des damit verbundenen
Aufwands längere Zeit dauert. Vorgestellt werden verschiedene
Ansätze samt deren Vor- und Nachteilen:

1. Blacklisting, d.h. das Ausfiltern bekannter Angriffsmuster, und
   Whitelisting, d.h. das Ausfiltern aller nicht explizit erlaubten Daten

2. Das Erkennen generischer Angriffsmuster (“Generic Attack
   Detection” oder “Generic Attack Payload Detection”)

3. Das Erkennen falscher oder fehlender Ausgabe-Kodierungen, um
   mögliche XSS-Schwachstellen etc. zu erkennen

4. Anwendungs-Profiling, um danach mögliche Angriffe an Abweichungen
   vom Normalzustand zu erkennen

5. Einfügen einer JavaScript-Sandbox in die ausgegebene Seite, um
   z.B. DOM-basiertes XSS zu verhindern (“JavaScript Sandbox
   Injection”)

Laurent Oudot: Inglourious Hackerds

Laurent Oudots Vortrag auf der Black Hat DC 2011 hatte den Titel
“Inglourious Hackerds: Targeting Web Clients”.
Schwachstellen in HTTP-Clients, speziell Webbrowsern, sollen ausgenutzt
werden, um Dritte anzugreifen und damit den eigentlichen Angreifer zu
verschleiern. Um Schwachstellen in den Clients zu finden, setzt Laurent
Oudot zuerst auf Fuzzing. Damit wurde eine Reihe von Schwachstellen in
verschiedenen HTTP-Clients wie dem Android Browser und Apples Safari
gefunden.

Als Angriff über HTTP-Clients wurde der anonyme Austausch von Daten
zwischen zwei Servern über den dafür missbrauchten Client
demonstriert. Des weiteren wurden Angriffe mit sehr langen URIs
vorgestellt. Der HTTP-Standard RFC 2616 legt keine Maximallänge
für URI fest, Server und Clients begrenzen die Länge aber schon
aus Kapazitätsgründen auf mehr oder weniger große Werte.
Die gefundenen Schwachstellen, meist Überlauf-Schwachstellen, wurden zum
größten Teil von den betroffenen Herstellern behoben.

Zum Abschluss ging es um die Frage, wie solchen Angriffen begegnet werden
kann. Laurent Oudots Vorschlag: Im Tool der Angreifer, z.B. einem
Exploit-Kit,
nach Schwachstellen suchen und darüber die Angreifer selbst angreifen.

Chris Rohlf & Yan Ivnitskiy: Attacking Clientside JIT Compilers

Der Vortrag von Chris Rohlf und Yan Ivnitskiy auf der Black Hat USA 2011
hatte den Titel
“Attacking Clientside JIT Compilers”.
Zur schnelleren Ausführung von JavaScript-Code setzten Browser
inzwischen oft Just-In-Time (JIT) Execution Engines / Compiler ein. Die
wandeln die von einem Frontend-Compiler erzeugte Intermediate
Representation (IR) in Maschinencode um und führen ihn aus. Der
Frontend-Compiler seinerseits verarbeitet z.B. JavaScript, ActionScript
oder JScript. Außerdem werden JIT-Compiler auch in anderen
Umgebungen eingesetzt, z.B. Rubinius (Ruby), Unladen Swallow (Python), der
Java Virtual Machine und der Microsoft .NET Common Language Runtime.

Angreifer können die JIT-Implementierungen auf zwei Arten für ihre
Zwecke nutzen:

1. Sie können missbraucht werden, um andere Schwachstellen
   auszunutzen, z.B. indem darüber Code im Speicher verteilt wird, der
   dann nach einem Pufferüberlauf angesprungen und ausgeführt wird
   (JIT Spray).

2. Schwachstellen in der JIT-Implementierung können direkt
   ausgenutzt werden.

Chris Rohlf und Yan Ivnitskiy haben bisher wenig untersuchte
JIT-Komponenten auf mögliche Schwachstellen untersucht:

• Mozilla SpiderMonkey Front End
  • Mozilla JaegerMonkey und Nitro Back End
  • Mozilla TraceMonkey und NanoJIT Back End
• LLVM Bitcode Parser, dessen JIT Engine und Anwendungen, die diese
  einsetzen

Nach einer Beschreibung dieser Architekturen und bekannter Schwachstellen
in JIT-Implementierungen sowie deren Ausnutzung werden mögliche
Härtungs-Maßnahmen untersucht, mit denen mögliche Angriffe
erschwert werden können. Für verschiedene JIT-Implementierung
werden die vorhandenen Schutzmaßnahmen gegenüber gestellt.
Außerdem werden die verschiedenen zur Untersuchung der
JIT-Implementierungen genutzten Tools, vor allem Fuzzer, vorgestellt.

Auch in der
nächsten Folge geht es um Vorträge auf
Sicherheitskonferenzen zum Thema “Webclient Security”.

Carsten Eilers

Übersicht über alle Artikel zum Thema

Neues zur Sicherheit von Web-Clients

Neues zur Sicherheit von Web-Clients, Teil 2

Neues zur Sicherheit von Clients, nicht nur im Web

Neues zur Sicherheit von Clients

Neues zur Sicherheit von Clients, Teil 2

Neues zur Sicherheit von Webservern und -anwendungen

Neues zur Sicherheit von Webservern und -anwendungen, Teil 2

Sicherheitskonferenzen 2011: Autos und Insulinpumpen im Visier

SAP-Anwendungen dringen ins Web vor, die Angreifer nehmen die Gegenrichtung