Dozent: Im
Laufe des Kurses haben wir eine Reihe von
Methoden kennengelernt, um Fehler und Schwachstellen in verschiedenen Arten
von Software und Infrastruktur zu entdecken.
In der Regel müssen Sie am
Ende des Pentests den Client
über alle gefundenen Schwachstellen oder
über alle Ergebnisse
informieren, dies geschieht mit einem Pentest-Bericht.
Was wir unter einem Pentest-Bericht verstehen, ist
also im Grunde nur ein Dokument, das alles
enthält, was Sie durch Ihr Engagement
gefunden haben, damit der Kunde
oder der Administrator alle Schwachstellen und Schwächen beheben
kann, die Sie gefunden haben.
Diese Berichte werden auch häufig von Führungskräften gelesen, daher
müssen Sie dies berücksichtigen.
Ein guter Bericht sollte also einfach
genug sein, aber auch leicht zu verstehen.
Wenn Sie nun als Pentester arbeiten,
hat das Unternehmen, für das
Sie arbeiten, wahrscheinlich eine eigene Vorlage und
eigene Standards, die Sie beim Schreiben eines
Berichts befolgen müssen.
Und in vielen Fällen
tun Sie das gar
nicht, sondern leiten Ihre Ergebnisse einfach an ein anderes Mitglied
Ihres eigenen
Teams weiter, und diese werden die Lücken im Bericht korrekt ausfüllen.
Daher müssen Sie wahrscheinlich keinen von Grund
auf neu
schreiben, und in vielen Fällen werden Sie nicht einmal den eigentlichen Bericht schreiben,
den der Kunde sieht.
Abgesehen davon möchte ich Ihnen trotzdem
zeigen, wie dies gemacht wird, nur um Ihnen eine
Vorstellung davon zu geben, wie ein Pentest-Bericht aussieht.
Bevor ich Ihnen nun das Beispiel zeige, das
ich habe, werde ich
zunächst dieses Repository einbinden, das im Grunde eine große Anzahl von Pentest-Berichten enthält.
Sie können diese also tatsächlich zur Inspiration durchsehen und
einfach die verschiedenen Stile sehen,
die verschiedene Unternehmen
bei der Erstellung eines Pentest-Berichts verfolgen.
Sie können also auf eines davon klicken und Sie finden
den Bericht, und Sie
können ihn tatsächlich durchgehen, um zu erfahren, wie dieses spezielle Unternehmen seine
Berichte verfasst, und vielleicht finden Sie etwas, das
Ihnen gefällt und das Sie in Ihre eigenen Berichte aufnehmen würden .
Ich werde dies also in die Ressourcen des Vortrags
aufnehmen, damit Sie zur Inspiration darauf zurückkommen können.
Aber was ich wirklich
tun möchte, ist, Sie durch einen
Beispielbericht zu führen, den wir hier in ZSecurity
verwenden, nur um Ihnen eine Vorstellung von den Hauptabschnitten
zu geben, die die meisten Berichte enthalten.
Ich werde dies auch in die Ressourcen aufnehmen, also zögern
Sie nicht, es zu ändern und zu verwenden
oder einige Elemente davon zu übernehmen, wenn Sie möchten.
Sie werden also aus dem
Repository hier merken, dass jedes Unternehmen seinen eigenen Stil hat, Berichte
zu schreiben, aber im Allgemeinen gibt es immer ein paar
Hauptabschnitte, die Sie in jedem Bericht finden.
Also beginnend mit der ersten Seite hier
haben wir das Deckblatt.
Sie können dies also wieder
verkaufen, wie Sie möchten, Sie haben normalerweise das
Firmenlogo, Sie haben
den Titel und dann das Datum des Berichts und die
Version, das ist sehr wichtig.
Und dann haben wir das Unternehmen, unsere Unternehmensinformationen, also dieser
von uns verfasste Bericht, das
sind unsere Unternehmensinformationen.
Und dann haben Sie im Feld
for die Firma, für die Sie diesen Bericht schreiben.
Sie hätten also den
Firmennamen und eine spezifische ID für diese Firma.
Dies ist die ID, mit der Sie dieses Unternehmen in
Ihren eigenen Aufzeichnungen identifizieren.
Auch dies werden Sie wahrscheinlich
nicht selbst
tun, Sie erhalten diese ID von Ihrer eigenen Firma.
Und dann haben wir Kontaktinformationen für beide Unternehmen.
Sie können also in dieser Firma sehen,
dass wir Pentester 1 und Pentester 2 mit ihren
E-Mail-Adressen haben. Dies könnte offensichtlich
eine größere Liste mit dem gesamten Team sein,
das den Pentest
durchführt, und ähnlich der Firma, die
den Pentest durchführt denn Sie
haben wiederum ihre Namen, ihre Position im Unternehmen und ihre Kontaktdaten.
Denken Sie daran, dass
Sie die erste Seite nicht immer so gestalten müssen, aber mehr oder
weniger, normalerweise auf der ersten Seite, haben Sie
den Titel, das Datum, die Version und die Kontaktinformationen
, so machen wir es,
aber auch
hier können Sie es so machen, wie
Sie es möchten, und Sie können
sich von der Ressource inspirieren lassen, die ich hier einfügen werde.
Als nächstes haben wir normalerweise das Inhaltsverzeichnis.
Auch hier,
wie Sie sehen können, einfache Dinge, die wir normalerweise in jedem Dokument haben.
Dies wird Ihnen die Navigation durch das gesamte Dokument erleichtern.
Und wie gesagt,
hier drin können wir die Hauptabschnitte jedes Pentest-Berichts sehen.
Daher ist es sehr wichtig, eine Zusammenfassung zu haben. Dies
ist eine Zusammenfassung des gesamten Engagements,
die für weniger technische Personen konzipiert ist.
Es soll ihnen also eine Vorstellung von Ihren
Erkenntnissen geben, ohne zu tief in die technischen Details einzutauchen.
Dann haben wir eine Zusammenfassung des
Engagements, in der wir
den Umfang detailliert beschreiben, also das,
was Sie getestet haben, welche Teile des Systems
Sie getestet haben, die Risikobewertungen, die Sie
verwendet haben, und eine Übersicht über alles, was Sie gefunden haben.
Nochmals, bis jetzt tauchen wir nicht
tief oder einfach, dies ist nur eine Zusammenfassung des gesamten Engagements.
Sie werden eine bessere Vorstellung von
all dem bekommen, wenn ich den Bericht durchgehe.
Und dann im Abschnitt "Technische Details" tauchen Sie
hier wirklich tief in alles ein,
was Sie gefunden haben.
Wir haben also im Grunde für jeden Fund eine Rubrik.
Wie Sie sehen, ist
dies nur ein Beispiel, daher
habe ich nur drei Erkenntnisse gewonnen, wir haben eine
SQL-Injection, eine Cross-Site-Request-Forgery, eine CSRF und eine Offenlegung von Informationen.
Wie Sie im ersten Abschnitt
sehen können, haben wir im Grunde
nur
die Zusammenfassung von allem,
was wir gefunden haben, während wir in den technischen
Details im Wesentlichen jeden einzelnen Befund aufschlüsseln und
darüber sprechen, wie
wir ihn gefunden haben Details, wie Sie
es replizieren können, werden Sie nach Möglichkeit Screenshots einfügen, damit
das technische Team den Schweregrad dieser Sicherheitsanfälligkeit genau verstehen
und beheben kann.
Sie werden feststellen, dass andere Unternehmen am Ende
einen Anhang
hinzufügen, sie werden Empfehlungen enthalten, in denen Sie
genau sagen, wie Sie Schwachstellen beheben können.
Wie gesagt, es hängt wirklich vom Unternehmen ab,
jedes einzelne Unternehmen hat seinen eigenen
Stil und jedes einzelne Unternehmen hat sein eigenes Format.
Was ich Ihnen hier zeige,
ist also nur ein Beispiel dafür, wie wir es
machen. Sie können sich von den Ressourcen inspirieren lassen und
in vielen Fällen müssen Sie
sich nur an die Vorlage halten, die Ihr
Unternehmen hat, weil dies nicht der Fall ist möchten, dass Sie es auf Ihre
Weise tun.
Gehen wir also zur nächsten Seite, und
Sie werden auf dieser Seite
sehen, dass wir die rechtlichen Informationen haben.
Und deshalb habe ich eigentlich
gesagt, du wirst das wahrscheinlich
nicht selbst machen, du wirst das
nie selbst machen müssen, weil du solche Teile des Berichts hast, die
du nie ändern musst, und
sie werden es tatsächlich sein geschrieben von der Rechtsabteilung
in Ihrem Unternehmen.
Sie werden also für alles verantwortlich sein,
was außer
Kontrolle geraten könnte, um
sicherzustellen, dass Sie nicht verklagt werden, wenn
etwas schiefgeht Ich
weiß es nicht wirklich gut, wie
Pentester und Juristen normalerweise schreiben.
Und dann haben wir das Änderungsprotokoll des Dokuments.
Jedes Mal, wenn eine Änderung am Dokument vorgenommen wird, können Sie
sehen, wir haben das Datum, wir
haben die Version und wir haben einen Kommentar, warum haben
wir diese Änderung vorgenommen?
Oder was ist an dieser Veränderung so bedeutsam?
Dies war also der erste Bericht, als wir
ihn am 1. Januar erstellten,
und dann am 10. Januar
die zweite Version,
in der wir mit der Aufklärungsphase fertig sind.
Auch dies sind nur Beispiele,
aber nur um Ihnen eine Vorstellung davon zu geben,
dass es sehr, sehr wichtig ist, ein Änderungsprotokoll aller
Änderungen zu führen, die dieses Dokument durchläuft.
Nicht alle Unternehmen tun dies,
aber auch hier ist es nur unsere eigene
Entscheidung, es in unseren Bericht aufzunehmen.
Ich sage dies immer wieder, um Ihnen eine Vorstellung
davon zu geben, dass es keine
festen Regeln für die Erstellung solcher Dokumente gibt.
Sie können alles hinzufügen oder entfernen,
was Sie möchten, aber die Hauptteile wären
der rechtliche Teil, die Zusammenfassung und dann
der technische Teil, dies wären die Hauptteile des Berichts.
Jetzt haben wir also die Zusammenfassung, und Sie
können diese durchlesen.
Das soll nicht lang sein,
daher muss es
meiner Meinung nach eine Seite sein, maximal zwei Seiten,
wenn es wirklich sein muss.
Und es heißt im
Grunde nur, dass wir angewiesen wurden, das X-System zu testen.
Es wird erklärt, wie dieses Dokument aufgebaut ist, wobei der
erste Abschnitt weniger detailliert ist, nur
um Ihnen eine Vorstellung von dem Risiko
zu geben, und dann der zweite Abschnitt detaillierter
ist die Techniker, um diese Risiken zu verstehen und zu beheben.
Und dann erhalten wir die
Risikobewertung, also gehen wir davon aus, dass
dies aufgrund der von uns gefundenen Schwachstellen ein
hohes Risiko darstellt. Darin wird die von uns verfolgte Methodik detailliert beschrieben.
Und dann haben wir hier ein paar Charts.
Denken Sie daran, dieser Teil wurde von den Führungskräften
gelesen, das sind Leute, die die
meiste Zeit nicht sehr technisch sind und auch nicht viel Zeit haben.
Daher fügen wir hier Grafiken hinzu,
um ihnen die Anzahl der gefundenen Schwachstellen zu zeigen.
Wir können also sehen, dass wir fünf
hohe Schwachstellen haben, zehn mittel und acht niedrig sind.
Auf diese Weise erhalten sie ein wirklich gutes Verständnis
für die Bedrohungen, denen sie ausgesetzt sind.
Und dann gehen wir in die Zusammenfassung.
Auch dies wird immer noch von den weniger technisch versierten Leuten gelesen.
Daher beschreiben wir zunächst den Umfang, um sicherzustellen,
dass wir ihnen mitteilen, was wir getestet haben, obwohl
sie uns bereits gesagt haben, was wir testen
sollen, nur für den Fall, dass in Zukunft
etwas außerhalb unseres Umfangs entdeckt wird und sie kommen
zu uns
zurück, wir können sagen, naja, das war außerhalb des Rahmens,
wir haben das nicht getestet.
Als nächstes fügen wir die Risikobewertungen hinzu.
Sie werden dies also in
jedem Dokument haben, das
ich ändern soll. Wir sagen im Grunde nur, wie
wir eine bestimmte Schwachstelle als niedrig, mittel, hoch oder kritisch einstufen würden.
Und wir sagen unserer Meinung nach,
wie Sie mit den niedrigen, mittleren, hohen
und kritischen Schwachstellen umgehen sollten.
Sie können sehen,
dass das Kritische sofort behoben werden
muss, während Sie das Niedrige
im nächsten Aktualisierungszyklus beheben müssen.
Auch dies ist nur unsere eigene Meinung.
Als nächstes haben wir die Ergebnisübersicht.
Wir sind also immer noch
in Abschnitt eins, das ist immer noch
für die Führungskräfte, wir müssen nicht zu tief eintauchen.
Wir erhalten also nur die Schwachstellen-ID.
Und wie Sie sehen, ist die erste Schwachstelle kritisch, es
handelt sich um eine SQL-Injection.
Und in vielen Fällen werden sie in
vielen Berichten tatsächlich damit aufhören zu sagen, dass es sich nur um eine SQL-Injection handelt.
Wir möchten die Auswirkungen in diesem Abschnitt tatsächlich zeigen,
denn wie gesagt, diese Leute sind
nicht technisch. Wenn sie
also SQL-Injection lesen, wissen sie möglicherweise nicht, was
eine SQL-Injection ist, sondern interessieren sich für die Auswirkungen dieser Sicherheitsanfälligkeit.
Auch hier haben sie nicht
viel Zeit, also müssen Sie direkt auf den
Punkt kommen. Wir sagen also, dass es sich um
eine SQL-Injection handelt, die zu einem autorisierten Datenbankzugriff führen könnte.
Jetzt wissen sie also, dass mit dieser
Schwachstelle ein Hacker auf
ihre Datenbank zugreifen kann, das ist wahrscheinlich ziemlich schlimm.
Eine andere Schwachstelle, die wir gefunden haben,
ist mittelgroß, und die CSRF, viele Berichte werden hier
aufhören, erklärt Nicht-Technikern wirklich nichts.
Wir sagen also, dass Clients gezwungen werden können, bestimmte
nicht kritische Anfragen zu senden, deshalb ist es ein
Medium, es sind keine unkritischen
Anfragen, aber sie können gezwungen werden, Dinge zu senden.
Und dann haben wir noch
eine kleine Schwachstelle, bei der die PHP-Version
offengelegt wird, also ist dies nicht
wirklich kritisch, da es sich
nicht um eine tatsächliche Schwachstelle handelt, die ausgenutzt werden kann, um Zugang zu erhalten
oder Benutzerdaten offenzulegen, aber diese Informationen könnten für Hacker
nützlich sein, um mit
ihnen zu verketten andere Angriffe oder entdecken Sie Schwachstellen für diese spezielle
PHP-Version, und
deshalb ist es erlaubt, deshalb muss es
nicht so dringend behandelt werden, wie
die kritischen, wie wir hier oben erwähnt haben.
Und lesen Sie den Text hier,
Sie werden sehen, dass vieles davon im Grunde nur dazu dient, unsere
Fehler zu beseitigen und sicherzustellen, dass sie alles verstehen, was
in dem Bericht steht.
Und das wäre das Ende der Zusammenfassung, und jetzt
sind wir bei den technischen Details.
In diesem Abschnitt haben wir also im Grunde, wie ich schon
sagte, einen Unterabschnitt für jeden einzelnen Befund, den wir haben,
und wir tauchen wirklich tief in die
Details dieses Befunds ein.
Sie können also sehen, dass
dies die SQL-Injection ist, die wir zuvor
in der Zusammenfassung erwähnt haben, aber dieses
Mal geben
wir ihnen tatsächlich die URL, die anfällig ist, wir
geben ihnen den anfälligen Parameter, wir
geben ihnen Referenzen, um zu verstehen, was SQL-Injection ist für den Fall,
dass sie es nicht verstehen,
wir geben ihnen die genaue Anfrage und die genaue
Antwort, die wir erhalten haben, wodurch wir festgestellt haben, dass diese
spezielle Seite für eine SQL-Injection anfällig ist.
Dann geben wir ihnen hier die Auswirkungen im Detail und
sagen nicht nur, dass sie auf die Datenbank zugreifen können,
also sagen wir, dass sie auf die
Datenbank zugreifen können, sie können Daten
abrufen, wir haben Zugriff auf die Tabelle des
Benutzers, also bist du
Ich werde in Details eintauchen und Sie sollten hier sogar Screenshots
einfügen, wenn Sie denken, dass sie nützlich sein werden.
Im Abschnitt
zur Risikominderung geben wir ihnen nur
eine kurze Empfehlung, wie gesagt, einige Unternehmen geben detaillierte Empfehlungen,
dies hängt wirklich auch vom Engagement ab.
In diesem Beispiel sagen wir also
im Grunde nur, verwenden Sie vorbereitete Anweisungen mit parametrisierten Abfragen, und
wir geben ihnen eine Referenz, um zu lernen, wie
das geht oder um zu verstehen, wie es funktioniert.
Und das ist es so ziemlich.
Sie werden also für jede einzelne Schwachstelle,
die Sie gefunden haben, wiederholen,
dass ich den Rest leer lasse, da dies nur ein Beispiel ist, aber Sie
haben die Idee.
Sie haben also einen Unterabschnitt für jeden Fund, den
Sie haben, erklären Sie alles im Detail, damit Sie
die Schwachstelle verstehen und
dann können sie es beheben.
Am Ende hätten viele Unternehmen einen Anhang und
vielleicht einen größeren Empfehlungsbereich, wie ich schon sagte, dies
ist unser Stil, Berichte zu schreiben, aber
jedes Unternehmen hat seinen eigenen Stil.
Wenn Ihnen das gefällt, verbringen Sie vielleicht
etwas Zeit damit, die Beispielberichte
durchzugehen, die wir in diesem Repository haben.
Natürlich werde ich sowohl Links für mein Beispiel als auch
für die anderen Beispiele in die Ressourcen
einfügen, damit Sie sie selbst
durchgehen und eine Vorstellung davon bekommen können, wie Pentest-Berichte aussehen.
Aber wie gesagt, in vielen Fällen
füllen Sie einfach eine Probe aus, die der
hier beschriebenen ähnelt, sodass
Sie nie aufgefordert werden, eine von Grund auf neu zu erstellen.