🛡️ Analyse de faille avec Nikto : exploitation et protection contre Shellshock via CGI

Introduction : pourquoi analyser les failles ?

Dans le monde de la cybersécurité, l’analyse de faille est un processus indispensable. Elle permet d’identifier et corriger les vulnérabilités avant qu’elles ne soient exploitées. Un attaquant n’a besoin que d’un seul point faible : à nous de le détecter avant lui.

Dans cet article, nous allons nous intéresser à une faille emblématique : Shellshock (CVE-2014-6271), qui a touché Bash en 2014. Nous verrons comment utiliser Nikto, un scanner de vulnérabilités web, pour la détecter, comment l’exploiter manuellement, et surtout comment s’en prémunir. Pour cela, il est essentiel de comprendre le rôle joué par CGI (Common Gateway Interface) dans l’exploitation.

🧠 CGI : le chaînon faible de Shellshock

Qu’est-ce que CGI ?

CGI (Common Gateway Interface) est une spécification permettant à un serveur web d’exécuter des programmes externes – appelés scripts CGI – pour générer dynamiquement des réponses HTTP. Ces scripts peuvent être écrits en Bash, Perl, Python, etc., et sont souvent utilisés dans des environnements anciens ou embarqués.

Fonctionnement général

Lorsqu’un utilisateur accède à un script CGI via le web :

1. Le serveur (ex. Apache) exécute le script comme processus système.

2. Il lui transmet les en-têtes HTTP sous forme de variables d’environnement (ex : User-Agent, Host, etc.).

3. Le corps de la requête est envoyé via stdin.

4. Le résultat du script est retourné au client comme une réponse HTTP.

C’est précisément le passage des variables d’environnement qui rend Shellshock si dangereuse dans ce contexte.

📜 Exemple de script CGI Bash vulnérable

bash
#!/bin/bash
echo "Content-type: text/plain"
echo
echo "Hello, world!"

Décryptage du script :

• #!/bin/bash : indique que le script sera interprété par Bash.

• echo "Content-type: text/plain" : définit le type MIME de la réponse HTTP.

• echo : une ligne vide obligatoire après les en-têtes HTTP.

• echo "Hello, world!" : le corps de la réponse, affiché dans le navigateur.

Ce script peut être appelé par un navigateur à l’adresse :
http://vulnerable-site.com/cgi-bin/test.sh

🐚 Shellshock (CVE-2014-6271) : la faille

La vulnérabilité Shellshock réside dans le fait que Bash exécute du code contenu dans les définitions de fonctions transmises via des variables d’environnement. C’est un comportement inattendu et dangereux.

Une requête HTTP malicieuse :

http
GET /cgi-bin/test.sh HTTP/1.1
Host: vulnerable-site.com
User-Agent: () { :; }; echo; /bin/bash -c 'echo shellshock exploited'

entraînera l’exécution de la commande "echo shellshock exploited" sur le serveur, sans vérification ni contrôle.

🔎 Détection avec Nikto

Nikto est un scanner open source de vulnérabilités web. Il teste des milliers de failles connues sur des serveurs HTTP. L’une de ses forces est sa capacité à détecter automatiquement des scripts CGI vulnérables à Shellshock.

bash
nikto -h http://vulnerable-site.com/cgi-bin/ -Tuning x

Explication des options principales :

• -h : hôte ou URL cible

• -Tuning x : active tous les types de tests (CGI, injection, XSS…)

• -output fichier.txt : exporte les résultats

• -evasion : tente de contourner des filtres ou WAF simples

• -Display V : n’affiche que les vulnérabilités confirmées

🧪 Exploitation manuelle de Shellshock

Un simple test curl peut suffire à démontrer une faille :

bash
curl -H 'User-Agent: () { :; }; echo Content-Type: text/plain; echo; echo HACKED' http://vulnerable-site.com/cgi-bin/test.sh

⚙️ Fonctionnement des variables CGI

Les scripts CGI récupèrent les données HTTP via des variables d’environnement, par exemple :

• REQUEST_METHOD (GET, POST…)

• HTTP_USER_AGENT, HTTP_COOKIE, etc.

