Utiliser un proxy pour le scan avec Nikto

Introduction

Nikto est un scanner de serveurs web open-source populaire qui effectue des tests complets sur les serveurs web pour plusieurs éléments, notamment plus de 6700 fichiers/programmes potentiellement dangereux, des vérifications de versions obsolètes pour plus de 1250 serveurs, et des problèmes spécifiques à la version sur plus de 270 serveurs.

Un proxy, dans ce contexte, est un serveur intermédiaire qui se situe entre votre outil (Nikto) et le serveur cible. Des outils tels que Burp Suite, OWASP ZAP, ou mitmproxy sont couramment utilisés à cette fin. Acheminer le trafic de Nikto via un proxy est une technique puissante pour les professionnels de la sécurité. Elle vous permet de voir exactement quelles requêtes le scanner envoie et quelles réponses il reçoit. Ceci est inestimable pour le débogage des scans, la compréhension du comportement d'un scanner, et même la modification du trafic à la volée pour contourner les mesures de sécurité.

Dans ce laboratoire, vous apprendrez comment configurer un proxy local, comment configurer Nikto pour l'utiliser, comment exécuter un scan et comment analyser le trafic intercepté. Nous utiliserons mitmproxy comme notre proxy et un simple serveur web Python local comme notre cible.

Configuration d'un proxy local comme Burp Suite ou OWASP ZAP

Dans cette étape, vous allez démarrer un serveur web simple qui servira de cible pour notre scan, puis démarrer mitmproxy, un proxy léger en ligne de commande, pour intercepter notre trafic. Toutes les opérations seront effectuées dans le terminal.

Tout d'abord, démarrons un serveur web Python de base. Ce serveur hébergera un simple fichier index.html de notre répertoire actuel, ~/project. Nous le lancerons sur le port 8000 en arrière-plan afin de pouvoir continuer à utiliser le même terminal.

Exécutez la commande suivante :

python3 -m http.server 8000 &

Le & à la fin de la commande exécute le processus en arrière-plan. Vous devriez voir une sortie indiquant l'ID du processus.

Ensuite, démarrons notre proxy. Nous utiliserons mitmweb, qui est l'interface web de mitmproxy. Cela offre un moyen convivial de visualiser le trafic capturé. Il écoute le trafic proxy sur le port 8080 par défaut et sert son interface web sur le port 8081.

Exécutez la commande suivante pour démarrer mitmweb, également en arrière-plan :

mitmweb --web-host 0.0.0.0 &

Vous verrez une sortie lors du démarrage de mitmweb. Vous avez maintenant un serveur cible fonctionnant sur le port 8000 et un proxy fonctionnant sur le port 8080. Vous pouvez visualiser le trafic du proxy en ouvrant un navigateur dans l'environnement du laboratoire et en naviguant vers http://127.0.0.1:8081. Pour l'instant, il sera vide.

Configuration de Nikto pour utiliser le proxy avec -useproxy

Dans cette étape, vous apprendrez comment indiquer à Nikto d'envoyer son trafic via l'instance mitmproxy que nous venons de démarrer. Nikto dispose d'une option de ligne de commande dédiée, -useproxy, à cet effet.

La syntaxe de cette option est -useproxy http://<proxy_host>:<proxy_port>. Comme notre mitmproxy fonctionne sur la machine locale (127.0.0.1) sur le port 8080, l'URL correcte sera http://127.0.0.1:8080.

Avant d'exécuter un scan complet, effectuons un test simple pour nous assurer que Nikto peut se connecter au serveur cible via le proxy. Nous utiliserons l'option -Plugins '@@NONE', qui demande à Nikto de se connecter et d'afficher la bannière du serveur, mais de ne pas exécuter de tests de vulnérabilité. C'est un moyen rapide et efficace de vérifier notre configuration de proxy.

Exécutez la commande suivante dans votre terminal :

nikto -h 127.0.0.1 -p 8000 -useproxy http://127.0.0.1:8080 -Plugins '@@NONE'

