Vier XSS für ein Halleluja - Plädoyer für mehr Wertschätzung von Entwicklern

Vier XSS für ein Halleluja

Plädoyer für mehr Wertschätzung von Entwicklern

Veit Hailperin
von Veit Hailperin
am 10. November 2016
Lesezeit: 10 Minuten

Die Welt ist von Hackern fasziniert. Grüne Schrift auf schwarzem Hintergrund, wie auch der Hoodie sind stereotypische Merkmale. Es fasziniert, weil es so unfassbar kompliziert und unerreichbar erscheint. Es fasziniert, weil es den Touch von Verbotenem hat. Die meisten Leute hören hier auf. Der Rest ist so fasziniert, dass er sich mehr mit dem Thema auseinander setzt und ganz erschrocken feststellt – so schwierig scheint das ja gar nicht zu sein. Wenige Monate später wird das erste Mal über Entwickler gespottet und auf Twitter geschrieben, wie einfach Offensive Security ist. Aber nichts ist einfach. Nicht wenn man es tatsächlich seriös und gut betreiben will. Offensive Security stellt keine Ausnahme dar.

Jedes Fachgebiet hat sein Trendthema. In IT-Security ist es Web Application Security. Web Application Security beschäftigt sich mit der Sicherheit der Anwendungen, welche über einen Browser angesteuert werden. Wie der Begriff “Trendthema” bereits ausdrückt, war das nicht immer so. Binary Exploitation hatte seine Zeit zu glänzen. Netzwerksicherheit war lange Zeit ein grosses Thema. Doch dann wurde die Anwendungsvielfalt grösser und es wurden neue Angriffsarten wie SQL-Injection entdeckt. Das Trendthema heisst deshalb seit dem immer noch Web Application Security.

Es scheint momentan aber in der Sicherheitsbranche wieder einen Trend zur Verstärkung von Netzwerksicherheit zu geben. Vermutlich liegt das an der grossen Anzahl an gehackten Firmen in den letzten Monaten.

Ein leichter Einstieg mit XSS

Der Einstieg in Web Application Security ist tatsächlich leicht. Es gibt massenhaft gute Quellen und Programme, die beim Einstieg helfen. Insbesondere das Open Web Application Security Project ist eine riesige Ressource. Liest ein Anfänger die Top 10 durch, so wird er schnell Cross Site Scripting (XSS) im Internet finden. Der fehlerbehaftete Code, welcher der Grund für die Lücke ist, ist häufig nicht komplizierter als das folgende Beispiel:

<?php
$username = $_GET[‘username’];
echo “<!DOCTYPE html><head><title>XSS</title></head><body>Hello “;
echo $username;
echo “</body></html>”
?>

Das Problem ist offensichtlich: Ungefilterte Ausgabe eines mitgeschickten Parameters. Dies kann ein Angreifer ausnützen, in dem eigener JavaScript Code über den Parameter username übergeben wird:

https://unsafe-domain.tld/?username=<script>alert(1)</script>

Das Alert-Böxchen erfreut. Aber wie sieht es aus, wenn eine Template-Engine involviert ist und diese noch zusätzliche Filter in den Compiler eingebaut hat? Genau das passiert bei dem populären JavaScript Framework AngularJS.

AngularJS

AngularJS 1.5.7 hat mehr als 31’000 Zeilen Code. Das Framework bietet seine eigene Template Engine an, welche in einer Sandbox läuft. Die Sandbox soll verhindern, dass beliebiger JavaScript Code ausgeführt werden kann. Gelingt es einem Angreifer aus dieser Sandbox auszubrechen und wird zusätzlich AngularJS falsch benutzt sowie die Sandbox als Sicherheitsmechanismus von den Entwicklern eingesetzt, führt das wiederum zu XSS. Obwohl dies von aussen möglicherweise nach vielen Konditionen aussieht, finden wir diese Situation regelmässig in unseren Tests.

Die ersten Sandbox-Escapes, waren noch relativ simpel. Daraufhin wurden jedoch mehrere Schutzmechanismen zur Verhinderung in den Template-Parser eingebaut. Der aktuelle Bypass für das Framework sieht folgendermassen aus:

{{a=toString().constructor.prototype;a.charAt=a.trim;$eval(‘a,alert(1),a’)}}

Um einen solchen AngularJS-Sandbox-Bypass nur schon zu verstehen, bedarf es grundlegender JavaScript Kenntnisse, Verständnis zur Funktionsweise der Templating Engine von AngularJS und die Fähigkeit zum Debuggen. Möchte man einen solchen Angriff entwickeln, die tatsächliche Arbeit eines Penetration Testers, braucht es mehr als nur grundlegende Programmierkenntnisse.

In dem Fall des AngularJS Bypasses, gibt es ein Video welches den Bypass erklärt. Dieses Video bietet auch einen guten Einblick, was für grundlegende Fähigkeiten und Kenntnisse benötigt werden, um die Schwachstelle zu finden und den Exploit zu entwickeln. In der Bachelorarbeit von Jann Horn, einem der Bypass Autoren, findet sich eine sehr detaillierte Beschreibung der Funktionsweise.

