Vous avez plusieurs hypothèses ici:

• les scanners peuvent trouver toutes les vulnérabilités
• si un scanner ne peut pas trouver une vulnérabilité, alors il n'y a aucune vulnérabilité
• toutes les tâches manuelles peuvent être automatisées
• les attaquants utiliseraient uniquement des outils automatisés et non des approches manuelles
• les approches manuelles ne peuvent pas être transformées en outils automatisés sur mesure
• la recherche de vulnérabilités est la pareil à l'exploitation des vulnérabilités

Aucune de ces hypothèses n'est universellement vraie.

Les scanners automatisés contribuent à rendre le processus de recherche de vulnérabilités plus efficace, mais ils sont loin d'être parfaits et loin d'être complets. Les scanners ne sont pas non plus conçus pour exploiter les vulnérabilités de manière utile.

En pratique, vous souhaitez tester manuellement les résultats d'un scanner (faux positifs) et effectuer des tests manuels pour rechercher des éléments que l'outil automatisé aurait pu manquer.

Les attaquants utiliseront un mélange d'approches puis créeront ou modifieront souvent un outil pour exploiter la vulnérabilité afin qu'elle soit reproductible et fiable. Mais cela ne signifie pas que l'outil fonctionnera dans d'autres situations.

Les tests automatisés sont le seuil de base. Si votre site / programme échoue à un test automatisé, vous avez commis une erreur assez cruelle et elle devrait être corrigée immédiatement (car elle sera facile à trouver). Mais j'ai vu des cas où un développeur a ajouté une vérification de 1 = 1 dans son SQL afin de se cacher des scanners automatiques, mais j'ai pu exploiter le site en utilisant 2 = 2 (les scanners SQL modernes en tiennent compte maintenant). Je ne le savais que grâce à des tests manuels et à mon expérience personnelle. Vous ne pouvez pas encoder l'expérience et l'intuition dans un outil.

Le codage est une activité incroyablement complexe. Cela signifie que les erreurs peuvent également être complexes. Aucun outil n'a pu être créé pour rechercher ou exploiter toutes les vulnérabilités.

DAST ont plusieurs limitations qui doivent être résolues par une inspection manuelle de l'application:

• Ils ne peuvent pas trouver de failles de logique métier, car ils ne comprennent pas le cas d'utilisation et cas d'utilisation abusive de l'application.
• Ils ne trouvent que les types et modèles de vulnérabilité connus. Votre kilométrage variera en fonction du niveau de maturité du scanner, mais même les meilleurs scanners ne trouveront pas tous les problèmes.
• Les modèles complexes présentent souvent des problèmes de sécurité subtils, comme une implémentation personnalisée d'un protocole d'autorisation comme OAuth. Ce n'est qu'en étudiant l'architecture sous-jacente en détail qu'un pentester peut trouver ces failles, tandis qu'un outil automatisé échouera, car ce type d'analyse nécessite un raisonnement d'ordre supérieur.
• Les charges utiles pour vérifier l'exploitabilité d'une application ont souvent à être conçu pour l'application spécifique. Même si le scanner soupçonne une vulnérabilité, sa vérification doit souvent être effectuée manuellement.

Cela étant dit, un scanner de sécurité est un outil pratique dans l'arsenal d'un testeur de pénétration, pour identifier les faibles fruits suspendus. La majorité du travail sera toujours manuelle.

De plus, en tant que testeur de sécurité, vous devriez toujours faire des tests en boîte blanche, si possible. Cela inclut l'accès au code source, ce qui vous donne également la possibilité d'utiliser les outils SAST. Ces outils souffrent de limitations similaires, mais peuvent être en mesure de trouver différents types de vulnérabilités, et ainsi ajouter une valeur supplémentaire. Mais même avec les outils DAST et SAST combinés, vous n'atteindrez pas la profondeur de test requise sans test manuel, en particulier pour les applications avec un profil de protection élevé.

Voici un sujet très récent qui aborde le même problème: Pourquoi OpenVAS ne trouve pas tous les ports ouverts par rapport à Nmap?. À retenir: chaque outil est différent et peut donner des résultats différents. Sans parler des faux positifs et des différentes méthodologies de test.

En termes simples, les outils automatisés font des suppositions éclairées et interprètent les résultats. Ils font les choses correctement, la plupart du temps, mais vous devez comprendre comment l'outil fonctionne, ce qu'il fait (et ne le fait pas ) et être en mesure de le régler pour des résultats optimaux .

Un exemple simple: par défaut nmap, Openvas etc ne scanne pas tous les ports tcp / udp mais une sélection des ports les plus populaires, soit quelques milliers sur 65535. Si vous n'êtes pas au courant et exécutez les outils avec les paramètres par défaut, vous pouvez très facilement manquer les ports actifs. Par exemple, de nombreux administrateurs système choisissent d'exécuter SSH sur un port aléatoire plutôt que sur le port standard 22.

Les outils automatisés ont généralement de nombreuses options, et pas seulement un bouton - vous devez donc comprendre ce qu'ils font ou vous filmez dans le noir. Ensuite, votre audit n'est pas approfondi et n'a que peu de valeur, car vous ne savez pas ce que vous faites et ce que vous devriez rechercher. Tout ce que vous avez fait est de gratter la surface et de rechercher les défauts les plus évidents.

En d'autres termes, pourquoi devrions-nous engager des pentesters professionnels si tout ce qu'il faut, c'est télécharger et exécuter un outil? Parce qu'un pentester compétent a de l'expérience et ira plus loin et peut trouver des vulnérabilités qu'un script kiddie manquera.

C'est rarement "aussi simple que d'exécuter un outil".

Une machine correctement configurée et exposée sur Internet devrait avoir une sorte de mécanisme de défense intégré: un pare-feu et / ou un IDS qui contrarieront ce genre d'effort de reconnaissance.

Lorsqu'ils détectent une activité d'analyse des ports , ils réagissent généralement en bloquant votre adresse IP, ou ils limitent le trafic, abandonnent certains paquets de manière sélective ou choisissent de renvoyer des résultats délibérément trompeurs pour frustrer les pirates. Vous vous retrouvez avec des résultats incomplets ou carrément faux.

Gardez à l'esprit que des outils comme nmap, Acunetix, etc. sont bruyants et généralement très faciles à repérer (et à bloquer) par un IDS car le trafic qu'ils génèrent a des signatures et des modèles typiques. Donc, à moins que vous ne testiez une machine non protégée ou faiblement protégée (sur un LAN peut-être), vous devrez les régler un peu pour obtenir des résultats significatifs.

La réponse est donc que vous faites les deux : vous utilisez des outils automatisés, puis vous effectuez des tests manuels , en particulier lorsque l'outil a détecté quelque chose, comme un port ouvert, mais n'a pas été en mesure de l'exploiter, ou que vous voulez revérifier.

Les scanners de vulnérabilité ne peuvent pas trouver toutes les vulnérabilités qui peuvent être présentes. Ils recherchent essentiellement des modèles et une exploitabilité de vulnérabilités déjà connues.

De plus, vous pouvez obtenir des faux positifs ou d'autres résultats inattendus lorsque vous utilisez des outils automatisés. Vous avez donc besoin de professionnels capables d'évaluer la sortie et de réaliser des pentestings plus avancés.

Voici quelques défis difficiles courants (en particulier des activités de reconnaissance et de pivotement) aux scanners automatiques de sécurité des applications qu'ils ne parviennent généralement pas à détecter ou qui pourraient avoir des détections faussement positives:

• Paramètre caché détection pour une analyse plus approfondie
• Détection d'URL masquées ou relativement référencées pour une analyse plus approfondie
• Impact de la sécurité métier / logique pour identifier une vulnérabilité à partir de détections potentielles de faux positifs La menace d'attaques CSRF fait partie de ce type de défi. Les scanners ont également des problèmes avec les vulnérabilités affichées uniquement lorsqu'une valeur spécifique d'un paramètre est définie.