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.

In unseren Web Application Penetration Tests verwenden wir hauptsächlich Burp Suite Professional als Machine-in-the-Middle Proxy, um uns bei unseren Tests zu unterstützen und diese so effektiver durchführen zu können. In den letzten Monaten kamen zwei grössere Features zu Burp Suite hinzu: Bambdas und BChecks. Im Rahmen dieses Artikels schauen wir uns diese zwei Neuerungen genauer an, deren Einsatzzweck und einige Einstiegsbeispiele.

Bamdbas

Die Bezeichnung Bambdas setzt sich aus einer Kombination von Burp und Lambda zusammen. Bambdas ermöglichen Anwender von Burp Suite ihr Tool beziehungsweise deren Funktionalität auf einfache Weise direkt auf der grafischen Benutzeroberfläche mittels Java Codestücken zu erweitern. PortSwigger möchte damit eine Möglichkeit bieten, Burp in sämtlichen Punkten von Benutzern erweitern zu können. Bisher war dies nur durch die Entwicklung von Burp Extensions möglich, welche mehr an Entwicklungs-Know-how wie zum Beispiel den Umgang mit Build Tools wie Maven oder Gradle voraussetzten.

Aktueller Stand

Bambdas wurden mit der Veröffentlichung von Burp Suite Release 2023.10.3 eingeführt. Als erstes wurden Bambdas im Proxy Tab eingeführt und ermöglichen so das Filtern von HTTP Traffic. Somit brachte PortSwigger zuerst eine Erweiterung des HTTP History Filters. Ein Bambda wird an dieser Stelle auf ein HTTP History Item (requestResponse Item) angewendet und kann somit sämtliche Eigenschaften der durchgeführten Requests und dazugehörige Responses abfragen, filtern und hervorheben. Im bisherigen Filter der HTTP History konnten reguläre Ausdrücke eingesetzt werden, jedoch sind Bambdas deutlich mächtiger und umfangreicher. Nun ist es auch möglich, ein regulär konfigurierter Filter in ein Bambda zu konvertieren und dies mit Java Code zu erweitern. Im Bambda Mode lassen sich bereits fertige Bambdas hineinkopieren, aus Dateien importieren oder direkt im Editor entwickeln sowie zu einem späteren Zeitpunkt speichern. Zum Zeitpunkt dieses Labs wurden Bambdas im WebSockets Histroy Filter und in der Filterfunktion im Logger Tab in einer Early Adopter Version von Burp Suite bereits veröffentlicht. Der stable Release wird wohl in den kommenden Wochen folgen.

Anwendungsbereiche & Beispiele

Mit Bambdas im Proxy HTTP Traffic Filter lassen sich spezifische Endpunkte, Requests mit Inputfelder, spezielle Header oder andere Anomalien aus allen History Items filtern und hervorheben. Damit lassen sich Sonderfälle einfach eingrenzen und anschliessend einzeln untersuchen. Da Bambdas aus Java Code sind, besteht die Möglichkeit von Exceptions bei der Ausführung. Im Falle von Exceptions wird dies in Burp angezeigt und beim Öffnen des Filters werden detailliertere Informationen inklusive StackTrace dargestellt.

Mit Bambdas können zum Beispiel Requests welche /resources/ oder /image/ im Request Path beziehungsweise der URL enthalten ausgeblendet werden. Gleichzeitig können interessante History Items wie jene die /api im Request Path haben grün und solche die die /graphql beinhalten gelb eingefärbt werden. Im folgenden Beispiel werden noch zusätzlich History Items, welche im Request Path .js enthalten sind, in der Farbe Magenta eingefärbt.

String requestPath = requestResponse.request().pathWithoutQuery();
if(requestPath.isBlank()){
   return false;
}
if(requestPath.contains("/resources/") || requestPath.contains("/image/")){
   return false;
}
if(requestPath.contains("api")){
   requestResponse.annotations().setHighlightColor(HighlightColor.GREEN);
}
if(requestPath.contains("graphql")){
   requestResponse.annotations().setHighlightColor(HighlightColor.YELLOW);
}
if(requestPath.contains(".js")){
   requestResponse.annotations().setHighlightColor(HighlightColor.MAGENTA);
}
return true;