Programmieren als Notwendigkeit

Ein guter Hacker beherrscht nicht nur seine Tools, sondern ist in der Lage diese zu erweitern und seine eigenen zu entwickeln. Wer bereits in der Industrie arbeitet und noch nicht programmieren kann, sollte schleunigst damit anfangen. Einen guten Einstieg bieten Skript-Sprachen, wie Python, Ruby, Bash, Lua und PowerShell. Gute Startprojekte sind die Automatisierung von immer wiederkehrenden, oft bei Penetration Testern unbeliebten Dokumentationsaufgaben. Gute Hacker erledigen nicht die Arbeit, die ein Computer für sie besser und schneller erledigen kann.

Was für Tools bestimmen den Alltag? Nmap, Metasploit, BurpSuite, Zap, Sqlmap. Alle diese Tools haben Schnittstellen zur Erweiterung. Es lohnt sich das Tool, mit dem man am häufigsten arbeitet für seine Zwecke anpassen zu können!

Ein Phänomen, welches ich immer wieder beobachte ist, dass Penetration Tester ihre Entwicklungen nicht teilen wollen, weil die Code-Qualität nicht gut genug ist. Aber durch das Veröffentlichen der Tools werden es andere verwenden, Fehler finden und manchmal sich auch die Arbeit machen, den Code zu verschönern. Nicht nur hat man jemandem anderes geholfen, sondern auch etwas mehr über Programmieren gelernt. Der Grund warum heute der Einstieg so simpel ist, ist weil sich Leute durchgerungen haben, ihren Anfänger-Code Online zu stellen.

Der Respekt gegenüber Entwicklern wächst massiv in dem Moment, in dem Programmieren erlernt wird. Die Anzahl an Fehlermöglichkeiten ist so hoch, dass man sich eigentlich nicht darüber wundern kann, dass das Internet voller Lücken ist. Und das ohne die Designfehler.

Ein weiterer positiver Aspekt von Programmierkenntnissen ist, dass man anstatt nur zu kritisieren, die Entwickler aktiv unterstützen kann. Es ist glücklicherweise eher selten, aber gelegentlich sieht man, dass seitens Entwickler Ausreden oder schlechte Lösungsansätze vorgeschlagen werden. In diesen Momenten erlaubt es einem, den Kunden zu schützen. Selbst zu programmieren vereinfacht natürlich auch jegliche Art von Code-Review.

Debugging und Developer Tools

Last but not least, Developer Tools sind hervorragend zum Testen. Natürlich gibt es einige Tools die speziell zum Hacken entwickelt wurden. Proxies sind während Web Application Penetration Tests unerlässlich. Der Trend zu One-Pagern, also Webseiten, die komplett im DOM leben, steigt. Um das DOM zu auditieren, ist die Beherrschung der Developer-Console ein Muss! Zusätzlich kann es praktisch sein, selbst Browser-Apps entwickeln zu können oder Plugins zu programmieren. Allerdings die mächtigste Art clientseitige Funktionen zu testen, ist momentan die Developer Console. Für Tester, welche sich selten in der Developer Console aufhalten, oder diese sogar fürchten, empfehle ich die folgenden zwei Artikel zum Einstieg:

Ich bin nicht der erste der über dieses Thema schreibt. Ein, für mich persönlich, sehr inspirierender Artikel von Security Researcher Andreas Lindh Hacking Open Source software for fun and non-profit betrachtet das Thema aus der Perspektive des Operating.

Für Einsteiger im Bereich Offensive Security sind die Beiträge von dem belgischen Researcher corelan How to become a pentester und So, you want to work in security? von Security Engineer Parisa Tabriz empfehlenswert. In beiden Artikeln ist Programmieren ebenfalls ein Thema.

Fazit

Programmieren erlernen sollte für jeden angehenden Penetration Tester ein Ziel sein. Programmieren ermöglicht sich in Entwickler besser hineinzudenken, deren Tools als Angriffswerkzeuge zu verwenden, Findings nicht zu überbewerten und Sicherheit auch durch Patches zu verbessern.

Über den Autor

Veit Hailperin

Veit Hailperin arbeitet seit 2010 im Bereich der Informationssicherheit. Seine Forschung konzentriert sich auf Network und Application Layer Security sowie auf den Schutz der Privatsphäre. Die Resultate präsentiert er an Konferenzen.

Links

Sie wollen die Sicherheit Ihrer Firewall prüfen?

Unsere Spezialisten kontaktieren Sie gern!

×
Crypto-Malware

Crypto-Malware

Ahmet Hrnjadovic

TIBER-EU Framework

TIBER-EU Framework

Dominik Altermatt

Vertrauen und KI

Vertrauen und KI

Marisa Tschopp

Datenverschlüsselung in der Cloud

Datenverschlüsselung in der Cloud

Tomaso Vasella

Sie wollen mehr?

Weitere Artikel im Archiv

Sie brauchen Unterstützung bei einem solchen Projekt?

Unsere Spezialisten kontaktieren Sie gern!

Sie wollen mehr?

Weitere Artikel im Archiv