Attacco directory traversal

Recentemente ho notato il moltiplicarsi di articoli riguardanti le più comuni vulnerabilità del Web, tra cui l’SQL injection ed il cross site scripting. Poco risalto però, secondo il mio parere, viene dato ad un altro tipo di attacco, dagli effetti altrettanto devastanti, quale il directory traversal. Esso consente ad utenti non autorizzati di accedere a risorse la cui visualizzazione dovrebbe essere inibita (si pensi, ad esempio, al file passwd o ancora peggio al file shadow dei server Web basati su sitemi *nix).

Un attacco di questo tipo va a buon fine quando non sono stati previsti opportuni meccanismi di controllo dell’input. Per rendere meglio l’idea si consideri il seguente codice PHP:

<?php
$template = 'red.php';
if ( isset( $_COOKIE['TEMPLATE'] ) )
$template = $_COOKIE['TEMPLATE'];
include ( "/home/users/phpguru/templates/" . $template );
?>

Essendo il PHP un linguaggio di scripting top-down è facile comprendere la logica che sta dietro a questo stralcio di istruzioni. Nella fattispecie,
dopo aver settato la variabile stringa $template, viene verificata la presenza della variabile superglobale $_COOKIE[‘TEMPLATE’]. Se tale verifica ha esito positivo, la variabile $template settata in precedenza viene sovrascritta con il contenuto della variabile $_COOKIE[‘TEMPLATE’]. Infine, viene richiamata la direttiva include, per richiamare all’interno della pagina il seguente percorso:

"/home/users/phpguru/templates/" . $template

che nel nostro caso diventa:

/home/users/phpguru/templates/$_COOKIE['TEMPLATE']

Ebbene, il problema è proprio questo. Che controllo viene fatto sul contenuto della variabile $_COOKIE[‘TEMPLATE’]? Proprio nessuno. Quindi nulla vieta ad un utente malevolo di utilizzare un cookie (ebbene si, la variabile $_COOKIE[‘TEMPLATE’] non fa altro che leggere il valore associato al campo TEMPLATE contenuto nel cookie) nel quale sono presenti le seguenti istruzioni:

 GET /vulnerable.php HTTP/1.0
 Cookie: TEMPLATE=../../../../../../../../../etc/passwd

Ovvero si vuole utilizzare il metodo GET relativo al protocollo HTTP 1.0 per accedere alla pagina vulnerable.php.
Focalizziamo ora la nostra attenzione sul campo TEMPLATE. Esso contiene tutta una serie di ../ che consentono all’attacker di posizionarsi nella directory immediatamente superiore a quella su cui si trova il sito Web. Supponiamo che il sito si trovi nella dir /var/www/sitovulnerabile. Con un ../ si posiziona su /var/www, con un altro ../ si posiziona su /var e così via.

A questo punto, appare chiaro come sia opportuno filtrare appositamente i campi di input per evitare problemi di questo tipo. Ma è sufficiente andare alla ricerca dei caratteri tipici dell’attacco descritto in questo post (quali .., ../ oppure ..) per impedire che venga eseguito con successo? Assolutamente no. Infatti, quando si digita un indirizzo sul nostro browser, viene opportunamente codificato (URI encoded) ed i simboli non supportati da tale codifica vengono tradotti mediante la notazione %hh. Ad esepio, ../ diventa %2e%2e%2f, dove %2e rappresenta il punto (.), mentre %2f rappresenta lo slash (/).

Discorso simile riguarda la codifica Unicode/UTF-8. Nel momento in cui Microsoft ha introdotto il supporto a tale codifica sui propri server Web, tutti i meccanismi di prevenzione relativi al directory traversal previsti per la codifica URI sono venuti meno. Infatti, l’UTF-8 permette di utilizzare la notazione %hh%hh per rappresentare i caratteri non supportati. Ad esempio:

%c1%1c rappresenta il carattere /;

%c0%9v rappresenta il carattere backslash;

%c0%af rappresenta il carattere .

Inutile dire che esistono diversi modi per prevenire l’attacco in questione, ma certamente quello più efficace consiste nalla creazione di gabbie chroot.

Il post termina qui, a presto.

Attacco directory traversalultima modifica: 2010-04-17T18:15:16+02:00da nazarenolatella
Reposta per primo quest’articolo

Lascia un commento