Burp Suite von PortSwigger ist eines der bekanntesten Werkzeuge für Web Application Penetration Testing. Die Stärke von Burp Suite liegt nicht nur in den integrierten Modulen wie Proxy, Scanner oder Repeater, sondern vor allem in seiner Erweiterbarkeit. Es gibt verschiedene Möglichkeiten Burp Suite mit Funktionalität zu erweitern, unteranderem BChecks, Bambdas und die wohl älteste Methode Extensions. Dieser Artikel wird kurz auf die verschiedenen Arten eingehen und anschliessend vertieft in die Entwicklung einer Extension mit Kotlin. Gleichzeitig mit diesem Artikel veröffentlichen wir auch eine erste Version des HeaderMate, eine eigene Burp Suite Extensions für das Loggen und Auswerten von Server-Response-Headern.

Bambdas

Bambdas wurden bereits im Artikel Burp Bambdas & BCheck vorgestellt. Dabei handelt es sich, um Java Codestücke, welche das Filtern an mehreren Orten in Burp ermöglichen. Seit dem Publizieren des letzten Artikels können Bambdas auch im Logger Capture Filter eingesetzt werden, um damit den Traffic genauer zu spezifizieren, welcher später analysiert werden soll. Zudem kann die Site Map ebenfalls mit Hilfe von Bambdas feiner gefiltert werden. Bambdas haben eingeschränkten Zugriff auf die MontoyaApi erhalten, um fortschrittlichere Match and Replace Regeln erstellen zu können. Ebenfalls gibt es nun eine eigene Output-Konsole für ein verbessertes Debuggen von Bambdas.

BChecks

Eine weitere Möglichkeit Burp Suite einfach und mit wenig Code zu erweitern, stellen BChecks dar. Bei BChecks handelt es sich um Scanchecks, die vom Benutzer selbst geschrieben beziehungsweise hinzugefügt werden können. Eine Einführung sowie ein Beispiel sind im Artikel Burp Bambdas & BCheck zu finden.

Extensions

Mit sogenannten Burp Extensions lässt sich Burp Suite gezielt an eigene Bedürfnisse anpassen. Ob man eine spezielle Sicherheitsprüfung automatisieren, Daten aufbereiten oder die Benutzeroberfläche erweitern möchte – eine Extension kann einem viel Zeit und manuelle Arbeit ersparen. Extensions sind gegenüber von BChecks und Bambdas deutlich aufwendiger zu erstellen, jedoch auch umso mächtiger. Burp Extensions können in verschiedenen Programmiersprachen erstellt werden.

Unterstützte Programmiersprachen

PortSwigger bietet Entwicklern mehrere Schnittstellen, um Burp Suite zu erweitern. Grundsätzlich gibt es zwei APIs: Die alte Extender API und die neue MontoyaApi. Burp Extensions können in verschiedenen Programmiersprachen geschrieben werden:

• Java – Die “Hauptsprache” für Burp-Entwicklungen, da Burp Suite selbst ebenfalls in Java geschrieben ist
• Kotlin – Wird ebenfalls in der Java Virtual Machine (JVM) ausgeführt und die Extension Erstellung mittels Kotlin wurde letztes Jahr in einem Webcast von Virtue Security vorgestellt
• Python beziehungsweise Jython – Einfacher Einstieg für Script-Entwickler oder Personen mit Python Hintergrund, ideal für schnelle Prototypen
• Ruby beziehungsweise JRuby – Geeignet für Ruby Entwickler, heutzutage kaum mehr anzutreffen

In Kombination mit Jython und JRuby wird die legacy Extender API verwendet, welche nicht mehr aktiv unterhalten wird, daher wird empfohlen Kotlin oder Java in Kombination mit der MontoyaApi für Neuentwicklungen zu verwenden. Mit ganz alten Versionen von Burp Suite (z.B. 1.5.02) war es noch möglich eine Kombination zwischen Java und JavaScript mittels Rhino für Extensions zu verwenden.

BApp Store

Burp Suite beinhaltet einen BApp Store, über welchen publizierte Extensions, welche von PortSwigger in den Store aufgenommen wurden, installiert werden können. Je nach Testsetup hilft es jedoch auch die Extensions via BApp Store im Browser oder direkt via GitHub herunterzuladen und zu installieren.

Burp Extender API (Legacy)

Diese API war lange Zeit der Standard und ist immer noch weit verbreitet. Hier registriert sich die Extension über das IBurpExtender-Interface und kann dann verschiedene Listener implementieren:

• IHttpListener für HTTP-Requests und Responses
• IScannerCheck für eigene Scans
• IMessageEditorTab für eigene Anzeige-Tabs auf der Benutzeroberfläche

Ein grosser Vorteil ist die grosse Community und die vielen Beispielen im Internet, gerade auf GitHub. Jedoch ist die API veraltet, wird nicht mehr weiterentwickelt und ist teilweise unübersichtlich.

