Test d’intrusion – Pentest : Présentation et méthodologies

Aujourd’hui j’ai décidé de m’intéresser aux méthodologies utilisées dans le monde de la sécurité pour organiser et exécuter des tests d’intrusion (pentests). L’occasion de vous partager ce que j’ai appris à ce sujet et d’introduire ce qu’est un test d’intrusion.


Nous verrons un peu plus loin dans l’article, après avoir revu quelques notions sur les tests d’intrusion, différents documents qui ont été édités et publiés dans le but d’aider les équipes de sécurité (pentesters, mais aussi RSSI) à avoir une démarche et un cadre d’évaluation de la sécurité d’un système d’information.

Test d’intrusion et audit de sécurité

Commençons par distinguer tests d’intrusion et audit de sécurité, ce sont deux notions qui peuvent paraître similaires au premier abord mais dont les cadres respectifs ne correspondent pas forcément.

Un audit de sécurité est plus large qu’un test d’intrusion, lors d’un audit de sécurité, nous allons vérifier la sécurité organisationnelle, le PRA/PCA, DLP (Data Loss Prevention), la conformité par rapport aux exigences d’une norme (exemple : PCI DSS) ou un référentiel, et également procéder à un audit des configurations, audit de code, et enfin effectuer une analyse des risques (EBIOS, MEHARI, MARION).

L’audit de sécurité s’effectue en plusieurs phases, dont le test d’intrusion. Parmi les autres phases, on peut donc trouver la correspondance orale avec les membres du SI, DSI, RSSI et membres de l’équipe technique, l’audit de configuration des services, serveurs, composants réseaux, etc., également l’audit de code pour les applications utilisées, déployées, voir développées en interne par l’entreprise cliente.

Parmi les référentiels souvent utilisés pour l’audit de sécurité, on retrouve la norme ISO 27 000 / ISO 27 001, le référentiel général de sécurité de l’ANSSI, le référentiel COBIT et dans d’autres contextes, les normes de type SOX, PCI-DSS, etc.

Mais alors, quelles sont les  différences entre audit de sécurité et test d’intrusion (pentest) ?

Le test d’intrusion est une partie de l’audit de sécurité et consiste à se mettre dans la peau d’un attaquant souhaitant s’introduire dans le système d’information pour y effectuer des méfaits (espionnage, sabotage, etc.). Comme son nom l’indique, le test d’intrusion, ou test de pénétration (pentest) vise à s’introduire sur le réseau ou dans une partie spécifique du réseau. L’objectif du pentester est alors multiple et peu varier selon les contextes :

  • Lister un ensemble d’informations, trouvées d’une manière ou d’une autre, et qui peuvent être sensibles ou critiques
  • Dresser une liste des vulnérabilités ou faiblesses du système de sécurité pouvant être exploitées
  • Démontrer qu’un attaquant potentiel est en capacité de trouver des vulnérabilités et de les exploiter pour s’introduire dans le système d’information. Au delà des vulnérabilités sans relations entre elles, une réelle démarche vise à relever la présence d’un plan d’action amenant de la position d’un attaquant externe à la prise de contrôle du SI ou la possibilité d’y effectuer des actions (espionnage, sabotage, etc.)
  • Tester l’efficacité des systèmes de détection d’intrusion et la réactivité de l’équipe de sécurité, et parfois des utilisateurs (social engineering)
  • Effectuer un reporting et une présentation finale de son avancement et de ses découvertes au client
  • Donner des pistes et conseiller sur les méthodes de résolution et de correction des vulnérabilités découvertes.

Le test d’intrusion porte principalement, mais pas uniquement, sur la partie technique de la sécurité du système d’information (au sens large, comprendre technologique, physique et humain) et moins sur le côté organisationnel / fonctionnel.

Deux types de test d’intrusion