Bambdas können ebenfalls zum Filtern von eingesetzten Server-Response-Headern verwendet werden, wie zum Beispiel Server oder X-Powered-By. Anschliessend kann manuell geprüft werden, ob es sich bei dem Ergebnis um eine Offenlegung von Informationen handelt.

// in case of no response
if (!requestResponse.hasResponse()) {
   return false;
   }
var response = requestResponse.response();
// Header Server or X-Powered-By is present
if (response.hasHeader("Server") || response.hasHeader("X-Powered-By")){
   String headerServer = response.headerValue("Server");
   if(headerServer==null || headerServer.isBlank()){
      return false;
   }
} else {
   return false;
}
return true;

Im Vorstellungsartikel von PortSwigger zu Bambdas sind noch weitere Beispiele zu finden. PortSwigger führt zudem ein eigenes Github Repository für Bambdas, welches von Anwender gerne erweitert werden darf.

Zukünftige Entwicklung

In Zukunft möchte PortSwigger die Erweiterbarkeit von Burp mittels Bambdas an zusätzlichen Orten wie in die zentrale Suchfunktion integrieren. Ein Vorfiltern bei Intruder-Attacken ermöglichen, sowie Bambdas in den Capture Filter beim Logger und bei HTTP Listeners einbauen. Ziel soll es sein, mehrere einfache Bambdas kombinieren zu können, um so komplexe Aufgaben in einem Tool durchzuführen.

BChecks

Der in Burp Suite integrierte Scanner bringt bereits von Haus aus eine grosse Anzahl an Scanchecks für ein breites Spektrum von bekannten Schwachstellen wie SQL-Injections, Cross-Site-Scripting, XML-Injections und viele weitere. Mit BChecks soll der integrierte Scanner auf eine einfache Art direkt in Burp Suite selbst mit eigenen Checks erweitert werden können. Produktspezifische Schwachstellen sind in den mitgelieferten Scanchecks oft nicht enthalten, können daher mittels BChecks selbst hinzugefügt werden.

Aktueller Stand

Mit dem Release 2023.6.2 von Burp Suite wurden BChecks hinzugefügt. Diese befinden sich innerhalb des Extensions Tabs und können dort importiert, erstellt und verändert werden. Im letzten stable Release vor der Publikation dieses Artikels (2023.11.1.3) kam noch Syntax highlighting im BChecks Editor hinzu. Auch für BChecks pflegt PortSwigger ein Github Repository. Mit dem Early Adopter Release 2023.12.1 kam eine Formatier Funktion für BChecks hinzu, diese ist mittels Rechtsklick im Editor durchführbar.

Anwendungsbereiche & Beispiele

Mittels BChecks können Prüfpunkte für produktspezifische Schwachstellen erstellt werden, welche noch nicht in Burp Suite enthalten sind, einige Beispiel können im Artikel von PortSwigger gefunden werden. BChecks können auch eingesetzt werden, um nicht optimal gesetzte Server-Response-Header festzustellen, im folgenden Beispiel geht es um die Konfiguration des HTTP Strict-Transport-Security Header:

metadata:
   language: v2-beta
   name: "HSTS Header Check"
   description: "Checks used HTTP Strict-Transport-Security Header"
   tags: "passive"
   author: "rame"