Vous devriez voir une sortie similaire à celle-ci, affichant la bannière de Nikto et des informations sur le serveur cible :

- Nikto v2.x.x
---------------------------------------------------------------------------
+ Target IP:          127.0.0.1
+ Target Hostname:    127.0.0.1
+ Target Port:        8000
+ Start Time:         ...
---------------------------------------------------------------------------
+ Server: SimpleHTTP/0.6 Python/3.10.6
+ END TIME:           ...
---------------------------------------------------------------------------
+ 1 host(s) tested

Maintenant, si vous vérifiez l'interface mitmweb dans votre navigateur à l'adresse http://127.0.0.1:8081, vous verrez la première requête capturée provenant de Nikto. Cela confirme que la configuration du proxy fonctionne correctement.

Exécution d'un scan dirigé via le proxy configuré

Dans cette étape, la configuration du proxy étant vérifiée, vous allez maintenant effectuer un scan de vulnérabilité réel avec Nikto. Cela générera une quantité significative de trafic, dont tout sera acheminé et enregistré par mitmproxy.

Afin de maintenir un temps de scan raisonnable pour ce laboratoire, nous utiliserons l'option -Tuning 1. L'option de tuning dans Nikto contrôle les types de tests effectués. -Tuning 1 se concentre sur les vérifications "Fichier intéressant / Vu dans le log" (Interesting File / Seen in Log), ce qui constitue un bon point de départ.

Exécutez la commande suivante pour lancer le scan :

nikto -h 127.0.0.1 -p 8000 -useproxy http://127.0.0.1:8080 -Tuning 1

Nikto va maintenant commencer à scanner le serveur cible. Vous verrez sa progression et les éventuelles découvertes directement dans votre terminal. La sortie pourrait ressembler à ceci, en fonction des découvertes :

- Nikto v2.x.x
---------------------------------------------------------------------------
+ Target IP:          127.0.0.1
+ Target Hostname:    127.0.0.1
+ Target Port:        8000
+ Start Time:         ...
---------------------------------------------------------------------------
+ Server: SimpleHTTP/0.6 Python/3.10.6
+ The anti-clickjacking X-Frame-Options header is not present.
+ The X-XSS-Protection header is not defined. This header can hint to the user agent to protect against some forms of XSS
+ The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type
...
+ /: The server returns the following message when a request for a non-existent page is made: b'<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"\n        "http://www.w3.org/TR/html4/strict.dtd">\n<html>\n    <head>\n        <meta http-equiv="Content-Type" content="text/html;charset=utf-8">\n        <title>Error response</title>\n    </head>\n    <body>\n        <h1>Error response</h1>\n        <p>Error code: 404.</p>\n        <p>Message: File not found.</p>\n        <p>Error code explanation: 404 - Nothing matches the given URI.</p>\n    </body>\n</html>'
...
+ END TIME:           ...
---------------------------------------------------------------------------
+ 1 host(s) tested

Pendant que le scan s'exécute, vous pouvez basculer vers l'onglet du navigateur mitmweb et observer les requêtes apparaître en temps réel.

Observation du trafic Nikto dans l'historique HTTP du proxy

Dans cette étape, vous allez vous concentrer sur l'analyse du trafic capturé par mitmproxy. C'est là que la véritable valeur de l'utilisation d'un proxy devient évidente. Aucune nouvelle commande n'est nécessaire pour cette étape ; vous utiliserez l'interface mitmweb dans votre navigateur.

Accédez à l'onglet du navigateur exécutant mitmweb à l'adresse http://127.0.0.1:8081. Vous devriez voir une longue liste de requêtes web. Chaque entrée de cette liste correspond à un test spécifique que Nikto a effectué sur le serveur cible.

Cliquez sur l'une des requêtes dans la liste de gauche. Le panneau de droite se mettra à jour pour afficher les détails de cette requête spécifique et sa réponse correspondante.

Explorez l'interface :

