Webapp Pentesting mit Burp

Webapp Pentesting mit Burp

Marc Ruef
by Marc Ruef
time to read: 14 minutes

Mit der Einführung neuer Technologien hat das Web immer mehr an Dynamik gewonnen und ist somit für webbasierte Applikationen immer interessanter geworden. Viele Anwendungen, die früher nativ und lokal auf einem Betriebssystem ausgeführt werden mussten, können heute remote und innerhalb eines Webbrowsers genutzt werden.

Automatisierte Analyse

Sowohl die Steigerung der Popularität von Webdiensten als auch die Erhöhung der Komplexität der dafür notwendigen Technologien hat direkten Einfluss auf die Angriffsfläche solcher Lösungen. Aus diesem Grund sind Web Application Penetration Tests in den letzten Jahren vermehrt in den Fokus von Sicherheitsüberprüfungen gerückt.

Der Umfang und die Vielschichtigkeit moderner Webapplikationen macht es praktisch unmöglich, diese binnen nützlicher Frist auf rein manueller Basis einer gerechten Prüfung unterziehen zu können. Zur Erhöhung von Effizienz und Zuverlässigkeit, werden aus diesem Grund nach Möglichkeiten automatisierte Mechanismen eingesetzt. Grundsätzlich kann dabei zwischen zwei Ansätzen unterschieden werden:

Der primäre Einsatz automatisierter Vulnerability Scanner ist umstritten, denn gerade bei inviduell entwickelten Applikationen können sie gar nicht oder nur in beschränktem Rahmen verlässige Resultate zusammenführen.

Aus diesem Grund pflegen wir bei der Durchführung von Penetration Tests auf Frameworks zur computergestützten Identifikation und Ausnutzung von Schwachstellen zurückzugreifen. Anhand des Beispiels von Burp soll das Vorgehen illustriert werden. Die Software steht als Freeware zum Download bereit. Viele der hier vorgestellten Funktionen (z.B. Scanning) sind aber nur in der kommerziellen Variante freigeschaltet.

Target – Ziele definieren

Typischerweise werden innerhalb von Netzwerktools die anzugehenden Zielsysteme als Targets definiert. Burp funktioniert hier ein bisschen anders, denn es handelt sich nicht um eine klassische Standalone-Applikation, mit der die Zugriffe initiiert werden. Stattdessen fungiert Burp als Proxy, der die initialen Zugriffe eines beliebigen Webbrowsers weiterleitet, anpassen und erweitern kann (ähnlich OWASP WebScarab).

Zu diesem Zweck muss Burp zuerst gestartet und der Proxy aktiviert werden. Standardmässig kann man ihn sofort als lokalen Proxy über 127.0.0.1:8080 ansteuern (Anpassungen können im Tab proxy vorgenommen werden). Im entsprechend konfigurierten Webbrowser kann nun die für die Prüfung vorgesehene Webseite aufgerufen werden.

Die erste Abfrage wird vom Proxy abgefangen

Beim ersten Zugriff wird der Tab proxy aufblinken und eben diese zuvor initiierte HTTP-Anfrage darstellen. Sie wird noch nicht direkt an das Zielsystem weitergeleitet, sondern wurde vorerst abgefangen. Durch das Abschalten des Buttons intercept is on kann dieses Enkoppeln deaktiviert und der Proxy in einen transparenten Modus geschalten werden: Von nun an werden sämtliche Anfragen nicht mehr aufgehalten, sondern direkt weitergereicht – Die Interception kann wieder aktiviert werden, um beispielsweise einzelne Zugriffe abfangen und dann dediziert weiterleiten, verändern oder verwerfen zu können.

Der Zugriff auf das Zielsystem hat nun, sofern die eigenen Anfragen sowie die daraus resultierenden Antworten weitergereicht wurden, stattgefunden. Um das Testing beginnen zu können, muss nun aber das Zielsystem – oder Teile davon – explizit als Target definiert werden. Zu diesem Zweck muss in den gleichnamigen Reiter gewechselt werden. In diesem werden unter scope die Zielobjekte festgehalten. Viele Funktionen können nur auf die hier definierten Objekte angewendet werden. Damit wird verhindert, dass die Prüfung auf nicht vorgesehene Objekte (z.B. externe Systeme, ausgeschlossene Verzeichnisse) durchgeführt wird.

Das Definieren des Target Scope ist emminent wichtig

Es können unter include in scope die zu prüfenden Objekte manuell definiert und entfernt werden. Typischerweise werden ganze Hostnamen zum Scope hinzugefügt. Und unter exclude from scope lassen sich Objekte festhalten, die in jedem Fall nicht angegangen werden sollen. In der Regel finden sich hier URLs und Parameter, die für Logout-Funktionen eingesetzt werden (es soll nicht mitten im Testing als authentisierter Benutzer ein Logout stattfinen). Oder Bereiche, die als instabil und besonders heikel gelten.