given response then
   if "Strict-Transport-Security" in {latest.response.headers} then
     if ({latest.response.headers} matches "Strict-Transport-Security:\s*max-age\s*=\s*([3-9]{1}[0-9]{7,})") then
       if not({latest.response.headers} matches "preload") and
         not({latest.response.headers} matches "includeSubDomains") then
         report issue:
            severity: low
            confidence: firm
            detail: "Unsecure HSTS Header in use: no includeSubDomains and no preload set."
            remediation: "Include \"includeSubDomains; preload\" in HTTTP Strict-Transport-Security Header."
       else if not({latest.response.headers} matches "preload") then
         report issue:
            severity: low
            confidence: firm
            detail: "Unsecure HSTS Header in use: no preload set"
            remediation: "Include \"preload\" in HTTTP Strict-Transport-Security Header."
       else if not({latest.response.headers} matches "includeSubDomains") then
         report issue:
            severity: low
            confidence: firm
            detail: "Unsecure HSTS Header in use: no includeSubDomains set"
            remediation: "Include \"includeSubDomains\" in HTTTP Strict-Transport-Security Header."
       end if
     else then
       if not({latest.response.headers} matches "preload") and
         not({latest.response.headers} matches "includeSubDomains") then
          report issue:
            severity: medium
            confidence: firm
            detail: "Unsecure HSTS Header in use: max-age too short, no includeSubDomains and no preload set."
            remediation: "Set HTTTP Strict-Transport-Security to max-age=63072000; includeSubDomains; preload."
       else if not({latest.response.headers} matches "preload") then
         report issue:
            severity: medium
            confidence: firm
            detail: "Unsecure HSTS Header in use: max-age too short and no preload set."
            remediation: "Include \"preload\" and increase max-age in HTTTP Strict-Transport-Security Header."
       else if not({latest.response.headers} matches "includeSubDomains") then
         report issue:
            severity: medium
            confidence: firm
            detail: "Unsecure HSTS Header in use: max-age too short and no includeSubDomains set."
            remediation: "Include \"includeSubDomains\" and increase max-age in HTTTP Strict-Transport-Security Header."
       end if
     end if
   else then
     report issue:
       severity: medium
       confidence: firm
       detail: "No HTTP Strict Transport Header in use"
       remediation: "Set HTTTP Srict Transport Security to max-age=63072000; includeSubDomains; preload"
   end if

Bei der Entwicklung von BChecks kann die BCheck Definition Reference von PortSwigger enorm helfen, da sie einen guten Gesamtüberblick über die Möglichkeiten und Informationen über die notwendigen Teile eines BChecks enthält. Weitere Beispiele können im BChecks Repository von PortSwigger gefunden werden.

BChecks Testing Tool

Im Release 2023.10.2.2 von Burp Suite wurde die Möglichkeit BChecks zu testen ausgeliefert. Das Testen von erstellten oder importieren BChecks findet im BChecks Editor statt. Dafür werden History Items aus der HTTP Proxy History via Send to BCheck editor, was neu im Rechtsklick Kontextmenü in der HTTP Proxy History zu finden ist, als Test Case beim BChecks Editor hinzugefügt. Anschliessend kann im BCheck Editor der ausgewählte BCheck auf die selektierten Test Cases mittels Run Test angewendet werden. Das Ergebnis kann danach in den Tabs Audit items, Event Log, Logger und die aus dem BCheck erstellen Schwachstellen im Issue activity Tab angeschaut werden. Diese Testing Methode wurde eingeführt, um herauszufinden wieso false Positives aus einem BCheck entstehen und ihn dahingehend zu verbessern und einfach erneut anwenden zu können.

Zukünftige Entwicklung

Über die zukünftige Entwicklung und Erweiterung von BChecks ist aktuell nichts bekannt.

Fazit

Mit BChecks lassen sich schnell eigene Checks für produktspezifische Schwachstellen entwickeln und einsetzten. Die Einführung von Bambdas in Burp hilft Benutzern das Filtern von History Items exakter zu steuern und ihre persönlichen Vorlieben in der Hervorhebung einfach und automatisch durch den erstellten Bambdas umzusetzen. Die Einführung von Bambdas an weiteren Orten ist sehr vielversprechend und fördert kleine Automatisierungen und benutzerspezifische Anpassungen, ohne die Entwicklung von dedizierten Extensions vorzunehmen. Neben Bambdas und BChecks unterstützt Burp Suite auch Makros, damit hat sich Andrea im Artikel Burp Makros – Wie sie korrekt verwendet werden auseinandergesetzt.

Penetration Testing oder allgemein Security Testing ist die gezielte Suche nach Schwachstellen, um das Sicherheitsniveau einer IT-Umgebung einzuschätzen und entsprechend informierte Entscheidungen treffen zu können. Was so einfach und einleuchtend klingt, ist in der Praxis oft viel komplexer und häufig bei weitem nicht so klar definiert, wie es den Anschein machen kann.

Penetration Tests sind eine etablierte und bekannte Praxis im Gebiet der Informationssicherheit. In vielen Sicherheitsprogrammen sind sie ein fester Bestandteil und verschiedene Branchenstandards und Aufsichtsbehörden schreiben die regelmässige Durchführung von Penetration Tests vor. Dies ist erfreulich, weil damit ein sehr effektives Mittel zur Steigerung des Sicherheitsniveaus allgemeine Verbreitung gefunden hat, gleichzeitig besteht die Gefahr, durch einen Gewöhnungseffekt Penetration Tests nicht mit der nötigen Sorgfalt zu betrachten oder nur als reine Compliance-Aufgabe zu sehen.