Globalement, il existe deux types de contexte pour l’exécution d’un pentest : le pentest en mode Black box et le pentest en mode White Box, et également quelques “modes” dérivés :

  • Le pentest en mode Black Box : Dans le contexte Black Box, le pentester se met réellement dans la peau d’un attaquant externe et commence son test d’intrusion en ayant le moins d’information possible sur sa cible (sa cible étant alors l’entreprise ayant demandé un pentest). En effet, lorsqu’un asseyant débute son attaque, il ne dispose pas (ou rarement) de la cartographie complète du SI, de la liste des serveurs avec leurs IP, etc. Le contexte Black Box vise donc à trouver et à démontrer la présence d’un plan d’action exploitable par une personne externe permettant de prendre le contrôle du système d’information ou de mettre la main sur certaines informations. En commençant avec très peu d’informations, le pentester doit chercher depuis l’extérieur comment s’introduire dans le système cible, il adopte alors la méthodologie et le comportement qu’aurait un pirate réel.
  • Le pentest en mode White Box : Ici, c’est exactement l’inverse. Le pentesteur travail en proche collaboration avec le DSI, le RSSI et l’équipe technique du système d’information. Le but est alors d’obtenir 100% des informations sur le système d’information et d’accompagner la DSI/RSSI dans la détection de vulnérabilité. Un des avantages du mode White Box est que l’on peut alors détecter des failles de sécurité de façon plus large et que le mode Black Box n’aurait pas permis de déceler, par exemple si le pentesteur n’avait pas atteint un certain stade de l’intrusion. De plus, le mode White Box s’intègre plus facilement dans le cycle de vie du SI, parfois à chaque stade de son évolution.

Il existe des dérivés des modes Black Box / White Box. On peut par exemple s’intéresser au mode dit “Grey Box” dans lequel le pentester débute son test d’intrusion avec un nombre limité d’information, en étant par exemple dans la peau d’un utilisateur du SI. En tant que membre du service comptabilité par exemple, il débutera avec un poste dans le LAN, un compte utilisateur valide, l’accès à certaines applications métiers. En revanche il n’aura pas la permission de demander la version du serveur de mail à la DSI, information que la DSI ne donnerait pas à un utilisateur lambda.

Ici, on peut donc simuler les méfaits que peut causer un utilisateur au système de sa propre entreprise à partir d’une position précise dans le système d’information. Le mode Grey Box ne se résume pas qu’à ce contexte, on peut par exemple également imaginer un point de départ qui serait la possession par l’attaquant du compte d’un utilisateur ayant quitté l’entreprise mais qui serait toujours valide dans le système d’information cible (un compte VPN/AD par exemple).

Outre ces différents contextes de départ, il existe également la notion de “Red Team” visant à simuler ce que l’on pourrait commencer à décrire comme une APT (Advanced Persistent Threat). Dans ce contexte Red Team, le test d’intrusion est étendu sur une période beaucoup plus grande (plusieurs mois au lieu de quelques jours/semaines). Cela reflète encore plus fidèlement le contexte d’une attaque externe dans laquelle les pirates tendent de plus en plus à prendre leur temps pour étudier le SI ciblé et également pour dissimuler leur présence.

Voir mon article à ce sujet pour plus de détails : Tests d’intrusion : L’approche Red Team

Une méthodologie, pourquoi faire ?

Après avoir  introduit ce qu’est un pentest, intéressons nous à la seconde partie de cet article : les méthodologies du déroulement d’un pentest. Mais pourquoi les tests d’intrusion ont-ils besoin de suivre une méthodologie ? J’y vois plusieurs raisons :

  • Le milieu de la sécurité évolue vite, les techniques et les technologies changent sans cesse, des vulnérabilités paraissent quotidiennement et leurs patchs également. Face à cela, un peu d’organisation s’impose. Les méthodologies permettent d’apporter un cadre fixe sur le déroulement d’un test d’intrusion.
  • Face à un système d’information, voir à plusieurs, un pentester a du travail, chaque système, service, port et IP peut cacher une vulnérabilité, voir un chemin tout tracé jusqu’à la prise de contrôle du système. Cela multiplié par la très grande quantité de test à effectuer en fonction du service ou de la technologie utilisée, il est facile de se perdre. Une méthodologie cadrée et fixée permet alors de suivre une trame et ainsi d’organiser son test d’intrusion afin que celui-ci soit le plus complet possible.
  • Dans le milieu professionnel, il faut savoir travailler en équipe ! C’est aussi à cela que servent les méthodologies communes, les normes et les référentiels. Une méthodologie connue de plusieurs pentesters va permettre de faciliter et de rendre plus efficient le travail au sein d’une équipe de pentest. Également, le rapport généré et la documentation sera faite en suivant une trame connue : celle de la méthodologie utilisée.

