[VULNERABILITY ASSESSMENT] MISSION: Find the hole!

Les tests de vulnérabilités occupent une grande place dans les besoins de sécurité des SI pour évaluer la sécurité d'un système ou dans le cadre d'un test d'intrusion. Le but est bien entendu de trouver les faiblesses des serveurs afin d'assurer une sécurité système maximale au final. Pour mieux comprendre ce sujet, je vous invite à lire mon dossier paru dans le magazine Hakin9, n°26 - Juillet/Août. Ma pub étant faite ;), je vous propose d'en voir les points essentiels dans ce blog à travers trois parties : la préparation d'un test, son déroulement et son interprétation.

Introduction et définitions :

Avant de parler de tests de vulnérabilités, je vous invite avant tout à lire la définition d'une vulnérabilité (sur le site de Wikipédia par exemple). Quant aux tests eux-mêmes, ils sont définis par le clusif comme "l'identification de failles connues". Nous ne sommes donc pas dans la même problématique d'un test d'intrusion où ce qui prévaut est la créativité et l'ingéniosité à trouver les faiblesses d'un réseau.

Préparation d'un test de vulnérabilités :

Le but de cette partie est d'essayer d'obtenir les résultats les plus pertinents possible et d'éviter les faux-positifs.

1. Trouver le(s) bon(s) outil(s) :

Il pourrait exister autant de tests de vulnérabilités que de serveurs. En effet, les besoins sont différents en fonction de la machine à auditer et selon, les outils utilisés le seront aussi. Par exemple, dans le cadre d'un serveur WEB, on utilisera très certainement un scanner WEB comme NIKTO. Cependant, un serveur ne se caractérise pas seulement par son rôle principal mais de manière plus complexe (un OS, des comptes, des droits, des partages, etc ...). C'est pour cette raison que pour réaliser un test complet, il faudra utiliser une combinaison d'outils appropriés. Cependant, dans de nombreux cas, NESSUS est l'outil privilégié pour ce genre de tâche. il existe des outils plus complets mais qui entrent plutôt dans le cadre d'un test d'intrusion.

2. Déterminer la nature du test :
Le demandeur devra choisir en premier lieu entre :

• Les tests externes ; Nous simulons un attaquant qui opère depuis le réseau internet ;
• Les tests internes ; Nous simulons un employé de l'entreprise ou un intrus qui s'est infiltré physiquement au sein de celle ci.

Puis, il devra choisir entre :

• Les tests dits "boîte noire" ; tout ce que l'auditeur a à sa disposition, c'est une adresse IP ou un range d'adresses. Il simule ainsi le comportement d'un attaquant.
  
• Les tests dits "boîte grise" ; l'auditeur connaît les informations de bases sur la ou les cibles.
  
• Les tests dits "boîte blanche" ; l'auditeur a accès à toutes les informations qu'il désire sur la ou les cibles.

Le choix se fera en fonction des besoins du demandeur. Par exemple, un test externe en boîte noire révèlera seulement ce qu'un hacker pourra trouver en choisissant l'entreprise pour cible (aléatoire ?) alors qu'un test interne en boîte blanche fournira le maximum d'information et les actions correctives pourront être plus poussées.

3. La configuration de l'outil :

Après avoir pris connaissance des informations nécessaires - ne serait-ce qu'une adresse IP dans le cas d'un test en boîte noire - nous devons nous en servir pour configurer les outils choisis. Si nous prenons par exemple le cas de NESSUS, la configuration s'effectuera en plusieurs étapes ici simplifiée à l'extrême :

