Introduction
Gobuster est un outil puissant utilisé pour le brute-force de répertoires et de fichiers, le brute-force de sous-domaines DNS et l'énumération de buckets S3. Lors de l'exécution d'opérations de fuzzing, en particulier contre des serveurs web, il est courant de rencontrer un grand nombre de résultats "bruyants". Ceux-ci incluent souvent des réponses pour des chemins inexistants qui renvoient un code d'état HTTP cohérent (par exemple, 404 Not Found) et, surtout, une longueur de corps de réponse cohérente. Cela peut encombrer la sortie et rendre difficile l'identification des découvertes légitimes.
Dans ce laboratoire, vous apprendrez à utiliser le drapeau --exclude-length de Gobuster en mode fuzz. Cette fonctionnalité vous permet de spécifier une ou plusieurs longueurs de corps de réponse à ignorer, filtrant ainsi efficacement ces résultats bruyants. À la fin de ce laboratoire, vous serez en mesure d'effectuer des scans de fuzzing plus ciblés et efficaces, en vous concentrant uniquement sur les réponses pertinentes.
Lancer un scan de fuzzing et identifier une taille de réponse commune pour les requêtes invalides
Dans cette étape, vous allez effectuer un scan de fuzzing Gobuster initial contre un serveur web local. Cela vous aidera à observer la sortie typique, en particulier les tailles de réponse pour les chemins inexistants, qui représentent souvent des résultats "bruyants".
Tout d'abord, assurez-vous que le serveur web est en cours d'exécution. Vous pouvez vérifier si le processus est actif :
ps aux | grep "python3 -m http.server 8000" | grep -v grep
Vous devriez voir une sortie similaire à celle-ci, indiquant que le serveur est en cours d'exécution :
labex 1234 0.0 0.0 12345 6789 ? Sl HH:MM 0:00 python3 -m http.server 8000 --directory /tmp/web_root
Maintenant, lancez un scan de fuzzing Gobuster en utilisant la liste de mots créée lors de la configuration. Nous ciblerons http://127.0.0.1:8000.
gobuster fuzz -u http://127.0.0.1:8000/FUZZ -w /tmp/wordlist.txt
Observez la sortie. Vous remarquerez plusieurs entrées avec le même code d'état (par exemple, 404) et, plus important encore, la même taille. Cette taille cohérente pour les requêtes invalides est ce que nous allons cibler pour l'exclusion. Par exemple, nonexistentpath123 et anothernonexistentpath devraient afficher la même taille.
/index.html (Status: 200) [Size: 19]
/admin (Status: 404) [Size: 19]
/login (Status: 404) [Size: 19]
/config (Status: 404) [Size: 19]
/robots.txt (Status: 404) [Size: 19]
/nonexistentpath123 (Status: 404) [Size: 19]
/anothernonexistentpath (Status: 404) [Size: 19]
À partir de la sortie, identifiez la taille de réponse commune pour les erreurs 404 (Not Found). Dans cet exemple, c'est 19. C'est la taille que nous utiliserons pour filtrer le bruit dans l'étape suivante.
Relancer le scan en utilisant le drapeau --exclude-length avec la taille identifiée
Dans cette étape, vous allez relancer le scan Gobuster, mais cette fois vous utiliserez le drapeau --exclude-length pour filtrer les résultats bruyants en fonction de la taille de réponse que vous avez identifiée à l'étape précédente.
Rappelez-vous la taille de réponse commune pour les erreurs 404 de l'étape précédente. Dans notre exemple, c'était 19. Maintenant, ajoutez --exclude-length 19 à votre commande Gobuster :
gobuster fuzz -u http://127.0.0.1:8000/FUZZ -w /tmp/wordlist.txt --exclude-length 19
Exécutez la commande et observez la sortie.
Observer comment les résultats bruyants sont filtrés
Après avoir exécuté la commande de l'étape précédente, vous devriez immédiatement remarquer une différence significative dans la sortie. Les entrées correspondant à la taille exclue (par exemple, les réponses 404 avec une taille de 19) ne devraient plus apparaître.
Comparez la sortie de ce scan avec la sortie de l'Étape 1.
Sortie attendue :
/index.html (Status: 200) [Size: 19]
Vous ne devriez voir que l'entrée /index.html, car c'est la seule qui a renvoyé un statut 200 OK avec une longueur de contenu différente (bien que dans cette configuration spécifique, la page 404 ait également une taille de 19, ce qui est une limitation de notre serveur simple. Dans un scénario réel, les pages 404 ont souvent une taille distincte de celle des pages valides). L'essentiel est que toute réponse avec la taille spécifiée est maintenant filtrée.
Cela démontre l'efficacité avec laquelle le drapeau --exclude-length peut réduire le bruit, vous permettant de vous concentrer sur des découvertes potentiellement intéressantes.
Affiner l'exclusion avec une liste de tailles séparées par des virgules
Parfois, un serveur web peut renvoyer différentes tailles de réponse pour divers types de requêtes "non trouvées" ou "invalides". Gobuster vous permet d'exclure plusieurs tailles en fournissant une liste séparée par des virgules au drapeau --exclude-length.
Pour démontrer cela, imaginons que notre serveur puisse renvoyer des pages 404 avec des tailles de 19 et 50. Nous allons simuler cela en ajoutant un autre chemin "valide" qui renvoie une taille différente.
Tout d'abord, ajoutons un nouveau fichier à notre racine web avec une taille différente :
echo "This is a test page with a different length." > /tmp/web_root/testpage.html
Maintenant, ajoutons testpage.html à notre liste de mots :
echo "testpage.html" >> /tmp/wordlist.txt
Exécutez à nouveau le scan, mais cette fois, supposons que nous voulions exclure à la fois 19 et 39 (la taille de testpage.html est de 39).
gobuster fuzz -u http://127.0.0.1:8000/FUZZ -w /tmp/wordlist.txt --exclude-length 19,39
Observez la sortie. Vous devriez voir que les réponses 404 d'origine (taille 19) et la réponse testpage.html (taille 39) sont maintenant exclues.
Analyser la sortie nettoyée pour des découvertes intéressantes
Dans cette dernière étape, vous analyserez la sortie nettoyée produite en utilisant le drapeau --exclude-length. L'objectif est de comprendre comment ce filtrage aide à identifier les découvertes réellement intéressantes lors d'une opération de fuzzing.
Après avoir exécuté la commande de l'étape précédente, la sortie devrait être encore plus concise. S'il y avait d'autres chemins dans votre liste de mots qui renvoyaient un code de statut et une longueur non présents dans votre liste d'exclusion, ils ressortiraient maintenant.
Par exemple, si vous aviez un chemin comme /secret_admin_panel qui renvoyait un 200 OK avec une longueur unique, il serait clairement visible dans la sortie filtrée, alors qu'il aurait pu se perdre parmi des centaines de 404 dans un scan non filtré.
Dans notre configuration actuelle, avec 19 et 39 exclus, et index.html ayant une longueur de 19, la sortie devrait être vide, car toutes les entrées sont maintenant exclues. Cela démontre la puissance d'un filtrage précis.
Cette technique est inestimable dans les tests d'intrusion et la chasse aux bugs dans le monde réel, où de grandes listes de mots peuvent générer une quantité écrasante de données non pertinentes. En excluant systématiquement les longueurs de "bruit" courantes, vous pouvez réduire considérablement l'effort manuel requis pour examiner les résultats des scans et augmenter vos chances de découvrir des répertoires ou des fichiers cachés.
Pour nettoyer l'environnement, vous pouvez arrêter le serveur web Python :
kill $(cat /tmp/web_server_pid)
Ceci conclut le laboratoire. Vous avez appris avec succès comment utiliser le drapeau --exclude-length de Gobuster pour affiner vos scans de fuzzing.
Résumé
Dans ce laboratoire, vous avez acquis une expérience pratique de l'utilisation du drapeau --exclude-length de Gobuster en mode fuzzing. Vous avez commencé par effectuer un scan initial pour identifier les tailles de réponse courantes pour les requêtes invalides, qui représentent souvent du bruit. Ensuite, vous avez appris à utiliser le drapeau --exclude-length avec une seule taille pour filtrer ces résultats non pertinents, ce qui a conduit à une sortie plus propre. Enfin, vous avez exploré comment affiner davantage l'exclusion en fournissant une liste de tailles séparées par des virgules, démontrant ainsi sa flexibilité dans la gestion de divers types de réponses bruyantes.
En maîtrisant cette technique, vous pouvez améliorer considérablement l'efficacité et la pertinence de vos opérations de fuzzing d'applications web, vous permettant de vous concentrer sur les découvertes réellement intéressantes et d'accélérer votre processus de découverte de vulnérabilités.