Dieser Beitrag geht auf ein paar einfache, aber essenzielle Punkte ein, die massgeblich zum Erfolg und zum Nutzen von Security Tests beitragen. Im Bereich der offensiven Informationssicherheit sind viele Begriffe wie Penetration Testing, Ethical Hacking, Red Teaming usw. anzutreffen. Für diesen Beitrag wird der Begriff Security Testing allgemein verwendet und bezieht sich auf das ganze Spektrum des offensiven Sicherheitstestens.

Wozu Security Testing?

Einfach gesagt: Um das tatsächliche Sicherheitsniveau eines IT-Systems, einer IT-Umgebung oder gar einer ganzen Organisation zu bestimmen. Es geht darum, mit möglichst grosser Realitätsnähe herauszufinden, was bei echten Angriffen geschehen kann, wie weit ein Angreifer kommen könnte und was die daraus erwachsenden Schäden sein können. Es werden also die effektiv vorhandenen Sicherheitsmassnahmen einer Realitätsprüfung unterzogen, wodurch Schwachstellen und potenzielle Lücken ermittelt werden, die von echten Angreifern ausgenutzt werden könnten.

Mit den so gewonnenen Erkenntnissen können Risiken realistisch eingeschätzt werden und Entscheidungen über zu treffende Massnahmen werden unterstützt, womit eine Organisation ihr Sicherheitsniveau optimieren kann. Regelmässig durchgeführtes Security Testing kann einen wesentlichen Beitrag zur Reduktion der Gefahr von Sicherheitsvorfällen und Datenlecks leisten.

Man kann die Frage stellen, wozu es heutzutage angesichts der riesigen Zahl an Sicherheitsprodukten und Services überhaupt noch Security Testing braucht. Die Antwort ist einfach: Die Effektivität von Sicherheitsmassnahmen kann nicht ausreichend beurteilt werden, ohne sie getestet zu haben. Ausserdem ist die IT in besonderem Mass ständigem Wandel unterworfen, dementsprechend müssen Sicherheitsvorkehrungen laufend angepasst und geprüft werden. Die Redewendung “Vertrauen ist gut, Kontrolle ist besser!” gilt ganz besonders für die Informationssicherheit.

Hypothese und Experiment

Die klassische Vorgehensweise der wissenschaftlichen Methode mit den Definitionen von Hypothese und Experiment lassen sich sehr gut auf das Security Testing anwenden. Dies ist wertvoll, weil damit Voraussetzungen und Erfolgsfaktoren besser hervortreten.

Eine Hypothese ist eine unbewiesene Aussage oder Annahme von Tatsachen oder Gesetzmässigkeiten. Eine Hypothese ist meistens aus einer Theorie abgeleitet, im betrachteten Kontext beispielsweise: Sichere Entwicklungsprozesse bedeuten sichere Software, Best Practices funktionieren, Sicherheitsprodukte schützen ausreichend, Compliance bedeutet Sicherheit und so weiter. Entsprechende Hypothesen können sein: Es sind ausreichend Sicherheitsmassnahmen umgesetzt, deshalb ist die Umgebung sicher, das eingekaufte Produkt ist sicher, die Organisation ist sicher, weil sie compliant ist, das System ist so abgeschottet, dass es für Angreifer unerreichbar ist.

Ein Experiment ist eine methodisch angelegte Untersuchung zur empirischen Gewinnung von Informationen. Das ist genau der Anspruch eines Penetration Tests. Der Wert eines Experiments bemisst sich durch die Korrektheit, Verwendbarkeit und Nützlichkeit der gewonnenen Informationen. Mit diesen Informationen werden Fragen beantwortet, das heisst, sie bestätigen oder widerlegen die aufgestellte Hypothese. Damit wird unmittelbar klar, dass alles mit der geeigneten Fragestellung beginnt.

Geeignete Fragen im Zusammenhang mit Security Tests können sein:

• Kann sich ein Angreifer Zugang zu sensitiven Daten oder Systemen verschaffen?
• Existieren bekannte Schwachstellen in den eingesetzten Technologien?
• Wurde das Notwendige getan, um ein angemessenes Sicherheitsniveau zu etablieren?
• Sind die geltenden Sicherheitsvorgaben erfüllt?
• Wurde das Konzept richtig umgesetzt und funktioniert es in der Praxis?
• Kann ein vorhandenes Bedenken widerlegt oder bestätigt werden?
• Funktionieren die sicherheitsrelevanten Prozesse?
• Wie schwierig oder wie einfach ist es für einen Angreifer, erfolgreich zu sein?
• Sind die Detektions- und Reaktionsmechanismen ausreichend leistungsfähig?

Beim Planen von Penetration Tests wird dies gerne zu wenig berücksichtigt. Oft ist nicht ausreichend geklärt, welche Fragen ein Security Test beantworten soll und wozu die Antworten dienen sollen. Der Vorbereitungs- und Planungsphase hat deshalb beim Security Testing einen besonders hohen Stellenwert und darf nicht vernachlässigt werden. Es kann für einen Auftraggeber herausfordernd sein zu wissen, welche Möglichkeiten bestehen, welche Einschränkungen vorhanden sind und welche Punkte beachtet werden müssen. Wird dies zu wenig beachtet oder zu ungenau abgemacht, besteht die Gefahr, dass Geld für einen zu wenig nützlichen Test ausgegeben wird oder die Ressourcen nicht zielführend eingesetzt werden können oder der Test wiederholt werden muss. Ein erfahrener Dienstleister unterstützt und berät in dieser Phase neutral und sachlich und sorgt dafür, dass vor der Beauftragung gemeinsam geklärt ist, welche Fragen der Test beantworten soll und welche Mittel dafür angewendet werden.

Schliesslich ist ein Penetration Test nur ein Mittel zum Zweck, nämlich Erkenntnisse zu gewinnen, mit denen Entscheidungen getroffen werden können. Üblicherweise werden diese Erkenntnisse vom Dienstleister, soweit es für ihn möglich ist, interpretiert, d.h. mit Schweregraden bewertet und es werden geeignete Massnahmen empfohlen, um die mit den Feststellungen verbundenen Risiken zu begrenzen. Anschliessend ist der Auftraggeber gefordert und muss entscheiden, was die gewonnen Erkenntnisse für ihn bedeuten und wie er damit umgeht.

Die Wichtigkeit, sich über die zu beantwortenden Fragen klar zu sein, sei nochmals betont. In diesem Zusammenhang werden nachfolgend ein paar der gängigsten Ansätze im Security Testing einander gegenübergestellt, um aufzuzeigen, welche Fragestellungen damit beantwortet werden können.

Gegenüberstellung dreier häufiger Security Testing Ansätze

Untenstehend erläutern wir nun näher verschiedene Security Testing Ansätze, darunter Penetration Testing und Red Team Testing, wie auch die Hauptunterschiede zwischen Penetration Testing und einem Bug Bounty.

Penetration Testing und Red Team Testing

Penetration Tests werden üblicherweise durchgeführt, um die Sicherheit eines Prüfobjektes mit definiertem Scope aus Sicht eines realen Angreifers zu untersuchen. Es wird geprüft, ob die im Scope befindlichen Netzwerke, Plattformen, Anwendungen, Systeme, usw. für einen Angreifer ausnutzbare Schwachstellen aufweisen. Dabei wird darauf geachtet, im Rahmen des vereinbarten Aufwands eine möglichst vollständige Untersuchung des Prüfgegenstands durchzuführen. Beispielsweise wird für Webapplikationen meist der OWASP Testing Guide verwendet, der alle für die Sicherheit von Webapplikationen relevanten Themen beinhaltet. Damit wird eine umfassende Testabdeckung angestrebt, um Teilaussagen mit eingeschränktem Nutzen zu vermeiden. Penetration Tests dienen der breiten Untersuchung eines gegebenen Scope und sind normalerweise nicht darauf ausgerichtet, unbemerkt vonstattenzugehen oder die Detektionsmöglichkeiten eines SOC zu testen.

