Test d'intrusion

Un test d'intrusion (« penetration test » ou « pentest », en anglais) est une méthode d'évaluation (« audit », en anglais) de la sécurité d'un système d'information ou d'un réseau informatique ; il est réalisé par un testeur (« pentester », en anglais).

Principe

La méthode consiste généralement à analyser l'infrastructure d'un réseau informatique, afin de simuler l'attaque d'un utilisateur mal intentionné, voire d'un logiciel malveillant (« malware »).

Le consultant (« pentester ») analyse alors les risques potentiels dus à une mauvaise configuration d'un système d'information, d'un défaut de configuration, de programmation informatique ou encore d'une vulnérabilité liée à la solution testée (par exemple : WannaCry, en 2017).

Lors d'un test d'intrusion, le pentester adopte la position de l'attaquant potentiel (hacker). Le principal but de cette manœuvre est de trouver des vulnérabilités exploitables en vue de proposer un plan d'actions permettant d'améliorer la sécurité du système d'information plus élaboré que le précédent, afin notamment d'empêcher des pirates informatiques de compromettre les infrastructures internes d'une entreprise.

La différence avec un simple audit de sécurité est la motivation pour la personne à aller jusqu'à exploiter les failles, montrant ainsi la vulnérabilité. L'exploitation n'a bien sûr pas pour but de détruire ou endommager le système, mais elle permettra de situer le degré du risque lui étant associé.

L'analyse peut se réaliser selon trois cas, qui peuvent varier selon les attentes de l'entreprise :

1. le testeur se met dans la peau d'un attaquant potentiel, et ne possède aucune information ;
2. le testeur possède un nombre limité d'informations (ex. : un compte) ;
3. le testeur possède les informations dont il a besoin.

Il est facile d'illustrer et de mettre en pratique ces propos par le biais d'un test d'intrusion applicatif web. Le testeur peut effectuer cette prestation de plusieurs manières :

1. En boite noire : l'auditeur ne connait que le nom, l'adresse et l'ip du serveur web à auditer.
2. En boite grise : l'auditeur possède, en plus des informations de la boite noire, des comptes applicatifs pour se connecter au site web.
3. En boite blanche : l'auditeur possède, en plus des informations de la boite noire et grise, le code source ainsi que la documentation associée à l'application.

Test de type "boîte noire"

Fondement

Dans cette configuration (appelée « black box test » en anglais), il s'agit dans un premier temps de rechercher des informations sur l'entreprise, la personne, ou toute autre donnée pour s'assurer que la cible est bien celle que l'on tente d'infiltrer. Connaître la situation géographique, les informations générales d'une société, ou son fournisseur d'accès à Internet sont peut être des choses banales, mais pourtant à ne pas négliger. Effectivement, ces quelques informations en disent plus sur la cible.

Pour cela, le testeur dispose de plusieurs outils :

• le World Wide Web : cela peut paraître insignifiant, mais il peut devenir une véritable mine d'informations (adresses email, adresses postales, numéros de téléphone...) sur une cible donnée (entité physique ou morale) ; cette pratique devient triviale avec les réseaux sociaux et les moteurs de recherche ;
• le service DNS via les outils nslookup et dig afin d'interroger les serveurs DNS pour obtenir soit l'adresse IP en fonction d'un nom de domaine, soit l'inverse, ou encore les noms de domaine des serveurs par lesquels transitent les emails. Par ailleurs, les enregistrements DNS fournissent souvent de nombreuses informations utiles ;
• le service whois qui, même si ses données ne sont pas toujours à jour, permet de récupérer des informations diverses sur une adresse IP ou un nom de domaine.

Cet ensemble de techniques non intrusives permet d'obtenir des informations publiques sur la cible. Certaines d'entre elles peuvent cependant être confidentielles (mais diffusées généralement par erreur ou par insouciance). Leur récupération, pas toujours détectable par la cible, entre dans le cadre de ce que l'on pourrait appeler une « reconnaissance passive » :

• l'utilisation d'outils et du protocole de communication ICMP dont traceroute qui permet entre autres la géolocalisation d'une adresse IP et la détection d'équipements filtrants entre le poste du testeur et l'équipement testé ;
• l'ingénierie sociale, qui reste probablement le meilleur outil du testeur afin d'obtenir un maximum d'informations sur sa cible en un minimum de temps.

Ces deux dernières techniques, bien que non intrusives, deviennent détectables par la cible et entrent dans le cadre de ce que l'on pourrait appeler une « reconnaissance semi-active ».

