Local File Inclusion

L’impatto di questa tipologia di vulnerabilità può dipendere dai permessi che possiede l’utente, in quanto, non tutti i file sono accessibili se non si possiedono privilegi adeguati. Solitamente gli impatti riguardano l’acquisizioni di informazioni di questo tipo:

1. Acquisizione di informazioni tecniche del sistema
2. Acquisizione di credenziali e/o di chiavi SSH
3. Acquisizione di dati personali/sensibili
4. Acquisizione di log

È evidente, quindi, che l’impatto dipende anche da quante e quali informazioni sono contenute nel server vulnerabile.

Poichè non esistono delle vere e proprie tipologie di attacco LFI, possiamo differenziare due “metodologie” principali: queste dipendono da come è stata scritta la funzione vulnerabile del codice che andremo a sfruttare:

1. Il classico metodo richiedendo il file con il percorso assoluto all’interno del server.
2. Il “Directory Traversal” andando a ritroso nelle cartelle locali in cui siamo attualmente.

Nel primo modo, infatti, ci basterà inserire il percorso completo del file partendo dalla cartella “root” (per sistemi *nix: “/”; per sistemi windwos: “C:”), quindi, facendo un esempio più pratico:

paginavulnerabile.php?parametrovulnerabile=/etc/

o, in caso fossimo su un sitema operativo windows:

paginavulnerabile.php?parametrovulnerabile=C:Windowswin.ini

Invece, nel secondo caso, quando la funzione vulnerabile richiede un file locale in modo “relativo”:

paginavulnerabile.php?parametrovulnerabile=../../../etc/passwd

o

paginavulnerabile.php?parametrovulnerabile=......C:Windowswin.ini

Quest’ultima tipologia di attacco si chiama “Path Traversal” o “Directory Traversal” in cui con i caratteri “../” o “..” si comunica alla funzione di andare a ritroso nelle directory locali, quindi, per il funzionamento dell’attacco, bisognerà inserire tanti “../” quante (o più) directories si vuole arretrare, in modo da tornare nella “root” (come in questo esempio) del server ed aggiungere il percorso del file che si vuole visualizzare.

A volte vengono attuate delle metodologie di difesa in modo superficiale: queste si basano su un parsing basilare dell’input, dove i caratteri per eseguire il path traversal (quindi “/” o “..”) vengono sanificati o sostituiti con altri caratteri in maniera tale che il server possa gestirgli e quindi non “innescare” la vulnerabilità. Uno dei metodi per bypassare questa difesa è la codifica URL dei caratteri, per fare un esempio più pratico: “..%2F..%2F..%2F..%2F” è la codifica di: “../../../../”. Un esempio di tale vulnerabilità la si può riscontrare nella LFI a cui il web server Apache v. 2.4.49 era vulnerabile (trovate il nostro articolo qui).

Un’altra di queste metodologie di bypass è quella di utilizzare i cosiddetti “escapers“: questi sono dei caratteri “particolari” che, in molti linguaggi di programmazione, se inseriti prima di un carattere, vengono interpretati in modo diverso, e quindi, aggirando il filtro di validazione; uno dei classici escaper utilizzati per il directory traversal è il backslash (). Di seguito un esempio pratico:

Molto spesso, è possibile che la vulnerabilità LFI nasconda un’altra vulnerabilità di tipo Remote Code Execution: in questo caso, è possibile – ad esempio – terminare manualmente la funzione vulnerabile tramite l’inserimento di caratteri come l’apice (‘), doppio apice (“), parentesi chiusa ()), etc. 

1. 1. Il classico esempio di LFI di un parametro vulnerabile, infatti, come sarà rappresentato nella gif sottostante, è quello di sfruttare un parametro in GET vulnerabile in cui andremo ad eseguire la richiesta del file direttamente, in questo caso andremo a prendere il file “/etc/passwd” del server (linux), in cui sono contenuti gli utenti del server:
2.  

1. 1. Come si può vedere dalla GIF, il parametro in GET vulnerabile fa una richiesta diretta del file locale; nel momento in cui viene eseguita la richiesta, nel riquadro sottostante, si può vedere il contenuto del file richiesto.
   2. Nel secondo caso invece, andremo a sfruttare il così detto “Directory Traversal“, questa volta su un parametro in POST e per comodità useremo un proxy:

Come si vede dalla GIF, prima di tutto, abbiamo effettuato una richiesta per verificare come viene processata dal server, in questo caso, abbiamo usato un proxy per intercettare e manomettere la richiesta modificando il valore del parametro “file” tramesso in POST inserendo il payload formato da molteplici “../” in modo da indicare al server vulnerabile di arretrare nelle directory locali ed andare a leggere il file /etc/passwd, posizionato nella root (/).

1. Se possibile, non richiedere direttamente i file locali attraverso i parametri  manipolabili dall’utente, siano essi in GET o in POST (indifferentemente).
2. Validazione dell’input in modo da non accettare dai parametri (GET o in POST) i valori come per esempio: “..” o “/” o “%00” (null byte) o altri caratteri simili e le varie codifiche di questi, gestendo anche possibili escapers.
3. È importante limitare l’accesso ai file locali della web application in modo che possa utilizzare solo i file all’interno della sua cartella, così da evitare il “Directory Traversal” dei file locali del server.