Introduzione
Le vulnerabilità di File Inclusion si verificano solitamente quando un’applicazione utilizza un input utente per leggere file senza prima sanificarlo. In generale, le vulnerabilità di File Inclusion consentono a un utente malintenzionato di leggere ed eseguire file arbitrari sul server remoto. Mentre se esiste solo la possibilità di lettura di file arbitrari si parla di Path Traversal. Esistono due tipi diversi di File Inclusion:
- Local File Inclusion (LFI)
- Remote File Inclusion (RFI)
Nel primo caso (LFI) un aggressore può leggere/eseguire file locali memorizzati sul sistema vulnerabile, nel secondo (RFI) un aggressore è in grado di leggere/eseguire file memorizzati su un sistema remoto arbitrario e che quindi potrebbe anche essere controllato dall’aggressore.
Un esempio di applicazione vulnerabile
Per comprendere meglio le vulnerabilità di LFI e RFI useremo una semplice applicazione web vulnerabile, scritta in php, come esempio. Diamo un’occhiata al codice:
Il sorgente è piuttosto semplice ed è stato anche sottolineato il punto vulnerabile. L’applicazione si limita a verificare se il parametro page è impostato, in caso la condizione risulti vera, allora l’applicazione utilizza questo parametro all’interno del costrutto include, altrimenti l’applicazione include semplicemente il file home.php.
L’espressione include copia il contenuto del file specificato all’interno dello script che utilizza l’istruzione include, prima che lo script venga effettivamente valutato/eseguito. Si possono leggere ulteriori informazioni sull’include ai seguenti link:
- https://www.w3schools.com/php/php_includes.asp
- https://www.php.net/manual/en/function.include.php
Exploitation
Vediamo ora come è possibile sfruttare l’applicazione vulnerabile per leggere file sensibili o eseguire codice arbitrario. Per dimostrare l’impatto del problema, creiamo una cartella protetta da password denominata secret. Nell’immagine seguente è possibile osservare la struttura delle directory dell’applicazione web.
Se si naviga la pagina principale senza inserire il parametro page, il sito appare così.
Proviamo ora ad accedere alla cartella secret.
Osserviamo che il server richiede un’autenticazione per poter visitare la cartella secret. Impostiamo il parametro page con un file accessibile/leggibile e osserviamo il comportamento dell’applicazione. Poiché stiamo eseguendo i test in ambiente Windows, utilizziamo il file win.ini come PoC.
Come possiamo notare, l’applicazione restituisce il contenuto del file win.ini come previsto.
Il Web Server Apache, sul quale stiamo eseguendo i test, gestisce la cartella protetta con un file di configurazione solitamente chiamato .htaccess; tale file si trova nella cartella secret, proviamo a leggerlo!
Ha funzionato a meraviglia e possiamo anche notare che all’interno è contenuta l’informazione su dove si trova il file di autorizzazione, in questo caso nella cartella C:\xampp\ con il nome .htpasswd. Proviamo ora a estrarre il contenuto di questo file.
Ora che conosciamo il contenuto del file .htpasswd, possiamo tentare un attacco a dizionario per ottenere le credenziali.
Come è possibile notare dagli screenshot sopra, l’attacco a dizionario è riuscito. A questo punto non resta che accedere alla cartella protetta utilizzando la password appena ottenuta.
Abbiamo analizzato un semplice caso di studio che rappresenta un esempio di come è possibile sfruttare una vulnerabilità di LFI per leggere file arbitrari sul file system remoto. Adesso proviamo a includere contenuti di file remoti. Per verificare la presenza di RFI, utilizzeremo un semplice server python per esporre un file contenente codice php.
Di seguito il contenuto del file che il server python restituisce.
Come si può notare, si tratta di una php webshell che un aggressore può utilizzare per eseguire comandi arbitrari sul sistema vulnerabile.
Usando questo payload http://localhost:4444/exploit.txt e avviando il nostro server su localhost, porta 4444, siamo in grado di includere il file remoto.
Utilizzando il payload menzionato, è possibile osservare la richiesta al nostro server da parte dell’applicazione vulnerabile.
Inoltre è possibile eseguire comandi arbitrari utilizzando il parametro cmd, come mostra l’immagine seguente.
La possibilità di includere file remoti in un ambiente php dipende dal file di configurazione php.ini, in particolare è possibile includere file remoti quando l’impostazione allow_url_include è impostato ad On (di default è settato ad Off). Di seguito uno screenshot che mostra il nostro file php.ini.
Conclusioni
In questo articolo abbiamo voluto presentare un semplice caso di studio per far comprendere quando si verifica una vulnerabilità di File Inclusion e come può essere sfruttata. Come spesso accade, questa tipo di vulnerabilità, è dovuta ad un input utente che non viene adeguatamente controllato prima di essere utilizzato in costrutti o funzioni che hanno a che fare con la lettura di file. Di conseguenza è molto importante la sanificazione di tale input per evitare scenari dove un attaccante potrebbe compromettere l’intero ambiente.