© pejo, 123RF.com

Burp, der Rülpser, bringt Fehler in Webseiten ans Licht. Als Java-basierter Proxy schaltet sich Burp zwischen Browser und Webserver und bietet Programmierern, Pentestern und sicherheitsaffinen Experten ein praktisches GUI mit vielen Funktionen.

Sicherheitstests laufender Webapplikationen gehören zu den sich häufig wiederholenden Arbeiten eines Admin. Dabei begibt er sich in der Regel auf die Suche nach Fehlern wie jenen, die sich in der OWASP-Liste [1] finden und die Lücken wie Cross Site Scripting oder Cross Site Request Forgery ausnutzen. Selbst wenn bei der Suche nach Löchern in den Webapplikationen automatische Scanner helfen, wollen die gefundenen Lücken doch per Hand verifiziert sein.

Ein Proxy als Hilfsmittel für den Pentester

Besonders verdächtige Komponenten der Applikation nimmt der sicherheisbewusste Admin manuell unter die Lupe. Vor allem Eingabeparameter aus Formularen oder auch Cookies lassen sich immer wieder so manipulieren, dass ein vom Autor der Webseite nicht gewünschtes Ergebnis herauskommt. Das Lieblingswerkzeug vieler Security-Consultants ist dabei die Burp-Suite, die unter [2] erhältlich ist. In der Pro-Version enthält sie sowohl einen Scanner als auch eine grafische Oberfläche mit zusätzlichen Funktionen, die das manuelle Testen optimal unterstützt.

Viele Fehler in Webapplikationen rühren daher, dass die Entwickler sich darauf verlassen, nur gültige Eingaben zu bekommen. Codeschnipsel wie

$dbh->do("insert into bestellungen values(".$cgi->param("orderid").",".$cgi->param("anzahl").")");

führen beispielsweise dazu, dass ein Angreifer dem Formularfeld »orderid« einen Wert wie »,”); drop table bestellungen;« geben kann, was das Perl-Snippet dann ohne Nachfrage ausführen würde. Schlimmstenfalls ist die Datenbanktabelle dann Geschichte.

Abhilfe schafft hier nur, jeden CGI-Parameter auf gültige Inhalte zu prüfen sowie Prepared Statements zu verwenden, wobei manche Datenbanktreiber Letztere jedoch so lausig implementieren, dass Vorsicht geboten ist. Modernere Webseiten versuchen diese Validierung mittels Javascript im Browser, übersehen dabei aber, dass ein Angreifer ja nicht unbedingt den Webbrowser zum Angriff verwendet, also die bösen Daten in das Formular eintippt, sondern ein Skript die Arbeit erledigen lässt, das sich um das importierte, gut gemeinte Javascript überhaupt nicht kümmert.

Gegen Schlamperei hilft nur Validierung

Die Ursachen für derlei fahrlässige Implementierungen finden sich oft im Zeitdruck gegen Ende eines Projekts, in schlampiger Programmierung oder auch im schlicht fehlendem Bewusstsein für die Problematik. Eine Entwicklerin, die der Autor mit den Ergebnissen seines Scans konfrontierte, antwortete etwa: “Dann soll der Benutzer halt solche Daten nicht eingeben!”

Beim Test auf Verwundbarkeiten sucht sich der Tester erst einmal alle Parameter, die der Browser an den Server schickt, und fängt an mit diesen zu spielen. Im einfachsten Fall gibt er dabei die Daten in die Formularfelder ein, besser ist es aber, die Kommunikation zwischen Browser und Server anzuschauen und dabei entweder in »GET« -Requests eingepackte Parameter oder jene Parameter, die im Body von »POST« -Requests eingepackt sind, zu kontrollieren. Die Eingabefelder vom Typ »HIDDEN« ließen sich sonst gar nicht manipulieren. Auch Cookies, die auf solchen Eingabefeldern basieren, bieten ein Angriffsziel.

Wer komplett manuell testet, manipuliert bei »GET« -Requests die Werte direkt in der URL im Browser. Das hat den Vorteil, dass Cookies für die laufende Session erhalten bleiben, ist aber auf die Dauer etwas mühsam. Externe Skripte tun sich dagegen sehr schwer, Authentisierungen der Websites zu überstehen, damit sie überhaupt zum interessanten Teil der Webanwendung kommen.

Und genau da setzt die Burp-Suite der britischen Firma Portswigger an. Burp arbeitet als Proxy, der auch HTTPS-Verbindungen aufbricht. Burp ist eine Java-Applikation und läuft auf allen gängigen Betriebssystemen mit Java-Engine. Das Produkt gibt es in einer Free- und einer Pro-Ausgabe (zum Preis von knapp 300 Euro für eine Jahreslizenz). Der Artikel beschreibt zunächst die Free- und dann, was die Pro-Version mehr kann.

