Docent: Tijdens
de cursus hebben we een aantal methoden geleerd om bugs
en kwetsbaarheden te ontdekken in verschillende soorten
software en infrastructuur.
Gewoonlijk moet u aan het einde van de pentest
de klant op de hoogte brengen van alle kwetsbaarheden
die u hebt gevonden of van alle bevindingen,
dit gebeurt met behulp van een pentest-rapport.
Dus wat we eigenlijk bedoelen met een pentest
rapport, is gewoon een document dat alles bevat
wat je hebt gevonden tijdens je opdracht,
zodat de klant of de beheerder alle kwetsbaarheden
en zwakheden die je hebt gevonden kan verhelpen.
Deze verslagen worden ook vaak gelezen door leidinggevenden, dus
daar moet je rekening mee houden, dus een
goed verslag moet gemakkelijk genoeg zijn,
maar ook gemakkelijk te begrijpen.
Als je als pentester werkt, dan heeft het
bedrijf waarvoor je werkt waarschijnlijk
zijn eigen sjabloon en zijn eigen normen die
je moet volgen bij het schrijven van een rapport.
En in veel gevallen
doe je dat niet eens, je
stuurt je bevindingen gewoon door naar een ander lid
van je eigen team,
en die vult de lege plekken in het rapport goed in.
Daarom hoeft u er waarschijnlijk niet vanaf nul
een te schrijven,
en in veel gevallen schrijft u niet eens het eigenlijke rapport dat de klant
te zien krijgt.
Dit gezegd zijnde, wil ik u toch laten zien
hoe dit in zijn werk gaat, om u een idee te geven van
hoe een pentest-rapport eruit ziet.
Nu eerst, voordat ik u het voorbeeld laat zien
dat ik heb, ga ik deze repository
opnemen die in principe een groot aantal pentest rapporten bevat.
U kunt deze dus bekijken ter inspiratie en om de verschillende
stijlen te zien die verschillende
bedrijven volgen bij het maken
van een pentest-rapport.
Dus u kunt op een van deze klikken en u vindt het rapport,
en u kunt het doornemen om
te leren hoe dit specifieke bedrijf zijn rapporten schrijft,
en misschien vindt u iets dat u bevalt en
dat u in uw eigen rapporten wilt opnemen.
Dus ik ga dit opnemen in de bronnen van de lezing, zodat
je er naar terug kunt keren voor inspiratie.
Maar wat ik echt wil doen
is u door een voorbeeldrapport leiden
dat we hier in ZSecurity gebruiken om u een
idee te geven van de belangrijkste secties die
de meeste rapporten hebben.
Ik zal dit ook opnemen in de hulpmiddelen, dus voel
je vrij om het aan te passen en te gebruiken, of
er elementen van over te nemen als je dat wilt.
U zult merken dat elk bedrijf zijn eigen
stijl heeft om rapporten te schrijven, maar in het algemeen
zijn er altijd een paar hoofdrubrieken die u in elk
rapport aantreft.
Dus te beginnen met de eerste pagina hier,
hebben we de voorpagina.
Dus nogmaals, je kunt dit verkopen
zoals je wilt, je hebt meestal het bedrijfslogo,
je hebt de titel, en dan heb
je de datum van het rapport en de versie, dit is heel belangrijk.
En dan hebben we het bedrijf, onze bedrijfsinformatie, dus dit rapport
geschreven door ons, dit is onze
bedrijfsinformatie.
En dan heb je in het voorveld het bedrijf
waarvoor je dit rapport schrijft.
Dus je hebt de bedrijfsnaam,
je hebt een specifieke ID voor dit bedrijf.
Dit is de ID waarmee u dit bedrijf identificeert in
uw eigen administratie.
Nogmaals, dit is waarschijnlijk
niet iets wat je zelf
zult doen, je krijgt deze ID van je eigen bedrijf.
En dan hebben we contactinformatie voor beide bedrijven.
Dus je ziet in dit bedrijf, hebben we pentester
1 en pentester 2 met hun e-mailadressen, dit kan
natuurlijk een grotere lijst zijn
met al het team dat de pentest doet, en vergelijkbaar
met het bedrijf waarvoor
je de pentest doet, nogmaals, je
hebt hun namen, hun positie in het
bedrijf en hun contactgegevens.
Let wel, je hoeft de
eerste pagina niet altijd zo te stylen, maar meestal
heb je op de eerste pagina de titel, de
datum, de versie en de contactinformatie,
zo doen wij het, maar nogmaals, je kunt het
doen zoals jij wilt en je kunt
inspiratie putten uit de
bron die ik hier ga toevoegen.
Vervolgens hebben we meestal de inhoudsopgave.
Nogmaals, zoals je
ziet, eenvoudige dingen, die we meestal in elk soort document hebben.
Dit zal u helpen door dit hele document te navigeren.
En zoals ik al zei, hier zien
we de belangrijkste secties van elk pentest rapport.
Het is dus heel belangrijk om een samenvatting te hebben, dit is
een samenvatting van de hele opdracht die bedoeld
is voor minder technische mensen.
Het moet hen dus een idee geven van je bevindingen zonder
al te diep in de technische details te duiken.
Dan hebben we een opdrachtsamenvatting
met details over de reikwijdte,
dus wat je hebt getest, welke onderdelen
van hun systeem je hebt getest, de risicowaarderingen
die je hebt gebruikt en een overzicht van
alles wat je hebt gevonden.
Dus nogmaals, we duiken niet diep of eenvoudig,
dit is slechts een samenvatting van de hele verbintenis.
Je krijgt een beter idee van dit
alles als ik het verslag doorneem.
En dan in de technische details, hier
duik je echt diep in alles
wat je gevonden hebt.
Dus we hebben eigenlijk een sectie voor elke bevinding.
Dus zoals u kunt zien, is dit slechts
een voorbeeld, dus ik heb slechts drie
bevindingen gedaan, we hebben een SQL injectie, een Cross-Site
Request Forgery, een CSRF en een information disclosure.
Dus zoals u kunt zien in de eerste
sectie, hebben we eigenlijk alleen de
samenvatting van
alles wat we hebben gevonden,
terwijl in de technische details, we eigenlijk elke bevinding
uitsplitsen, en we gaan praten over hoe we het in detail
hebben gevonden, hoe
het te repliceren, je gaat screenshots toevoegen
als je kunt, zodat het technische team precies de ernst van deze
kwetsbaarheid kan begrijpen en hoe het te repareren.
U zult merken dat andere bedrijven aan het eind een
bijlage opnemen,
met aanbevelingen waarin zij u precies vertellen
hoe u kwetsbaarheden kunt verhelpen.
Zoals ik al zei, het hangt echt af van het bedrijf,
elk bedrijf heeft zijn eigen stijl,
en elk bedrijf heeft zijn eigen formaat.
Dus wat ik u hier laat zien
is slechts een voorbeeld van hoe we het
doen, u kunt inspiratie putten uit de bronnen,
en in veel gevallen moet
u gewoon het sjabloon volgen dat uw bedrijf
heeft, omdat ze niet willen dat u het op uw eigen manier doet.
Dus laten we naar de volgende pagina gaan,
en je zult zien dat we op deze pagina
de wettelijke informatie hebben.
En daarom zei ik eigenlijk, je
zult dit waarschijnlijk niet zelf
doen, je zult dit nooit zelf hoeven
te doen omdat je delen van het rapport zoals deze zult hebben die je nooit
hoeft aan te passen, en ze zullen
eigenlijk geschreven zijn door het juridische team in
je bedrijf.
Ze zullen dus rekening houden met alles wat uit de hand kan
lopen om ervoor te zorgen dat je
niet wordt aangeklaagd als er iets
fout gaat, het zal dingen bevatten zoals disclaimers, GDPR, privacy,
juridische zaken, en al die dingen
die wij als pentesters en juridische mensen meestal
niet zo goed kennen.
En dan hebben we de change log van het document.
Dus elke keer dat er een wijziging in het document wordt aangebracht,
kunt u zien, we hebben de datum, we hebben
de versie en we hebben een opmerking, waarom hebben we deze
wijziging gedaan?
Of wat is er zo belangrijk aan deze verandering?
Dus dit was het eerste verslag toen we
het maakten op 1 januari, en
op 10 januari maakten we de
tweede versie waarin we
klaar zijn met de Recon Stage.
Nogmaals, dit zijn slechts voorbeelden,
maar om u een idee te geven dat het bijhouden van een change
log van alle wijzigingen die dit document ondergaat
zeer, zeer belangrijk is.
Niet alle bedrijven doen dat, maar
nogmaals, dat is gewoon onze eigen keuze om
het in ons verslag op te nemen.
Ik blijf dit zeggen om u een idee te geven
dat er geen vaste regels zijn voor
het maken van dit soort documenten.
U kunt alles toevoegen of verwijderen
wat u wilt, maar de belangrijkste onderdelen
zijn het juridische gedeelte, de samenvatting
en het technische gedeelte.
Dus nu hebben we de samenvatting, en u kunt
deze doorlezen.
Het is niet de bedoeling dat dit
lang is, dus naar mijn
mening moet het een pagina zijn, maximaal twee pagina's
als het echt moet.
En het zegt eigenlijk alleen:
we kregen de opdracht X systeem te testen, het legt uit hoe dit
document is georganiseerd, waarbij het eerste deel minder
gedetailleerd is, gewoon om u een idee
te geven van het risico, en het tweede deel
is gedetailleerd voor de technische mensen om deze
risico's te begrijpen en ze op te lossen.
En dan krijgen we de risicoclassificatie,
dus we gaan ervan uit dat dit een
hoog risico is op basis van de kwetsbaarheden
die we hebben gevonden.
En dan hebben we hier wat grafieken.
Vergeet niet dat dit deel is gelezen door de leidinggevenden,
dit zijn mensen die meestal niet erg technisch
zijn, en ze hebben ook niet veel tijd.
Dus we voegen hier grafieken bij om te laten
zien hoeveel kwetsbaarheden we hebben gevonden.
Dus we zien dat we vijf kwetsbaarheden hebben die hoog
zijn, tien die gemiddeld zijn en acht die laag zijn.
Dus dit zal hen een goed inzicht geven in de bedreigingen
waarmee ze geconfronteerd worden.
En dan gaan we naar de samenvatting.
Nogmaals, dit zal nog steeds worden gelezen door de minder technische mensen.
Dus allereerst detailleren we de reikwijdte om
ervoor te zorgen dat we hen vertellen wat we getest
hebben, ook al hebben zij ons al verteld wat we
moeten testen, zodat we in de toekomst, als
er iets buiten onze reikwijdte wordt ontdekt en zij
bij ons terugkomen,
kunnen zeggen: dit viel buiten de reikwijdte, we hebben
dit niet getest.
Vervolgens nemen we de risicobeoordelingen op.
Dit staat dus in elk document dat
ik moet aanpassen, we zeggen eigenlijk
gewoon hoe we een bepaalde kwetsbaarheid zouden classificeren
als laag, gemiddeld, hoog of kritiek.
En wij zeggen, naar onze mening, hoe je
moet omgaan met de lage, gemiddelde, hoge en
kritieke kwetsbaarheden.
U kunt zien dat voor de kritieke,
we zeggen dat u onmiddellijk moet repareren,
terwijl voor de lage, u moet repareren
in de volgende update cyclus.
Nogmaals, dit is slechts onze eigen mening.
Vervolgens hebben we het overzicht van de bevindingen.
Dus we zijn nog steeds in deel één,
dit is nog steeds voor de leidinggevenden,
we hoeven niet te diep te duiken.
Dus we krijgen gewoon de kwetsbaarheid ID.
En je ziet, voor de eerste kwetsbaarheid, het is kritiek,
het is een SQL injectie.
En in veel gevallen, in veel
rapporten, houden ze het bij een SQL injectie.
Wij laten graag de impact zien in dit gedeelte, want zoals
ik al zei, deze mensen zijn niet technisch,
dus als ze SQL injectie lezen,
weten ze misschien niet wat een SQL injectie is,
waar ze om geven is de impact van deze kwetsbaarheid.
Nogmaals, ze hebben niet veel tijd,
dus je moet direct ter zake komen, dus wat
we doen is zeggen dat het een SQL injectie is die kan
leiden tot een geautoriseerde database toegang.
Dus nu weten ze dat een hacker
met deze kwetsbaarheid
toegang heeft tot hun database.
Een andere kwetsbaarheid die we vonden is medium,
en de CSRF weer, veel rapporten zullen hier stoppen, legt niet
echt iets uit aan niet-technische mensen.
Dus we zeggen dat klanten gedwongen
kunnen worden om bepaalde niet-kritische verzoeken
in te dienen.
En dan hebben we nog een lage kwetsbaarheid
waarbij de PHP-versie wordt onthuld, dus dit
is niet echt kritisch omdat het geen echte
kwetsbaarheid is die kan worden uitgebuit
om toegang te krijgen of gebruikersgegevens bloot te leggen, maar deze informatie kan
nuttig zijn voor hackers om andere aanvallen uit te voeren of kwetsbaarheden te ontdekken
voor deze specifieke PHP-versie, en daarom is het toegestaan, daarom hoeft er niet zo dringend
iets aan te worden gedaan als aan de kritieke
kwetsbaarheden die we hierboven hebben
vermeld.
En lees gerust de tekst hier, je zult zien
dat een groot deel ervan eigenlijk alleen bedoeld is om onze fouten op te
helderen en ervoor te zorgen dat zij alles begrijpen wat
in het verslag staat.
En dat is het einde van de samenvatting, en nu
komen we bij de technische details.
Dus in dit deel hebben we eigenlijk, zoals ik zei, een
subsectie voor elke bevinding die we hebben,
en we duiken echt diep in de details
van deze bevinding.
U ziet dus dat dit de SQL-injectie
is die we eerder in de samenvatting noemden,
maar deze keer geven we hen de URL die kwetsbaar is, we geven
hen de kwetsbare parameter, we geven hen referenties
om te begrijpen wat SQL-injectie
is voor het geval ze het niet begrijpen, we geven hen het exacte
verzoek en de exacte respons die
we kregen, waardoor we hebben vastgesteld dat
deze specifieke pagina kwetsbaar is voor een SQL-injectie.
Dan geven we ze hier de impact in details, niet alleen
zeggen dat ze toegang hebben tot de database, dus
we zeggen dat ze toegang hebben tot
de database, ze kunnen gegevens
ophalen, we hebben toegang tot de tabel van
de gebruiker, dus je gaat in details
duiken en je moet zelfs screenshots toevoegen als
je denkt dat dat nuttig is.
In het mitigatiegedeelte
geven we hen slechts een snelle aanbeveling,
zoals ik al zei, sommige bedrijven geven gedetailleerde aanbevelingen,
dit hangt ook echt af van de verbintenis.
Dus in dit voorbeeld zeggen we eigenlijk
gewoon, gebruik prepared statements met geparametriseerde
queries, en we geven ze een referentie om te leren hoe
dat moet of om te begrijpen hoe het werkt.
En dat is het wel zo'n beetje.
Dus dat ga je herhalen voor elke kwetsbaarheid
die je hebt gevonden, ik laat
de rest leeg omdat dit maar een voorbeeld is, maar je snapt het idee.
Dus heb je een subsectie voor elke bevinding die
je hebt, leg alles in detail uit zodat ze de kwetsbaarheid
begrijpen en dan kunnen ze het
oplossen.
Aan het eind hebben veel bedrijven een bijlage en een
grotere sectie met aanbevelingen, zoals ik al zei,
dit is onze stijl van rapporten schrijven, maar
elk bedrijf heeft zijn eigen stijl.
Als je dit leuk vindt, neem dan eens
de voorbeeldrapporten door die
we in dit archief hebben.
Uiteraard zal ik zowel links voor mijn monster als voor de
andere monsters in de bronnen opnemen,
zodat u ze zelf kunt doornemen en een idee
kunt krijgen van hoe pentest-rapporten eruit zien.
Maar zoals ik al zei,
in veel gevallen zul je gewoon
een voorbeeld vullen
dat lijkt op wat we hier hebben.