Lorsque l’on fait du pentest – dans un cadre légal s’entend – on peut être amené à utiliser un scanner de vulnérabilités voire plusieurs afin d’obtenir une première couche d’informations plus ou moins pertinentes.
Concrètement, un scanner de vulnérabilités va « bombarder » un site afin de collecter le plus d’informations sur son architecture, sa structure, ses technologies, ses contenus et tester différentes faiblesses.
Il existe de nombreux scanners disponibles, certains sont totalement libres et/ou open-source, d’autres nécessitent l’acquisition d’une licence commerciale, vous en trouverez qui procèdent à une batterie de tests complets et d’autres qui vont se limiter à la recherche de certaines failles précises comme les injections SQL. De la même manière, certains sont des clic-au-drôme avec interface graphique ne nécessitant quasiment aucune connaissance technique – ce qui peut s’avérer désastreux ou comique – et d’autres sont entièrement en ligne de commande avec comme prérequis de maîtriser un minimum les tenants et les aboutissants des failles que l’on souhaite découvrir et exploiter.
Personnellement, il m’arrive d’utiliser des scanners afin d’obtenir cette première couche d’informations même si je ne répugne pas de faire le job à la main et ce, pour deux raisons.
La première est que le scanner de vulnérabilité – peu importe celui que l’on va choisir – peut tout à fait générer des faux-positifs et des faux-négatifs. Le faux-positif va être la faille répertoriée comme telle qui en réalité ne sera absolument pas une faille. Typiquement, cela pourra être une URL catégorisée comme vulnérable à une injection SQL et qui s’avérera ne déboucher sur rien. Le faux-négatif est la faille qui ne sera pas détectée par le scanner, ce qui sera beaucoup plus dérangeant car la personne qui se basera uniquement sur le rapport de vulnérabilité, sans rechercher manuellement les éventuelles faiblesses d’un système, passera à côté de quelque chose qui pourrait s’avérer critique. Il faut savoir qu’une bonne partie des scanners fonctionnent un peu comme les anti-virus : sur un système de reconnaissance de signature. Pour faire simple, le scanner possède une base de données plus ou moins exhaustive et dès qu’il verra quelque chose qui va ressembler – de près ou de loin – à une donnée inscrite dans sa base, le scanner va analyser la faille. On l’aura compris : les scanners de vulnérabilité ne vont pas nécessairement détecter les 0days, les vrais, pas ceux qui finissent par être patchés au bout de deux ans.
L’autre faiblesse majeure réside dans l’absence d’invisibilité. Non seulement un scanner de vulnérabilité qui va « bombarder » un site attirera l’attention d’un webmaster mais il laisse souvent une trace tout à fait explicite comme celle-ci :
Il convient de se rappeler que les scanners de vulnérabilité ont été mis au point pour être utilisés dans un cadre légal et non pour attaquer gratuitement et surtout bêtement quelqu’un. Non seulement le nom du scanner va apparaître en clair dans certains cas, mais quand un webmaster regarde ses logs et qu’il voit qu’une vingtaine de recherches ou de consultations de contenus ont été faites en l’espace de quelques secondes, il comprend tout de suite ce que cela signifie. Enfin, il le comprendra encore mieux en consultant les statistiques de charge de son réseau et qu’il verra une curieuse augmentation à une heure totalement indue. S’il subsiste le moindre doute, ce dernier sera balayer quand il verra plusieurs noms de scanners de vulnérabilités apparaître en clair dans ses logs, soit du site Web soit dans Apache.
Message de service au crétin d’hier soir : JE LIS MES LOGS !
Ajouter un commentaire