Die Site Map ist eine gute Ausgangslage für dedizierte Zugriffe

Einfacher ist es aber, dass wenn auf die site map zur Generierung des Scopes zurückgegriffen wird. In dieser wird in Echtzeit jedes Objekt (Host, Verzeichnis, Datei), mit dem interagiert wurde, festgehalten. In einer Baumstruktur lassen sich Hosts, Verzeichnisse, Dateien und Parameter ausmachen. Durch einen Rechtsklick auf ein solches Objekt kann das Kontextmenu geöffnet und dieses – sowie alle darunterliegenden Objekte – zum Scope hinzugefühgt werden. In der Regel werden ganze Hosts – oder wenigstens ganze Verzeichnisse – zu einem Scope hinzugefügt. Ob ein solches Hinzufügen funktioniert hat, kann dann wieder im scope geprüft (und bei bedarf manuell angepasst) werden.

Alle Zugriffe werden vollumfänglich in der History dokumentiert

Alternativ kann unter history beim Tab Proxy jede bisher durchgeführte Anfrage angezeigt werden. Dies ist einerseits wertvoll, um ein Höchstmass an Nachvollziehbarkeit gewährleisten zu können. Andererseits kann auch hier über das Kontext-Menu auf weitere Funktionen zugegriffen werden (z.B. Hinzufügen zum Scope, Starten eines Scans).

Bevor weitreichende Zugriffe angestrebt werden, sollte immer der Scope geprüft und gegebenenfalls angepasst werden. Daten aus vorangegangenen Sessions werden übernommen und es ist nicht untypisch, dass damit plötzlich Zielobjekte anderer Projekte in eine neue Prüfung miteinfliessen. Dies sollte unbedingt verhindert werden.

Spider – Daten sammeln

Es gibt nun zwei Varianten, wie die Zielobjekte angegangen werden können. Einerseits können weitere Zugriffe über den Webbrowser initiiert werden. Diese werden durch die Proxy-Funktionalität von Burp dokumentiert – hauptsächlich in history und in site map – und weitergereicht. Mit einem Mehr an Zugriffen wird auch ein Mehr an Daten anfallen. Diese bilden dann die Ausgangslage für weitere Zugriffe und Tests.

Das Durchforsten der Webseite kann aber auch in automatisierter Weise geschehen. Zu diesem Zweck kann der Spider eingesetzt werden, dessen Funktionalität unter dem gleichnamigen Reiter angeboten wird. Er wird durch das Aktivieren der Checkbox spider running (bis Version 1.4.1x) bzw. das Klicken des entsprechenden Buttons ein- und ausgeschaltet.

Durch den Spider werden alle potentiellen Zielobjekte gefunden

Standardmässig ist in spider scope definiert, dass die Datensammlung nur auf die zuvor im Gesamtscope definierten Objekte angewendet wird. Es lässt sich aber auch ein Custom Scope für den Spider definieren. In jedem Fall ist es wichtig, dass bei automatisierten Funktionen immer zuerst die Korrektheit der Scope-Definition und -Auswahl verifiziert wird.

Wird der Spider aktiviert, greift er als erstes auf jene Objekte des Zielsystems zu, die er schon bei vorangegangenen Zugriffen (sie sind in der Site Map dokumentiert) gesehen hat. Diese Dokumente lädt er herunter, wie wenn sie durch einen regulären Browser angefordert worden wären. Innerhalb der Dokumente werden weiterführende Objekte und Links gesucht, die – sofern sie ebenfalls im Scope sind – ebenfalls heruntergeladen werden. Dieser Prozess wird solange wiederholt, bis sämtliche verlinkten und angebotenen Objekte heruntergeladen worden sind. Im Grunde lässt sich damit eine Offline-Kopie der Webseite anstellen, so wie man es beispielsweise von wget kennt.

Ist der Spider aktiv, wird in einer kleinen Übersicht der aktuelle Status angezeigt. Die Anzahl für durchgeführte Anfragen, übertragene Bytes, vorgesehene Anfragen und abgeschickte Formulare wird aufgelistet.

Hierbei ist wichtig zu beobachten, ob die Anzahl der ausstehenden Objekte (requests queued) tendenziell abnimmt oder nicht. Sollte es über mehrere Minuten gegeben sein, dass die dort ausgewiesene Zahl gleich bleibt oder gar ansteigt, dann ist eine Fehlkonfiguration von Burp und/oder ein spezielles Verhalten der Webapplikation gegeben. Voraussichtlich unterstützt die Zielanwendung eine schier unendliche Zahl an verschiedenen Anfrageformen, wodurch stetig die gleichen Daten heruntergeladen und damit Burp quasi in eine Endlosschleife geschickt wird. In diesem Fall sollte der Spider deaktiviert und mit dem Drücken auf den Button clear queues die ausstehenden Anfragen entfernt werden.

