Un test d’intrusion (pentest) est une méthode d'audit de la sécurité d'une application, d'un système ou d'un réseau informatique.
Pour ce faire, un auditeur (pentester en anglais) va, à la demande du propriétaire d'un système informatique (site web, serveur, postes de travail...), se mettre à la place d’un pirate informatique et tenter de le pirater, le tout en utilisant les mêmes techniques qu’un réel attaquant.
Cela permet de détecter des failles de sécurité et de les corriger avant qu’elles ne soient exploitées par un réel attaquant. Cependant, contrairement à un réel attaquant qui va en général s'arrêter une fois le système compromis, le pentester va tenter de trouver un maximum de vulnérabilités dans le temps qui lui est imparti, en suivant une méthodologie stricte et efficace.
À la suite du test d’intrusion, un rapport détaillé permettant de comprendre et de corriger les failles est remis au client.
Cette discipline est appelée “Ethical Hacking”, le hacking éthique, le but étant de travailler étroitement avec le client afin de lui apporter des solutions lui permettant de renforcer sa sécurité informatique.
Lorsque vous souhaitez effectuer un pentest, la première étape sera de définir ensemble votre cible et vos besoins et quelle sera l'approche qui vous correspond le mieux (Blackbox, Greybox, Whitebox...), tout en tenant compte de votre budget.
Une fois que ces éléments seront définis, nous signerons ensemble un contrat et un mandat de test, qui nous autorisent à effectuer des tests d'intrusions sur une cible bien précise, pour une durée et une date bien spécifiques.
Nous allons ensuite effectuer le test d'intrusion proprement dit en suivant notre méthodologie. Une fois les tests achevés, nous rédigerons un rapport d'audit comportant le détail des vulnérabilités découvertes et des solutions pour corriger les vulnérabilités.
Pour finir, ce rapport d'audit vous sera présenté en visioconférence par le pentester responsable du projet et vous sera ensuite envoyé de manière sécurisée.
Une phase de validation des corrections que vous aurez mises en place pourra également être prévue.
Afin de réaliser un audit de sécurité le plus fiable et précis possible, nous nous appuyons sur les standards du métier, et notamment sur les recommandations et méthodologies de l’OWASP. Nous réalisons de nombreux tests manuels et nous utilisons également de nombreux outils spécialisés dans la sécurité nous permettant d’automatiser et d’approfondir certaines tâches.
Cette méthodologie repose sur une série de quatre grandes étapes effectuées de manière cyclique :
Durant notre reconnaissance, nous recherchons des informations publiques sur notre client et notre cible. Cela nous permet de bien comprendre et appréhender notre cible et son environnement. Cela nous permet également de vérifier si des données sensibles relatives à notre client sont présentes sur internet et/ou sur le darknet. Par exemple, si des données ont été volées et publiées quelque part, nous pourrons l'en informer.
Lors de cette phase, nous allons étudier en détail le fonctionnement de l’application ou du système cible et son environnement. Nous allons lister précisément les différentes fonctionnalités et les différents services qui sont accessibles et qui font partie de ce que nous devons auditer. Cela nous permet d'avoir une vision d'ensemble de sorte à bien répartir le temps qui nous est imparti pour notre audit afin d'être en mesure de bien couvrir tout ce qui est nécessaire.
C'est durant cette phase que nous allons réellement commencer à chercher des vulnérabilités sur l'application ou le système cible. Nous n'allons cependant pas forcément exploiter de manière approfondie les vulnérabilités découvertes durant cette phase, car cela pourrait être chronophage et nous pourrions manquer de temps pour découvrir d'autres vulnérabilités. Nous allons donc bien identifier un maximum de vulnérabilités et effectuer l'exploitation lors de la phase suivante.
C'est lors de cette phase que nous allons réellement exploiter les vulnérabilités que nous avons découvertes lors de la phase précédente. Cela nous permet de bien évaluer l'impact qu'elles peuvent avoir afin de conseiller au mieux notre client. Cela peut également nous permettre de découvrir d'autres vulnérabilités.
Lors de la réalisation d'un test d'intrusion, il existe généralement trois approches :
Pour un audit effectué en Blackbox (ou boite noire en français), aucune information particulière ne nous est fournie par le client autre que notre cible. Nous sommes donc au plus proche du contexte dans lequel se trouverait un réel attaquant.
Cette approche peut être intéressante pour un premier audit de sécurité, car elle permet d'évaluer son niveau de sécurité à un instant précis et dans des conditions réelles. Cependant, certaines parties de l'application ou du système pourront ne pas être auditées, comme les parties d'administration.
Pour un audit effectué en Greybox (ou boite grise en français), le client nous fournit des accès utilisateurs spécifiques qu'un réel attaquant n'aurait pas directement, comme des accès administrateurs. Celui-ci peut également nous fournir de la documentation nous permettant de mieux cartographier et appréhender une application ou un système. De plus, avec cette approche, des échanges techniques avec le client sont possibles, permettant d'approfondir encore plus certains aspects.
Cette approche nous permet d'aller beaucoup plus loin que pour du Blackbox. Par exemple, sur une application Web pour laquelle un compte administrateur a été fourni, il nous est possible d'évaluer avec précision quel serait l'impact d'une vulnérabilité exploitée par un utilisateur classique et ciblant un administrateur.
L'approche Whitebox (ou boite blanche en français) reprend les avantages d'un audit Greybox mais le client nous fournit en complément tous les éléments dont nous avons besoin pour comprendre de manière très approfondi comment fonctionne une application ou un système. Par exemple, nous pouvons avoir accès au code source d'une application ou à un compte administrateur d'un serveur de production.
Ici, nous allons utiliser les éléments fournis en complément (code source, accès divers) comme support de notre test d'intrusion. Nous n'effectuerons pas ici d'audit de code source (c'est un autre type de prestation que nous proposons également) mais cela nous permettra de lever des doutes beaucoup plus facilement ou encore de découvrir des vulnérabilités qu'il aurait été très difficile de détecter par des moyens plus conventionnels.
A la fin de tout test d'intrusion, nous vous fournirons un rapport reprenant les différentes vulnérabilités découvertes triées par criticité ainsi que les éléments découverts durant la phase de reconnaissance.
Pour chaque vulnérabilité, vous trouverez une description du type de vulnérabilité et de ce qu'elle implique. Vous trouverez ensuite des détails techniques vous permettant de comprendre et de reproduire la vulnérabilité découverte. Enfin, pour chaque élément, nous vous proposerons des pistes vous permettant de le corriger.