On a vu comment il était possible de chercher des cibles connexes, si le périmètre défini le permet. On va maintenant se recentrer sur notre cible principale : l’application.
Reprenons le fil de notre métaphore du braquage de banque.
Malheureusement, vous n’avez pas trouvé de succursales, locaux ou points de dépôt pour votre cible. Tout semble se passer à une seule et même adresse, dans un seul bâtiment. Reste donc à savoir comment rentrer dans ce bâtiment. Par la grande porte ? Ou bien est-ce qu’il existe une porte de service, des fenêtres, un Velux sur le toit ou encore des canalisations praticables ?
Ces points d’entrée dans le bâtiment où se trouve la cible (l'intérieur de la banque) sont l'équivalent de nos services en écoute sur le serveur qui héberge l'application web à tester.
Pour découvrir les points d’entrée, nous allons avoir besoin de réaliser un scan de ports. En effet, le serveur ne vous dira pas de lui-même tous les services qu’il expose.
Réalisez un scan de ports
Dans notre exemple nous allons utiliser Nmap, c’est le principal à connaître. Dans son utilisation basique, Nmap est relativement simple :
❯ nmap app.preprod.example.com
Cette commande nous donne le résultat suivant :
Starting Nmap 7.92 ( https://nmap.org ) at 2022-04-22 07:40 AST Nmap scan report for app.preprod.example.com (<adresse_IP>;) Host is up (0.14s latency). Not shown: 998 closed tcp ports (conn-refused) PORT STATE SERVICE 22/tcp open ssh 80/tcp open http Nmap done: 1 IP address (1 host up) scanned in 36.24 seconds
Cette première commande nous donne déjà plusieurs informations :
l'hôte en face est bien en ligne avec la partie “Host is up” ;
2 ports parmi les 1 000 plus connus sont ouverts ;
c’est vraisemblablement un serveur Linux en face (port SSH ouvert) ;
un serveur web est à priori en écoute (port 80 ouvert).
Mais que s'est-il passé exactement en entrant cette commande ?
Dans sa configuration par défaut, Nmap :
Résout le nom DNS de l'hôte.
Ping l'hôte.
Si l'hôte répond, réalise un “SYN scan”.
Ne scanne que les 1 000 premiers ports les plus connus sur les 65 535 possibles.
Ne fait pas de détection du service en écoute.
Ça n'a généralement que peu d’impact sur les systèmes récents, mais peut en avoir sur les systèmes plus fragiles. Vous vous rappelez mon anecdote sur le fait que j’avais saturé le pare-feu ? Eh bien c’était notamment à cause de ça. Vu que les requêtes n’étaient jamais fermées, le pare-feu a attendu pendant que je continuais à remplir sa table des connexions, puis a saturé.
Attardons-nous sur ce qui peut être problématique pour notre besoin :
nous ne sommes pas exhaustifs (seulement 1 000 ports scannés parmi 65 535 disponibles) ;
nous ne savons pas avec certitude quel service se cache derrière chaque port.
Pour indiquer à Nmap de scanner tous les ports possibles, il faut le lui spécifier avec l’option-p <ports ou range>.
La syntaxe de cette option est très permissive, mais le plus simple si vous souhaitez scanner tous les ports, c’est de spécifier l’option -p- , qui est l’équivalent de -p 0-65535.
La plupart du temps, on trouvera les services standard sur les ports où on les attend :
SSH sur le port
22;HTTPS sur le
443;SMB sur le
445, etc.
Mais si l’administrateur du serveur le décide, il peut aussi bien tout mélanger et faire tourner le service SSH sur le port 443 et le HTTPS sur le port 22 !
Certaines préconisations invitent même à changer le port par défaut des services d’administration (comme SSH, pour le faire tourner sur un port qui n’est pas 22 ). Cela évite qu’il soit détecté trop facilement par les scans de masse.
Dernier point, les scans que nous faisons sont très voyants : si vous avez besoin de discrétion, il faudra pousser votre compréhension de l’outil et du scan de ports en général beaucoup plus loin ! Mais ce n’est pas le but de ce cours, donc nous ne nous étendrons pas sur le sujet ici.
À vous de jouer !
Challenge
Pour participer à ce challenge, il faut posséder un compte sur Root Me, c’est gratuit.
Connectez-vous à Root Me.
Cliquez sur ce lien (CTF OpenClassrooms - DVWA) pour démarrer ou rejoindre l'environnement.
Une fois sur la page, attendez qu'un cartouche vert apparaisse :
L’adresse à scanner y sera indiquée : lancez-vous !
Vos objectifs sont les suivants :
scanner la machine pour identifier son exposition et trouver le nombre de ports qui sont ouverts ;
trouver quel est le service en écoute sur le port 2121.
Solution
Identifiez les services vulnérables
Une fois que vous avez identifié les services et leurs versions via Nmap par exemple, il faut savoir si ces services sont vulnérables. Pour cela, nous pouvons par exemple taper dans la barre de recherche de Google : wordpress 3.5.1 vulnerability pour connaître les vulnérabilités de cette version de WordPress.
Google est le premier réflexe, mais ce n’est pas une base de données spécialisée, et il est possible de passer à côté d’une vulnérabilité si les données n’ont pas encore été indexées, ou que la recherche n’est pas la bonne.
Vous pouvez mener des recherches complètes sur le site CVE Details qui donne des compléments utiles dans le cadre d’un pentest, comme le score CVSS de la vulnérabilité (nous définirons cette notion en partie 4), ou encore si un code d'exécution public existe. Cependant, cette recherche reste manuelle, ce qui n’est pas très pratique quand on a beaucoup de services ou de technologies à analyser.
Les scanners de vulnérabilités sont là pour vous faire gagner du temps : leur principale utilité réside dans le fait de vous dire si le service détecté est affecté par une vulnérabilité, et notamment une CVE. Ils se basent généralement sur la version détectée du service, mais pas seulement.
Ces produits sont très efficaces pour identifier très rapidement :
si un service est vulnérable ou non ;
s’il existe un “exploit” public ou non.
Voici par exemple un scan Nessus sur la VM OpenClassrooms - DVWA :
Les principaux acteurs du marché sont :
Nessus ;
ou encore Nexpose de Rapid7.
Certains possèdent des versions gratuites à usage personnel. Dans la catégorie de l’open source, on retrouve principalement OpenVAS de Greenbone.
Ces produits peuvent également scanner des applications web et trouver des vulnérabilités spécifiques au web comme des XSS, des injections SQL, celles que nous verrons plus tard dans ce cours. Cependant, ce n’est pas leur cœur d’action et ils sont généralement moins fiables pour détecter ce genre de vulnérabilités. Vous comprendrez mieux pourquoi dans la suite du cours.
C’est pour ça qu’un test d’intrusion manuel comme nous l’apprenons dans ce cours reste pertinent.
Interprétez les résultats et prenez du recul sur l’exercice
Une fois le scan de ports effectué, il est nécessaire de l'interpréter car sinon il ne sera d’aucune utilité pour le commanditaire :
Quels sont les ports légitimes par rapport au besoin ?
Est-ce que les ports que vous avez identifiés sont normaux et ont leur place sur le serveur ? Par exemple, si vous avez identifié que le port 22 est ouvert, à votre avis, est-ce normal ?
Par défaut, non ! Dans le cadre d’une application web, les seuls ports nécessaires sont le port 80 (HTTP) et le port 443 (HTTPS), sauf si l’application est en écoute sur un port non standard, mais le commanditaire vous l’aura normalement précisé dans la phase de cadrage.
Qu’un service SSH soit en écoute sur le serveur et accessible à tout internet n’est pas normal et augmente la surface d’attaque. Imaginez que demain une vulnérabilité critique soit publiée sur le service qui propose la connexion SSH, que va-t-il se passer ? Très probablement une attaque massive de pirates opportunistes qui vont chercher à accéder au serveur et le compromettre, pour voler des informations ou le transformer en zombie pour d’autres attaques.
Si vous avez effectué un scan de vulnérabilité et que des vulnérabilités sont identifiées, testez-les pour vérifier si le serveur est effectivement vulnérable, car ce sont parfois des faux positifs !
En résumé
Un serveur possède un grand nombre de ports (65 535, précisément) qui peuvent héberger des services et même plusieurs services web sur différents ports.
Dans le cadre d’un test d’intrusion, il est important de savoir quels sont les ports exposés pour connaître la surface d’attaque du serveur. Attention toutefois à bien respecter le périmètre défini par le commanditaire.
Pour détecter les ports ouverts en étant à l'extérieur du serveur, il faut réaliser un scan de ports.
Les outils de scan réseau comme Nmap disposent d’une multitude d'options qu’il faut comprendre et maîtriser pour ne pas faire d'erreurs d’interprétation.
Les scans de vulnérabilités sont très utiles pour automatiser et accélérer la recherche des services et composants vulnérables sur une cible, mais ce sont des produits qui sont généralement assez onéreux.
Les scans réseau sont très sensibles aux facteurs externes, comme la latence ! Quand on fait un scan et qu’on cherche l’exhaustivité, mieux vaut prendre son temps.
Dans le prochain chapitre, nous allons vérifier la qualité du chiffrement des services chiffrés.