• Renseigner la ou les adresses IP (ou noms de serveurs) ;
• Déterminer le(s) type(s) de scan de ports à utiliser (ex : scan TCP, SYN, etc...) ainsi que le range de ports à étudier ;
• Donner les paramètres de connexions vers la serveur NESSUS ;
• Donner les paramètres des tests ("safe check" ou non, "optimize the test" ou non, etc ...) ;
• Activer les plugins nécessaires et seulement ceux-là (un plugin = un module ayant pour fonction d'exécuter un test). Il est possible de désactiver les attaques DoS pour éviter de faire tomber le serveur ;
  
• Et enfin lancer le scan (qui a dit qu'un test de vulnérabilités consistait seulement à cliquer sur le bouton "start" ? ;)

Déroulement d'un test :

La plupart du temps, un test de vulnérabilités consistera en :

• connexion de ports ;
• lancement de module executant des tests ;
• récupération d'information sur les tests réussis et traitement des données.

De nouveau, prenons NESSUS pour exemple car un peu plus complexe mais du coup plus intéressant :

1. L'utilisateur se connecte via son client vers le serveur NESSUS (en effet, cette solution fonctionne en mode client / serveur). La connexion est chiffrée (certificats).

2. Le serveur NESSUS effectue les tests vers la machine à auditer.

3. Pendant cette phase de tests, NESSUS se sert de la base de connaissances pour optimiser l'exécution des tests (entre autres, il enregistrant les informations collectées au fur et à mesure et évite ainsi d'effectuer plusieurs fois les mêmes tests, comme la présence d'un serveur FTP sur le port XX).

4. Les résultats sont renvoyés aux clients qui peut alors générer un rapport.

Interprétation d'un test :

A l'issue de la deuxième phase, nous avons donc en main toutes les informations nécessaires (certainement sous forme de rapport). Peut-être que les mêmes personnes qui pensaient qu'appuyer sur le bouton "start" suffisait pensent que nous en avons fini ? Ce serait une erreur ! Au contraire, la partie la plus importante (et intéressante) va commencer...

Pour cela, voici le résumé des étapes ;

• Repérer les failles réelles ou éventuelles parmi les alertes relevées par le scanner,
• Evaluer la pertinence de chaque faille,
• Evaluer l'importance de chaque faille (criticité, impact, risque),
• Ajuster les évaluations en fonction des conditions de tests (zone critique ou non, serveur critique ou non, etc ...) et des paramètres des tests (attaques DoS activées ou non, mode "safe check" ou non, etc ...).

Augmenter le niveau de pertinence des résultats en ;

• Eliminant les incohérences évidentes (ex : faille concernant un SOLARIS 8 alors que nous sommes en version 10),
• Trouvant les intéractions entre les alertes (ex : "un mot de passe n'a jamais été changé" et "une "le mot de passe n'expire jamais selon sa politique de sécurité"),
• Eliminer les derniers faux-positifs grâce à NASL - langage dans lequel sont écrits les plugins - en l'utilisant en ligne de commande ou en créant ses propres plugins,
• Utiliser plusieurs outils pour confirmer ou non une faille.

Ensuite, il faudra agrémenter le rapport avec ;

• Des explications sur la faille et le risque encouru (travail de sensibilisation),
• Des solutions contenant des actions correctives concrètes et réalisables,
• Des références (documents, références CVE ou autre),
• Une évaluation globale de la sécurité avec les conseils avisés de l'auditeur.

Pour conclure :

Un test de vulnérabilités n'étant pas aussi complet qu'un test d'intrusion, nous ne pourrons pas tout voir dans notre cas. Cependant, à l'issu de notre travail, nous devrions avoir repéré les problèmes majeurs aux niveaux OS et applicatif. Mais "savoir" ne suffit pas. Pour que la tâche ait vraiment un intérêt, il faut pouvoir appliquer les actions correctives et alors réellement augmenter le niveau de sécurité du système audité. Evidemment, un travail de fond serait à envisager pour obtenir les meilleurs résultats : il s'agirait en amont de déterminer des politiques de sécurité, un hardening des OS strict et en aval de maintenir le niveau de sécurité à travers une gestion de correctifs continue accompagnée d'une veille de vulnérabilités. Bref, c'est ce qu'on peut appeller un cycle vertueux, non ?