Immaginate che un'attaccante scopra che un sito web è vulnerabile ad un'inclusione remota di file php (RFI).
Nella maggior parte dei casi l'attaccante proverà ad eseguire comandi, inserire una shell e leggere i file di configurazione che potrebbero contenere dati sensibili.
E' questa la strada migliore per esploitare con php una RFI? Ce ne sono altre?

ALTERNATIVE WAYS TO EPLOIT PHP REMOTE FILE INCLUDE VULNERABILITIES

Fonte: http://itbloggen.se/cs/blogs/secteam/archive/2009/01/26/alternative-ways-to-exploit-PHP-remote-file-include-vulnerabilities.aspx [Broken link]

La strada maggiormente seguita da un'attaccante per esploitare una vulnerabilità RFI è quella di uploadare il suo cod php in una macchina sotto il suo controllo poi aggiungere l'URL come argomento ad un'applicazione vulnerabile. L'applicazione scaricherà poi il codice maligno php e lo eseguirà localmente sulla macchina vulnerabile (n.d.r. secondo me è un po' evasivo qui :) ).
Potrebbero esserci diverse cose ad impedire il successo dell'attaccante nell'exploitare questa vulnerabilità.
Su una macchina Hardenizzata potrebbe esserci qualsiasi cosa, un IPS (Servizio di prevenzione intrusioni), una macchina firewall o delle impostazioni di firewall per prevenire l'attacco.
Inoltre nelle recenti versioni di php, la configurazione di default non permette il file include remoto, solo locale.
Questo documento illustrerà una nuova strada, leggermente diversa, per bypassare i meccanismi di sicurezza, su una macchina, con php ed exploitare con successo i file include.
Potrebbero esserci diversi modi per realizzare tale attacco, ma andrebbe oltre gli scopi di questo documento.Il suoobbiettivo è quello di porre l'attenzione dei ricercatori su queste nuove tecniche di exploiting.
Questo tipo di vulnerabilità è dovuta, in parte, ad una mancanza di validazione dell'input e, per il resto, al fatto che esistono funzioni di php che permettono ad un utente esterno al server l'inclusione e l'esecuzione di file remoti su di esso.
Alcune delle funzioni vulnerabili di php sono include(), require_once(), e require().
Potrebbero essercene altre ma noi lavoreremo su queste.
Queste funzioni danno all'applicazione la possibilità di ereditare variabili, funzioni e altre informazioni da file php aggiuntivi e possibilmente malevoli.
Quello che fa di questo una falla nella sicurezza è il fatto che queste funzioni vulnerabili permettono ad un attaccante di includere file che sono posizionati esternamente al sito web senza validare il loro contenuto contenuto.
L'applicazione dovrà semplicemente scaricare il file remoto ed eseguirlo come un'altro file php.
Le RFI sono tecniche di exploiting conosciutissime, e ultimamente esistono svariate applicazioni da implementare per prevenirle.
Un'altra misura di sicurezza contro le RFI è stata inserita dal team di php; di default,oggi, nei file di configurazione di php, non viene permessa l'inclusione di files remoti da parte di http:// o ftp://.

La nuova configurazione potrebbe risultare molto simile a questa:

###############
# Fopen wrappers ;
###############

# Whether to allow the treatment of URLs (like http:// or ftp://) as files.
allow_url_fopen = On

# Whether to allow include/require to open URLs (like http:// or ftp://) as files.
allow_url_include = Off 

 Grazie a questa nuova configurazione, l'attaccante non può più includere files situati su altri sistemi remoti.

Ma può ancora operare inclusioni di files locali. Potete sfruttare questa debolezza!
Per fare in modo che l'attacco abbia successo, l'attaccante deve depositare in qualche modo del codice php valido nella macchina vulnerabile.
Se un attaccante ha la possibilita di effettuare l'upload di files, questa potrebbe essere la strada migliore, ma è anche possibile salvare codice php sull'obiettivo attraverso i logfiles. Il trucco sta nell'individuare i files che possono essere scritti con successo e capire dove sono ubicati sul sistema.
Questa non è una novità.
Ci sono stati exploits che usavano i logfiles per salvare codice php, ma siccome spesso non conoscendo il corretto path dei file, forzavano sia i filename che le directories.
Qui di seguito c'è un piccolo esempio riguardante l'individuazione dei logfiles sul sistema vulnerabile, e anche informazioni su quali di essi utilizzare per exploitare un RFI.

#1 APACHE LOGFILES
Normalmente Apache usa due differenti logfiles, uno che è l'access_log che contiene tutte le richieste valide inviate al webserver. Il secondo log file è l'error_log e contiene i messaggi di errore.
Apache offre la possibilità di personalizzare quello che il log file deve contenere e quindi restituire ad un'amministratore informazioni circa browser, sistema operativo, referring URLS e altre informazioni tecniche potenzialmente utili. Un'installazione default di Apache, comprende il volume sopra menzionato.
Quando controlla il browser dell'attaccante, questo può semplicemente cambiare browser e sistema operativo in altrettanto valido codice php capace di divenire un'informazione riguardante il client.
Il fatto che Apache supporta i virtual hosts, significa che può gestire domini multipli sullo stesso ip e l'admin può specificare il nome e la posizione del logfile logfile. Sapere l'ubicazione dei log di Apache risulta molto difficile, tuttavia,è molto importante per l'attaccante conoscerla per fare in modo che la possibilità di successo dell'attacco aumenti esponenzialmente.
I precedenti exploits vedono la locazione dei logfiles semplicemente con forza bruta, e sperano di includere il file giusto. Come detto prima, php non valida i file che include, così anche se il logfile contiene dati a caso esso non terminerà, legge semplicemente l'intero file e per ogni riga che trova che inizia con <?php , esegue tutto ciò che si trova tra i tags.
Dopo varie analisi, diventa chiaro che un attaccante può usare il/proc filesystem su Linux per ottenere un percorso diretto ai files,
Il filesystem/proc contiene informazioni circa l'ambiente e i processi e in esso c'è anche una directory speciale chiamata/self che contiene informazioni circa la sessione corrente, e un'attaccante accedendo a questa directory da Apache può avere informazioni su di esso.
Un semplice listato delle directory in >proc/self/fd/ mostra il seguente output:

dr-x------ 2 www-data www-data 0 Jan 2 18:27 .
dr-xr-xr-x 6 www-data www-data 0 Jan 2 18:27 ..
lr-x------ 1 www-data www-data 64 Jan 2 18:27 0 -> /dev/null
l-wx------ 1 www-data www-data 64 Jan 2 18:27 1 -> pipe:[3113414]
l-wx------ 1 www-data www-data 64 Jan 2 18:27 2 -> /var/log/apache2/error.log
lrwx------ 1 www-data www-data 64 Jan 2 18:27 3 -> socket:[2714910]
lr-x------ 1 www-data www-data 64 Jan 2 18:27 4 -> pipe:[2714921]
l-wx------ 1 www-data www-data 64 Jan 2 18:27 5 -> pipe:[2714921]
l-wx------ 1 www-data www-data 64 Jan 2 18:27 6 -> /var/log/apache2/access.log
lrwx------ 1 www-data www-data 64 Jan 2 18:27 7 -> /anon_inode:[eventpoll]
lrwx------ 1 www-data www-data 64 Jan 2 18:27 8 -> socket:[2742717]
lr-x------ 1 www-data www-data 64 Jan 2 18:27 9 -> /proc/27262/fd

 La directory /proc/self/fd/contiene i link simbolici a diversi socket, file descriptors, ma anche logfiles.
Qui abbiamo una path diretta ai files a cui un attaccante è interessato, e inoltre egli ha il permesso di leggerli. Il trucco adesso è di aggiungere del codice php valido all'interno di essi.
Potenzialmente ci sono diverse strade per compiere questa parte di attacco, tuttavia, un analisi identifica una strada che funziona bene sui sistemi che loggano informazioni circa il browser.
Quello che deve fare un'attaccante è cambiare gli HTTP headers che contengono le informazioni circa il loro browser, memorizzate in uno speciale header chiamato User-Agent.
Un beneficio quando si usa l'HTTP User-Agent Header è che la dimensione del buffer è grossa, permette di aggiungere molto codice all'interno di esso(n.d.r. Geremia aveva già spiegato questa tecnica di forging http headers,mi sembra di averla anche tradotta su qs forum, ma non si era avventurato nell'esploitazione attraverso i logfile...).

Un'altro vantaggio che ha un'attaccante usando questo header è che non esiste una restrizione nell'uso di caratteri speciali.
Un attaccante può usare il carattere che vuole, e può essere un ulteriore vantaggio nel permettere di bypassare i meccanismi di validazione dell'input.
Un'altro vantaggio nell'uso dell'User-Agent Header è che non chiede nulla all'attaccante; egli può semplicemente visitare il sito web e il php trovato nell'user-agent verrebbe salvato nei logfiles automaticamente.
Sotto un esempio su come una richiesta GET appare dopo che avrete modificato l'header:

GET /NoSuchFile HTTP/1.1
Host: localhost
User-Agent: <? print('<html><pre><br>'); system('id'); ?>
Keep-Alive: 300
Connection: keep-alive

Semplicemente accedendo ad un file a caso, in questo caso un file chiamato NoSuchFile, nell'esempio, il codice php verrà salvato nell'access_log come un errore 404 (file not found error).
Invece di salvare le normali informazioni benigne riguardanti browser e so dell'utente, salva il codice php che potrà essere usato più tardi.
Ora, se guardiamo in access_log apparirà così:

david@spasmo:/var/log/apache2$ cat access.log
127.0.0.1 - - "OPTIONS * HTTP/1.0" 200 - "-" "Apache/2.2.8 (Ubuntu)"
127.0.0.1 - - "OPTIONS * HTTP/1.0" 200 - "-" "Apache/2.2.8 (Ubuntu)"
127.0.0.1 - - "OPTIONS * HTTP/1.0" 200 - "-" "Apache/2.2.8 (Ubuntu)"
127.0.0.1 - - "OPTIONS * HTTP/1.0" 200 - "-" "Apache/2.2.8 (Ubuntu)"
127.0.0.1 - - "GET /NoSuchFile HTTP/1.1" 404 322 "-" "<? print('<html><pre><br>'
); system('id'); ?>"

Tutto quello che ci occorre ora è includere l'access_log attraverso la nostra applicazione vulnerabile.
Per dimostrare questa tecnica qui c'è un'esempio di uno script di test vulnerabile:

<? include($_GET[file]); ?>

Lo script php include semplicemente il file che l'attaccante invia come argomento.
Questo è come lavora tipicamente un file incluso.

Nel codice d'esempio l'attaccante tenta semplicemente di eseguire il system command id.
Invece di provare a forzare la path ad access_log, l'attaccante include semplicementet /proc/self/fd/6 che è il link simbolico ad access_log.

#2 UNIX MAIL SPOOL

Molte delle tipiche applicazioni web includono una funzione mail come parte di un modulo di registrazione o come invio info e così via. Sfortunatamente, è spesso possibile per un'attaccante scegliere a quale email si vuole venga inviato il messaggio.
Il "sistema obbiettivo" può salvare le email localmente, per esempio attraversolo spool mail in Unix.
Un attaccante può usare questi files per salvare il suo codice php.

Questa tecnica per savare dati non è infallibile, così come il metodo dei log di Apache descritto prima, dal momento che questa tecnica richiede che l'attaccante possa inviare dati senza validazione dell'input.
Presume che un attaccante abbia un profilo sull'applicazione web e anche che abbia trovato una vulnerabilità RFI Per queste ragioni i trucchi per Apache menzionati sopra non funzionano.
Un attaccante può essere capace di enumerare che l'obbiettivo usa un sistema Unix mail spool per salvare email localmente sul sistema obbiettivo.

Quello che un'attaccante deve fare è semplicemente cambiare ogni informazione che contiene il codice php e le parti più importanti, cambiare l'indirizzo email in www-data@localhost

Questo invierà le mail to www-data, che in molti casi è l'utente che avvia il demone http.
L'email verrà salvata localmente e finchè il sistema userà Unix mail spools, la path sarà una path generica.
I files delle email verranno salvati o in /var/mail o in /var/spool/mail con lo stesso nome-file dello username, in questo caso www-data.

Sotto uno snapshot di uno spool file exploitato:

www-data@spasmo:/var/mail$ cat www-data
From david[@]spasmo.internal.truesec.com Fri Jan 02 19:02:56 2009
Return-path: <david[@]spasmo.internal.truesec.com>
Delivery-date: Fri, 02 Jan 2009 19:02:56 +0100
Received: from david by spasmo.internal.truesec.com with local (Exim 4.69)
(envelope-from <david[@]spasmo.internal.truesec.com>)
id 1LIoMA-0007P7-US
for www-data[@]spasmo.internal.truesec.com; Fri, 02 Jan 2009 19:02:46 +0100
To: www-data[@]spasmo.internal.truesec.com
Subject: <? print('<html><pre><br>'); system('id'); ?>
Message-Id: <E1LIoMA-0007P7-US[@]spasmo.internal.truesec.com>
From: David Jacoby <david[@]spasmo.internal.truesec.com>
Date: Fri, 02 Jan 2009 19:02:46 +0100

Tutto quello che un attaccante deve fare a questo punto è includere il file mail situato in /var/spool/mail/www-data dall'applicazione vulnerabile.

ALTRE STRADE PER SALVARE DATI
Ci sono diversi modi con cui un attaccante può salvare dati in locale su un sistema target.
Che un'attaccante possa avere accesso in lettura al file costituisce un errore di procedura.
Molti servizi che sono soliti salvare dati localmente sono, ad esempio:

* OpenSSH
* OpenBSD FTPD
* Samba