Argthtjtr

Cet article est une ébauche concernant la sécurité informatique.

Vous pouvez partager vos connaissances en l’améliorant (comment ?) selon les recommandations des projets correspondants.

En sécurité informatique, un scanner (ou scanneur) de vulnérabilités est un programme conçu pour identifier des vulnérabilités dans une application, un système d'exploitation, ou un réseau.

Utilisation |

Les scanneurs de vulnérabilités peuvent être utilisés dans des objectifs licites ou illicites :

• objectifs licites : les experts en sécurité informatique ou les entreprises utilisent les scanneurs de vulnérabilités pour trouver les failles de sécurité des systèmes informatiques et des systèmes de communications de leurs entreprises dans le but de les corriger avant que les pirates informatiques ne les exploitent ;


• objectifs illicites : les pirates informatiques utilisent les mêmes équipements pour trouver les failles dans les systèmes des entreprises pour les exploiter à leur avantage.

Cet outil peut être une brique intégrée d'une solution de sécurité plus large: un SIEM ou un SOC par exemple.

Principes de fonctionnement |

Les scanners de vulnérabilités se présentent sous plusieurs formes: logiciel à installer sur son système, machine virtuelle pré-configurée (virtual appliance) ou encore en SaaS dans le cloud.

Un scanner de vulnérabilités se "lance" sur une ou plusieurs cibles, dans un réseau interne ou sur Internet. Ces cibles (URL, adresse IP, sous-réseau) sont renseignées par l'utilisateur lorsqu'il désire mener son scan. La plupart des outils suivent le schéma de scan suivant:

• détection des cibles actives (attente d'une réponse ICMP, ARP, TCP, etc. pour déterminer si la cible répondra au scanner)


• détection des ports TCP et UDP accessibles sur la cible (scan de ports)


• détection des services actifs (SSH, HTTP, etc.) sur chacun de ces ports et de leurs versions (phase de "fingerprint")


• éventuellement: utilisation d'un compte fourni pour se connecter sur la machine et lister les programmes non visibles depuis le réseau (navigateur, liseuse, suite bureautique, etc.)


• éventuellement: reconnaissance des applications Web accessibles et construction de l'arbre de chaque site Web (phase dite de "crawling")


• sélection des modules de sécurité à lancer sur la cible selon les services précédemment reconnus


• lancement des modules de sécurité


• génération du rapport de sécurité

Un scanner de vulnérabilités est donc un outil complexe qui peut faire appel à de nombreux programmes spécifiques pour chacune des tâches pré-citées.

Cibles |

Un scanner de vulnérabilités est théoriquement capable de tester tout élément joignable par une adresse IP :

• Ordinateur


• Serveur


• Routeur, commutateur, pare-feu


• Smartphone


• Objet connecté


• Site Web


• Automate, robot, machine


• Caméra IP


• IPBX, poste téléphonique sur IP


• etc.

Le fait de pouvoir joindre un élément n'implique cependant pas forcément que son niveau de sécurité puisse être audité correctement. Pour cela, le scanner doit embarquer les modules de sécurité idoines dans son catalogue. Par exemple, si une cible ne possède que le port UDP 161 ouvert avec le service SNMP, un scanner pourra reconnaître que cette cible est active mais ne pourra juger son niveau de sécurité qu'en incorporant des modules d'attaque contre SNMP.

Méthodes de détection |

Pour établir la présence d'une vulnérabilité, un scanner dispose de plusieurs méthodes:

Fingerprint de version |

Cette première méthode est la plus répandue. L'outil tente de déterminer la nature et la version d'un service, par exemple: apache httpd 2.4.2.

Pour cela, il peut se fier aux bannières présentées par les différents services, rechercher des motifs caractéristiques d'une version dans les réponses du serveur (notamment dans les en-têtes), etc.

Une fois que la version est déterminée, l'outil utilise une base qui associe à chaque version d'un outil, la liste des vulnérabilités publiquement connues sur celui-ci.

De telles bases sont publiquement accessibles et enrichies par l'éditeur de la solution concernée, par un État ou encore par une communauté. La base la plus connue est celle des CVE: Common Vulnerabilities and Exposures publiée par le MITRE, une organisation à but non lucratif soutenue par le département de la Sécurité intérieure des États-Unis. Une alternative indépendante est l'OSVDB (Open Source Vulnerability Database). Ces bases tentent donc de recenser toutes les vulnérabilités découvertes et de les associer aux produits vulnérables. Généralement seuls les produits les plus connus font l'objet d'une entrée dans ces deux bases. Les éditeurs les plus connus maintiennent aussi leur propres base: Debian Security Advisory (DSA) pour Debian, CSA pour Cisco, RHSA pour RedHat, idem pour Wordpress, Gentoo, Drupal, etc.

De manière symétrique, la dénomination des programmes et de leurs versions a été normalisée avec les CPE (Common Platform Enumeration également maintenu par le MITRE) afin de pouvoir faire des associations en base de données plus simple.

Cette méthode est cependant notoirement sujette aux faux positifs et aux faux négatifs. De nombreux programmes ne laissent pas transparaître leur version (désactivation des bannières, etc.), le scanner ne pourra donc pas en déduire leurs vulnérabilités (faux négatifs). Inversement, des programmes peuvent donner leur version mais avoir subi un rétroportage des correctifs et donc, ne pas souffrir des vulnérabilités officiellement rattachées à cette version (faux positifs). Ce dernier cas se produit très fréquemment sur les versions paquetagées par les distributions Linux comme Debian ou Ubuntu.

En outre, les informations fournies par la base CVE et par la normalisation CPE ne sont pas toujours suffisantes pour identifier la présence d'une vulnérabilité. Par exemple, dans le cas d'une vulnérabilité comme la CVE-2017-0143^[1] (liée à l'attaque WannaCry), on constate que toute machine Microsoft Windows 8.1 utilisant SMB v1 est vulnérable d'après les informations fournies par le NVD^[2] et la terminologie CPE. Or, une telle machine disposant des correctifs de sécurité appropriés (KB4012213^[3]) sera bel et bien protégée de cette vulnérabilité, et représentera ainsi un "faux-positif". Il faut donc affiner une telle analyse à partir des alertes de sécurité en provenance des éditeurs, qui indiquent de manière plus précise les conditions de vulnérabilité.

Exploitation active |

Lorsque des vulnérabilités sont publiquement dévoilées, elles sont parfois accompagnées d'un "exploit" (prononcé "exploite" ou "exploïte") qui est un programme permettant de les exploiter automatiquement.

Un scanner de vulnérabilités peut donc recourir à cet exploit pour vérifier la présence d'une vulnérabilité. Dans ce cas-là, le scanner n'a pas besoin de se fier à la version du programme qu'il audit, il se fie à la réussite ou à l'échec de l'exploit.

Plusieurs bases d'exploits existent telles que exploit-db(maintenu par la communauté à l'origine de Kali Linux, distribution dédiée au tests d'intrusion) ou encore celle de l'outil metasploit (publié par Rapid7 qui édite notamment le scanner de vulnérabilités Nexpose).

Cette méthode est donc très efficace mais souffre de deux inconvénients. Premièrement il existe peu de vulnérabilités pour lesquelles un exploit est disponible: pour donner un ordre de grandeur, il existe 90 000 CVE enregistrées et moins de 4000 exploits dans metasploit. Deuxièmement, certains exploits peuvent avoir des effets de bord significatifs et perturber le fonctionnement de la machine auditées (pouvant aller jusqu'à un crash). Ils doivent donc être utilisés avec parcimonie et être rigoureusement qualifiés.

Scan de configuration |

Certaines vulnérabilités ne proviennent pas d'un défaut dans le code source du programme mais simplement d'un mauvais réglage de celui-ci dans un certain contexte. Les scanners de vulnérabilités peuvent donc détecter certaines vulnérabilités en analysant la configuration distante du service audité (ce qui est un service généralement prévus par celui-ci).

Ceci concerne par exemple les options de sécurité activées sur les cookies, les cipher suite dans la configuration SSL/TLS, les transferts de zone pour un serveur DNS, les mots de passe par défaut inchangés, les services par défaut laissés activés, etc.

Cette méthode est généralement sans risque (excepté tester les mots de passe par défaut qui peut bloquer des comptes après trop d'échecs) et la base des bonnes pratiques est relativement simple à maintenir (par rapport à celle des nouvelles vulnérabilités où l'on compte en moyenne 13 nouvelles CVE par jour). Cependant, il y a des risques de faux positifs puisque le scanner de vulnérabilités n'est pas forcément à même de connaître le contexte et donc de juger si la configuration en question est adaptée ou non (exemple: un transfert de zone DNS est problématique vers Internet mais relativement sans danger dans un réseau interne).

Scans authentifiés |

Bien que la plupart des scanners soient "sans agents", ils fournissent souvent la possibilité d'utiliser un compte renseigné par l'utilisateur pour mener des tests authentifiés.

Lors d'un scan authentifié, le scanner utilise des modules appelés "local security check" qui consistent à consulter la base des programmes installés et leur version (en interrogeant le registre Windows ou Aptitude, pacman, emerge, etc. pour Linux). En se basant sur les alertes de sécurités des éditeurs (DSA, CSA, RHSA, etc.), le scanner pourra constater la présence ou l'absence de programmes ayant des vulnérabilités connues.

L'intérêt principal de cette méthode est de ne pas se limiter à la surface visible de la machine depuis le réseau. En effet, une machine ayant un navigateur obsolète pourrait facilement être compromise par un maliciel, mais le navigateur étant un programme "client" et non pas "serveur", il n'émet pas sur un port (puisqu'il consomme un service) comme le ferait par exemple un serveur SSH (qui fournit un service). Donc, en l'absence de scan authentifié, le risque peut demeurer totalement ignoré de l'utilisateur du scanner de vulnérabilités.

Avec cette méthode, le scanner de vulnérabilités remplit donc également une fonction proche du "patch management" (il permet la détection des anomalies même s'il ne les corrige pas lui-même).

Cette méthode est fiable (pas ou peu de faux positifs/négatifs), ne risque pas d'engendrer d'instabilités sur le système audité et est rapide. Elle peut se substituer aux méthodes de fingerprint et d'exploitation active mais pas à celle du scan de configuration qui demeure complémentaire. En revanche, elle nécessite de fournir des comptes valides pour chaque machine auditée.

Spécificité des applications Web |

Les méthodes pré-citées ne sont pas suffisantes pour attester de la sécurité d'un site Web. Elles permettent de savoir si le serveur Web sous-jacent (exemples : Apache, Nginx, IIS) est exempt de vulnérabilités mais ne peuvent pas connaître la sécurité de l'application Web (ou du service Web) propulsée par ce serveur Web.

L'application Web peut souffrir de défauts de conception dans leur code source qui entraînent l'apparition de failles applicatives. Comme chaque site Web est unique, le scanner ne peut pas se fier à une quelconque base de connaissances. Néanmoins, les failles applicatives sont un sujet exhaustivement traité par l'OWASP (Open Web Application Security Project) qui est une communauté libre et ouverte œuvrant pour la sécurité des applications Web. L'OWASP recense toutes les familles de vulnérabilités Web et les attaques qui y sont associées. Certains scanners implémentent donc des modules de détection de ces familles de failles. D'autres scanners se spécialisent même exclusivement dans cette tâches (Burp suite, Zap, Wapiti...).

Il s'agit d'une approche comparable à l'exploitation active mais bien plus complexe. Ici, le scanner ne peut pas utiliser un exploit créé spécifiquement pour fonctionner sur un cas particulier bien connu. Le module d'attaque doit pouvoir s'adapter à tous les sites Web quelle que soit leur architecture. Pour cela, les tests Web incorporent une phase appelée "crawling" qui consiste à cartographier le site Web et tous ses points d'entrées de données (en suivant tous les liens ou même en tentant de deviner la présence de certaines pages : /admin, /phpmyadmin, etc.). Les points d'entrées sont ensuite soumis à des motifs d'attaque adaptatifs spécifiques aux familles d'attaques: injections SQL, XSS, LFI, RFI, traversée d'arborescence, etc.

Les scanners permettent généralement aussi de fournir un compte ou un cookie de session pour accéder aux parties réservées aux utilisateur authentifiés.

Les scanners Web sont cependant limités puisque des opérations complexes, comme remplir un formulaire d'assurance en ligne, ne peuvent être menées de bout en bout car elles peuvent nécessiter de renseigner des informations contextuelles et cohérentes que le scanner ne peut pas deviner.

En pratique, les scanners Web peuvent néanmoins remonter des informations pertinentes pour des technologies très répandues, telles que les CMS. Des outils spécialisés pour chaque famille de CMS peuvent alors être utilisés, comme WPScan pour l'analyse de sites WordPress.

Restitution des résultats |

La visualisation et la restitution des résultats se fait traditionnellement via deux paradigmes. Premièrement, une vue "par vulnérabilité" permettant de lister toutes les vulnérabilités identifiées dans le scan et de donner pour chacune d'elles la liste des machines affectées. Deuxièmement, une vue "par machine" listant les cibles de l'audit associées à la liste de leur vulnérabilités respectives.

Traditionnellement, en sécurité informatique, les vulnérabilités sont restituées par ordre de criticité suivant une échelle à 4 niveaux:

• Critiques: les vulnérabilités permettant généralement une prise de contrôle ou une exécution de commande à distance dont l'exploitation est relativement simple


• Majeures: les vulnérabilités permettant une prise de contrôle ou une exécution de commande à distance dont l'exploitation demeure complexe


• Moyennes: les vulnérabilités ayant des impacts limités ou dont l'exploitation nécessite des conditions initiales non triviales


• Mineures: les vulnérabilités ayant des impacts faibles ou nuls à moins d'être combinées à d'autres vulnérabilités plus importantes

L'état de l'art associe à chaque vulnérabilité un score entre 0 et 10 appelé CVSS (Common Vulnerability Scoring System) qui dépend des caractéristiques de cette vulnérabilité. La version 3 du CVSS prend en compte, au minimum, les éléments suivants :

• Le vecteur d'attaque : est-ce que l'attaquant peut venir de n'importe où ou bien doit-il avoir une position de départ privilégiée ?


• Complexité : exploiter la vulnérabilité est-il trivial (par exemple si un exploit existe) ou bien hautement techniques ?


• Privilèges requis : l'attaquant doit-l disposer d'accès préalables (un compte utilisateur par exemple) pour pouvoir mener son action ?


• Interaction avec un utilisateur: l'attaquant doit-il amener la victime à effectuer une action pour que son attaque réussisse (comme l'inciter à cliquer sur un lien) ?


• Périmètre : est-ce qu'une exploitation permet à l'attaquant d'avoir accès à de nouvelles cibles ?


• Impacts : une exploitation réussie entraîne-t-elle des pertes de confidentialité/disponibilité/intégrité ?

Le score CVSS est régulièrement utilisé par les scanners de vulnérabilités pour pondérer les risques associés à une cible.

Les scanners doivent donner à l'utilisateur tous les éléments pertinents pour sa compréhension de la vulnérabilité. Traditionnellement, une description de vulnérabilité comporte les éléments suivants :

• Le nom de la vulnérabilité


• Sa criticité


• La cible touchée


• Une brève description de sa nature


• Une référence à une base de connaissance type CVE, DSA...


• Une mention de la simplicité de l'exploitation


• Une description de l'impact en cas d'exploitation réussie


• Une ou plusieurs préconisations pour la résoudre

Parfois, d'autres éléments y sont ajoutés:

• Le niveau de confiance à accorder à la vulnérabilité : quantification du risque qu'il s'agisse ou non d'un faux positif


• S'il existe ou non un exploit automatique


• Un extrait des données ayant permis au module de sécurité de conclure à la présence de cette faille


• La famille de vulnérabilité (authentification, mise à jour, etc.)


• Des liens pour en savoir plus (notamment pour des explications plus détaillées du fonctionnement technique de la vulnérabilité)

Les rapports sont souvent exportables aux formats PDF, CSV, HTML, etc.

Outils proches des scanners de vulnérabilités |

Cas des outils d'audit de code |

Certains outils d'audit de code se présentent parfois comme des scanners de vulnérabilités dans la mesure où ils permettent de détecter les failles applicatives en amont (directement dans le code source plutôt que via des tests externes). Il y a effectivement des similitudes dans la philosophie de ces outils. Ils se limitent cependant aux failles liées aux fonctionnement applicatifs mais ne couvrent pas les failles liées au déploiement (système d'exploitation et serveur sous-jacent) et à la configuration (mot de passe par défaut, données sensibles accessibles sans authentification).

Cas des scanners de ports |

Les scanners de vulnérabilités embarquent un service de scan de ports, qu'il soit sur mesure ou sur étagère.

Les scanners de ports existent aussi tout à fait indépendamment des scanners de vulnérabilités. L'outil nmap est la référence incontournable dans ce domaine. En plus du scan de port, ils effectuent parfois aussi du fingerprint de service et peuvent tester la présence de certaines vulnérabilités. Ces fonctionnalités sont cependant limités : pas de corrélation des versions (seulement de l'exploitation active et du scan de configuration), pas de scans authentifiés, pas de scans Web.

Cas des outil d'audit de configuration |

Des outils comme Lynis peuvent être déployés localement sur une machine pour vérifier le respect des bonnes pratiques de sécurité: permissions, mises à jour, configuration des services, etc. Leur approche les exclu cependant de découvrir certaines vulnérabilités puisqu'ils n'auditent la machine que d'après une liste figée de règles. Un mot de passe trivial sur un service de base de données ou un service lancée sans être installé sur le serveur (programme portable par exemple) échappent à ces outils.

Cas des outils de patch management |

Certains outils permettent de lister tous les programmes installés et de vérifier leur état de mise à jour (et proposent d'appliquer les mises à jour nécessaire si besoin). Ces outils sont très puissants mais ne couvrent pas tout le périmètre des scanners de vulnérabilités: des programmes portables non à jour, des défauts de configuration, des mots de passe par défaut, sont autant d'éléments non pris en compte par ces outils.

Cas des scanners de vulnérabilités ciblés |

Plusieurs outils permettent de détecter les vulnérabilités d'un seul type de cible :

• wpscan: pour les failles Wordpress


• routersploit: pour les failles sur routeur, commutateur et pare-feu


• sqlmap: pour les injections SQL uniquement


• brutespray: pour les mots de passe par défaut uniquement


• etc.

De même, les scanners de vulnérabilités uniquement orientés Web appartiennent, de fait, à cette catégorie: BurpSuite, Zap, W3af, Nikto, etc.

Distinctions entre les scanners |

Les distinctions technologiques entre les scanners portent essentiellement sur les points suivants :

• Ergonomie


• Rapidité de la détection des cibles et ports ouverts


• Qualité de la fonction de fingerprint


• Support de la fonctionnalité de tests authentifiés


• Services testés: Web uniquement (comme BurpSuite, Wapiti, ...), tous excepté le Web (comme OpenVas, Nexpose free...), tous


• Richesse du catalogue des modules de sécurité et des technologies pouvant être auditées (systèmes d'exploitation, programmes, etc.)


• Rapidité du scan de vulnérabilités


• Clarté et exploitabilité des résultats restitués par le scanner


• Conformité à certaines normes sectorielles (PCI DSS, etc.)

Liste des scanners de vulnérabilités |

Le site de l'OWASP maintient une liste de ces outils, cependant elle assez peu maintenue, notamment OpenVAS, Arachni et Nessus n'y figurent pas et sont pourtant parmi les plus connus^[4] :

Références |

Voir aussi |

Articles connexes |

• Correcteur de vulnérabilités


• Scanneur de ports


• Footprinting

• Portail de la sécurité informatique