Im Rahmen von Red Team Tests wird versucht, ausgehend von einem vereinbarten Startpunkt ein definiertes Ziel zu erreichen, beispielsweise Zugriff auf sensitive Daten oder Systeme zu erlangen. Im Unterschied zu einem Penetration Test wird hier aber der Fokus darauf gelegt, einen Angreifer zu simulieren, der sich sämtlicher sachdienlicher Mittel und Methoden bedient, um das definierte Ziel zu erreichen und dabei möglichst unentdeckt zu bleiben. Es geht also nicht darum, möglichst alle Schwachstellen eines Scope zu identifizieren, sondern Schwachstellen zu finden, die dem Vorwärtskommen hinsichtlich Zielerreichung dienen. Dementsprechend wird bei Red Team Tests das SOC oder das Blue Team in der Regel nicht vorinformiert, womit auch Aussagen über das Detektions- und Reaktionsvermögen des Auftraggebers gegenüber fortgeschrittenen Angriffen getroffen werden können. Red Team Tests sind dann sinnvoll, wenn die getestete Organisation bereits über eine gewisse Maturität in der Informationssicherheit verfügt.

Die in Penetration Tests und Red Team Tests verwendeten Methoden und Werkzeuge sind in vielen Fällen ähnlich oder sogar gleich. Bei Red Team Tests steht die Widerstandsfähigkeit einer Organisation gegenüber realen, fortgeschrittenen Angriffen im Fokus während Penetration Tests sich in der Regel auf einzelne Systeme oder Bereiche beziehen.

Penetration Testing und Bug Bounty

In den letzten Jahren haben Bug Bounty Programme zunehmend an Popularität gewonnen. Richtig aufgesetzt, können dadurch mit definiertem Maximalaufwand und in vergleichsweise kurzer Zeit wichtige Erkenntnisse gewonnen werden. Die wichtigsten Unterschiede zwischen Penetration Tests und Bug Bounties sind einander in der folgenden Tabelle gegenübergestellt.

Bug Bounty Programme und Penetration Tests verfolgen beide das Ziel, Schwachstellen zu identifizieren, unterscheiden sich aber in ihren Beauftragungsmodellen, Anreizen und Schwerpunktbereichen. Bug Bounty Programme nutzen das Fachwissen einer Vielzahl von Testern, bieten finanzielle Belohnungen für die Meldung von Schwachstellen und können schnelle, aber vielleicht nicht immer umfassende Ergebnisse liefern. Penetration Tests folgen einem ganzheitlichen Ansatz, bieten einfachere Interaktionsmöglichkeit mit den Testern und werden durch wenige, dedizierte Experten durchgeführt.

Fazit

Ein Security Test ist ein Experiment, das Informationen liefert und damit Fragen beantwortet. Es ist deshalb sehr wichtig, dass für den Auftraggeber und für den Auftragnehmer vor Beginn eines Security Tests Klarheit darüber gewonnen wird, welche Fragen durch den Test beantwortet werden sollen und wozu die Ergebnisse verwendet werden sollen. Dies trifft als allgemeine Feststellung auf die verschiedenen Arten von Security Tests gleichermassen zu. Ein erfahrener Dienstleister unterstützt und berät in dieser Phase neutral und sachbezogen und sorgt dafür, dass geklärt ist, welche Fragen der Test beantworten soll und welche Mittel dafür angewendet werden.

• ESET warns of PromptLock, the first AI-driven ransomware (securityaffairs.com)
• AI browsers could leave users penniless: A prompt injection warning (malwarebytes.com)
• Inner speech in motor cortex and implications for speech neuroprostheses (cell.com)
• Wireless-Tap: Automatic Transcription of Phone Calls Using Millimeter-Wave Radar Sensing (dl.acm.org)
• Our first outage from LLM-written code (sketch.dev)
• Detecting AI Music (hackerfactor.com)
• Red Teams Jailbreak GPT-5 With Ease, Warn It’s ‘Nearly Unusable’ for Enterprise (securityweek.com)
• Microsoft investigates Israeli military’s use of Azure cloud storage (theguardian.com)
• Google to Publicly Report New Vulnerabilities Within One Week of Vendor Disclosure (infosecurity-magazine.com)
• Einstein was wrong: MIT just settled a 100-year quantum debate (sciencedaily.com)
• OpenAI kills ‘short-lived experiment’ where ChatGPT chats could be found on Google (malwarebytes.com)