Neuerungen mit der MontoyaApi

Seit 2022 gibt es die neue MontoyaApi, die moderner, klarer strukturiert und einfacher zu verwenden ist. Sie setzt auf ein sauberes Objektmodell und ersetzt langfristig die alte Extender API. Die MontoyaApi bringt ein klares Objektmodell mit konsistenter Namenskonvention mit sich, statt verstreuter Interfaces. Die oben verlinkte Javadoc-Dokumentation ist verständlich, umfangreich und enthält diverse Beispiele. Sie gilt als zukunftssicher, da die Extender API nicht mehr weiterentwickelt und die neuen Funktionen in der MontoyaApi integriert werden.

Grundstruktur einer Extension mit der MontoyaApi

Eine Extension mit der MontoyaApi implementiert das Interface burp.api.montoya.BurpExtension und überschreibt die initialize-Methode mit den gewünschten Werten und Funktionsweisen der Extension.

class MyFirstExtension : BurpExtension {
  private lateinit var montoyaApi: MontoyaApi
  override fun initialize(api: MontoyaApi?) {
    montoyaApi = requireNotNull(api) { "api : MontoyaApi is not allowed to be null" }
    montoyaApi.logging().logToOutput("Started loading the extension...")
    montoyaApi.extension().setName("MyFirstExtension")

    //register active or passive ScanChecks
    montoyaApi.scanner().registerPassiveScanCheck(MyOwnPassiveScanCheck(montoyaApi), ScanCheckType.PER_REQUEST)

    //register a ContextMenuItemsProvider
    montoyaApi.userInterface().registerContextMenuItemsProvider(MyOwnContextMenu(montoyaApi))
    montoyaApi.logging().logToOutput("...Finished loading the extension")
  }
}

Die Logausgaben eignen sich in diesem Teil, um auf einfache Weise das erfolgreiche Laden der Extension festzustellen.

Über das MontoyaApi-Objekt erhält man Zugriff auf:

• HTTP-Interception und -Manipulation
• Scanner-Integration (aktiv und passiv)
• UI-Erweiterungen
• Logging und Einstellungen
• Burp’s AI Integration
• und weitere Burp Module und Funktionen

Das gewünschte Interface erweitert man mittels einer eigenen Klasse und registriert diese in der MyFirstExtension-Klasse und kann so Burp Suite mit der gewünschten Funktionalität erweitern. Für die Entwicklung von Extensions mittels Kotlin eignet sich das GitHub Repository KotlinBurpExtensionBase sehr gut als Einstieg. Darin ist auch beschrieben, wie das Erstellen eines Jars mit Hilfe von Gradle und shadowJar vonstattengeht und wie man einen Debugger an seine Extension anschliesst.

HeaderMate

Im Rahmen dieses Artikels wurde mit der Entwicklung der Extension HeaderMate begonnen. Diese soll unsere interne Burp Suite Extension zur Auswertung von Server-Response-Headern ersetzen, welche in Python entwickelt wurde und die alte Extender API verwendet. Bei der Neuentwicklung haben wir versucht die Extension weniger ressourcenintensiv zu gestalten. Dazu werden nur Requests von zuvor konfigurierten Hostnamen überprüft und die Extension bietet die Möglichkeit die Issue Erstellung innerhalb von Burp Suite ein- beziehungsweise auszuschalten. Im Hintergrund werden die ausgewerteten Server-Response-Header in den persistenten Speicher des Burp Suite Projekts geschrieben. Achtung bei temporären Projekten gibt es den persistenten Speicher nur so lange Burp Suite offen ist.

Am Ende können die protokollierten Server-Response-Header als CSV-Datei über das Kontextmenü zum Beispiel in der Proxy History exportiert werden. Der Export eignet sich gut, um mit einem internen Skript ausgewertet und in das erforderliche Format für das Reporting-Tool konvertiert zu werden. Der Export der ausgewerteten Server-Response-Headern ist im CSV-Format und als Separator wird der ASCII Unit Separator 0×1F verwendet. Dies weil er maschinenfreundlich sowie eindeutig und weder in HTTP-Header-Werten noch in URLs erlaubt ist.

Für die HeaderMate Extension gibt es noch eine Konfigurationsdatei, in welcher hinterlegt ist, welche Header überprüft werden, was deren Optimalwert ist sowie was die Werte für unterschiedliche Schweregrade sind. Es gibt eine default Konfigurationsdatei, welche auch mit der Extension mitgeliefert wird. Es kann auch eine eigene Konfigurationsdatei hineingeladen werden, mit anderen Headern. Sofern es sich bei neuen Server-Response-Headern nicht um Spezialfälle wie zum Beispiel bei Content-Security-Policy handelt, wäre die Idee, dass es ohne eine Anpassung des Codes der Extension funktioniert. Neue Spezialfälle erfordern jedoch gewisse Anpassungen an der Extension selbst. Bei der Entwicklung wurde auf Kotlin statt auf Java gesetzt, da Kotlin eine modernere Syntax bietet, Null-Safety und viele Komfortfunktionen.

