Angriffsmöglichkeiten gegen Generative AI
Andrea Hauser
Burp Makros
Wie sie korrekt verwendet werden
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
Bevor allerdings Burp Makros näher erläutert werden, beleuchten wir deren verschiedene Einsatzgebiete:
- Für das Scannen/Wiederholen eines Requests, der sich in der Mitte eines Prozesses befindet und dessen Scanning nur Sinn macht, wenn der Prozess jeweils von Beginn an durchlaufen wird – oder die Umgekehrte Anforderung: Des Scannen eines Requests, bei dem der Prozess abgeschlossen werden muss, um die Auswirkungen des Scannings zu sehen.
- Für das Scannen/Wiederholen eines Requests, der ein CSRF-Token benötigt, welches von einem anderen Ort abgefragt werden muss.
- Für Sessions mit einem sehr kurzen Timeout, das kein sinnvolles Scanning oder manuelles Testen zulässt.
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.
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.
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:
Korrekt konfigurierte Session handling Regel bei der nur die spezifizierten Parameter überschrieben werden:
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:
Das korrekte und Default-Verhalten wäre:
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
Links
Sie wollen mehr als einen simplen Security Test mit Nessus und Nmap?
Unsere Spezialisten kontaktieren Sie gern!
×
XML-Injection
Andrea Hauser
WebSocket Fuzzing
Andrea Hauser
Prototype Pollution
Andrea Hauser
Sie brauchen Unterstützung bei einem solchen Projekt?
Unsere Spezialisten kontaktieren Sie gern!