Schon gut ausgestattet: Burp Free Edition

Burp startet mit »java -jar burpsuite_free_v1.5.jar« , wobei es sich empfiehlt, bei längeren Tests je nach Standardeinstellungen des Rechners den Heapspace mit »-Xmx1024m« zu erhöhen. Der Proxy akzeptiert Verbindungen auf Port 8080 und nimmt ohne Konfigurationsänderung erst einmal nur Verbindungen auf dem Loopback-Interface entgegen. Soll der Browser auf einem anderen Rechner laufen, muss der Tester dies über den Reiter »Proxy | Options« ändern.

Eine weitere Eigenschaft der Software, die dem Testenden vor der Erstbenutzung bewusst sein sollte, ist, dass der Proxy anfänglich im »Intercept« -Modus läuft. Das bedeutet, dass er Anfragen des Browsers unterbricht, anhält und dem Tester die Möglichkeit gibt, sie zu modifizieren, bevor Burp sie weitersendet.

Um einen Überblick über das Testobjekt zu gewinnen, schaltet der Tester diese Option erst einmal aus, konfiguriert seinen Browser so, dass er Burp als Proxy nutzt, und surft das Testobjekt an. Vor allem wenn eine Anmeldung notwendig ist, empfiehlt sich dieses Vorgehen, weil Burp danach alle Informationen im Header hat, um als authentisierter Benutzer weitermachen zu können.

Praktisches GUI

Ein Klick auf »Proxy | History« zeigt ab sofort eine Übersicht der angesurften Seiten sowie die akzeptierten CGI-Parameter oder Cookies. Abbildung 1 demonstriert dies am Beispiel Owncloud. Ein Rechtsklick auf einen Request öffnet ein Menü, das unter anderem den Eintrag »Send to Repeater« enthält. Damit kann die Arbeit beginnen.

Abbildung 1: Der Burp-Angriff rollt. Hier hat der Admin die unter Sicherheitsexperten berüchtigte Owncloud-Weboberfläche als Ziel ausgesucht.

Ein Klick sendet die Anfrage samt Antwort an die Repeater-Komponente, und mit einem Klick auf den entsprechenden Reiter landet der Tester beim Request. Abbildung 2 zeigt diese Ansicht. In diesem Dialog kann er alle HTTP-Header sowie alle CGI-Parameter übersichtlich editieren und die Anfrage nochmals an den Server schicken. Die Antwort stellt Burp im Rohformat oder in HTML gerendert dar. Weil sich dieser Schritt beim Testen recht häufig wiederholt, heißt diese Komponente Repeater.

Abbildung 2: Der Repeater zeigt das Testen mit einem einzelnen Request. Auch Cookies beherrscht Burp.

Burp führt währenddessen eine History, die der Anwender browsen und durchsuchen kann. Letzteres ist sehr hilfreich, wenn er konkret danach sucht, ob sich der modifizierte Parameter in der Antwort des Servers (mit viel HTML und Javascript aufgefüllt) wiederfindet.

Base64 decodieren

Häufig finden sich im HTTP-Traffic auch codierte Parameter. Das fängt bei der Base64-Codierung von Basic-Auth an, enthält aber auch komprimierte Daten oder andere Formate, die sich von den meisten Menschen nicht direkt lesen lassen. Hier greift der Decoder von Burp ein: Der Tester markiert einen Textteil, von dem er vermutet, dass dieser entsprechend eingepackt ist (Base64 ist meist recht gut erkennbar), führt einen Rechtsklick darauf aus und wählt aus dem Menü »Send to Decoder« . Wer das Format kennt, wählt das richtige einfach aus, sonst hilft ihm »Smart Decode« weiter. Abbildung 3 zeigt dies am Beispiel von Accountdaten.

Abbildung 3: Burp kann Base64, aber auch Adobes AWF decodieren.

Mit jedem Klick erscheint ein weiterer Dialog, sodass der Tester auch mehrfach verpackte Daten Schritt für Schritt auspacken kann. Zum Manipulieren der Eingabedaten ist der »Encode as …« -Button in dieser Funktion aber genauso wichtig. Erwartet ein Skript einen Base64-verpackten Parameter, muss auch der Versuch der SQL-Injection oder des Cross Site Scripting erst in Base64 eingepackt sein. Wer Burp nicht nutzt, muss dafür ein eigenes Skript, etwa in Perl, heranziehen. Die reibungslose Integration in Burp macht das Arbeiten viel entspannter – die Programmautoren standen wohl selbst oft vor derselben Aufgabe.