Avant tout et principalement, une méthodologie va permettre de ne rien oublier durant son test d’intrusion et de faire en sorte que celui-ci soit le plus complet possible, durant ledit pentest, la méthodologie fait office de chemin à suivre, facilitant l’organisation du pentester.

Les méthodologies existantes

Intéressons nous aux différentes méthodologies qui existent pour l’organisation d’un pentest. Pour la plupart, ces méthodologies sont très certainement utilisées comme base dans les équipes de pentest qui les agrémentent de leurs propres méthodes, outils et techniques, c’est ce qui fera la différence entre une équipe de pentest et une autre, l’expérience du terrain s’ajoute alors à la théorie de la méthodologie et du référentiel utilisé. Il faut également noter que chaque pentest suit un chemin qui lui est propre en fonction du SI à tester.

Bref ! Je vais ici vous parler brièvement de ces différentes méthodologies, la liste n’est sûrement pas exhaustive et je n’ai pas (encore) lu tous ces ouvrages. Je m’attarderai un peu plus sur le PTES qui est le plus précis au sujet du test d’intrusion :

> PTES (Penetration Testing Execution Standard)

Le Penetration Testing Execution Standard est un standard créé afin de proposer aux entreprises et aux équipes de sécurité une trame commune et un cadre (scope) pour l’exécution d’un pentest. Créé en 2009, une version 2 est en cours de rédaction. Les rédacteurs du PTES sont nombreux,  je vous invite à consulter la liste dans leur FAQ : PTES Rédacteurs

Concernant son contenu, le PTES , voici les 7 étapes décrites :

La phase de  “pré-engagement” . Comme je vous l’ai dit plus haut, chaque test d’intrusion débute avant tout par une négociation, une compréhension des besoins clients et pour finir une contractualisation qui met tout cela en forme sur papier. L’établissement du contrat est l’occasion pour l’entreprise demandant le test de sa sécurité de préciser plusieurs choses concernant le cadre (scope) du test d’intrusion à effectuer. En terme de temps (jours, semaines, mois ?), en terme technologies, en terme géographique (Plage d’IP à tester et à ne pas tester par exemple). Également, c’est l’occasion de préciser le type de test à prévoir : est-ce que les testeurs pourront mettre en place des phases d’attaque DoS ? Devront-ils aller au bout de l’exploitation quitte à ouvrir des documents sensibles ? Le contrat vise également à établir un lien juridique et une protection du pentester qui pourrait tomber sur des documents sensibles, mais également à négocier et prévenir les entreprises collaborant avec le client (FAI, hébergeur, application métier, etc.).

La seconde étape est celle de “Intelligence Gathering” ou “Information Gathering” . Comprendre la collecte de renseignements/d’informations. Ici, on va chercher à lister un maximum d’informations à propos du SI testé, et cela via plusieurs méthodes. L’objectif est donc de dresser une cartographie de la surface d’attaque depuis la position de départ de l’attaque, d’obtenir des renseignements sur les services, serveurs et éléments actifs utilisés, mais également leur version et les systèmes de sécurité en place (VPN, Firewall, Anti-Ddos, DMZ, etc.). La partie Intelligence Gathering peut se faire de manière passive (sans interaction directe avec le SI de la cible) et/ou de manière active (en allant communiquer avec les serveurs ciblés). On retrouve également les notions de OSINT (Open Source Intelligence) et de HUMINT (Human Intelligence, comprendre social engineering).

La troisième étape est celle du Threat Modeling, on va ici chercher à dresser une liste des menaces pour l’entreprise. À quoi l’entreprise peut elle avoir à faire face ? On va ici chercher à évaluer ce qui est critique pour l’entreprise (Ex : son secret de fabrication), à établir l’impact potentiel de la perte de ce secret puis de voir ensuite quelles vulnérabilités peuvent amener à une perte du secret de fabrication. Également, on peut passer par une phase d’analyse en terme de sécurité des concurrents/entreprises similaires. Ont-elles été compromises récemment ? Quel a été l’impact de l’attaque ?  Une analyse du process de l’entreprise et de ses actifs humains peut aussi être à effectuer ainsi qu’une analyse du SI : existe-t-il un mécanisme de chiffrement pour les commerciaux communiquant avec l’intérieur du SI sur l’application métier ? Un VPN est-il en place pour l’administration distante du SI ?

