CTF_WRITEUPS-TryHackMe-CVE-2021-41773-

CTF_WRITEUPS/TryHackMe /CVE-2021-41773/

CVE-2021-41773/42013

Una piccola spiegazione di un bug di path traversal di Apache e di una correzione incompleta

Task 1: Un po' di contesto...

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:

• Dalla prima parte, vediamo che una modifica recente ha esposto la falla. La normalizzazione dei percorsi significa che trasformiamo un percorso dato in una forma canonica che il software può comprendere, e quindi mapparlo al filesystem reale. Questo ci porta già a sospettare un attacco di path traversal che può potenzialmente leggere file non desiderati.
• La parte successiva conferma i nostri sospetti, e siamo in grado di usare un attacco di path traversal per leggere risorse al di fuori dello scopo previsto.
• Vediamo che è necessaria una configurazione molto particolare. I file al di fuori della document root devono avere i permessi concessi esplicitamente. Questa non è la configurazione predefinita e quindi dovrebbe rendere questo exploit inutile contro una larga percentuale di host Apache (per fortuna).
• La parte successiva parla di script CGI, il che erroneamente ci porta a credere che CGI debba essere abilitato perché l'attacco funzioni o che il percorso coinvolga in qualche modo CGI.
• Anche se la nostra configurazione non è direttamente affetta da questo bug, vorremo comunque aggiornare le versioni vulnerabili al più presto.

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 il primo exploit è stato apparentemente corretto, esiste un altro input che permette alla traversal di funzionare (ricordatelo per dopo).
• Ora siamo limitati alle direttive di percorso alias.
• Le directory al di fuori dei percorsi abituali richiedono ancora che vengano concessi permessi espliciti.
• Se CGI è abilitato, possiamo ottenere RCE oltre alla semplice divulgazione 😲

Mentre elaboriamo questa follia, esamineremo la configurazione richiesta nel prossimo task.

Rispondi alle domande qui sotto

1. Quale versione di Apache httpd era inizialmente vulnerabile a questo CVE?

• 2.4.49

2. Questa vulnerabilità richiede una misconfigurazione inusuale per essere sfruttabile (Sì/No)

• Sì

---

Task 2 Cos'è il Path Traversal comunque?

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

1. Un exploit di path traversal (scegli la risposta migliore):

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.

• C

2. Codifica in URL il simbolo .

• %2E

3. A cosa decodifica questo frammento di URL: %%32%65 ?

• %2E

---

Task 3 Ok, Ok; Dacci gli Hax!

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**