URL: https://linuxfr.org/news/wapiti-3-0-0-nouvelle-version-du-scanneur-de-vulnerabilites-web Title: Wapiti 3.0.0 : Nouvelle version du scanneur de vulnérabilités Web Authors: devoop Benoît Sibaud, palm123, Davy Defaud et bubar🦥 Date: 2018-01-12T13:13:41+01:00 License: CC By-SA Tags: wapiti, shellshock, sécurité, python et web Score: 48 Wapiti est un scanneur de vulnérabilités Web publié sous licence GNU GPL v2. Il permet de détecter la présence de failles courantes (injection SQL, XSS, inclusion de fichier, exécution de code ou de commande, etc.) sur les sites Internet et les applications Web via différents modules d’attaque. L’exploitation des failles remontées n’est pas gérée par le logiciel, l’utilisateur doit donc procéder à l’exploitation lui‐même ou s’en remettre à un logiciel spécifique (comme _sqlmap_ pour les failles SQL). Wapiti génère des rapports de vulnérabilités dans différents formats (HTML, texte, JSON, XML). C’est un outil en ligne de commande qui a peu de dépendances et s’installe facilement. ---- [Dépêche pour la sortie de Wapiti 2.3.0](https://linuxfr.org/news/sortie-de-wapiti-2-3-0) [Site officiel](http://wapiti.sourceforge.net/) ---- ![Logo](http://wapiti.sourceforge.net/wapiti_400.png) Fonctionnement ============== Le fonctionnement général de Wapiti est simple : dans un premier temps scanner le site demandé afin d’énumérer les adresses URL et formulaires présents sur le site. L’outil qui parcourt les pages (ou _crawler_) est efficace et certains projets spécialisés dans la comparaison d’outils de sécurité considèrent Wapiti comme la meilleure solution libre sur le sujet. Wapiti est capable d’extraire des URL depuis des fichiers Flash (`.swf`), JavaScript (tant bien que mal) et gère parfaitement les dernières subtilités de HTML 5. Une fois cette phase d’énumération effectuée, chaque module va injecter un ou plusieurs charges (_payloads_) dans les différentes entrées (paramètres d’URL, champs de formulaire) et déduire on non la présence d’une vulnérabilité en se basant sur la réponse obtenue (principalement via la présence de messages d’erreur, d’un motif spécifique ou d’un comportement réseau particulier comme un délai d’expiration). Nouveautés ========== Python 3 ----------- Ce qui explique le passage du numéro de version 2.3.0 au 3.0.0, c’est le passage du code à Python 3 (en remplacement de Python 2.7). Ce numéro de version est donc l’occasion d’afficher clairement ce changement auprès des utilisateurs du logiciel. Attaques -------- Sur le plan des types d’attaques pris en charge, peu de nouveautés. Il y a certes un module pour détecter la vulnérabilité _Shellshock_ et un autre pour l’attaque en force brute des noms de dossiers et fichiers sur le serveur Web ciblé (comme le font _DirBuster_, _dirb_ ou _gobuster_ pour les initiés), mais ces derniers traînaient déjà sur le SVN du projet depuis un moment. Un nouveau module permet d’afficher les dix ressources les plus lentes du serveur Web (en termes de vitesse de téléchargement). Il s’agit là d’une preuve de concept pour montrer que l’architecture de Wapiti peut aussi être utilisée pour autre chose que lancer des attaques. Des améliorations ont été apportées aux modules existants, comme la diminution de faux‐positifs ou encore l’ajout de nouvelles charges (_payloads_) d’attaque. Interface utilisateur --------------------- Le gros du changement a visé à donner plus de contrôle à l’utilisateur sur l’exécution des différentes phases (_crawling_ et attaque). Cela s’est fait par l’ajout d’un vrai mécanisme de sessions basé sur des bases de données SQLite 3. Jusqu'à présent, il était possible de stopper la recherche via `Ctrl` + `C` pour passer aux attaques, et arrêter les attaques signifiait stopper le logiciel. De même, dans les précédentes versions seules les URL et formulaires trouvés lors de la recherche étaient conservés. Désormais, les sessions permettent de garder les URL et formulaires, mais aussi de savoir quels modules ont déjà attaqués, quelles vulnérabilités ont déjà été trouvées et quelles requêtes HTTP sont associées. On peut dès lors stopper durant la phase d’attaque sans avoir à tout recommencer. Cela se voit lors d’un `Ctrl` + `C` qui propose alors soit de continuer les attaques du module existant, soit de passer au module d’attaque suivant, soit de quitter sans générer le rapport, soit de quitter et générer le rapport. Relancer le logiciel permet alors de reprendre par défaut exactement où l’on était resté. Plusieurs nouvelles options permettent d’agir sur la session si l’on souhaite par exemple relancer les attaques sans relancer le _crawling_. Au lancement de l’application, l’utilisateur est dorénavant accueilli par un _ASCII art_ car, bien sûr, un outil d’attaque n’est pas concevable sans [art ASCII](https://fr.wikipedia.org/wiki/Art_ASCII) (par exemple _sqlmap_ ou _Metasploit_, pour ne pas les citer). Contrôle des requêtes --------------------- Ceux qui ont déjà écrit un _crawler_ savent à quel genre de problèmes on doit faire face. Un cas d’école et celui des calendriers : leur contenu est généré dynamiquement, tout comme les liens trouvables dans l’application. On peut suivre éternellement le lien permettant de passer à l’année suivante, ça ne s’arrêtera jamais. Wapiti avait déjà des garde‐fous pour ce genre de problématiques, mais de nouvelles options permettent de contrôler plus finement le _crawler_. Au total neuf options permettent de fixer la profondeur de recherche, limiter la durée de parcours, spécifier une intensité de recherche, limiter le nombre de liens sous un même dossier, ou encore limiter le nombre de variantes d’une _query string_ pour un script. Plus que le parcours, c’est le temps de réalisation des attaques qui peut être excessif. Si un module qui dispose de cinq charges s’attaque à une URL avec cinq paramètres, il devra envoyer 3 125 (5^(5)) requêtes. Je vous laisse imaginer le temps qu’il faut pour s’attaquer à un formulaire disposant de plus de 50 entrées. En plus de pouvoir supprimer des paramètres des URL, Wapiti peut maintenant ignorer certains paramètres lors de l’attaque. Il peut aussi ignorer les URL et formulaires ayant plus d’un certain nombre d’entrées. Enfin, l’option d’intensité de la recherche (`--scan-force` ou `-S`) propose des valeurs similaires à Nmap (de _paranoid_ à _insane_) qui permettent de réduire plus ou moins fortement la quantité d’URL au fur et à mesure que le nombre de paramètres augmente. Installation et utilisation =========================== Le wiki du projet contient [une page dédiée à l’Installation](https://sourceforge.net/p/wapiti/wiki/Installation/) du logiciel sous différentes distributions GNU/Linux, ainsi que sous Windows. Des tutoriels vidéos ont aussi été créés. L’utilisation de base est très simple, on appellera juste Wapiti avec l’option `-u` pour spécifier l’URL servant de base pour le périmètre d’attaque (le périmètre par d’attaque par défaut est _folder_, donc tout ce qui se trouve sous le chemin spécifié est attaqué). Les modules d’attaque les plus courants seront lancés une fois la recherche terminée et le rapport sera généré. [La page de manuel](http://wapiti.sourceforge.net/wapiti.1.html) est sans doute l’aide la plus fournie pour contrôler plus en détail Wapiti. Aider le logiciel ================= En tant qu’utilisateurs de GNU/Linux, vous pouvez aider le logiciel en créant des paquets pour cette nouvelle version pour votre distribution favorite ou demander à un mainteneur la création du paquet. J’ai déjà cru voir un paquet pour Gentoo ainsi qu’un paquet Arch Linux sur un dépôt spécifique. Le logiciel est gratuit et je le développe sur mon temps libre. Vous pouvez aussi contribuer via une aide financière au projet qui sera la bienvenue.