Quatrième étape : L’analyse des vulnérabilités. On va ici se servir des informations collectées précédemment pour analyser les systèmes, le personnel et les processus en place afin de rechercher des failles de sécurité et de vulnérabilités exploitables. Cela passe donc par un processus de recherche, manuelle et/ou automatique des vulnérabilités, l’objectif est ici de dresser une liste de ce qui pourrait être exploitable et de construire un “arbre d’attaque” , c’est à dire une suite d’attaque pouvant amener à la découverte d’autres vulnérabilités, traçant un chemin vers la prise de contrôle du SI ou la possibilité d’établir des actes d’espionnage ou de sabotage. Cette phase passe systématiquement par de la recherche sur les bases d’exploits publiques, la vérification des patchs des systèmes scannés et l’utilisation d’outils de scans (Ex : Nessus, Nitko, WpScan, etc.).

La cinquième étape est souvent la plus attendue des pentesters, c’est le moment de passer à l’attaque : l’exploitation. Ici, on va chercher à tester les vulnérabilités trouvées dans la phase précédente et à avancer dans l’intrusion du système d’information. On va également chercher à tester les  barrières et systèmes de sécurité mis en place (évasion d’un IDS, contournement d’un mod_security, bypass de l’authentification). S’en suivra un procédé de validation des vulnérabilités potentielles trouvées. Il est ici important de trouver des moyens d’exploiter les vulnérabilités et également les systèmes de sécurité. Si le pentester avance dans le SI, il peut avoir à revenir à l’étape 4 afin d’effectuer à nouveau une analyse des vulnérabilités dans la nouvelle zone (admettons s’il parvient à passer de la DMZ au LAN).

La sixième étape est celle de la Post-Exploitation. Cette étape comporte plusieurs phases intéressantes, comme un attaquant réel, le pentester va devoir effacer ses traces pour que ces agissements soient les plus discrets possible. Également, il va devoir chercher à s’implanter de manière durable dans le système d’information en y insérant des backdoors, en se créant un compte VPN ou en implantant un malware/rootkit par exemple. La phase de post-exploitation est également la dernière phase technique du test d’intrusion, il est donc temps de viser les informations à dérober (on parle de “Pillaging” pour “Pillage“), les personnes intéressantes de l’entreprise (piéger une cible haut placée par exemple). L’idée est ici de réellement montrer quels méfaits un attaquant pourrait accomplir : espionnage, sabotage, exfiltration de données, déploiement d’un botnet, mise hors service d’une partie du SI, etc.

La démarche du Pentest décrite dans le PTES se termine par la phase de reporting, et c’est la phase la plus important car il s’agit d’exposer le déroulement du test d’intrusion et ses fruits à l’entreprise l’ayant commandé. Le reporting va être à la fois technique et non technique. On va donc détailler les informations récupérées durant la phase d’Intelligence Gathering, exposer les vulnérabilités listées puis exploitées et décrire les méfaits qui ont/auraient pu être perpétrés dans la phase de Post-Exploitation. Cette phase est souvent orale mais s’accompagne systématiquement d’un livrable écrit contenant toutes ces informations. Pour finir, l’équipe de pentest est souvent amenée à dresser une “Remediation Roadmap” , c’est à dire une liste de contre-mesures, corrections et protections à mettre en place pour que l’entreprise ait des pistes sur lesquelles débuter la suite de la sécurisation de son SI.

Pour ceux qui s’impatientent et qui meurent d’envie de découvrir cet ouvrage, voici le lien : PTES

Chose intéressante, l’équipe de rédaction a également rédigé une cartographie au format MindMap (FreeMind – .mm) permettant d’avoir un accès rapide à toute les sections, vous le trouverez ici : PTES MindMap

> OWASP Testing Guide