Il faut ensuite pouvoir schématiser l'emplacement et l'étendue du système d'information à tester, c'est-à-dire réaliser une cartographie (ou map en anglais). Outre le fait que l'on ne testera pas uniquement une partie du système, le fait d'effectuer une telle analyse permet de comprendre le mode de fonctionnement et le raisonnement de son propriétaire. De plus, un système en réseau étendu nécessite une sécurité plus importante : la pénétration d'un seul ordinateur d'un réseau peut permettre la pénétration de tous les autres beaucoup plus facilement.

La compromission (exploitation d'une vulnérabilité, escalade de privilège et mise en place d'un rootkit) d'un seul poste permet :

• la mise en place d'un sniffer qui permet la récupération des identifiants et mots de passe pour les protocoles de communication en clair ;
• une cartographie du réseau de l'intérieur et un inventaire des ressources disponibles, de ce fait beaucoup plus simple et détaillé, en utilisant par exemple les propriétés des protocoles SNMP, RPC et SMB ;
• la mise en place d'une détection automatisée de vulnérabilités via des outils tel que Nessus... ;
• l'effacement des traces.

Ces dernières techniques, hautement intrusives, entrent dans le cadre d'une « reconnaissance active ».

Réseau

Il n'est pas toujours chose aisée de cartographier un réseau informatique, surtout lorsque celui-ci est bien protégé. De ce fait, on peut très bien trouver une autre vulnérabilité permettant de pénétrer le réseau. Cela sera ensuite beaucoup plus simple de faire une cartographie.

C'est lors de cette étape de cartographie que l'on détermine et trouve les informations relatives au système d'information. Dans la pratique, il s'agit principalement de :

• prise d'empreinte de la pile TCP/IP afin d'étudier les différentes réponses dues aux implémentations des piles TCP/IP et de déterminer le système d'exploitation installé, ainsi que sa version.
• balayage des ports et firewalking (en) afin de détecter des ports ouverts et les règles de filtrage des machines.
• Récupération des bannières d'informations et identification protocolaire afin d'identifier les services qui tournent derrière ces ports et leur versions, en vue d'une exploitation ultérieure.

Ceci, de nos jours^[Quand ?], est relativement trivial avec des outils comme Nmap qui réalisent aisément ces opérations en fournissant une interface complète et conviviale.

Ces techniques quant à elles peuvent être aisément détectées notamment à l'aide d'un système de détection d'intrusion (IDS, pour Intrusion Detection System) et elles entrent aussi dans le cadre de la reconnaissance semi-passive.

Le testeur doit tester le réseau, autrement dit, il n'a pas encore terminé car c'est notamment pendant cette action qu'il va tenter de corrompre les éventuels pare-feux. Après un balayage des ports, le testeur s'intéresse également aux ports ouverts et filtrés, où il faudra utiliser les protocoles des services proposés.

Exemples :

• protocole de communication HTTP pour le service d'un serveur web ;
• protocole de communication IRC pour des conversations entre internautes.

Certains protocoles sont intrinsèquement faillibles ; dans ce cas, si le sujet respecte les normes, il sera alors facile de corrompre un service derrière un port. Cette étape est importante car sachant qu'un pare-feu ou un IDS est présent, il faudra alors le contourner ou le corrompre. La corruption s'effectue grâce à ce que l'on peut appeler des « paquets empoisonnés ». Selon une certaine méthode, le pare-feu ou l'IDS qui récupèrera ces paquets va réagir en laissant passer le testeur au travers.

L'IP et le DNS spoofing sont des techniques qui peuvent porter leur fruits dans ces conditions. Si une machine du réseau est en zone de confiance, alors il suffira d'usurper son identité pour pouvoir être dans cette même zone.

Il est donc important pour l'attaquant de savoir forger ses propres paquets, et notamment utiliser des sockets brutes (raw socks).

Applicatif

Il ne s'agit pas d'une étape, mais d'une globalité. Après avoir trouvé les programmes actifs qui communiquent avec un autre réseau, trouver une faille dans ces applications peut amener à corrompre tout un système en peu de temps. Trouver une faille dans une application est très complexe, et peut nécessiter beaucoup de temps. Cela dit, les attaques portées sur des applications sont très efficaces.

Il est tout de même important pour le testeur d'avoir de solides connaissances en architecture des systèmes d'exploitation, et en langage d'assemblage, qui différera bien sûr en fonction du type de système sur lequel on tente de pénétrer.