Spider, Sequencer, Intruder und Repeater

Die nächste Funktion in der freien Ausgabe ist der »Spider« , der ausgehend von einer unter »Target« ausgewählten URL auf Entdeckungstour geht. Den »Intruder« bringt zwar auch die freie Version mit, dort besitzt er aber nur eingeschränkte Funktionen. Der »Sequencer« steht nur in der Pro-Version bereit, er dient dazu, die Zufälligkeit von Parametern wie Session Tokens zu testen. Sind diese nicht zufällig genug, weil bei ihrer Berechnung beispielsweise die Uhrzeit verwendet wird, kann ein Angreifer sie leicht erraten, vielleicht die Session eines anderen Benutzers übernehmen und auf dessen Rechnung einkaufen.

Der Sequencer funktioniert ähnlich wie der Intruder: Der Tester wählt aus der Proxy-History einen Request aus, bei dem ein Session Token zugewiesen wurde, und schickt dieses per Rechtsklick an den Sequencer. Dann im Repeater unter Live Capture »Start Live Capture« anklicken, und schon testet Burp den Server. Im Ergebnis erhält der Benutzer eine Auswertung der Zufälligkeit.

Features im Profi-Rülpser

Auf den ersten Blick unterscheidet sich die Pro-Version nicht von der freien. Doch sind einige Reiter und Menüpunkte mit Leben erfüllt, die vorher ausgegraut waren oder einen Hinweis auf die Pro-Version enthielten. Gleich im »Burp« -Menü finden sich zwei wichtige Einträge: »Save State« und »Restore State« . Dies ermöglicht es, Tests zu unterbrechen, zu speichern und später wieder aufzunehmen.

Das spannendste Werkzeug ist sicherlich der Scanner, der einen aktiven und einen passiven Modus bietet. Im passiven untersucht er die durchlaufenden Requests – dazu muss der Tester durch die Webseite surfen und von sich aus auftretende Sicherheitslücken melden, farblich codiert von rot (kritisch) bis schwarz (informativ). Im passiven Modus fallen zwar viele Dinge nicht auf, aber es gibt Anhaltspunkte für Verbesserungen.

Sind Burp genug Teile der zu testenden Applikation durch den passiven Scan bekannt, wählt der Tester im zweiten Schritt den aktiven Scan aus. Dazu klickt er zuerst die URL unter dem »Target« -Reiter an und sendet dann dieses Ziel an den Active Scan. Nun wird Burp die Webapplikation mit aktiven Versuchen bombardieren.

Dabei rattert es die Verwundbarkeiten der OWASP-Top-Ten rauf und runter, testet Cookies und andere Einstiegspunkte für Angriffe. Burp variiert und versucht es sogar mit Timing-basierten Angriffen, die aufgrund der Antwortzeit versuchen den Erfolg eines Angriffs zu erkennen. Weil es die bestehende Session einfach weiterverwendet, bleiben Anmeldungen bestehen, normalerweise verlangt Burp keine gesonderten Anmeldeinformationen.

Vorsicht ist geboten

Bevor der Tester einen solchen Angriff auf eine Webseite loslässt, sollte er sichergestellt haben, dass die Seite mit der entstehenden Last zurechtkommt. Als Ziel sollte auf jeden Fall nur ein Klon der Produktivseite dienen. Zwar sind die Burp-Tests sehr vorsichtig ausgelegt – die SQL-Injection testet Burp natürlich nicht mit »drop database« –, bei schlampiger Programmierung der Applikation kann dennoch einiges kaputtgehen. Auch die Last kann schnell überraschend hoch werden. Im Test kam unter anderem eine zu klein dimensionierte VM mit PHP Myadmin schon bei fünf parallelen Burp-Angriffsthreads ins Swappen.

Abbildung 4 zeigt den Reiter »Scan queue« auf ein paar solcher Installationen, die die Tester für diesen Artikel unter die Lupe genommen haben. Unter dem Reiter »Results« findet sich eine detaillierte Übersicht der Ergebnisse. Klickt der Tester auf den Eintrag für die ganze Webseite, erhält er eine Liste aller gefundenen Lücken. Diese wiederum kann er ebenfalls weiter aufklappen, um zu sehen, bei welcher URL welche Lücke gefunden wurde.

Abbildung 4: Die Scan Queue zeigt die durchlaufenen URLs, den Fortschritt und wie viele Lücken Burp gefunden hat sowie die Farbe der schwersten Kategorie.

