Burp Makros - Wie sie korrekt verwendet werden

Burp Makros

Wie sie korrekt verwendet werden

Andrea Hauser
von Andrea Hauser
am 13. Juli 2023
Lesezeit: 13 Minuten

Keypoints

Burp Makros und ihre Funktionalitäten

  • Zu Beginn hatte ich Mühe mit der Verwendung von Burp Makros
  • Diese können dazu verwendet werden, CSRF-Tokens abzufragen
  • Zudem können damit Requests in der Mitte eines Prozesses gescannt werden
  • Oder sind auch einsetzbar, wenn Session Tokens nur für eine sehr kurze Zeit gültig sind
  • Burp Makros können einen Tester dabei unterstützen, das Testen viel einfacher zu gestalten

In den Anfangszeiten der Verwendung von Burp habe ich Burp Makros immer als umständlich empfunden. In diesem Artikel will ich meine Erfahrung mit der Verwendung dieser Makros teilen, damit deutlich wird, wie damit das Testing vereinfacht und besser automatisiert werden kann. Nach der Lektüre dieses Artikels sollten Burp Makros keine so grosse Herausforderung mehr sein.

Bevor allerdings Burp Makros näher erläutert werden, beleuchten wir deren verschiedene Einsatzgebiete:

Der Bereich für die Konfiguration von Burp Makros kann im Settings > Sessions Tab gefunden werden. In diesem Session Tab besteht ein Bereich, in dem Makros definiert werden können. Zudem besteht ein Bereich namens Session Handling Rules, in dem die definierten Makros verwendet werden können. Mit diesem Vorwissen sollte es nun machbar sein, sich mit den allgemeinen Anwendungsfällen von Burp Makros Vertraut zu machen.

Abrufen von CSRF-Token

Das folgende ist ein Beispielrequest mit einem ungültigen CSRF-Token, welcher vom Repeater, einem Active Scan, dem Intruder oder einem anderen Tool von Burp ausgelöst worden ist:

POST /post/comment HTTP/2
Host: example.com
Cookie: session=8SBvBwMjQsrORhTzZP7UPjyzm1DC37Sk
X-Csrf-Token: ungueltig
Content-Length: 41
Content-Type: application/x-www-form-urlencoded

csrf=ungueltig&postId=6&comment=CSRF+test

Dieser Request erhält folgende Response:

HTTP/2 400 Bad Request
Content-Type: application/json; charset=utf-8
Content-Length: 20

"Invalid CSRF token"

Mit einem gültigen CSRF-Token wäre die folgende Antwort erwartet worden:

HTTP/2 302 Found
Location: /post/comment/confirmation?postId=6
Content-Length: 0

Ein gültiges CSRF-Token für diese Beispielapplikation wird jedes Mal generiert, wenn ein Blog-Post aufgerufen wird:

GET /post?postId=6 HTTP/2
Host: example.com
Cookie: session=8SBvBwMjQsrORhTzZP7UPjyzm1DC37Sk

Die Response beinhaltet dann folgendes:

HTTP/2 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 7795

< der Einfachheit halber gekürzt >
<!DOCTYPE html>
<html> <body>
  <h2>Leave a comment</h2>
  <form action="/post/comment" method="POST" enctype="application/x-www-form-urlencoded">
    <input required type="hidden" name="csrf" value="BDy7eKqX0YE1SfNi4aPtuXcDktU4EMvB">
    <input required type="hidden" name="postId" value="6">
    <input required name="comment">
    <button class="button" type="submit">Post Comment</button>
  </form>
</body> </html>

Damit nun Tools wie der Repeater, der Intruder, der Sequencer und eventuell auch Extensions korrekt verwendet werden können, muss ein Makro definiert werden, welches ein gültiges CSRF-Token abfragt. Dafür verwenden wir den zuvor identifizierten GET-Request. Ein neues Makro kann unter Settings > Sessions erstellt werden. Sobald der add Button verwendet wurde, erscheint der Macro Recorder, wo der eben identifizierte GET-Request ausgewählt werden muss. In der Macro Editor Sicht muss nun definiert werden, wie Burp das CSRF-Token aus der Response extrahieren kann. Dies kann über Configure Item und Custom Parameter geschehen. Da die Beispielapplikation die wir verwenden das CSRF-Token sowohl als CSRF Parameter im Body erwartet wie auch als X-Csrf-Token Header, müssen zwei Custom Parameter mit den entsprechenden Namen erstellt werden.