Der Inhalt der default Konfigurationsdatei entspricht den Empfehlungen von OWASP und den Artikeln Inglorious Headers, Response Header Hardening und HTTP Strict Transport Security – Fünf häufige Fehler und wie man sie behebt.

Funktionsweise

Die Hauptfunktionalität der HeaderMate Extension geschieht in der Klasse HeaderScanCheck genauer gesagt in der Methode passiveAudit.

Zuerst wird geprüft, ob es eine Änderung an der Konfiguration gab. Anschliessend folgen die ersten Abbruchkriterien, ist eine Response vorhanden und sollten Responses von diesem Host geprüft werden. Danach wird die aktive Header-Konfiguration Zeile um Zeile beziehungsweise Header um Header durchlaufen, dabei werden folgende Schritte durchgespielt:

1. Header und dessen Wert wird in aktueller Response markiert für die Issue Erstellung
2. Wird der Header in der Response nicht gefunden wird daraus ein Logeintrag erstellt sowie bei aktiver Issue Erstellung ein Issue generiert. Der verwendete Schweregrad des Issues hängt dabei von der Konfiguration für einen nicht gesetzten Header ab
3. Wenn der Header gesetzt ist, wird geprüft, ob es sich um den optimalen Wert handelt, was zum einem passed Issue führt
4. Handelt es sich nicht um den optimalen Wert, werden die restlichen Werte aus der Konfiguration geprüft sowie die Spezialfälle, welche in der ersten veröffentlichen Version noch nicht enthalten sind. Sofern keine Übereinstimmung mit der Konfiguration gemacht werden kann, wird in der ersten veröffentlichen Version der Schweregrad false positive im Code gesetzt und kein Issue erstellt. Hierbei handelt es sich um eine bewusste Entwicklungsentscheidung

Zukünftige Erweiterungen

In den letzten Versionen von Burp Suite gab es in der MontoyaApi noch eine Umstellung bei den ScanChecks wobei das Interface burp.api.montoya.scanner.ScanCheck als deprecated deklariert wurde und nun PassiveScanCheck beziehungsweise ActiveScanCheck je nach Einsatzgebiet verwendet werden sollte. Bei der Umstellung beim HeaderMate führte dies zu kuriosen Seiteneffekten, welche noch nicht behoben werden konnten. Die Umstellung auf das PassiveScanCheck Interface erfolgt daher in einer zukünftigen Version. In der ersten veröffentlichten Version wird nur auf die optimale Konfiguration und wenige Spezialfälle wie der CacheControl Header geprüft und aufgrund dessen der Schweregrad gesetzt, dies wird in den nächsten Releases ebenfalls weiter ausgebaut.

Fazit

Das Entwickeln von Burp Extensions ist eine mächtige Möglichkeit, eigene Sicherheitsprüfungen zu automatisieren und Burp Suite individuell zu erweitern. Ob in Java, Python oder Kotlin – die Flexibilität von Burp Suite macht es möglich, eigene Ideen direkt in produktive Werkzeuge zu verwandeln. Mit der MontoyaApi hat PortSwigger einen modernen Weg geschaffen, der die Entwicklung einfacher, sauberer und zukunftssicher macht. Mittels Kotlin und der vorgestellten Extension Basis lässt sich das Setup in kurzer Zeit für eine neue Extension einrichten. Die Vielzahl der vorhandenen Burp Extensions im BApp Store und auf GitHub zeigt den Bedarf und die Möglichkeiten Burp Suite zu erweitern und zu personalisieren.

Über den Autor

Ralph Meier hat eine Lehre als Applikationsentwickler, Fokus Webentwicklung mit Java, bei einer Schweizer Grossbank absolviert und danach einen Bachelor of Science ZFH in Informatik an der ZHAW School of Engineering abgeschlossen. Er fokussiert sich auf die sicherheitstechnische Untersuchung von Webapplikationen. (ORCID 0000-0002-3997-8482)

Links

• https://github.com/ncoblentz/KotlinBurpExtensionBase
• https://github.com/scipag/HeaderMate
• https://portswigger.github.io/burp-extensions-montoya-api/javadoc/burp/api/montoya/MontoyaApi.html
• https://portswigger.net/bappstore
• https://portswigger.net/burp
• https://portswigger.net/burp/documentation/desktop/extend-burp/extensions/creating/extender-api-examples-legacy
• https://www.scip.ch/?labs.20160121
• https://www.scip.ch/?labs.20180308
• https://www.scip.ch/?labs.20190214
• https://www.scip.ch/?labs.20240111
• https://www.youtube.com/watch?v=C8r6uSem93A