Conférencier :
Tout au long du cours, nous avons appris un certain
nombre de méthodes pour découvrir des bogues et des vulnérabilités
dans différents types de logiciels et d'infrastructures.
Habituellement, à la fin du pentest, vous
devrez informer le client de toutes les
vulnérabilités que vous avez trouvées ou de
tous les résultats, cela
se fait à l'aide d'un rapport de pentest.
Donc, fondamentalement, ce que nous entendons par rapport
de pentest, c'est juste un document qui inclut tout ce
que vous avez trouvé grâce à votre
engagement afin que le client ou l'administrateur
puisse aller de l'avant et corriger toutes les vulnérabilités et
les faiblesses que vous avez trouvées.
Ces rapports sont également lus par les dirigeants la plupart du temps,
vous devrez donc en tenir compte,
donc un bon rapport devrait être assez
simple, mais il est également facile à comprendre.
Maintenant, si vous travaillez en tant que
pentester, l'entreprise pour laquelle vous travaillez
aura probablement son propre modèle et ses propres
normes que vous devrez suivre lors de la
rédaction d'un rapport.
Et dans de nombreux
cas, vous ne le
ferez même pas, vous transmettrez simplement vos conclusions à un autre
membre de
votre propre équipe, et ils rempliront correctement les blancs dans le rapport.
Par conséquent, vous n'aurez probablement pas besoin d'en rédiger un
à partir
de zéro et, dans de nombreux cas, vous n'aurez même pas à rédiger le rapport
réel que le client voit.
Cela étant dit, je veux toujours vous
montrer comment cela se fait juste pour vous donner une idée
de ce à quoi ressemble un rapport de pentest.
Tout d'abord, avant de vous montrer l'exemple
que j'ai, je vais
inclure ce référentiel qui contient essentiellement un grand nombre de rapports de pentest.
Vous pouvez donc les parcourir pour vous inspirer et simplement voir
les différents styles que les
différentes entreprises suivent lors
de la création d'un rapport de pentest.
Vous pouvez donc cliquer sur l'un d'entre eux et vous trouverez
le rapport, et vous
pouvez le parcourir pour apprendre comment cette entreprise spécifique rédige ses rapports,
et peut-être que vous trouverez quelque chose que
vous aimez et que vous commencerez à inclure dans vos propres rapports. .
Je vais donc inclure cela dans les ressources de la conférence
afin que vous puissiez y revenir pour vous inspirer.
Mais ce que je
veux vraiment faire, c'est vous présenter
un exemple de rapport que nous utilisons ici
dans ZSecurity juste pour vous donner une idée des
sections principales de la plupart des rapports.
Je vais également l'inclure dans les ressources, alors n'hésitez pas
à le modifier et à l'utiliser, ou
à en prendre certains éléments si vous le souhaitez.
Vous remarquerez donc dans le référentiel
ici que chaque entreprise a son propre style de rédaction de
rapports, mais en général, il y a toujours quelques sections
principales que vous trouverez dans chaque rapport.
Donc, en commençant par la première page ici, nous
avons la page de couverture.
Donc, encore une fois, vous pouvez
vendre cela comme vous voulez, vous aurez généralement le
logo de l'entreprise, vous
aurez le titre, puis vous aurez la date du rapport et
la version, c'est très important.
Et puis, nous avons la société, les informations de notre société, donc ce
rapport rédigé par nous, ce sont
les informations de notre société.
Et puis vous avez dans le champ
for, vous avez l'entreprise pour laquelle vous rédigez ce rapport.
Vous aurez donc le nom
de l'entreprise, vous aurez un identifiant spécifique pour cette entreprise.
Il s'agit de l'ID que vous identifiez cette entreprise
dans vos propres dossiers.
Encore une fois, ce n'est probablement
pas quelque chose
que vous ferez vous-même, vous recevrez cet identifiant par votre propre entreprise.
Et puis nous avons les coordonnées des deux sociétés.
Vous pouvez donc voir dans cette entreprise, nous
avons pentester 1 et pentester 2 avec leurs adresses
e-mail, cela pourrait évidemment être
une plus grande liste avec toute l'équipe qui fait
le pentest, et
similaire à l'entreprise que vous faites
le pentest car, encore une
fois, vous avez leurs noms, leur position dans l'entreprise et leurs coordonnées.
Maintenant, encore une fois,
gardez à l'esprit que vous n'avez pas toujours à styliser la première page
comme ça, mais plus ou moins, généralement dans la
première page, vous aurez le titre, la date, la version
et les coordonnées , c'est ainsi
que nous procédons,
mais encore une fois, vous pouvez le
faire comme vous le souhaitez et
vous pouvez vous inspirer de la ressource que je vais inclure ici.
Ensuite, nous avons généralement la table des matières.
Encore une fois,
comme vous pouvez le voir, des trucs simples, généralement, nous aurons dans n'importe quel type de document.
Cela vous aidera à naviguer dans l'ensemble de ce document.
Et comme je l'ai dit,
ici, nous pouvons voir les sections principales de tout rapport de pentest.
Il est donc très important d'avoir un résumé exécutif, c'est
un résumé de l'ensemble de l'engagement
qui est conçu pour les personnes moins techniques.
C'est donc censé leur donner une idée de
vos découvertes sans trop plonger dans les détails techniques.
Ensuite, nous avons un résumé de l'engagement
où nous détaillons la
portée, c'est donc ce que vous
avez testé, les parties de leur système que vous
avez testées, les cotes de risque que
vous avez utilisées et un aperçu de tout ce que vous avez trouvé.
Encore une fois, jusqu'à présent, nous ne plongeons
pas profondément ou simplement, ce n'est qu'un résumé de l'ensemble de l'engagement.
Vous aurez une meilleure idée
de tout cela en parcourant le rapport.
Et puis dans la section des détails techniques, c'est là
que vous plongez vraiment dans tout
ce que vous avez trouvé.
Nous avons donc essentiellement une section pour chaque résultat.
Donc, comme vous pouvez le
voir, ce n'est qu'un échantillon, donc
je n'ai fait que trois constatations, nous avons une injection
SQL, un Cross-Site Request Forgery, un CSRF et une divulgation d'informations.
Donc, comme vous pouvez le voir
dans la première section, nous avons essentiellement
le résumé
de tout ce que nous
avons trouvé, tandis que dans les détails techniques, nous décomposons
essentiellement chaque résultat, et nous allons parler de la
façon dont nous
l'avons trouvé dans détails, comment le reproduire, vous
allez inclure des captures d'écran si vous le pouvez afin que
l'équipe technique puisse comprendre exactement la gravité de cette vulnérabilité
et comment la corriger.
Vous remarquerez que d'autres sociétés incluront une annexe
à la
fin, elles incluront des recommandations où elles vous
diront exactement comment corriger les vulnérabilités.
Comme je l'ai dit, cela dépend vraiment de
l'entreprise, chaque entreprise a son
propre style et chaque entreprise a son propre format.
Donc, ce que je
vous montre ici n'est qu'un exemple de la
façon dont nous procédons, vous pouvez vous inspirer des ressources,
et dans de nombreux cas,
vous n'aurez qu'à suivre le modèle de votre
entreprise parce qu'ils ne le font pas. veux que tu le fasses à
ta manière.
Passons donc à la page suivante,
et vous verrez dans
cette page, nous avons les informations légales.
Et c'est pourquoi j'ai dit
en fait, vous ne le ferez
probablement pas vous-même, vous n'aurez jamais besoin
de le faire vous-même parce que vous aurez des parties du rapport comme
celle-ci que vous n'aurez jamais à
modifier, et elles seront en fait rédigés par l'équipe juridique
de votre entreprise.
Ainsi, ils prendront en compte tout ce qui pourrait devenir incontrôlable pour
s'assurer que vous ne serez
pas poursuivi en cas de problème, il
contiendra des éléments tels que des clauses de non-responsabilité, le RGPD, la confidentialité,
des éléments juridiques et tous ces
éléments que nous ne Je ne sais pas très bien
ce que les pentesters et les personnes juridiques écrivent habituellement.
Et puis nous avons le journal des modifications du document.
Donc à chaque fois qu'un changement est apporté au document, vous pouvez
voir, nous avons la date, nous
avons la version et nous avons un commentaire, pourquoi avons-nous
fait ce changement ?
Ou qu'y a-t-il de si important dans ce changement ?
C'était donc le rapport initial lorsque nous l'avons
fait le 1er janvier, puis le
10 janvier, nous avons fait
la deuxième version où
nous en avons terminé avec la Recon Stage.
Encore une fois, ce ne
sont que des exemples, mais juste pour vous donner une idée
que la tenue d'un journal des modifications de toutes les modifications
que ce document subit est très, très importante.
Toutes les entreprises ne le
font pas, mais encore une fois, c'est simplement notre
propre choix de l'ajouter dans notre rapport.
Je n'arrête pas de dire cela juste pour vous
donner une idée qu'il n'y a pas
de règles établies pour faire ce genre de documents.
Vous pouvez ajouter ou supprimer tout
ce que vous voulez, mais les parties principales
seraient la partie juridique, le résumé, puis la
partie technique, ce seraient les parties principales du rapport.
Alors maintenant, nous avons le résumé, et vous
pouvez le lire.
Ce n'est pas censé être
long, donc à
mon avis, ça doit être une page, maximum deux pages
si vous le devez vraiment.
Et en gros,
il dit simplement qu'on nous a demandé de tester le
système X, cela expliquera comment ce document est organisé,
où la première section est moins
détaillée, juste pour vous donner une
idée du risque, puis la seconde est détaillée
pour les techniciens pour comprendre ces risques et les corriger.
Et puis on nous donne la
cote de risque, donc nous supposons qu'il
s'agit d'un risque élevé sur la base des
vulnérabilités que nous avons trouvées, cela détaillera la méthodologie que nous avons suivie.
Et puis, nous avons quelques graphiques ici.
Souvenez-vous, cette partie a été lue par les cadres, ce sont
des gens qui ne sont pas très
techniques la plupart du temps, et ils n'ont pas beaucoup de temps non plus.
Nous incluons donc des graphiques ici pour
leur montrer le nombre de vulnérabilités que nous avons trouvées.
Nous pouvons donc voir, nous avons cinq vulnérabilités qui sont
élevées, nous en avons 10 qui sont moyennes et huit sont faibles.
Cela leur donnera donc une très bonne compréhension
des menaces auxquelles ils sont confrontés.
Et puis nous allons entrer dans le résumé.
Encore une fois, cela sera toujours lu par les personnes moins techniques.
Donc tout d'abord, nous détaillons le périmètre pour nous
assurer de leur dire ce que nous avons testé,
même s'ils nous ont déjà dit quoi tester, juste
pour qu'au cas où, à l'avenir, si quelque
chose était découvert en dehors de notre périmètre et ils
nous reviennent,
on peut dire, eh bien, c'était en dehors du cadre,
nous n'avons pas testé cela.
Ensuite, nous incluons les cotes de risque.
Donc, vous aurez cela dans
chaque document que vous
voulez que je modifie, nous disons simplement comment
nous classerions une certaine vulnérabilité comme faible, moyenne, élevée ou critique.
Et nous disons, à notre avis,
comment vous devez gérer les vulnérabilités faibles,
moyennes, élevées et critiques.
Vous pouvez voir pour le
critique, nous disons que vous devez corriger immédiatement, tandis
que pour le faible, vous devez corriger
dans le prochain cycle de mise à jour.
Encore une fois, ce n'est que notre propre opinion.
Ensuite, nous avons la vue d'ensemble des résultats.
Nous sommes donc toujours dans
la première section, c'est toujours pour les
cadres, nous n'avons pas besoin de plonger trop profondément.
On nous donne donc juste l'ID de la vulnérabilité.
Et vous voyez, pour la première vulnérabilité, c'est critique,
c'est une injection SQL.
Et dans de nombreux cas, dans de
nombreux rapports, ils s'arrêteront en fait à dire, c'est juste une injection SQL.
Nous aimons montrer l'impact dans cette section, car comme je
l'ai dit, ces gars ne sont pas
techniques, donc s'ils lisent
l'injection SQL, ils pourraient ne pas savoir ce qu'est
une injection SQL, ce qui les intéresse, c'est l'impact de cette vulnérabilité.
Encore une fois, ils n'ont pas beaucoup
de temps, vous devez donc aller droit au but, donc
ce que nous faisons, c'est que nous disons qu'il s'agit d'une injection
SQL qui pourrait conduire à un accès autorisé à la base de données.
Alors maintenant, ils savent qu'avec cette vulnérabilité,
un pirate informatique peut accéder
à leur base de données, c'est probablement assez grave.
Une autre vulnérabilité que nous avons trouvée est moyenne,
et le CSRF encore une fois, de nombreux rapports s'arrêteront là,
n'explique vraiment rien aux personnes non techniques.
Nous disons donc que les clients peuvent être obligés de
soumettre certaines demandes non critiques, c'est pourquoi c'est un support,
ce ne sont pas des demandes
non critiques, mais ils peuvent être obligés de soumettre des choses.
Et puis nous avons une faible
vulnérabilité où la version PHP est divulguée, donc
ce n'est pas vraiment très critique
car ce n'est pas une vulnérabilité
réelle qui peut être exploitée pour accéder ou exposer les données des utilisateurs, mais
cette information pourrait être utile pour les pirates à
enchaîner avec d'autres attaques
ou découvrir des vulnérabilités pour cette version PHP spécifique, et c'est pourquoi
c'est autorisé,
c'est pourquoi il n'est pas nécessaire de
s'en occuper de toute urgence comme
les critiques comme nous l'avons mentionné ci-dessus ici.
Et n'hésitez pas à lire le
texte ici, vous verrez qu'il s'agit essentiellement d'éliminer nos bogues et
de vous assurer qu'ils comprennent tout ce qui est
dans le rapport.
Et ce serait la fin du résumé, et maintenant
nous sommes dans les détails techniques.
Donc, dans cette section, nous avons essentiellement, comme je l'ai dit,
une sous-section pour chaque découverte que nous avons, et
nous plongeons très profondément dans les
détails de cette découverte.
Vous pouvez donc voir qu'il s'agit
de l'injection SQL que nous avons mentionnée plus
tôt dans le résumé, mais cette fois, nous
leur donnons
en fait l'URL qui est vulnérable, nous leur donnons
le paramètre vulnérable, nous leur donnons des
références pour comprendre ce que L'injection SQL est au cas où ils ne
la comprendraient pas, nous leur donnons
la demande exacte et la réponse exacte que nous
avons obtenue, ce qui nous a permis de déterminer que cette page
particulière est vulnérable à une injection SQL.
Ensuite, nous leur donnons l'impact ici en détail, pas seulement
en disant qu'ils peuvent accéder à la base de données,
donc nous disons qu'ils peuvent accéder à
la base de données, ils peuvent
récupérer des données, nous avons accès à la table
de l'utilisateur, donc vous êtes
va plonger dans les détails et vous devriez même inclure des
captures d'écran ici si vous pensez qu'elles seront utiles.
Dans la section
atténuation, nous leur donnons juste une
recommandation rapide, comme je l'ai dit, certaines entreprises donnent des recommandations
détaillées, cela dépend aussi vraiment de l'engagement.
Donc, dans cet exemple, nous
disons simplement, utilisez des instructions préparées avec des requêtes paramétrées,
et nous leur donnons une référence pour apprendre comment
faire cela ou pour comprendre comment cela fonctionne.
Et c'est à peu près tout.
Donc, vous allez répéter que pour
chaque vulnérabilité que vous
avez trouvée, je laisse le reste vide car ce n'est qu'un échantillon, mais
vous voyez l'idée.
Donc, vous allez avoir une sous-section pour chaque découverte que
vous avez, tout expliquer en détail afin que vous compreniez
la vulnérabilité et qu'ils puissent
ensuite aller de l'avant et la réparer.
À la fin, de nombreuses entreprises auraient une annexe et
elles pourraient avoir une plus grande section de recommandations, comme je
l'ai dit, c'est notre style de rédaction de rapports,
mais chaque entreprise a son propre style.
Si vous aimez cela, passez peut-être du
temps à parcourir les exemples de
rapports que nous avons dans ce référentiel.
Évidemment, j'inclurai les deux liens pour mon exemple et pour les
autres exemples dans les ressources afin que
vous puissiez les parcourir vous-même et
avoir une idée de ce à quoi ressemblent les rapports de pentest.
Mais comme je l'ai dit, dans de
nombreux cas, vous remplirez simplement un échantillon similaire à
celui que nous avons ici, de
sorte qu'on ne vous demandera jamais d'en créer un à partir de zéro.