Custom Parameter CSRF definieren

Nun da das Makro erfolgreich definiert ist und Burp somit weiss, wie ein gültiges CSRF-Token abgefragt werden kann, müssen wir Burp noch wissen lassen, für welche Tools und welchen Scope das neu definierte Makro eingesetzt werden soll. Dies geschieht über die Session Handling Rules, welche sich ebenfalls in dem Settings > Sessions Bereich befinden.

Um dies zu tun, erstellen wir eine neue Session Handling-Regel und definieren als Befehl Run a macro und verwenden das zuvor erstellte Makro. Als nächstes wird im Scope Bereich festgehalten, für welche Tools und für welche URLs Burp das Makro ausgeführt werden soll. Es besteht sogar die Möglichkeit, Burp explizit mitzuteilen, dass das Makro nur ausgeführt werden soll, wenn sich im Request spezifische Parameter befinden. In unserem Beispiel wäre das, wenn CSRF und X-CSRF-Token vorkommen würden. Durch das korrekte Setzten dieser Regeln kann verhindert werden, dass unnötige Requests an die Applikation ausgelöst werden.

Scope der nur auslöst, wenn CSRF-Token effektiv genutzt wird

Wir überprüfen im Normalfall im Repeater kurz, ob das neu definierte Makro wie erwartet funktioniert, bevor wir einen Scan starten oder den Intruder laufen lassen.

Häufige Fehlerfälle

Wir haben ein Makro kreiert aber im Request, der im Repeater abgeschickt wird, wird nicht nur das CSRF Token überschrieben, sondern auch alle anderen eigentlich vom Benutzer vorgegebenen Parameter. Das kann passieren, wenn das Default-Verhalten von Burp verwendet wird, um Parameter zu erkennen. Um dies zu verhindern, muss in den Session Handling-Regeln das Häkchen vor Update all parameters and headers … zu Update only the following parameters and headers gewechselt werden und für die Beispielapplikation werden dann die folgenden Parameter festgelegt: CSRF und X-CSRF-Token.

Das Default-Verhalten, welches zum Überschreiben von falschen Parametern führt:

Falsch konfigurierte Session Handling-Regel

Korrekt konfigurierte Session handling Regel bei der nur die spezifizierten Parameter überschrieben werden:

Korrekt konfigurierte Session Handling-Regel

Ein zweiter Bereich, in dem sich Fehler einschleichen können, ist wenn das Makro zwar korrekt definiert wurde und das CSRF-Token erneuert wird, allerdings ein Fehler aufgrund eines ungültigen Cookies resultiert. Dann kann es sein, dass aus Versehen das Default-Verhalten von Burp deaktiviert wird, mit welchem immer die aktuellen Cookies aus der Session-Verwaltung von Burp verwendet werden. Dabei handelt es sich um die Einstellung Update current request with cookies from session handling cookie jar, die aktiviert sein müsste.

Fehlerhaft entferntes Default-Verhalten im Bereich der Cookie-Handhabung:

Falsch konfigurierte Session Handling-Regel

Das korrekte und Default-Verhalten wäre:

Korrekt konfigurierte Session Handling-Regel

Request in der Mitte eines Prozesses

