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.
Sommaire
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 (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 (55) 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 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 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.
Aller plus loin
- Dépêche pour la sortie de Wapiti 2.3.0 (294 clics)
- Site officiel (1467 clics)
# VS ZAP et le reste ?
Posté par Guillaume Kulakowski (site web personnel) . Évalué à 4.
Bonjour,
par rapport à ZAP attack Proxy ça donne quoi ?
Perso, j'ai benchmarké ZAP VS Burp, j'ai trouvé Burp au dessus.
Après si tu as une fortune il y a Qualys qui fait de jolie rapport pour délivrer en ComOp'.
[^] # Re: VS ZAP et le reste ?
Posté par devoop . Évalué à 10.
Bonjour,
La force de Burp ou ZAP (que j'utilise moi-même) c'est surtout le fonctionnement en proxy intercepteur qui permettent de trouver efficacement les requêtes dynamiques (ajax / flash et compagnie) et c'est là ou Wapiti aura tendance à pécher.
Après Wapiti a un fonctionnement totalement automatique là où une utilisation de ZAP requerra plus d’interaction humaine.
Wapiti sera bien pour faire le gros du boulot et trouver les failles les plus évidentes rapidement et ZAP sera à privilégier pour trouver les failles moins évidentes sur lesquelles il faut fouiller un peu et qui demanderont plus de minutie.
Ce côté automatique de Wapiti peut être utile pour mettre par exemple en place un process de test sécurité continu sur une application web.
[^] # Re: VS ZAP et le reste ?
Posté par Johann Ollivier-Lapeyre (site web personnel) . Évalué à 2.
On peut industrialiser la chose aussi avec ZAP, par exemple avec le plugin Jenkins qui va bien. Il est possible d'avoir une chaine qui fait par exemple (en 1 ou plusieurs Job):
Perso, je suis partisant de tests courts à chaque commit/push (tests U, intégration avec jeux réduit) et de garder le ZAProxy+intégration complete + bench plutot 1 ou 2 fois par jours, car les déploiements /test peuvent être assez long avec en plus la reconstruction des jeux de données.
# Parallélisme
Posté par Anonyme . Évalué à -2.
Votre outil semble chouette. J'ai tenté de l'utiliser sur 2/3 sites de petite ampleur sans soucis. Puis j'ai tenté sur le site du mouvement politique qui avance (pas en voiture). Le scan trouve 9170 URL / formulaires, et le script semble tourner sans fin. Avez-vous un ordre de grandeur pour la durée totale?
[^] # Re: Parallélisme
Posté par Guillaume Kulakowski (site web personnel) . Évalué à 10.
Vous n'avez pas le droit d'utiliser ce genre d'outil sur un site en production sans une autorisation…
[^] # Re: Parallélisme
Posté par j_m . Évalué à 1.
Attention a ne pas decourager les gens dans leurs recherches. On n'est pas non plus sur policefr.org ici
[^] # Re: Parallélisme
Posté par Anonyme . Évalué à 5.
De mémoire, ce qui est répréhensible, c'est l'accès et le maintien frauduleux dans un système de traitement automatisé de données. Je n'avais pas capté que l'outil, lors de son scan, rentrait dans cette catégorie. Si il y a une faille, il y a bien un accès (non-autorisé donc frauduleux) au système pour la tester, mais il n'y a pas maintien?
(et avec une connexion pourrie, on peut pas faire du DoS)
[^] # Re: Parallélisme
Posté par Anonyme . Évalué à 10.
ce qui est répréhensible c'est de tenter de trouver des failles sur ce qui ne t'appartient pas. Pourtant il y a eu assez de procès perdu en france a ce sujet. Surtout le celebre humpich et bluetouff.
si tu te sent de convaincre le juge de 54 ans qui a toujours un bibop que tu as raison, vas y fait toi plaisir.
si tu veux tester, tu monte un site internet toi meme ou tu prend un forfait en ligne pour un wordpress et tu la peux tester.
[^] # Re: Parallélisme
Posté par Anonyme . Évalué à -1.
Entendu, mais si il n'y a pas de failles, c'est donc illégal de scanner le site???
[^] # Re: Parallélisme
Posté par Anonyme . Évalué à 10.
oui, si ce n'est pas le tiens. Ou si tu n'as pas d'autorisation.
je comprend ton envie de white hat, c'est louable de scanner des site et d'avertir le proprio. Mais en france NE LE FAIT PAS.
et si tu en trouve je te conseil de te mettre a la pèche à la truite au lieu d'envoyer des mails d'alerte. A ce jours tous les lanceurs d'alerte (du monde) ont toujours perdu leur procès, aussi bonne soit leur intentions.
[^] # Re: Parallélisme
Posté par Kerro . Évalué à 3.
Étudier le plan d'un mécanisme de coffre fort n'est pas interdit.
Ni observer un entrepôt pour savoir ce qui y est stocké, et comment y accéder de nuit sans déclencher d'alarme.
Par contre la mise en œuvre est interdite lorsque tu te fais chopper :-)
[^] # Re: Parallélisme
Posté par Yth (Mastodon) . Évalué à 5.
Yth.
[^] # Re: Parallélisme
Posté par Renault (site web personnel) . Évalué à 5.
Je pense que si tu traines trop longtemps auprès d'un lieu où tu n'es pas convié pour observer la sécurité du coin, les propriétaires (que ce soit des propriétaires d'une entreprises ou d'une maison particulière) vont appeler les flics pour comportement douteux et ils vont t'interroger sur tes motivations.
Je ne vois pas l'intérêt de scanner un site quelconque sans y avoir été convié. Soit tu veux faire quelque chose d'illégal avec, soit tu veux les aider. Mais si tu veux les aider il y a un moyen simple : tu les contactes avant. Car de toute façon si tu le fais dans leur dos et qu'ils s'en aperçoivent, ils pourraient avoir peur et t'attaquer en représailles. Ils peuvent aussi ignorer tes résultats car ils ne t'auraient rien demandés ce qui t'aurait fait perdre du temps.
[^] # Re: Parallélisme
Posté par steph1978 . Évalué à 3.
Si tu tests les failles d'un site en prod, tu n'es plus sur les plans.
À moins d'y avoir été convié par le propriétaire (bug bounty), si, c'est interdit.
Il faut comprendre que notre loi considère internet comme un ensemble de propriétés privées et pas comme une terre libre où tu peux te promener comme bon te semble et toucher à tout.
Le fait de partager ce point de vue est une autre histoire.
[^] # Re: Parallélisme
Posté par Athel . Évalué à 2.
Il faut arréter avec l'affaire bluetouff, il a justement fait plus que trouver la faille :
Articlie de Maitre Eolas
[^] # Re: Parallélisme
Posté par Ambroise . Évalué à 7.
Tu ne seras peut-être pas poursuivi si tu as découvert la faille par hasard.
Par contre, après être passé via une logiciel de scanner, je doute fort que tu puisses invoquer la découverte par hasard…
[^] # Re: Parallélisme
Posté par devoop . Évalué à 6.
Il y a beaucoup de paramètres qui rentrent en jeu comme la réactivité du serveur et si il y a beaucoup de formulaires ou des URLs avec beaucoup de paramètres.
Un scan peut facilement durer plusieurs jours si il y a beaucoup d'URLs c'est pour cela qui sont l'on veut chercher une faille dans une application web connue il est préférable de la déployer chez soit pour la tester avec un jeu d'essai minimum (ex pour une application de forum: une section, un topic, un message, un membre, un message privé, etc ça peut suffire)
Après il faut jouer avec les options proposées par Wapiti comme -d et -S. Souvent une profondeur de 3 ramène déjà suffisamment de liens sur un site moderne.
Pour le reste et par rapport aux autres commentaires, Wapiti est un logiciel libre et c'est aussi la liberté d'utiliser le logiciel comme on l'entend. Chacun est sensé connaître la loi, la responsabilité est bien sûr laissée à celui qui utilise le logiciel.
# Merci
Posté par silenus . Évalué à 4.
Bonjour.
Merci pour ce travail, qui m'a trouvé des failles XSS evil là où d'autres n'en avaient pas trouvé.
J'avais utilisé les préconisations htmlentities ENT_QUOTE, strip_tag, html special chars de php. (avec encodage utf-8 bien précisé dans le meta du html).
Il me trouve même des failles si j'utilise le filtre Xss de Drupal ( bhttps://github.com/ymakux/xss ) ou xss_clean function.
J'ai même testé un site sous wordpress (à jour) qui ne passe pas les tests (pas qu'à cause d'extensions).
N'étant pas pro du dev web, auriez-vous une référence complète sur le sujet en matière de protection de script php afin de parer toutes les failles xss (librarie (plutot que de réinventer la roue..) , doc.. ) ?
Merci.
[^] # Re: Merci
Posté par devoop . Évalué à 4.
Il faudrait s'assurer que les résultats obtenus ne soient pas des faux positifs en ouvrant les URLs remontées via un navigateur.
A noter que pour vérifier la véracité de l'injection il faudra souvent désactiver la protection anti-XSS intégrée au navigateur (XSS auditor pour Chrome par exemple).
S'il s'agit de faux positifs je serais ravi de me pencher sur leur correction. Il est possible de créer des issues ici :
https://sourceforge.net/p/wapiti/bugs/
[^] # Re: Merci
Posté par silenus . Évalué à 1.
Concernant mon script, en exécutant le lien avec les paramètres indiqué, le défaut d'affichage se produit bien. Il y a donc un soucis dans mon code. D'où ma demande de conseils sur quelle lib utiliser pour parer les attaques (traitements des paramètres).
J'ai installé une version vierge de wordpress, il y a des erreurs Xss Get et Post. Là part, il s'agit peut être de ce que vous qualifiez de faux positif.
Cela renvoie sur des pages genre direction
The requested URL /wordpress/s=alert('w93gzd56v3') was not found on this server.
Si c'est un faux positif, merci de me confirmer, je génèrerais le ticket tel demandé
[^] # Re: Merci
Posté par nnamrok . Évalué à 1. Dernière modification le 19 janvier 2018 à 12:31.
Je m'insère dans la conversation, car je fait actuellement des tests avec Wapiti sur des sites fait avec Django. Pour être sûr des résultats, j'ai refait les tests avec une installation vierge de Django.
Wapiti me sort une ribambelle de failles XSS notamment sur les formulaires fournis par défaut avec Django (comme celui tout bête de login à l'admin).
Wapiti me sort aussi une alerte sur une injection SQL sur le formulaire (toujours celui fourni par django) de changement de langue (i18n/setlang/). En regardant les sources, on voit que jamais les arguments passés ne touchent la base de donnée.
N'arrivant pas à reproduire les comportements suspects remontés par Wapiti, je me pose la question suivante : est-ce des faux positifs ? D'autant que Django n'est pas tout jeune et est un framework ayant été éprouvé.
[^] # Re: Merci
Posté par devoop . Évalué à 1.
Très certainement des faux positifs. Ce sera l'occasion de faire la chasse aux bugs :)
# paquet pypi
Posté par François GUÉRIN (Mastodon) . Évalué à 3.
Bonjour,
J'avais testé l'outils plus tôt, et le passage à python 3 est une excellente idée…
Avez-vous prévu de fournir un paquet pour pypi ? Ça se fait très bien et assez rapidement…
Ça permettrai d'automatiser l'installation dans un env de tests ! (gitlab-runner dans un container docker dans mon cas)
Le déploiement à coup de
git clone, c'est assez moyen (même si ça reste possible)[^] # Re: paquet pypi
Posté par devoop . Évalué à 3.
J'y ait déjà pensé mais je ne me suis pas encore penché dessus :)
[^] # Re: paquet pypi
Posté par flan (site web personnel) . Évalué à 3.
À vue de nez (après 15 secondes d'analyse du setup.py), il te suffit de créer un compte sur https://pypi.python.org , puis dans le dossier des sources de faire
python3 setup.py register
python3 setup.py sdist upload
[^] # Re: paquet pypi
Posté par freem . Évalué à 5.
J'imagine qu'il faudrait faire attention si ça dépends de la libcaca.
# Scanner "statique" : intérêt limité ?
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2. Dernière modification le 16 janvier 2018 à 13:23.
Sans avoir beaucoup fouillé la doc, il semble que Wapiti se base sur un parser xml (ou html5) pour "naviguer" sur les pages.
Du coup, vu que de plus en plus de sites génèrent des pages (et donc des formulaires) de manière dynamique en JS, je ne vois pas comment Wapiti peut détecter des failles sur ces sites, puisqu'il n'execute pas le javascript. À moins qu'il y ait des modules proposant de surfer avec un navigateur headless (phantomjs, firefox --headless, ou via Selenium..) ?
[^] # Re: Scanner "statique" : intérêt limité ?
Posté par devoop . Évalué à 3.
Il y a un code pour gérer le JS (savamment baptisé LameJS et qui porte bien son nom) capable d'extraire des infos des codes javascripts (arguments des fonctions, valeurs de variables, ça gère aussi la concaténation de chaines), le tout se base sur pynarcissus (un parseur qui permet d'obtenir un AST).
Il n'y a pas encore d'utilisation d'un navigateur headless mais ça peut être une solution alternative à un module agissant comme proxy interceptant (mentionné dans les commentaires sur ZAP).
Evidemment c'est + de ressources et + de dépendances pour le logiciel mais ça pourrait être optionnel.
# Dommage...
Posté par nimch . Évalué à -1.
Je voulais tester mais hébergé chez sourceforge… uMatrix est rouge de colère, pas envie de passer 1/4 heure à chercher quel truc il faut activer. À quand un dépôt git hébergé je ne sais où ? Dommage.
[^] # Re: Dommage...
Posté par steph1978 . Évalué à 2.
mauvais filtre, changer de filtre.
µBlock0 n'y voit rien à redire et je lui fais plutôt confiance.
[^] # Re: Dommage...
Posté par nimch . Évalué à 2.
Indépendamment des extensions de sécu, j'ai arrêté d'utiliser sourceforge à l'époque où ils proposaient des binaires modifiés discrètement (cf ici par exemple).
[^] # Re: Dommage...
Posté par steph1978 . Évalué à 2.
Je comprends. J'ai fait de même.
Maintenant, je crois que ça c'est calmé.
Le prochain evil sera sûrement github.
[^] # Re: Dommage...
Posté par nimch . Évalué à 1.
Peut-être… Pour mes besoins perso, j'ai opté pour un gogs sur un vps perso.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.