Docente: Durante
il corso, abbiamo appreso una serie di
metodi per scoprire bug e vulnerabilità in diversi
tipi di software e infrastruttura.
Di solito, alla fine del pentest, dovrai
informare il cliente di tutte le
vulnerabilità che hai trovato o di
tutti i risultati, questo
viene fatto utilizzando un rapporto di pentest.
Quindi, in pratica, ciò che intendiamo per
rapporto pentest, è solo un documento che include tutto
ciò che hai trovato durante il tuo
impegno in modo che il cliente
o l'amministratore possano procedere e correggere tutte le vulnerabilità
e le debolezze che hai trovato.
Questi rapporti vengono letti anche dai dirigenti molto spesso, quindi
dovresti tenerne conto, quindi
un buon rapporto dovrebbe essere abbastanza
facile, ma è anche facile da capire.
Ora, se lavori come pentester, l'azienda
per cui lavori probabilmente avrà
il proprio modello e i propri
standard che devi seguire quando scrivi
un rapporto.
E in molti
casi, non lo farai
nemmeno, invierai semplicemente le tue scoperte a un altro
membro della
tua squadra, e loro riempiranno gli spazi vuoti nel rapporto.
Pertanto, probabilmente non sarà necessario scriverne uno
da zero
e, in molti casi, non si scriverà nemmeno il rapporto effettivo
visualizzato dal cliente.
Detto questo, voglio ancora mostrarti
come si fa solo per darti un'idea
di come sia un rapporto pentest.
Ora, prima di tutto, prima di mostrarti
il campione che ho,
includerò questo repository che contiene sostanzialmente un gran numero di rapporti pentest.
Quindi potresti effettivamente guardare attraverso questi per ispirazione e solo
per vedere i diversi stili
che le diverse aziende
seguono quando realizzano un rapporto pentest.
Quindi puoi fare clic su uno di questi e
troverai il rapporto, e
puoi effettivamente esaminarlo per imparare come questa specifica azienda scrive
i suoi rapporti, e forse trovi qualcosa
che ti piace che inizieresti a includere nei tuoi rapporti .
Quindi includerò questo nelle risorse della conferenza in modo
che tu possa tornarci per trarre ispirazione.
Ma quello che
voglio davvero fare è guidarti attraverso
un rapporto di esempio che usiamo qui
in ZSecurity solo per darti un'idea delle sezioni principali
che hanno la maggior parte dei rapporti.
Includerò anche questo nelle risorse, quindi sentiti
libero di modificarlo e usarlo, o
di prenderne alcuni elementi se lo desideri.
Quindi noterai dal repository qui
dentro, ogni azienda ha il suo stile di scrittura dei
report, ma in generale, ci sono sempre alcune sezioni
principali che troverai in ogni report.
Quindi, iniziando dalla prima pagina proprio qui,
abbiamo la pagina di copertina.
Quindi di nuovo, puoi venderlo
come vuoi, di solito hai il logo
dell'azienda, hai il
titolo e poi avrai la data del rapporto e la
versione, questo è molto importante.
E poi, abbiamo l'azienda, le informazioni sulla nostra azienda, quindi questo rapporto
scritto da noi, queste sono le
informazioni sulla nostra azienda.
E poi hai nel campo per,
hai l'azienda per cui stai scrivendo questo rapporto.
Quindi avresti il nome
dell'azienda, avrai un ID specifico per questa azienda.
Questo è l'ID con cui identifichi questa azienda
nei tuoi record.
Ancora una volta, probabilmente non
è qualcosa che
farai da solo, ti verrà dato questo ID dalla tua stessa azienda.
E poi abbiamo le informazioni di contatto per entrambe le società.
Quindi puoi vedere in questa azienda, abbiamo pentester 1
e pentester 2 con i loro indirizzi e-mail, questo potrebbe
essere ovviamente un elenco più grande
con tutto il team che sta facendo il pentest
e simile all'azienda
che stai facendo il pentest perché,
ancora una volta, hai i loro
nomi, la loro posizione nella società e le loro informazioni di contatto.
Ora, di nuovo, tieni
presente che non devi sempre modellare la prima pagina in questo modo,
ma più o meno, di solito nella prima
pagina, avrai il titolo, la data, la versione e
le informazioni di contatto ,
questo è
il modo in cui lo facciamo, ma
di nuovo, puoi farlo nel modo
che vuoi e puoi trarre ispirazione dalla risorsa che includerò qui.
Successivamente, di solito abbiamo il sommario.
Ancora una volta,
come puoi vedere, cose semplici, di solito abbiamo in qualsiasi tipo di documento.
Questo ti aiuterà a navigare nell'intero documento.
E come ho detto,
qui dentro possiamo vedere le sezioni principali di qualsiasi rapporto pentest.
Quindi è molto importante avere un riassunto esecutivo, questo
è un riassunto dell'intero impegno
progettato per le persone meno tecniche.
Quindi dovrebbe dare loro un'idea delle
tue scoperte senza immergerti troppo nei dettagli tecnici.
Quindi abbiamo un riepilogo del coinvolgimento
in cui dettagliamo
l'ambito, quindi questo è ciò che
hai testato, quali parti del loro sistema hai
testato, le valutazioni del rischio che
hai utilizzato e una panoramica di tutto ciò che hai trovato.
Quindi ancora una volta, finora non ci stiamo
immergendo in profondità o semplicemente, questo è solo un riassunto dell'intero impegno.
Avrai un'idea migliore di
tutto questo mentre esamino il rapporto.
E poi, nella sezione dei dettagli tecnici, è qui che
ti immergi davvero in profondità in
tutto ciò che hai trovato.
Quindi abbiamo fondamentalmente una sezione per ogni risultato.
Quindi, come puoi vedere,
questo è solo un esempio, quindi
ho fatto solo tre risultati, abbiamo un'iniezione SQL, una falsificazione
di richieste tra siti, un CSRF e una divulgazione di informazioni.
Quindi, come puoi vedere nella
prima sezione, abbiamo fondamentalmente solo
il
riepilogo di tutto ciò
che abbiamo trovato, mentre nei dettagli tecnici, stiamo
praticamente analizzando ogni singolo risultato e parleremo
di come l'abbiamo
trovato in dettagli, come replicarlo, includerai
schermate se possibile in modo che il team tecnico
possa comprendere esattamente la gravità di questa vulnerabilità
e come risolverla.
Noterai che altre aziende includeranno un'appendice
alla
fine, includeranno consigli in cui ti
diranno esattamente come correggere le vulnerabilità.
Come ho detto, dipende davvero dall'azienda, ogni
singola azienda ha il proprio
stile e ogni singola azienda ha il proprio format.
Quindi quello che ti
sto mostrando qui è solo un esempio di
come lo facciamo, puoi trarre ispirazione dalle risorse e,
in molti casi, dovrai
solo seguire il modello che la tua
azienda ha perché non lo fanno voglio che tu lo faccia a
modo tuo.
Quindi andiamo alla pagina successiva
e vedrai in questa
pagina che abbiamo le informazioni legali.
Ed è per questo che
in realtà ho detto, probabilmente non
lo farai da solo, non avrai
mai bisogno di farlo da solo perché avrai parti del rapporto come
questa che non dovrai mai
modificare, e in realtà saranno scritto dal team legale
della tua azienda.
Quindi terranno conto di tutto ciò che potrebbe andare
fuori controllo per assicurarsi
che non sarai citato in
giudizio se qualcosa va storto, conterrà cose come disclaimer, GDPR, privacy,
cose legali e tutte quelle
cose che non Non so molto bene come
scrivono di solito i pentester e i legali.
E poi abbiamo il registro delle modifiche del documento.
Quindi ogni volta che viene apportata una modifica al documento,
puoi vedere, abbiamo la data, abbiamo
la versione e abbiamo un commento, perché abbiamo
fatto questa modifica?
O cosa c'è di così significativo in questo cambiamento?
Quindi questo era il rapporto iniziale quando l'abbiamo
fatto il 1 gennaio, e poi
il 10 gennaio, abbiamo realizzato
la seconda versione
in cui abbiamo finito con il Recon Stage.
Di nuovo, questi sono
solo esempi, ma solo per darvi un'idea che tenere
un registro delle modifiche di tutte le modifiche che
questo documento subisce è molto, molto importante.
Non tutte le aziende lo
fanno, ma di nuovo, è solo una nostra
scelta di aggiungerlo nel nostro rapporto.
Continuo a dirlo solo per darti un'idea
che non ci sono regole
fisse per fare questo tipo di documenti.
Puoi aggiungere o rimuovere tutto ciò
che vuoi, ma le parti principali sarebbero la
parte legale, il riepilogo esecutivo e quindi la
parte tecnica, queste sarebbero le parti principali del rapporto.
Quindi ora abbiamo il sommario esecutivo
e puoi leggerlo.
Non dovrebbe essere lungo,
quindi secondo
me deve essere una pagina, massimo due
pagine se proprio devi.
E fondamentalmente dice
solo che ci è stato chiesto di testare il
sistema X, spiegherà come è organizzato questo documento,
dove la prima sezione è
meno dettagliata, solo per darti un'idea
del rischio, e poi la seconda è
dettagliata per i tecnici per comprendere questi rischi e risolverli.
E poi ci viene data
la valutazione del rischio, quindi supponiamo
che questo sia ad alto rischio in base
alle vulnerabilità che abbiamo trovato, che dettaglierà la metodologia che abbiamo seguito.
E poi, abbiamo alcuni grafici qui.
Ricorda, questa parte è stata letta dai dirigenti, queste
sono persone che non sono molto
tecniche per la maggior parte del tempo, e inoltre non hanno molto tempo.
Quindi includiamo dei grafici qui per
mostrare loro la quantità di vulnerabilità che abbiamo trovato.
Quindi possiamo vedere, abbiamo cinque
vulnerabilità alte, 10 medie e otto basse.
Quindi questo darà loro una buona comprensione
delle minacce che devono affrontare.
E poi entreremo nel riassunto.
Ancora una volta, questo sarà ancora letto dalle persone meno tecniche.
Quindi, prima di tutto, stiamo dettagliando l'ambito per
assicurarci di dire loro cosa abbiamo testato, anche se
ci hanno già detto cosa testare, solo in
modo che nel caso, in futuro, se
qualcosa fosse scoperto al di fuori del nostro scopo
e tornano
da noi, possiamo dire, beh, questo era al di fuori
dello scopo, non l'abbiamo testato.
Successivamente, includiamo le valutazioni del rischio.
Quindi avrai questo in
ogni documento che vuoi
che io modifichi, in pratica stiamo solo dicendo
come classificheremmo una certa vulnerabilità come bassa, media, alta o critica.
E stiamo dicendo, secondo noi,
come dovresti gestire le vulnerabilità basse,
medie, alte e critiche.
Puoi vedere per
il critico, stiamo dicendo che devi correggere
immediatamente, mentre per il basso, devi
correggere nel prossimo ciclo di aggiornamento.
Ancora una volta, questa è solo la nostra opinione.
Successivamente, abbiamo la panoramica dei risultati.
Quindi siamo ancora nella sezione
uno, questa è ancora per i dirigenti,
non abbiamo bisogno di immergerci troppo in profondità.
Quindi ci viene fornito solo l'ID della vulnerabilità.
E puoi vedere, per la prima vulnerabilità, è
fondamentale, è un'iniezione SQL.
E in molti casi, in
molti rapporti, si fermeranno effettivamente a dire che è solo un'iniezione SQL.
Ci piace mostrare effettivamente l'impatto in questa sezione, perché
come ho detto, questi ragazzi non
sono tecnici, quindi se
leggono SQL injection, potrebbero non sapere cos'è
un'iniezione SQL, ciò che interessa è l'impatto di questa vulnerabilità.
Di nuovo, non hanno molto
tempo, quindi devi essere dritto al
punto, quindi stiamo dicendo che è un'iniezione SQL
che potrebbe portare a un accesso autorizzato al database.
Quindi ora sanno che con questa
vulnerabilità un hacker può
accedere al loro database, probabilmente è piuttosto grave.
Un'altra vulnerabilità che abbiamo riscontrato è media, e ancora
una volta il CSRF, molti rapporti si fermeranno qui, in realtà
non spiega nulla alle persone non tecniche.
Quindi stiamo dicendo che i clienti possono essere costretti
a inviare determinate richieste non critiche, ecco perché è
un mezzo, non sono richieste
non critiche, ma possono essere costretti a inviare cose.
E poi abbiamo una vulnerabilità
bassa in cui viene divulgata la versione
PHP, quindi questo non è davvero
molto critico perché non è
una vera vulnerabilità che può essere sfruttata per ottenere l'accesso o esporre i
dati dell'utente, ma questa informazione potrebbe essere utile per
gli hacker per concatenare
altri attacchi o scoprire vulnerabilità per questa specifica versione PHP, ed
è per
questo che è consentito, ecco perché non
ha bisogno di essere curato molto
urgentemente come quelli critici come menzionato sopra qui.
E sentiti libero di leggere il
testo qui, vedrai che molto è fondamentalmente solo per cancellare i
nostri bug e assicurarci che capiscano tutto ciò che
è nel rapporto.
E quella sarebbe la fine del riassunto, e
ora entriamo nei dettagli tecnici.
Quindi, in questa sezione, abbiamo fondamentalmente, come ho detto, una
sottosezione per ogni singola scoperta che abbiamo, e ci
stiamo immergendo davvero in profondità nei
dettagli di questa scoperta.
Quindi puoi vedere che questa
è l'iniezione SQL di cui abbiamo parlato
prima nel riepilogo, ma questa volta stiamo
effettivamente dando
loro l'URL che è vulnerabile, stiamo dando loro
il parametro vulnerabile, stiamo dando loro
dei riferimenti per capire cosa SQL injection è nel caso in cui
non lo capiscano, stiamo dando
loro la richiesta esatta e la risposta esatta
che abbiamo ottenuto, il che ci ha fatto determinare che questa
particolare pagina è vulnerabile a un'iniezione SQL.
Quindi stiamo dando loro l'impatto qui in dettaglio,
non solo dicendo che possono accedere al database,
quindi stiamo dicendo che possono
accedere al database, possono recuperare
i dati, abbiamo accesso alla tabella dell'utente,
quindi sei mi
immergerò nei dettagli e dovresti anche includere schermate
qui se pensi che possano essere utili.
Nella sezione
sulla mitigazione, stiamo solo dando
loro una rapida raccomandazione, come ho detto, alcune aziende
danno consigli dettagliati, questo dipende anche dall'impegno.
Quindi, in questo esempio, stiamo
semplicemente dicendo, usa istruzioni preparate con query parametrizzate e
stiamo dando loro un riferimento per imparare
come farlo o per capire come funziona.
E questo è praticamente tutto.
Quindi ripeterai che per ogni singola
vulnerabilità che hai trovato,
lascio il resto vuoto perché questo è solo un campione, ma
hai l'idea.
Quindi avrai una sottosezione per ogni scoperta che hai,
spiegherai tutto nei dettagli in modo che capiscano
la vulnerabilità e poi
possano andare avanti e risolverla.
Alla fine, molte aziende avrebbero un'appendice e potrebbero avere
una sezione di consigli più ampia, come ho detto, questo
è il nostro stile di scrittura dei rapporti,
ma ogni azienda ha il proprio stile.
Se ti piace, forse dedica un po'
di tempo a esaminare i rapporti
di esempio che abbiamo in questo repository.
Ovviamente includerò entrambi i link per il mio campione e
per gli altri campioni nelle risorse in
modo che tu possa esaminarli
tu stesso e avere un'idea di come appaiono i rapporti pentest.
Ma come ho detto, in molti
casi, riempirai semplicemente un campione simile a
quello che abbiamo qui,
quindi non ti verrà mai chiesto di inventarne uno da zero.