Als zweites soll nun angeschaut werden, wie ein nur sinnvoll gescannter Request gescannt werden kann, wenn ein Prozess immer wieder vollständig von vorne beginnt. Dafür kann die bereits vorhin diskutierte Kreierung von Makros verwendet werden, allerdings werden im Marco Recorder mehrere Requests ausgewählt. Es ist sinnvoll, die Sequenz der benötigten Requests zuerst im Repeater manuell durchzuspielen um herauszufinden, ob das Makro tatsächlich funktioniert. Nachdem die notwendigen Requests ausgewählt wurden, muss sichergestellt werden, dass die zwischen den Requests übergebenen Parameter korrekt voneinander abgeleitet werden. Burp versucht bereits die Ableitung herzuleiten und weist eine Spalte mit Derived Parameters auf. Wenn einer der abzuleitenden Werte fehlt, kann dies manuell über die bereits diskutierte Funktion Custom Parameter nachgeholt werden. Dieser neu definierte Parameter kann dann in den nachfolgenden Requests als abgeleiteter Parameter verwendet werden.

Wenn es sich andererseits um einen Prozess handelt, der fortgeführt oder abgeschlossen werden muss, bevor die Resultate eines Scans oder einer manuellen Auswertung eingesehen werden können, kann das gleiche Prinzip mit dem Auswählen von mehreren Requests im Macro Recorder verwendet werden. Allerdings wird das so definierte Makro danach im Session Handling-Bereich als post-request macro ausgeführt. Damit wird das Makro jedes Mal ausgeführt, nachdem ein vom Benutzer festgelegter Request ausgeführt wurde.

Kurze Session Timeouts

Zu guter Letzt ist da noch der Anwendungsfall der sehr kurzen Session Timeouts, die es nicht erlauben, einen Scan abzuschliessen oder die manuelle Analyse, ohne viele Unterbrechungen herbeizuführen. Da es sich dabei um einen viel genutzten Anwendungsfall handelt, gibt es dafür sogar eine eingebaute Funktionalität in Burp. Diese befindet sich ebenfalls im Bereich des Session Handlings und wird Check session is valid genannt. Damit kann das Erkennen von nicht mehr gültigen Sessions einfach definiert und festgehalten werden, wie bei nicht mehr gültigen Sessions vorgegangen werden kann. Falls möglich, kann ein Makro festgelegt werden, in dem der Login-Prozess aufgezeichnet ist. Dieses kann dann in der Session Handling Regel verwendet werden, um eine neue gültige Session zu erhalten. Damit wird einem Tester erspart, immer wieder manuell eine neue Session generieren zu müssen, wenn eine Session ausläuft.

Für Parameter, die in diesem Artikel nicht besprochen wurden, kann nachfolgende Burp Dokumentation für Makros und Session Handling Rules weiterhelfen.

Fazit

Burp Makros brauchen ein bisschen Einarbeitungszeit, um damit zurecht zu kommen. Aber sobald die Möglichkeiten für den Einsatz verstanden sind, sind sie ein grossartiges Tool, um ein effizienteres Testen zu erlauben. Sie sind gut dafür gemacht, um nicht wiederholbare Requests dennoch Scannen zu können. Dies zum Beispiel, wenn für jeden Request zuerst ein gültiges CSRF-Token abgefragt, oder die Session Tokens innert kürzester Zeit erneuert werden müssen. Jeder Tester, der sein Leben vereinfachen will, sollte sich mit Burp Makros auseinandersetzen. Ganz generell ist es immer sinnvoll, die von einem Tool zur Verfügung gestellten Möglichkeiten voll auszuschöpfen, um die Effizienz zu steigern.

Über die Autorin

Andrea Hauser

Andrea Hauser hat ihren Bachelor of Science FHO in Informatik an der Hochschule für Technik Rapperswil abgeschlossen. Sie setzt sich im offensiven Bereich in erster Linie mit Web Application Security Testing und der Umsetzung von Social Engineering Kampagnen auseinander. Zudem ist sie in der Forschung zum Thema Deepfakes tätig. (ORCID 0000-0002-5161-8658)

Links

Sie wollen mehr als einen simplen Security Test mit Nessus und Nmap?

Unsere Spezialisten kontaktieren Sie gern!

×
Prompt Injection

Prompt Injection

Andrea Hauser

Angriffsmöglichkeiten gegen Generative AI

Angriffsmöglichkeiten gegen Generative AI

Andrea Hauser

XML-Injection

XML-Injection

Andrea Hauser

WebSocket Fuzzing

WebSocket Fuzzing

Andrea Hauser

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