Dans beaucoup de cas, la personne qui tente de corrompre un programme va aller le trouver, puis l'étudier. Dans le cas où il lui est possible d'obtenir la source, cela facilitera davantage la tâche, car il n'aura pas, ou presque pas, à lire de code assemblé. Il aura beaucoup plus de facilité à trouver des erreurs de programmation.

Le but recherché ici va être de corrompre une application pour lui faire exécuter son propre code, généralement donné en langage d'assemblage. La plus grande faille connue à ce jour est le dépassement de tampon (BOF pour Buffer Overflow). Mais il en existe bien d'autres qui peuvent être au moins aussi dangereuses et exploitables.

Web

De nombreuses possibilités s'offrent si le système d'information dispose d'un serveur web sur le même réseau. Naturellement, plus le nombre de services actifs est élevé, plus la surface d'attaque est importante. Ainsi, un service de plus mène à des failles potentielles.

Le service web est l'un des plus exploités des Hackers et débutants, de ce fait, il est primordial d'y avoir une bonne sécurité. D'autant plus que la sécurité d'un site web est beaucoup plus mise en péril en raison du grand nombre d'attaquants, qui préféreront ce type d'attaque à la recherche d'autres failles dans le système.

La plupart, pour ne pas dire la totalité des failles présentes sur le web, sont dues à une mauvaise programmation du service proposé. De multiples vulnérabilités sont connues à ce jour, telles que les injections SQL, les failles CSRF, etc.

Outre le fait que l'attaquant peut parfaitement élever ses droits sur le site, il lui est également possible en fonction des failles d'élever ses droits sur le système au complet, pouvant ainsi le corrompre aisément. Il doit pour cela avoir une maîtrise parfaite du protocole de communication mis à disposition, en l'occurrence, HTTP pour un site web.

L'attaquant présumé va alors tester tout le site: URL, formulaires et variables principalement (requêtes GET, POST), en-têtes, etc. On pourrait le classer dans la rubrique réseau car les attaques vont s'effectuer via des requêtes et leurs réponses.

Système, services et configuration

Pour les systèmes Linux, Microsoft Windows (ou autre), la configuration de ceux-là s'avère plus que primordiale. La configuration du réseau du système, de ses services, de la façon dont il réagit face aux événements. Pour les systèmes Windows, la configuration est beaucoup plus restreinte car le code du système ne peut être modifié sans être dans l'illégalité.

De nouvelles failles sont trouvées tous les jours dans les systèmes d'exploitation ; on parle souvent de failles applicatives, mais on en trouve également dans des services exploitant le réseau.

Test de type "boîte grise"

Ce type de test est une méthode intermédiaire entre le test d'intrusion en boite blanche (white box) et celui en boite noire (black box) : le testeur dispose d'un ou plusieurs accès authentifiés sur le système à tester (par exemple un couple identifiant/mot de passe permettant de s'authentifier sur l'application). Ceci permet de tester différents contextes applicatifs accessibles après l'étape d'authentification.

Test de type "boîte blanche"

Le testeur peut être en possession de nombreuses informations (mode « white box »). Parmi elles, les plus courantes sont : les schémas d'architecture, le compte utilisateur (permettant de s'authentifier), le code source de l'application, etc..

Dans ce cas, il n'aura plus qu'une chose à faire : rechercher la où sont les failles, et trouver le moyen de les exploiter.

De même, un testeur se trouvant à l'intérieur du réseau à tester aura plus de facilité à trouver ces failles car il connaît non seulement le système, mais il peut avoir accès directement aux ressources dont il a besoin.

Les tests red team

Les tests d'intrusion dits « red team » ont pour objectif de simuler le scénario où un pirate souhaiterait introduire le système d'information d'une entreprise ou d'une institution sans limite de temps, ni de périmètre. Les tests red team se déroulent sur une période de temps plus longue qu'un test d'intrusion normal (2 à 3 mois, contre 1 à 2 semaines) et n'ont pas de périmètre précis défini par le commanditaire (le testeur démarre avec uniquement le nom de l'entreprise).

En complément des techniques d'intrusion classiques, les testeurs peuvent user d'autres techniques, comme le spear phishing, le social-engineering, les watering holes ou encore les intrusions physiques.

Voir aussi

Articles connexes

• Sécurité du système d'information
• Sécurité de l'information
• Insécurité du système d'information
• Fédération des professionnels des tests intrusifs
• Hacking éthique
• Burp suite
• Breach and attack simulation