Archivi tag: directory traversal

Swatch ed HTTP 404 (not found)

Premessa

Swatch monitora attivamente tutte le richieste dirette ai miei server Web, quindi qualunque tentativo di accesso ad una particolare pagina viene loggato.

Problema

Ultimamente le richieste verso una particolare URL sono aumentate a dismisura. Ecco uno stralcio degli alert generati dal suddetto tool:

201.157.16.123 - - [06/Aug/2012:01:28:55 +0200] "GET /vtigercrm/modules/com_vtiger_workflow/sortfieldsjson.php?module_name=../../../../../../../..//etc/amportal.conf%00 HTTP/1.1" 404 2089 "-" "-"

201.22.125.163 - - [06/Aug/2012:00:03:58 +0200] "GET /vtigercrm/modules/com_vtiger_workflow/sortfieldsjson.php?module_name=../../../../../../../..//etc/amportal.conf%00 HTTP/1.1" 404 2089 "-" "-"

77.54.223.3 - - [05/Aug/2012:22:13:00 +0200] "GET /vtigercrm/modules/com_vtiger_workflow/sortfieldsjson.php?module_name=../../../../../../../..//etc/amportal.conf%00 HTTP/1.1" 404 2089 "-" "-"

95.229.250.152 - - [05/Aug/2012:20:59:13 +0200] "GET /vtigercrm/modules/com_vtiger_workflow/sortfieldsjson.php?module_name=../../../../../../../..//etc/amportal.conf%00 HTTP/1.1" 404 2089 "-" "-"

 

elastix, amportal.conf, directory traversal, input sanitiziation, php vulnerability, querystring, swatch, http 404

Trattasi palesemente di un attacco directory traversal, data la sintassi ../../../../../../../../ utilizzata nella URL, che consente all’attaccante di accedere alla directory /etc ed in particolare al file di configurazione amportal.conf

Tale attacco può essere attuato grazie ad una vulnerabilità specifica che affligge la distro Elastix, in particolare il CRM Vtiger. La vulnerabilità consiste nell’uso errato delle procedure di input sanitization, che consente l’uso dei caratteri . e / all’interno della querystring (espressi in URL encoding), in modo da eseguire la “scalata” delle directory fino ad arrivare al file di configurazione target.

Soluzione

Aggiornare il pacchetto elastix-vtigercrm alla versione 5.2.1-5.

Alla prossima.

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.