In einem solchen Fall ist es angeraten, dass die wichtigsten Bereiche der Webapplikation mittels manuellen Zugriffen innerhalb des Browser aufgerufen werden. Der Spider sollte dann nur noch punktuell in ausgewählten Fällen zum Einsatz kommen.

Scanner – Schwachstellen entdecken

Die gerade für Einsteiger am nützlichste Funktionalität wird durch den Scanner bereitgestellt. Dieses Modul ist dafür zuständig, möglichst automatisiert potentielle oder existente Schwachstellen als solche zu identifizieren. Burp ist also nicht nur ein Framework, das bei der Suche und dem Ausnutzen von Schwachstellen unterstützt – Im weitesten Sinn kann es diese Aufgabe auch zu einem gewissen grad automatisiert angehen.

Das Scanning-Module identifiziert potentielle Schwachstellen

Die Scan-Funktionalität ist nach Bedarf sowohl passiv als auch aktiv gewährleistet. Unter live scanning können die entsprechenden Funktionen bestimmt werden:

Unter results werden wiederum in Baumform die bisher zusammengetragenen Findings aufgelistet. Diese können ausgewählt werden, um eine Beschreibung und zusätzliche Details zu erhalten. Bei applikationsspezifischen Findings werden in der Regel sowohl Request als auch Response, die zum gegebenen Problem geführt haben, mitgeliefert. Dies erleichtert die Analyse und das weiterführende Ausnutzen einer Schwachstelle enorm.

Mit dem Aktivieren des automatisierten Scannings werden die zu prüfenden Objekte in die scan queue geschrieben. Dort ist zu sehen, welche Objekte gerade geprüft werden und welche Objekte für eine Prüfung vorgesehen sind. Burp unterscheidet hier nach URL ohne Parameter – Letztere werden iterativ bei den Zugriffen geprüft.

Durch das aktive Scanning werden Angriffsmöglichkeiten gesucht

Gerade bei grösseren Applikationen und bei Projekten mit einem eng gestrickten Zeitrahmen ist es nicht möglich, ein gesamtes aktives Scanning durchzuführen. Hier bietet es sich an, dass innerhalb der site map über das Kontext-Menu interessante Objekte an den aktiven Scanner geschickt werden. Gerade Such- und Kontakt-Formulare sind erste Anlaufstellen für solche Tests.

Standardmässig verwendet Burp ein Multi-Threading mit bis zu 10 gleichzeitigen Zugriffen innerhalb des aktiven Scannings. Obschon diese Einstellung bei den meisten Applikationen verträglich arbeitet, kann es durch die erhöhte Anzahl aggressiver Zugriffe zu Komplikationen, die den produktiven Betrieb tangieren können, kommen. Aus diesem Grund pflegen wir das Multi-Threading zwischen 2 und 5 gleichzeitigen Zugriffen festzulegen. Die Anzahl kann während des Scannings geändert und damit ein Optimieren der bestmöglichen Analyseform erarbeitet werden.

Intruder & Repeater – Schwachstellen ausnutzen

Die bisher diskutierte Funktionalität hat sich in erster Linie darum bemüht, einen Überblick zu einem Zielobjekt zu erhalten und etwaige Schwachstellen in diesem ausfindig zu machen. Ein professioneller Penetration Test geht aber noch einen Schritt weiter und nutzt die Sicherheitslücke aus, um Machbarkeit und Auswirkungen determinieren zu können.

Zu diesem Zweck werden in erster Linie die drei Module intruder und repeater eingesetzt:

Zusammenfassung

Die Professionalisierung von Web Application Penetration Tests ist in einer stark durch Webapplikationen getriebenen Zeit unabdingbar. Durch ein möglichst hohes Mass an Automatisierung soll die Effizienz und Zuverlässigkeit entsprechender Prüfungen erhöht werden.

Exemplarisch wurde mittels Burp aufgezeigt, welche Funktionalität im Rahmen solcher Betrachtungen erwartet werden. Anhand konkreter Beispiele wurde illustriert, wie sich die einzelnen Module und ihre Funktionen einsetzen lassen, um Schwachstellen finden und ausnutzen zu können. Ausführliche Informationen zur Funktionsweise und Nutzung von Burp ist in der Online-Hilfe zu finden.

About the Author

Marc Ruef

Marc Ruef has been working in information security since the late 1990s. He is well-known for his many publications and books. The last one called The Art of Penetration Testing is discussing security testing in detail. He is a lecturer at several faculties, like ETH, HWZ, HSLU and IKF. (ORCID 0000-0002-1328-6357)

Links

You want to test the security of your firewall?

Our experts will get in contact with you!

×
Specific Criticism of CVSS4

Specific Criticism of CVSS4

Marc Ruef

scip Cybersecurity Forecast

scip Cybersecurity Forecast

Marc Ruef

Voice Authentication

Voice Authentication

Marc Ruef

Bug Bounty

Bug Bounty

Marc Ruef

You want more?

Further articles available here

You need support in such a project?

Our experts will get in contact with you!

You want more?

Further articles available here