• REMOTE_ADDR, SERVER_NAME…

Shellshock tire parti de ce mécanisme pour injecter des fonctions Bash contenant du code dans des en-têtes comme User-Agent.

---

🔐 Contre-mesures : comment se protéger

✅ 1. Mettre à jour Bash

La mise à jour de Bash corrige le comportement fondamental à l’origine de Shellshock : les versions vulnérables traitaient automatiquement certaines définitions de fonction comme du code à exécuter.

Une version corrigée ignore ou désactive totalement ce comportement.

bash
# Debian/Ubuntu
sudo apt update && sudo apt install --only-upgrade bash

# CentOS/RHEL
sudo yum update bash

⚠️ Sans cette mise à jour, aucune autre mesure ne suffit : même avec un WAF ou une surveillance, la faille peut toujours être exploitée.

✅ 2. Désactiver les CGI inutiles

Définition : un script CGI est "inutile" dès lors qu’il ne sert plus à une fonctionnalité en production. Cela inclut :

• Des scripts de test (test.sh, env.cgi)

• Des scripts hérités de vieilles applications

• Des démonstrations installées par défaut (souvent oubliées)

Ces scripts peuvent rester accessibles sans être visibles, et sont très fréquemment ciblés automatiquement par les attaquants.

bash
sudo a2dismod cgi
sudo systemctl restart apache2

✅ 3. Filtrage HTTP avec un WAF (Web Application Firewall)

Un WAF agit comme une barrière entre l’utilisateur et le serveur. Il inspecte chaque requête HTTP à la recherche de motifs suspects. Dans le cas de Shellshock, cela signifie bloquer les en-têtes qui contiennent des définitions de fonction suspectes dans des champs comme User-Agent.

Exemple de règle ModSecurity :

apache
SecRule REQUEST_HEADERS:User-Agent "^\(\)\s*{.*;.*}" \
    "id:1000001,phase:1,t:lowercase,deny,status:403,msg:'Shellshock attack detected'"

• Cette règle détecte les chaînes qui ressemblent à une déclaration de fonction Bash suivie d’une commande.

• Elle agit avant que le script CGI ne soit exécuté, ce qui est crucial en environnement vulnérable.

💡 Bien que les WAF ne soient pas infaillibles, ils sont efficaces contre des attaques automatiques ou basiques.

✅ 4. Surveillance active avec IDS

Un IDS (Intrusion Detection System) complète la défense en détectant les tentatives suspectes et en générant des alertes.

Exemples d’IDS compatibles :

• OSSEC : centralisé, léger, facile à intégrer à des logs Apache.

• Snort : puissant, très utilisé, signatures personnalisables.

• Suricata : similaire à Snort mais multithreadé.

Exemple de règle Snort (simplifiée) :

css
alert tcp any any -> any 80 (msg:"Shellshock attempt"; content:"() { :; };"; sid:1000002; rev:1;)

Grâce à ces outils, même si une faille est présente, vous saurez en temps réel qu’une attaque a été tentée, et pourrez réagir (blocage d’IP, audit, etc.).

🔧 Déploiement local d’un script CGI pour test

bash
sudo apt install apache2
sudo a2enmod cgi
sudo mkdir -p /usr/lib/cgi-bin

Fichier /usr/lib/cgi-bin/test.sh :

bash
#!/bin/bash
echo "Content-type: text/plain"
echo
echo "Hello from CGI!"

bash
chmod +x /usr/lib/cgi-bin/test.sh
sudo systemctl restart apache2

Accès :
http://localhost/cgi-bin/test.sh

Conclusion

Shellshock n’est pas une faille anecdotique. Elle a montré comment un simple en-tête HTTP peut suffire à prendre le contrôle d’un serveur mal configuré. Les scripts CGI, souvent oubliés ou laissés en place par habitude, sont des portes ouvertes.

Ce qu’il faut retenir :

• Nikto permet de détecter ces failles rapidement.

• La mise à jour de Bash est obligatoire : elle corrige le comportement vulnérable.

• Les CGI non utilisés doivent être désactivés.