Ein Penetration Test Auftrag besteht aus den Etappen Scoping, Testing und Dokumentation. Bei allen drei gibt es wiederholt Diskussionen in der IT Security Community, wenngleich in unterschiedlichen Qualitäten. Im Scoping wird manchmal recht polemisch diskutiert, ob nicht auch Social Engineering beinhaltet sein muss. Andernorts wird behauptet, es müssen alle Umsysteme der Firma im Scope liegen. Die Diskussion ist wichtig, zu oft werden allerdings Risikoszenarien und Aussagekontexte durcheinander geworfen. Darunter leidet die Nachvollziehbarkeit für Laien, welche der Diskussionen folgen wollen. Auch im Testing kommt es zu solchen Debatten. Zwei lesenswerte Artikel zum Thema sind Purple Testing, welcher eine Kombination des klassischen Schemas Red (Angriff) versus Blue (Verteidigung) aufzeichnet. Im Artikel Interactive Pentesting plädiert der Autor für eine stärkere Einbindung des Kunden während der Tests. Interessant sind die Artikel, weil sie ausserhalb der regulären Linien zeichnen. Weniger lesenswert sind die Artikel zu Haarspaltereien, wie der Definition von Wörtern wie Penetration Test und Security Assessment.

Dokumentation ist manchmal ein etwas stiefmütterlich behandeltes Thema, denn was für Vampire Knoblauch und Sonnenlicht ist, ist für Tester oftmals Dokumentation. Häufig wird dabei beispielsweise übersehen, dass nicht für den Tester, sondern für den Leser des Berichts geschrieben werden muss. Wird direkt mit dem Entwicklerteam zusammengearbeitet, reicht manchmal das reine Auflisten von Schwachstellen. Muss aus einem Bericht anschliessend neues Budget bewilligt werden, dann reicht ein rein technischer Bericht meist nicht mehr.

Bei scip versuchen wir ständig uns zu verbessern und das führt zu Diskussionen darüber, was und wie getestet wird und natürlich auch die Dokumentation der Findings. Im Folgenden möchte ich zwei Test-Ansätzen reflektieren: checklistenbasiertes Testen versus szenariobasiertes Testen in Bezug auf (Web)-Applikationen und deren Implikationen auf Dokumentation.

Checklistenbasiertes Testen

Grundsätzlich ist dies bereits in vielen automatisieren Scannern für Netzwerk und Web Applications vorhanden. Im Programm sind Testfälle – was nichts anderes als Punkte auf einer Checkliste sind – definiert und diese werden durchgespielt. Es stellt sich die Frage, wie sieht dieser Ansatz für manuelle Tests aus und wie sinnvoll ist er?

Viele Vor- und Nachteile stehen und fallen mit der Implementation/Qualität der Checkliste. Sind Punkte in der Liste ein Risiko oder ein Testfall/Payload? Betrachten wir das am Fall des Session-Managements. Je nach Ansatz können wir entweder die vier folgenden Punkte einzeln in der Checkliste führen:

• Komplexität des Session Tokens
• Kollisionswahrscheinlichkeit des Session Tokens
• Länge des Session Tokens
• Token menschlich erratbar

Oder sie nur als einen Punkt zusammenfassen:

• Session Token Technologie

Es sind vier verschiedene Probleme und daher ist es durchaus möglich zu argumentieren, dass sie alle ihren eigenen Punkt in der Checkliste verdienen. Auf der anderen Seite kann allerdings auch argumentiert werden, dass die vier Punkte alle in dem gleichen Risiko enden: Eine Session kann übernommen werden. Hinzu kommt, dass für den Test der ersten drei Punkte vermutlich nur ein Werkzeug notwendig ist, denn die Punkte sind aus der Sicht der Implementation voneinander abhängig. So ist die Kollisionswahrscheinlichkeit beispielsweise höher, wenn der Token kurz ist. Die meisten Anwendungen verwenden heutzutage glücklicherweise Session Token Technologien, welche bereits existiert, oft getestet sind und als sicher gelten. Wird als Session Token z.B. einfach der Benutzername verwendet, dann wird das im Test auffallen und dokumentiert werden. Diesen Punkt ebenfalls in Session Token Technologie zu integrieren ist aber sinnvoll.

Wird die Frage von Risiko versus Testfall als Eintrag auf der Checkliste in Bezug auf Cross-Site Scripting (XSS) gestellt, ist es hingegen einfach zu entscheiden, ob eine Trennung nach Risiko oder Test sinnvoll ist:

• Unterscheidung von Risiken: Ja (Reflected, Stored und DOM-based XSS)
• Jeden einzelnen Payload auflisten: Nein

XSS die aufgrund von Browserfehlern existieren (Universal-XSS und Mutation-based XSS), gehören in eine Browser-Testing Checkliste. Gibt es einen Filter und ist es möglich diesen zu umgehen, dann ist dies eine weitere Schwachstelle und wird besser in einem eigenen Punkt aufgelistet.

Die Frage nach Testfall oder Risiko lässt sich nicht allgemein beantworten und muss von Fall zu Fall entschieden werden. Als oberste Prämisse definiert sich eine möglichst hohe und umfassende Abdeckung des definierten Scopes.

Vorteile, die Checklisten für Tests bieten:

1. Es lässt sich leichter sicherstellen, dass nichts vergessen wurde. Gerade bei grossen Anwendungen kann es schnell passieren, dass ein gewisser Schwachstellentyp oder eine Konfigurationseinstellung nicht überprüft wird. Die Checkliste hilft dabei, dass der Tester nichts übersieht.
2. Wird eine Schwachstelle gefunden, welche nicht in der Checkliste vorhanden ist, so kann die Checkliste leicht erweitert und in Zukunft dieser Punkt zusätzlich getestet werden. Damit kann eine kontinuierliche Verbesserung erzielt werden.

Bei Checklisten ist es wichtig, dass Tester die Checkliste nicht als vollumfänglich betrachten, sondern als Minimalanforderung. Dies ist allerdings mehr ein Problem des Umgangs mit Checklisten, als der Ansatz an sich. Wird ein Finding gefunden, welches selten ist und nicht in der Checkliste, lohnt es sich möglicherweise nicht, dies als zusätzlichen Punkt aufzunehmen. Stattdessen sollte es zusätzlich dokumentiert werden. Sich in diesem Fall auf die Liste einzuschränken, wäre schädlich durch den in Zukunft generierten Aufwand ohne Mehrwert.

Auch bei der Dokumentation hilft die Checkliste:

1. Die einzelnen Punkte lassen sich grösstenteils auf bestehende Standards wie OWASP, Finma, PCI DSS etc. abbilden. Verwendet ein Kunde intern einen dieser Standards, weiss er sofort, wie er diese einzuordnen hat. Gleichzeitig können wir als Tester aber auch Punkte aufnehmen, welche wir für wichtig erachten aber möglicherweise keine Abbildung in einem der Standards erhalten. Als Beispiel hierfür seien Cross-Site Script Inclusion-Angriffe genannt, welche keinem Punkt des aktuellen OWASP Testing Guides entsprechen.
2. Will ein Kunde ausnahmsweise nur die Schwachstellen in der Dokumentation aufgelistet sehen, dann ist das Filtern nach Schwachstellen immer leichter, als anschliessend alle Tests aufzuführen.
3. Viele Auditberichte, die ich zu sehen bekomme, dokumentieren ausschliesslich Schwachstellen. Wenn sehr nah mit dem technischen Team zusammengearbeitet wird, reicht dies möglicherweise auch vollkommen aus und ist sogar erwünscht. Wer aber für eine breitere Leserschaft dokumentiert, ist oft gut daran beraten, nicht nur eine Liste von technischen Sicherheitsproblemen zu liefern.
4. Dadurch, dass eine Checkliste während den Tests verwendet wurde, kann anschliessend auch ohne grossen Zusatzaufwand dokumentiert werden, was getestet wurde, aber kein Problem darstellt. Das ist auch eine wichtige Aussage!

Dass Schwachstellen im Kontext von allen geprüften Punkten stehen, ist dann eigentlich mehr ein Seiteneffekt von vollständiger Dokumentation. Dadurch wird vermieden, dass eine grosse Schwachstelle von 100 Tests, die ansonsten positiv ausfielen, den Ton angibt. Zum Beispiel war die Codierung der Ausgabe nicht vollständig, aber Session und Konfiguration der Server Header fehlerlos.

Berichte, welche nicht nur kritisieren, werden tendenziell leichter akzeptiert. Denn wir wollen mit einem Bericht die Sicherheit verbessern und die Entwickler unterstützen – Und nicht Widerstand erzeugen.

Als zusätzlicher positiver Nebeneffekt werden nebenbei Administratoren und Entwickler geschult. Nur weil eine Schwachstelle nicht in einer Anwendung vorhanden ist, heisst dies nicht, dass sie aktiv vermieden wurde oder überhaupt ein Bewusstsein für ihre Existenz vorhanden ist.

Szenariobasiertes Testen

Der Ansatz des szenariobasierten Testens kommt ursprünglich aus der Risikoanalyse. Bei einer Risikoanalyse wird überprüft, welche Risiken bestehen und diese nach ihrer Auswirkung beurteilt. Aufgrund dessen kann dann jeweils eine angemessene Gegenmassnahme entwickelt werden. Dieser Ansatz kann auch für Web Application Penetration Tests verwendet werden.

Generelle Risiken sind immer Kompromittierung des Servers oder Entstellung (engl. defacing) der Webseite. Aber jede Anwendung hat ihre spezifischen Risiken. In einer Banking Application wäre es fatal, wenn ein Benutzer Überweisungen im Namen eines anderen Benutzers durchführen könnte. Bei einem Mailanbieter wäre das Lesen von E-Mails anderer Benutzer ein Risiko, welches unter keinen Umständen auftreten darf.

Analog zum Checklistenansatz müssen erst einmal Szenarien erarbeitet werden. Manche können unabhängig vom Kunden entwickelt werden, andere brauchen hingegen ein Insiderwissen. So kann beispielsweise bei einer Anwendung, welche als Trainingsplattform fungiert, eine Künstliche Intelligenz im Hintergrund agieren. Ist es für einen Angreifer möglich diese zu stehlen, würde das komplette Geschäftsmodell der Firma zusammenbrechen. Ohne diese Hintergrundinformation wäre dies möglicherweise kein Testziel. Eine Aussage im Bericht hierzu ist hingegen sicherlich willkommen.

Die Vorteile von szenariobasiertem Testen sind:

1. Insbesondere aktiveres Suchen nach Wegen zum Ziel. Der Weg ist hierbei meist eine geschickte Verkettung von kleineren Schwachstellen und nicht eine alleinige Sicherheitslücke. Genau hierin liegt die Stärke des Ansatzes von szenariobasiertem Testen. Das Ziel ist definiert und genau die kreativen Ansätze, z.B. an eine Ressource zu gelangen, beeinflusst nachher die Qualität des Tests.
2. Ein positiver Randeffekt ist erhöhte Freude an der Arbeit. Dies mag für Kunden keine direkte Auswirkung haben. Aber indirekt sicherlich, denn mit Freude ausgeführte Arbeit bringt meist die qualitativ besseren Resultate.

Auch für die Dokumentation bietet diese Art zu testen Vorteile:

1. Muss ein Bericht auch für die Firmenleitung lesbar sein, welche technisch weniger versiert ist, kann er leichter aussagekräftig gestaltet werden. Beispielsweise kann die Aussage getroffen werden, dass von definierten Risiken X, Y und Z nur Y vorhanden ist und ein tatsächliches Risiko darstellt. Dies steht stark im Gegensatz zu einer Vielzahl von kleineren Schwachstellen, bei der nicht zwingend offensichtlich wird, wie diese zu einem erfolgreichen Angriff führen.
2. Insgesamt sind Szenarien für Leute ohne technischen Hintergrund leichter zu verstehen. Es wird sich von Testern immer wieder über fehlende Akzeptanz von Führungsposition der IT Security gegenüber beschwert. Akzeptanz fällt leichter, wenn verstanden wird, um was es geht. Szenarien sind eine Möglichkeit, die wir hierfür nutzen können.
3. Auch für die technische Leserschaft der Dokumentation helfen Szenarien, da sie Auswirkungen verdeutlichen. Ein Cross-Site Request Forgery (CSRF) technisch nachvollziehen zu können ist nicht das Gleiche, wie die Auswirkungen eines CSRF im konkreten Anwendungsfall zu verstehen. Die Auswirkungen von CSRF variieren stark. Nicht umsonst sind auf Bug-Bounty Seiten einem Tester vielleicht komisch anmutende Subkategorien aufgelistet, wie Logout-CSRF oder CSRF von öffentlichen Formularen. Dies ist aber verständlich, betrachtet man die Auswirkung. Ein CSRF mit dem ein Angreifer direkt in einer Banking Application eine Überweisung ausführen kann, ist offensichtlich ein Problem. Wenn generell der Schutz fehlt, ist es manchmal nicht so schnell erkennbar, warum dies eine Gefahr sein soll. Das Gleiche gilt für das im Internet gerne runtergespielte Logout-CSRF, denn auch das kann durchaus gravierende Folgen haben. In einem – aus Sicht eines Auditors – sehr schönen Angriff auf Uber, war aber genau das Logout-CSRF eine wichtige Komponente. Der Artikel ist auch ein gutes Beispiel dafür, wie ein Reflected-XSS im User Kontext (der Autor nennt es Self-XSS) auch an Bedeutung gewinnen kann.

Probleme können entstehen, wenn dieser Ansatz ins Extreme getrieben wird. Werden nur vollständige Szenarien dokumentiert, so verliert der Bericht unter Umständen gefundene Schwachstellen. Diese sind möglicherweise erst in einem zukünftigen Szenario relevant, aber die Möglichkeit, dass das Angriffsszenario überhaupt auftritt, könnte bereits verhindert werden. Deshalb müssen diese Schwachstellen trotzdem ihren Weg in die Dokumentation finden.

Fazit

Beide Ansätze haben ihre positiven Seiten. Im Red Team der scip versuchen wir das Beste von beiden Seiten gewinnen zu können. Bei den Tests verwenden wir Checklisten, um Vollständigkeit und Vergleichbarkeit zu gewährleisten. Die gefundenen einzelnen Schwachstellen ergeben manchmal neue Szenarien, welche vorher nicht ersichtlich waren. Umgekehrt verwenden wir aber auch Szenarien, welche manchmal dazu führen, dass neue Punkte in die Checkliste aufgenommen werden. Auch bei den Berichten verwenden wir eine Kombination der beiden Ansätze. Das Ziel eines jeden Berichts ist:

• Verständlichkeit für alle relevanten Leser (vom Management bis zum Administrator und Entwickler)
• Vollständigkeit
• Transparenz, welche Tests durchgeführt wurden
• Relevanz

Für die Transparenz hilft der Checklistenansatz enorm. Es ist leicht ersichtlich, was getestet wurde, welche Bereiche gut waren und welche Verbesserungsbedarf haben. Auch hilft dieser Ansatz die Vollständigkeit zu wahren. Die Verständlichkeit und Relevanz werden so gut wie möglich durch Szenarien abgedeckt. Szenarien fliessen dabei so oft wie möglich in den einzelnen Checklistepunkten ein und ihnen wird sich im Management Summary gewidmet. Mit den Szenarien können wir dementsprechend auch eine kundenspezifische Relevanz sicherstellen.

Über den Autor

Veit Hailperin arbeitet seit 2010 im Bereich der Informationssicherheit. Seine Forschung konzentriert sich auf Network und Application Layer Security sowie auf den Schutz der Privatsphäre. Die Resultate präsentiert er an Konferenzen.

Links

• http://carnal0wnage.attackresearch.com/2016/01/purple-teaming-lessons-learned-ruxcon.html
• https://digi.ninja/blog/interactive_pentesting.php
• https://whitton.xyz/articles/uber-turning-self-xss-into-good-xss/