juanschallibaum/cve-2024-38473-nuclei-templateModello Nuclei per rilevare server Apache vulnerabili a CVE-2024-38473
Template Nuclei progettato per rilevare server Apache vulnerabili a CVE-2024-38473. Identifica innanzitutto i server che eseguono Apache < 2.4.60 con impostazioni PHP-FPM predefinite. Successivamente, esegue fuzzing alla ricerca di potenziali file PHP protetti da ACL che potrebbero essere aggirati a causa di questa vulnerabilità.
Per utilizzare questo template Nuclei, devi clonare il repository. Puoi farlo eseguendo il seguente comando:
git clone https://github.com/juanschallibaum/CVE-2024-38473-Nuclei-Template
Spostati nella directory del repository clonato:
cd CVE-2024-38473-Nuclei-Template
Esegui il template Nuclei su un singolo host:
nuclei -t CVE-2024-38473.yaml -u http://example.com
Esegui il template Nuclei su un elenco di host:
nuclei -t CVE-2024-38473.yaml -l hosts.txt
Esegui il template Nuclei su un singolo host specificando un file .html o .php valido:
nuclei -t CVE-2024-38473.yaml -u http://example.com/valid.php
Eseguire Nuclei in questo modo può produrre un tasso di rilevamento più elevato. Puoi anche includere URL in questo formato nel file degli host per eseguire il template su tale elenco.
Per testare facilmente la vulnerabilità CVE-2024-38473, puoi impostare un ambiente vulnerabile usando Docker. Segui questi passaggi per verificare rapidamente l'efficacia del template Nuclei:
Assicurati che il Docker Daemon sia in esecuzione: assicurati che il daemon Docker sia in esecuzione sul tuo sistema. Puoi avviarlo con il seguente comando se non è già in esecuzione:
sudo systemctl start docker
Esegui il Container Docker: all'interno della directory del repository, usa il seguente comando Docker per avviare un container con una configurazione vulnerabile di Apache e PHP-FPM:
docker run -p 8787:80 -v "$(pwd)/test-env-webroot:/app" webdevops/php-apache:7.1
Testa la Vulnerabilità:
Manualmente: apri il tuo browser web e naviga su http://localhost:8787 per interagire con il server Apache in esecuzione nel container Docker. Accedi a http://localhost:8787/info.php per testare la vulnerabilità. Questo file è protetto da un ACL e, se il bypass dell'ACL ha successo, vedrai l'output di phpinfo():
Usando il Template Nuclei: esegui il seguente comando Nuclei per testare il server con il template:
nuclei -t CVE-2024-38473.yaml -u http://localhost:8787
L'8 agosto 2024, il ricercatore di sicurezza Orange Tsai ha tenuto una presentazione al Black Hat USA 2024 intitolata: Confusion Attacks: Exploiting Hidden Semantic Ambiguity in Apache HTTP Server!. In questa presentazione, ha riportato diverse vulnerabilità che interessano Apache HTTP Server. Ha spiegato che Apache ha un'architettura altamente modulare, composta da centinaia di moduli, ciascuno dei quali svolge la propria funzione mentre legge e scrive su una struttura condivisa chiamata request_rec, composta da quasi 100 campi.
La causa principale delle vulnerabilità riportate dal ricercatore di sicurezza risiede nell'incoerenza nel modo in cui i diversi moduli di Apache trattano i vari campi della struttura condivisa. Ad esempio, mod_authz_core tratta il campo r->filename come un file, mentre mod_proxy lo tratta come un URL, portando a discrepanze che determinano un'ampia gamma di vulnerabilità.
Nella sua presentazione, Orange Tsai definisce un tipo di attacco chiamato "Filename Confusion". Sebbene questo attacco abbia una superficie d'attacco variegata, CVE-2024-38473, che trattiamo in questo template, si riferisce a come possiamo applicare l'attacco "Filename Confusion" per bypassare le ACL di Apache e ottenere accesso a file ristretti.
Il problema sorge quando il modulo di autenticazione di Apache, mod_authz_core, tratta l'attributo r->filename come un file, mentre mod_proxy lo tratta come un URL. Per questo motivo, le installazioni Apache con PHP-FPM nella loro configurazione predefinita sono affette da questa vulnerabilità. Immagina che un server che esegue Apache e PHP-FPM abbia un'ACL configurata come la seguente per proteggere l'accesso al file admin.php con credenziali:
<Files "admin.php">
AuthType Basic
AuthName "Admin Panel"
AuthUserFile "/etc/apache2/.htpasswd"
Require valid-user
</Files>
A causa della vulnerabilità, è possibile bypassare ACL come quella sopra che implicano la protezione di un singolo file. In realtà, questo può essere fatto semplicemente inviando la seguente richiesta: http://server/admin.php%3fooo.php.
Per comprenderlo a fondo, è importante considerare che quando Apache elabora una richiesta come quella sopra, il modulo mod_authz_core legge il valore admin.php?fooo.php dal campo r->filename della struttura condivisa. Tratta questo valore come il nome del file richiesto e, quando lo confronta con l'ACL, non corrisponde perché admin.php?fooo.php è diverso da admin.php.
Quindi, poiché admin.php?fooo.php termina con .php, la richiesta viene gestita da PHP-FPM. PHP-FPM rimuove tutto ciò che segue ? nel nome file ricevuto da Apache prima di elaborarlo, trattandolo come un URL piuttosto che come un file. Di conseguenza, PHP-FPM elaborerà direttamente admin.php. Poiché il controllo ACL è stato superato in precedenza, l'attaccante può accedere a admin.php senza autenticazione.
Il template Nuclei attuale mira non solo a scoprire file protetti tramite forza bruta, ma include anche una logica per identificare quando un server ha una configurazione vulnerabile di Apache < 2.4.60 con PHP-FPM, anche se non vengono rilevati casi di file protetti da ACL. Nel flusso di base, tenta prima di identificare se il server ha una configurazione vulnerabile e, in caso affermativo, tenta di identificare file comuni che potrebbero essere protetti da ACL.
L'idea alla base del rilevamento di configurazioni vulnerabili con Apache < 2.4.60 e PHP-FPM si basa su due premesse fondamentali:
In una configurazione vulnerabile, se file.php esiste sul server, la richiesta a http://server/file.php%3fooo.php restituirebbe lo stesso codice di stato 200 e la stessa lunghezza del corpo della richiesta a http://server/file.php (perché dopo che PHP-FPM rimuove %3fooo.php, il file richiesto sarebbe lo stesso).
In una configurazione vulnerabile, se file.html esiste sul server, la richiesta a http://server/file.html%3fooo.php restituirebbe 403 Access Denied. Questo perché PHP-FPM tenterebbe di caricare un file con estensione .html invece di .php, che per impostazione predefinita non è consentito.
Il flusso del template consiste in 7 gruppi di richieste. Devono essere eseguite in ordine e devono soddisfare le rispettive condizioni di corrispondenza per procedere al gruppo successivo di richieste. Questo aiuta a minimizzare il numero di richieste inviate invano quando le condizioni sono già note come non soddisfatte.
Il template invia una richiesta a index.phpooo.php%3fooo.php, che è un file inesistente. L'idea è filtrare i falsi positivi nei casi in cui index.php%3fooo.php restituisce un codice di stato 200 e lo stesso corpo di index.php, anche quando PHP-FPM non è configurato. Questo potrebbe verificarsi, ad esempio, quando ci sono regole che riscrivono qualsiasi file richiesto o file che iniziano con "index" a index.php, come:
RewriteRule . /index.php [L]
RewriteRule ^index\.php(.*)$ index.php [L]
RewriteRule ^index(.*)$ index.php [L]
Questa richiesta dovrebbe restituire un codice di stato 200 se il server ha regole come quelle menzionate sopra, o un codice di stato 404 nei casi normali in cui PHP-FPM potrebbe essere configurato. Se questa richiesta non restituisce un codice di stato 404, il template interromperà l'elaborazione su questo host.
Il template invia una richiesta a foo.phpooo.php%3fooo.php che è un file inesistente. L'idea è filtrare i falsi positivi nei casi in cui index.html%3fooo.php restituisce un codice di stato 403, anche quando PHP-FPM non è configurato. Questo potrebbe verificarsi, ad esempio, quando ci sono regole che vietano il carattere %3f in qualsiasi punto dell'URL o che limitano l'accesso a file che terminano con .php. Esempi di tali regole includono:
<FilesMatch "\.php$">
Require all denied
</FilesMatch>
RewriteCond %{REQUEST_URI} (%3f)
RewriteRule ^(.*)$ - [F]
Questa richiesta dovrebbe restituire un codice di stato 403 se il server ha regole come quelle menzionate sopra, o un codice di stato 404 nei casi normali in cui PHP-FPM potrebbe essere configurato. Se questa richiesta non restituisce un codice di stato 404, il template interromperà l'elaborazione su questo host.
Il template invia richieste per identificare alcuni file disponibili sul server. Prima, tenta di identificare se index.php è disponibile. Poi, controlla index.html e index.htm. Infine, testa il file presente nell'URL fornito dall'utente, se esiste. Se Nuclei viene eseguito specificando un file valido nell'URL, può migliorare l'efficacia del rilevamento nei casi in cui i file index classici non esistono.
Il template invia una richiesta a un file inesistente per filtrare gli ultimi falsi positivi nei casi in cui index.php%3fooo.php restituisce un codice di stato 200 e lo stesso corpo di index.php, anche quando PHP-FPM non è configurato. Alcuni server web, specialmente quelli che non sono Apache, ignorano tutto ciò che segue %3f. Pertanto, se inviamo index.php%3fooo.php, il server lo tratta come index.php. Per filtrare questi casi, il template invia una richiesta a index.php%3fooo.html (se index.php è stato trovato sul server) o index.html%3fooo.html (se index.html è stato trovato sul server). Poiché termina con .html, nei casi normali in cui PHP-FPM potrebbe essere configurato, non verrebbe elaborato da PHP-FPM e verrebbe trattato come un file statico che logicamente non esiste, risultando in un codice di stato 404. Tuttavia, restituirebbe un codice di stato 200 nei casi che vogliamo filtrare, dove tutto ciò che segue %3f viene ignorato. Se questa richiesta non restituisce un codice di stato 404, il template interromperà l'elaborazione su questo host.
Il template invia una richiesta per identificare la configurazione vulnerabile. Ci sono 2 casi, di cui almeno una delle condizioni di corrispondenza deve essere soddisfatta:
Caso 1: In Richiesta #3, index.php è stato trovato. In questo caso, se Apache < 2.4.60 e PHP-FPM è abilitato con la configurazione predefinita, dovrebbe rimuovere la parte %3fooo.php e caricare index.php, risultando in una risposta 200 con la stessa lunghezza ottenuta nella Richiesta #3. Se viene usato mod_php o un altro handler, tratterebbe index.php%3fooo.php come nome file completo e restituirebbe un 404. Affinché questo caso corrisponda, la richiesta deve restituire 200 e un corpo con la stessa lunghezza della risposta della Richiesta #3.
Caso 2: In Richiesta #3, index.html è stato trovato. In questo caso, se Apache < 2.4.60 e PHP-FPM è abilitato con la configurazione predefinita, dovrebbe rimuovere la parte %3fooo.php e tentare di caricare index.html, che restituirebbe un 403 Access Denied, poiché PHP-FPM tenterebbe di caricare un file con un'estensione non consentita. Se viene usato mod_php o un altro handler, tratterebbe index.php%3fooo.php come nome file completo e restituirebbe un 404. Affinché questo caso corrisponda, la richiesta deve restituire 404.
Se il template è arrivato a questo punto, indica che il server ha una configurazione vulnerabile. Di conseguenza, il template invia richieste per eseguire fuzzing alla ricerca di potenziali file protetti che restituiscono un codice di stato 403 o che richiedono autenticazione e restituiscono un codice di stato 401. Per impostazione predefinita, tenta di identificare solo una manciata dei nomi di file più comuni e potenzialmente protetti. Tuttavia, puoi decommentare una riga per usare una wordlist personalizzata con 350 possibili nomi di file PHP.
Il template invia una richiesta per validare che il file protetto identificato nella Richiesta #6 restituisca un codice di stato 200 con il bypass.
Se viene soddisfatta una qualsiasi condizione di corrispondenza della Richiesta #5, indica che il server sta eseguendo Apache < 2.4.60 con impostazioni PHP-FPM predefinite. Ciò significa che se c'è un'ACL che protegge un singolo file, potrebbe essere aggirata. Tuttavia, molte volte queste configurazioni vulnerabili possono essere rilevate senza identificare alcun file protetto. Per impostazione predefinita, il template usa la wordlist wordlists/potential_protected_php_files_10.php per eseguire fuzzing sui file protetti. Questo elenco include i primi 10 nomi di file PHP più probabili da proteggere tramite ACL. In alternativa, è disponibile una wordlist più grande con 350 voci: wordlists/potential_protected_php_files_350.php. Per passare all'elenco più grande, commenta la wordlist da 10 voci e decommenta l'elenco da 350 voci nella sezione YAML della Richiesta #6 del template, come segue:
#fuzz: wordlists/potential_protected_php_files_10.txt
fuzz: wordlists/potential_protected_php_files_350.txt
L'uso della wordlist più grande può aumentare le possibilità di trovare file PHP protetti. Tuttavia, la wordlist potential_protected_php_files_350.txt può contenere nomi di file PHP non comuni e potrebbe non includere nomi di file PHP più comuni che potrebbero essere protetti da ACL. Pertanto, qualsiasi miglioramento o aggiunta alla wordlist è benvenuto. Inoltre, è possibile impiegare wordlist personalizzate ancora più grandi per un'esplorazione più approfondita.
Nota che le ACL aggirabili possono essere configurate per diversi virtual host, in file .htaccess in qualsiasi directory dell'applicazione, non solo nella directory root. Pertanto, per massimizzare la possibilità di identificare file protetti da ACL, si raccomanda di eseguire una ricognizione approfondita di directory e sottodomini, ed eseguire il template su tutti gli URL identificati con diversi sottodomini e directory.
Attualmente, il flusso della Richiesta #6 si ferma dopo aver identificato il primo file protetto da ACL. Tuttavia, potrebbero essercene altri. Questo accade perché non ho trovato un modo per eseguire fuzzing su più file con Nuclei, memorizzare i risultati e poi usarli in una richiesta successiva per verificare se il bypass concede effettivamente l'accesso ai file protetti. Pertanto, sono benvenuti anche suggerimenti su come il template possa essere modificato per identificare più file protetti e validare che siano effettivamente aggirabili.
Tutti i crediti per aver riportato le vulnerabilità e per aver condotto la ricerca eccezionale vanno a Orange Tsai. Il suo ampio lavoro sulle vulnerabilità di Apache HTTP Server, inclusa CVE-2024-38473, ha contribuito significativamente ad aumentare la consapevolezza della sicurezza. Io, Juan Schallibaum, sono responsabile esclusivamente della creazione di questo template Nuclei per facilitare il test e il rilevamento di CVE-2024-38473.
L'uso di questo template Nuclei per attaccare obiettivi senza previo consenso reciproco è illegale. È responsabilità dell'utente finale rispettare tutte le leggi locali, statali e federali applicabili. Gli sviluppatori non si assumono alcuna responsabilità per usi impropri, danni o conseguenze legali derivanti dall'uso di questo template. Assicurati sempre di avere il permesso esplicito prima di condurre qualsiasi test di sicurezza.