Aufbau Dokumentation und Berichterstellung

Wir erinnern uns kurz an den Anfang unserer Reise als Pentester zurück: Unser Auftraggeber hat uns gebeten, nach Schwachstellen in seinen IT-Systemen zu suchen. Die Ergebnisse unseres Pentests sollten wir daher in einem abschließenden Bericht festhalten. Dieser Bericht ist letztlich das Dokument, welches unser Auftraggeber in seinen Händen halten wird. Aus diesem Grund sollte die Berichterstellung von uns einen besonderen Stellenwert erhalten.

Sofern wir eine Schwachstelle identifiziert haben, wird aufseiten des Auftraggebers im Management eine Entscheidung getroffen werden müssen, wie mit dem Risiko verfahren werden soll. Im idealen Fall soll die Sicherheitslücke von Softwareentwicklern oder IT-Administratoren geschlossen werden. Folglich muss unser Bericht sowohl für die Personen mit starkem IT- als auch mit geringem IT-Hintergrund verfasst werden. Dies wird üblicherweise über die Aufteilung in eine Managementübersicht und einen technischen Bericht realisiert. Ferner sollten alle Randbedingungen des durchgeführten Pentests im Bericht enthalten sein, wie eine Auflistung der Zielsysteme oder der Durchführungszeitraum. Denn ein Pentest spiegelt immer nur eine Momentaufnahme des Sicherheitszustands wider. Eine mögliche Gliederung könnte wie folgt aussehen:

• Deckblatt
• Inhaltsverzeichnis
• Änderungsverzeichnis
• Ansprechpartner
• Projektübersicht (Scope, Klassifizierung, - Durchführungszeitraum)
• Managementübersicht
• Technischer Bericht
• Anhang (Vorgehensweise, Risikobewertung...)

Im Allgemeinen listet ein Deckblatt zentrale Informationen über das vorliegende Dokument auf. In unserem Fall sollten daher mindestens eine Kennung zum Pentest (bspw. „Penetrationstestbericht – Dubius Payment Ltd.“), der Autor, das Erstellungsdatum und die Version des Berichts ersichtlich sein. Die Version eines Pentestberichts ist von Bedeutung, da dieser mit ziemlicher Sicherheit zu einem späteren Zeitpunkt überarbeitet werden wird. Spätestens wenn wir eine Nachüberprüfung der identifizierten Schwachstellen vornehmen, müssen wir im Bericht die erfolgreich behobenen Risiken markieren. Demzufolge findet sich in der o. a. Gliederung auch das Änderungsverzeichnis wieder.

Den Hauptbestandteil eines Pentestberichts werden die Managementübersicht und der technische Bericht bilden. Beide listen alle identifizierten Schwachstellen auf, unterscheiden sich aber in der Intention des Verfassers. In der Managementübersicht muss die Schwere der Risiken von Schwachstellen deutlich werden, wohingegen im technischen Bericht die Detailbeschreibung im Vordergrund steht, die folgende Aspekte umfassen sollte:

• Beschreibung der Schwachstelle
• Beschreibung der Auswirkungen
• Proof of Concept
• Empfehlung

Grundsätzlich empfiehlt es sich, die Schwachstellen gemäß ihrem Risiko – in absteigender Reihenfolge – aufzulisten. Verständlicherweise sollten kritische Sicherheitslücken immer vor einfachen Anmerkungen aufgeführt werden. Natürlich müssen wir beim Verfassen der Texte auch die Zielgruppe berücksichtigen. So wird die Managementübersicht meist von einem IT-Leiter und der technische Bericht von IT-Administratoren oder Softwareentwicklern gelesen. Folglich können wir beim Verfassen der Managementübersicht rudimentäre IT-Grundlagen voraussetzen, sollten Fachbegriffe aber eher für den technischen Bericht aufsparen. Betrachten wir beispielsweise das folgende Szenario: Über einen GET-Parameter im Terminkalender der Dubius Payment Ltd. konnten wir Inhalte aus der Datenbank extrahieren. Diesen Sachverhalt könnten wir im Bericht wie folgt formulieren:

Managementübersicht

Aufgrund fehlender Eingabevalidierung können Datenbankinhalte über einen Parameter ausgelesen werden.

• Risiko: Unmittelbarer Handlungsbedarf (mittlere Eintrittswahrscheinlichkeit, hoher Schaden)
• Behoben: Nein
• System: manager.dubius-payment.com

Technischer Bericht

Überschrift: Time-Based Blind SQL Injection

Beschreibung der Schwachstelle: Bei einer SQL-Injection wird die fehlende Überprüfung von Benutzereingaben ausgenutzt. Dabei wird versucht Datenbankbefehle über die Parameter einzuschleusen. Sofern bei ungültiger SQL-Syntax kein Fehler angezeigt wird, handelt es sich um eine Blind SQL Injection. Time-based Angriffe identifizieren SQL-Injections mittels Delay-Funktionen bzw. -Prozeduren.

Beschreibung der Auswirkungen: Über den GET-Parameter period_time kann bei der Terminanzeige im Terminkalender die MySQL-Sleep-Funktion ausgeführt werden (http://manager.dubius-payment.com/edit_period.php?period_id =1). Eine Zeitverzögerung kann beispielsweise mit dem Angriffstring period_id=1 AND SLEEP(5) beobachtet werden. Unter Verwendung von Zeitverzögerungen können Datenbankinhalte extrahiert werden, wie nachfolgendes Listing zeigt. Bei diesem Verfahren werden alle Zeichen von einem Datenbankeintrag einzeln durchiteriert, wobei eine Zeitverzögerung einsetzt, wenn der korrekte Buchstabe an der Reihe ist.

Proof of Concept:

 +---------+----------+---------------------------------------------------+ 
 | user_id | fname    | lname   | level         | username  | passcode    | 
 +---------+----------+---------------------------------------------------+ 
 | 5       | Jaiden   | Pitts   | User          | jpitts    | v4orPzn9 [..]

Empfehlung: Zur Vermeidung von SQL-Injections sollten Prepared Statements verwendet werden.

Natürlich beinhaltet ein Pentestbericht sensitive Daten und sollte daher vertraulich behandelt werden. Aus diesem Grund muss auch die Form der Berichtübertragung mit dem Auftraggeber abgesprochen werden. Der Bericht könnte beispielsweise in einer verschlüsselten Mail via GPG oder S/MIME versandt werden.

Nachdem du mit der Berichterstellung die letzte Etappe deiner Reise so gut wie gemeistert hast, wollen wir dich nun auf der Zielgeraden begleiten: Du darfst uns gerne deinen abschließenden Pentestbericht zur Dubius Payment Ltd. verschlüsselt via GPG per E-Mail an training@binsec-academy. com übermitteln, um von uns Feedback einzuholen. Der zugehörige Public Key wurde zu diesem Zweck auf einem öffentlich erreichbaren Keyserver hinterlegt.

Philip Baker ist Werkstudent der Dubius Payment Ltd. und hegt großes Interesse an der IT-Sicherheit. Zurzeit führt er aufgrund der PCI-DSS-Anforderungen Vulnerability-Scans von den Netzen durch. Bis zur nächsten PCI-DSS-Zertifizierung soll er aber auch die Durchführung der Pentests übernehmen und hat bereits eine Berichtvorlage erstellt. Findest du sie im Labor? ;)