L’OWASP (Open Web Application Security Project) est un organisme qui œuvre pour la diffusion de pratiques de sécurité et d’outils de sécurité autour des applications web. Parmi les ouvrages qu’elle édite et publie se trouve l’OWASP Testing Guide, aujourd’hui en sa version 4. J’ai déjà rédigé sur Information-Security un article au sujet de l’OWASP Testing Guide : Référence de la sécurité des webapps

Ce qu’il faut savoir : Il s’agit d’une ouvrage très complet destiné aux pentesters et également aux développeurs d’applications et sites web, au delà d’une méthodologie de pentest, il s’agit plus d’un listing de différents points de sécurité à vérifier à la fois quand on est développeur d’une application web, mais également quand on est pentester. L’OWASP est un organisme reconnu dans le domaine de la sécurité et plus précisément de la sécurité des applications web et son Testing Guide est un outil très utile car très complet.

Pour ceux qui s’intéressent à la méthodologie pour le test de sécurité des applications web, chose d’ailleurs incontournable dans tout pentest, c’est par ici : OWASP Testing Guide v4

> OSSTM (Open Source Security Testing Methodology Manual)

L’Open Source Security Testing Methodology Manual est un document édité et publié par l’ISECOM (Institute for Security and Open Methodologies), un organisme à but non lucratif résidant en Espagne. La première rédaction de ce document s’est faite en 2001 par de nombreux chercheurs ayant besoin d’une méthodologie commune. Concernant le document en lui même, il en est à sa version 3 et une version 4 est en cours de rédaction. Il est décrit par ses auteurs comme un document accompagnant les audits de sécurité et utilisable dans différents contextes :

  • Ethical Hacking
  • Test d’intrusion
  • Évaluation de la sécurité
  • Évaluation des vulnérabilités
  • Red Team (mode d’attaque décris précédemment dans cet article)
  • Blue Team (côté défense d’un mode Red Team)

L’ISECOM est un organisme qui fournit également des cours et certifications pour les pentesters, l’OSSTM est donc en relation forte avec les certifications délivrées telles que OPST (OSSTM Professional Security Tester), l’OPSE (OSSTM Professionnel Security Expert), etc. L’intérêt de l’OSSTM est de décrire  un série de test à vue opérationnelle (concret) pour l’évaluation de la sécurité au niveau physique, système, réseau, humain, Wifi, etc., en prenant donc un nombre important de facteur. Il contient notamment une large introduction sur la terminologie utilisée, ce qui en fait un bon document pour s’initier au pentest.

Voici un lien où trouver l’OSSTM v3 :  OSSTMv3

> Technical Guide to Information Security Testing and Assessment

Le Technical Guide to Information Security Testing and Assessment est un document “recommandation” produit par le  NIST (National Institute of Standards and Technology), on peut comparer ces recommandations à celles de l’ANSSI en France qui produit également beaucoup de documents de ce type. Le document se décrit comme une vue d’ensemble pour la conduite de test de sécurité et d’évaluation des risques afin d’accompagner les entreprises dans leur démarche de sécurité. On s’éloigne alors quelque peu du sujet du test d’intrusion mais c’est un document pouvant néanmoins être utilisé dans ce contexte.

Retrouvez ce document en ligne : Technical Guide to Information Security Testing and Assessment

> ISAF (IT Security Assessment Framework)

Comme le document précédent, nous nous éloignons un peu du contexte des tests d’intrusion avec l’IT Security Assessment Framework, document d’une vingtaine de pages édité par le NIST qui vise à aider les entreprises à évaluer leur sécurité puis à définir une cible afin de les accompagner dans leur démarche de sécurisation. Le document est assez court et s’organise autour de différents tableaux listant et décrivant des critères à évaluer et à respecter selon que l’on se trouve dans la phase d’évaluation de l’état de la sécurité ou de définition de la cible.

Vous pourrez retrouver ce document en ligne : ISAF

Et vous ? Utilisez vous l’une de ces méthodes ou en connaissez vous d’autres ? N’hésitez pas à nous partager cela dans les commentaires ! 🙂

Vous aimerez aussi...

1 réponse

  1. Mastonic dit :

    Franchement merci ! Je me lance bientôt dans le domaine du pentest et ton article il est super.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *