Wapiti — vérification des vulnérabilités du site par vos propres moyens

Dans le passé, article nous avons parlé de Nemesida WAF Free un outil gratuit pour protéger les sites web et les API contre les attaques de hackers, et dans cet article, nous avons décidé de faire un aperçu d'un scanner de vulnérabilités populaire Wapiti.

Le scan de vulnérabilités d'un site est une mesure nécessaire qui, couplée à l'analyse du code source, permet d'évaluer le niveau de sécurité face aux menaces de compromission. Le scan d'une ressource web peut être effectué à l'aide d'outils spécialisés.

Nikto, W3af (développé en Python 2.7, dont le support a pris fin) ou Arachni (qui n'est plus pris en charge depuis février) sont les solutions les plus populaires proposées dans le segment gratuit. Bien sûr, il existe d'autres solutions, comme Wapiti, sur laquelle nous avons décidé de nous concentrer.

Wapiti fonctionne avec les types de vulnérabilités suivants :

• divulgation de fichiers (locaux et distants, fopen, readfile);
• injections (injections PHP / JSP / ASP / SQL et XPath);
• XSS (cross-site scripting) (réfléchi et persistant);
• découverte et exécution de commandes (eval (), system (), passthru ());
• injections CRLF (séparation des réponses HTTP, fixation de session);
• XXE (injection d'entité externe XML);
• SSRF (falsification de requête côté serveur);
• utilisation de fichiers potentiellement dangereux connus (grâce à la base de données Nikto);
• configurations .htaccess faibles qui peuvent être contournées;
• présence de fichiers de sauvegarde révélant des informations sensibles (divulgation de code source);
• Shellshock;
• redirections ouvertes;
• méthodes HTTP non standards qui peuvent être autorisées (PUT).

Fonctionnalités :

• support des proxy HTTP, HTTPS et SOCKS5;
• authentification par plusieurs méthodes : Basique, Digest, Kerberos ou NTLM;
• possibilité de limiter la portée du scan (domaine, dossier, page, URL);
• suppression automatique d'un des paramètres de l'URL;
• mesures multiples de précaution contre les cycles infinis de scan (exemple : ifor, limitation des valeurs pour le paramètre);
• possibilité de définir une priorité pour explorer les URL (même si elles ne se trouvent pas dans la portée du scan);
• possibilité d'exclure certaines URL du scan et des attaques (par exemple : URL de déconnexion);
• importation de fichiers cookies (les obtenir à l'aide de l'outil wapiti-getcookie);
• possibilité d'activer / désactiver la vérification des certificats SSL;
• possibilité d'extraire des URL à partir de JavaScript (un interpréteur JS très simple);
• interaction avec HTML5;
• plusieurs options pour gérer le comportement et les restrictions du crawler ;
• définition d'un temps maximal pour le processus d'exploration ;
• ajout de certains en-têtes HTTP personnalisables ou configuration d'un User-Agent personnalisé.

Fonctionnalités supplémentaires :

• génération de rapports de vulnérabilités dans divers formats (HTML, XML, JSON, TXT) ;
• suspension et reprise des explorations ou attaques (mécanisme de session utilisant des bases de données SQLite3) ;
• mise en surbrillance dans le terminal pour signaler une vulnérabilité ;
• différents niveaux de journalisation ;
• une manière rapide et simple d'activer / désactiver les modules d'attaque.

Installation

La version actuelle de Wapiti peut être installée de 2 manières :

• télécharger la source depuis le site officiel site et exécuter le script d'installation, après avoir installé Python3 ;
• en utilisant la commande pip3 install wapiti3.

Après cela, Wapiti sera prêt à fonctionner.

Utilisation de l'outil

Pour démontrer le fonctionnement de Wapiti, nous utiliserons une plateforme préparée matches.vulns.pentestit.ru (ressource interne) contenant diverses vulnérabilités (Injection, XSS, LFI / RFI) et d'autres défauts des applications web.

Les informations sont fournies à titre d'exemple uniquement. Ne violez pas la législation !

Commande de base pour démarrer le scanner :

# wapiti -u <target> <options>

Il existe une documentation assez détaillée avec un grand nombre d'options de lancement, par exemple :

—scope — domaine d'application
Si le paramètre scope est spécifié en même temps que l'URL à explorer, il est possible de régler le périmètre d'exploration du site en précisant soit une page spécifique, soit toutes les pages pouvant être trouvées sur le site.

-s et -x — paramètres pour ajouter ou supprimer des URL spécifiques. Ces paramètres sont utiles lorsqu'il est nécessaire d'ajouter ou de retirer une URL spécifique du processus d'exploration.

—skip — la clé de ce paramètre sera scannée, mais ne sera pas attaquée. Utile s'il y a des paramètres dangereux à exclure lors de l'exploration.

—verify-ssl — activation ou désactivation de la vérification du certificat.
Le scanner Wapiti est modulaire. Cependant, pour exécuter des modules spécifiques parmi ceux qui sont automatiquement connectés lors de l'exécution du scanner, il faut utiliser la clé -m et énumérer ceux-ci séparément par des virgules. Si la clé n'est pas utilisée, tous les modules fonctionneront par défaut. Dans la version la plus simple, cela ressemblera à ce qui suit :

# wapiti -u http://sites.vulns.pentestit.ru/ -m sql,xss,xxe

Cet exemple d'utilisation signifie que nous n'utiliserons que les modules SQL, XSS et XXE lors du scan de la cible. En outre, il est possible de filtrer le fonctionnement des modules en fonction de la méthode requise. Par exemple -m "xss: get, blindsql: post, xxe: post". Dans ce cas, le module xss sera appliqué aux requêtes transmises par la méthode GET, tandis que le module blibdsql sera utilisé pour les requêtes POST, etc. D'ailleurs, si un module qui a été inclus dans la liste n'est pas nécessaire pendant le scan ou fonctionne très longtemps, en appuyant sur la combinaison Ctrl+C, il est possible de sauter l'utilisation du module actuel en choisissant l'option correspondante dans le menu interactif.

Wapiti prend en charge l'envoi de requêtes via un serveur proxy en utilisant la clé -p et l'authentification sur le site cible via le paramètre -a. Il est également possible d'indiquer le type d'authentification : Basiс, Digest, Kerberos et NTLM. Pour les deux derniers, des modules supplémentaires peuvent être requis. De plus, il est possible d'insérer dans les requêtes n'importe quel en-tête (y compris un User-Agent) et bien d'autres.

Pour utiliser l'authentification, on peut utiliser l'outil wapiti-getcookie. Avec lui, nous formons cookie, que Wapiti utilisera lors du scan. La formation cookie s'effectue à l'aide de la commande :

# wapiti-getcookie -u http://sites.vulns.pentestit.ru/login.php -c cookie.json

Pendant le fonctionnement en mode interactif, nous répondons aux questions et fournissons les informations nécessaires telles que : login, mot de passe, etc. :

En sortie, nous obtenons un fichier au format JSON. Une autre option est d'ajouter toutes les informations nécessaires via le paramètre -d:

# wapiti-getcookie - http://sites.vulns.pentestit.ru/login.php -c cookie.json -d "username=admin&password=admin&enter=submit"

Le résultat sera similaire :

En considérant la fonctionnalité principale du scanner, la requête finale pour le test de l'application web dans notre cas était :

# wapiti --level 1 -u http://sites.vulns.pentestit.ru/ -f html -o /tmp/vulns.html -m all --color -с cookie.json --scope folder --flush-session -A 'Pentestit Scans' -p http://proxy.office.pentestit.ru:3128

où, parmi d'autres paramètres :

-f et -o — le format et le chemin pour enregistrer le rapport ;

-m — connexion de tous les modules — non recommandé, car cela affectera le temps de test et la taille du rapport ;

—color — permet de surligner les vulnérabilités trouvées en fonction de leur criticité selon la version même de Wapiti ;

-c — utilisation d'un fichier avec cookie, généré à l'aide de wapiti-getcookie;

—scope — choix de la cible pour l'attaque. En choisissant cette option, dossier chaque URL sera scannée et attaquée, en commençant par la base. L'URL de base doit se terminer par un slash (sans le nom du fichier) ;

—flush-session — permet d'effectuer un scan répétitif où les résultats précédents ne seront pas pris en compte ;

-A — propre User-Agent;

-p — adresse du serveur proxy, si nécessaire.

Un peu sur le rapport

Le résultat du scan est présenté sous la forme d'un rapport détaillé sur toutes les vulnérabilités détectées au format de page HTML, de manière claire et compréhensible. Le rapport indiquera les catégories et le nombre de vulnérabilités trouvées, leur description, les requêtes, les commandes pour curl et des conseils sur la façon de les corriger. Pour faciliter la navigation, un lien sera ajouté aux titres des catégories, en cliquant sur lequel on pourra y accéder :

Un inconvénient majeur du rapport est l'absence d'une carte de l'application web, sans laquelle il ne sera pas possible de savoir si toutes les adresses et paramètres ont été analysés. Il existe également un risque de faux positifs. Dans notre cas, le rapport mentionne "fichiers de sauvegarde" et "fichiers potentiellement dangereux". Leur nombre ne correspond pas à la réalité, car il n'y avait pas de tels fichiers sur le serveur :

Il est possible que des modules qui ne fonctionnent pas correctement soient corrigés avec le temps. On peut aussi considérer comme un inconvénient du rapport l'absence de coloration des vulnérabilités trouvées (en fonction de leur criticité), ou au moins leur séparation par catégories. La seule façon dont nous pouvons indirectement comprendre la criticité d'une vulnérabilité trouvée est d'appliquer le paramètre —color lors du scan et alors les vulnérabilités détectées seront colorées de différentes couleurs :

Mais dans le rapport lui-même, une telle coloration n'est pas prévue.

Vulnérabilités

SQLi

Le scanner a partiellement réussi à détecter les SQLi. Lors de la recherche de vulnérabilités SQL sur des pages où aucune authentification n'est requise, il n'y a pas de problème :

Il n'a pas été possible de détecter la vulnérabilité sur des pages accessibles uniquement après authentification, même en utilisant des cookie, car probablement après une authentification réussie, il y aura une "déconnexion de leur session" et cookie deviendront invalides. Si la fonction de désauthentification avait été réalisée sous la forme d'un script distinct, en charge de cette procédure, elle aurait pu être complètement exclue par le paramètre -x, empêchant ainsi son activation. Dans le cas contraire, il ne sera pas possible d'exclure son traitement. Ce n'est pas un problème d'un module particulier, mais de l'outil dans son ensemble, mais à cause de ce détail, plusieurs injections n'ont pas pu être détectées dans la zone protégée de la ressource.

XSS

Avec la tâche définie, le scanner a bien réussi et a trouvé toutes les vulnérabilités préparées :

LFI/RFI

Le scanner a trouvé toutes les vulnérabilités intégrées :

Dans l'ensemble, malgré les faux positifs et les omissions de vulnérabilités, Wapiti, en tant qu'outil gratuit, montre des résultats de travail plutôt satisfaisants. Il convient de noter que le scanner est assez puissant, flexible et multifonctionnel, et surtout — gratuit, ce qui justifie son utilisation, aidant les administrateurs et les développeurs à obtenir des informations de base sur l'état de la sécurité de l'application web.

Restez en bonne santé et en sécurité !

Source : habr.com