Für jede Lücke gibt es eine ausführliche Beschreibung, wie Burp sie gefunden hat und was sie potenziell bedeutet. Burp stellt auch die gesendete Anfrage sowie die Antwort des Servers dar, wobei es die Parameter des Angriffs in beiden hervorhebt (Abbildung 5).

Abbildung 5: Burp zeigt alle Details einer vorgefunden Sicherheitslücke an, hier am Beispiel von PHP Myadmin.

Report in XML oder HTML

Aus den Ergebnissen erhält der Tester einen ausführlichen Report, in dem er einen Rechtsklick auf jene Ergebnisse ausführt, über die der Report erstellt werden soll. Dann wählt er HTML oder XML als Format und den Detaillierungsgrad. Dabei zeigt Burp auf Wunsch sogar Lösungsansätze an, wie sich die Fehler beheben ließen. Im letzten Dialog blendet der Tester einzelne Findings aus und gibt schließlich den Dateinamen an, unter dem Burp speichert.

Agiert der Scanner eher wahllos, so entspricht der Intruder gezieltem Schießen. Dabei wählt der Tester aus der History des Proxys einen interessant erscheinenden Request mit mehreren Parametern aus und sendet ihn per Rechtsklick zum Intruder. Hier konfiguriert er die Details, also die Parameter, die Burp testen soll, wie viele parallele Threads und ob die Software einfaches Fuzzing oder eine andere Angriffsmethode nutzen soll. Dann startet er den Test über das »Intruder« -Menü.

Burp führt die Requests aus und zeigt die Ergebnisse an. Meist ist das Ziel, Abstürze zu generieren, also 500er Fehler zu provozieren. Da der Intruder gezielt Verwirrung stiftet, sollte man auch ihn nicht gegen Produktivsysteme einsetzen.

Invisible Proxying

Ein weiteres Feature der Pro-Version ist das Invisible Proxying. Gemeint ist eine Art transparenter Proxy für Webapplikationen, bei denen sich kein Proxy einstellen lässt. Dazu konfiguriert der Tester Burp so, dass es auf Port 80 und Port 443 Verbindungen annimmt. Dann ist der DNS-Server, den der Client nutzt, so zu konfigurieren, dass er für den Zielhost die IP-Adresse des Burp-Proxys zurückbekommt. Jetzt schickt der Client die Anfrage an Burp, als ob es der Ziel-Webserver wäre. Seit HTTP 1.1 ist ein Host-Header in der Anfrage enthalten, über den der Burp-Proxy weiß, an wen er die Anfrage weiterleiten soll.

Eine Besonderheit sollten Anwender bei Tests von Webseiten beachten, die HTTPS verwenden. Burp klemmt sich auch als Man in the Middle in den Strom, terminiert die SSL-Verbindung vom Client und präsentiert diesem ein selbst generiertes Zertifikat. Das macht das Testen von per TLS geschützten Seiten erst möglich, kann aber bei Client-Authentisierung per Zertifikat zu Problemen führen.

Allerdings bietet Burp hier die Möglichkeit, das passende Client-Zertifikat in Burp zu hinterlegen, sodass entweder die ausgehende Verbindung ordentlich angemeldet ist oder aber Burp für einzelne Teile von Webapplikationen, die das benötigen, den SSL-Verkehr unangetastet durchlässt.

Fazit

Burp ist auch in der freien Version ein sehr komfortables Werkzeug, um Webapplikationen zu testen, weil es viele Funktionen, die zum Werkzeugkasten des Admin gehören, sinnvoll und einfach integriert. Aber auch die Bonus-Features der kommerziellen Version sind ihren Preis wert, vor allem für Anwender, die wie der Autor häufiger Tests durchführen.

Ganz automatisch geht dies dennoch nicht: Der Tester sollte die Ergebnisse des Scanners immer durch Anschauen von Anfrage und Antwort verifizieren. Ein Beispiel ist eine vermeintliche SQL-Injection, die Burp im Test auf einer unterdimensionierten VM entdeckt und nur aufgrund des Timings als solche interpretiert hatte. Da war die VM schon so am Swappen, dass der Anwender derlei Verzögerungen vollständig als False Positive klassifizieren kann.

Trotzdem liefert ein Active Scan in der Regel sehr wertvolle Anhaltspunkte für mögliche Sicherheitslücken. Auch die Möglichkeit, über den Extender eigene Plugins zu entwickeln, macht die Software attraktiv.

Der Autor

Konstantin Agouros arbeitet bei der N.runs Professionals GmbH als Berater für Netzwerksicherheit. Dabei liegt sein Schwerpunkt im Bereich der Mobilfunknetze.