Onglet Request (Requête) : Ici, vous pouvez voir la requête HTTP exacte envoyée par Nikto. Portez attention à :
- La ligne de requête (par exemple, GET /some/test/file.html HTTP/1.1).
- L'en-tête Host, qui pointe vers notre serveur cible.
- L'en-tête User-Agent, qui identifiera le client comme Nikto.
Onglet Response (Réponse) : Cet onglet affiche la réponse complète du serveur. Vous pouvez voir le code d'état HTTP (par exemple, 200 OK ou 404 Not Found), les en-têtes de réponse et le corps de la réponse.

Prenez quelques minutes pour cliquer sur différentes requêtes. Vous verrez Nikto essayer d'accéder à des répertoires administratifs courants (comme /admin/), vérifier des fichiers de sauvegarde (comme /index.html.bak), et effectuer d'autres vérifications standard. En observant ce trafic, vous acquerrez une compréhension approfondie du fonctionnement d'un scanner de vulnérabilités.

Analyse de l'impact du proxy sur les résultats du scan

Dans cette étape, vous allez analyser comment l'utilisation d'un proxy peut potentiellement affecter un scan. Pour ce faire, vous avez besoin d'une référence pour comparaison. Vous allez exécuter à nouveau le même scan Nikto, mais cette fois-ci sans le proxy.

Exécutez la même commande de scan que lors de l'étape 3, mais omettez l'option -useproxy :

nikto -h 127.0.0.1 -p 8000 -Tuning 1

Observez la sortie dans votre terminal. Comparez maintenant les résultats de ce scan avec ceux du scan proxifié de l'étape 3. Dans notre environnement de laboratoire simple, sans pare-feu ni autres systèmes de sécurité en place, les résultats devraient être identiques.

Alors, quel est l'intérêt du proxy ?

Visibilité (Débogage) : Comme vous l'avez vu à l'étape précédente, le principal avantage est la visibilité. Si un scan échouait ou produisait des résultats inattendus, le proxy serait le premier endroit à consulter pour comprendre ce qui ne va pas. Vous pouvez voir les requêtes et réponses brutes, ce qui est essentiel pour le dépannage.
Performance : Un proxy ajoute un "saut" supplémentaire pour le trafic réseau, ce qui peut introduire une légère latence. Pour des scans très volumineux, cela pourrait légèrement augmenter le temps total du scan.
Modification (Avancé) : Les proxies avancés peuvent être configurés pour modifier le trafic. Par exemple, vous pourriez définir une règle pour changer automatiquement le User-Agent de "Nikto" à une chaîne de navigateur courante. Cela pourrait être utilisé pour contourner un pare-feu d'applications web (WAF) simple qui bloque les requêtes basées sur l'agent utilisateur Nikto. Bien que nous n'effectuions pas de modification dans ce laboratoire, comprendre cette capacité est essentiel.

En résumé, pour ce laboratoire, l'effet principal du proxy a été de vous donner une vue "man-in-the-middle" du processus de scan, ce qui est une compétence fondamentale pour les tests de sécurité.

Résumé

Dans ce laboratoire, vous avez appris avec succès comment utiliser un proxy lors de l'exécution d'un scan de vulnérabilités web avec Nikto.

Vous avez commencé par configurer l'environnement nécessaire, y compris un serveur web Python simple comme cible et mitmproxy comme proxy d'interception. Vous avez ensuite appris à utiliser l'option de ligne de commande -useproxy de Nikto pour router tout son trafic de scan à travers le proxy.

En exécutant un scan et en observant le trafic dans l'interface mitmweb, vous avez obtenu un aperçu direct des types de requêtes que Nikto envoie et des réponses qu'il reçoit. Enfin, en exécutant un scan comparatif sans le proxy, vous avez analysé comment un proxy peut affecter un scan, concluant que son rôle principal dans ce contexte est de fournir une visibilité critique pour l'analyse et le débogage. Il s'agit d'une technique fondamentale utilisée par les professionnels de la sécurité pour mieux comprendre et contrôler leurs outils de test.