Un attacco informatico directory traversal (o path traversal) consiste nello sfruttare un'insufficiente validazione di sicurezza o una scarsa sanificazione dell'input di nomi di file forniti dall'utente, come i caratteri speciali utilizzati per "raggiungere la cartella padre (root directory)" che vengono passati alle API dei file a livello web server. Questo significa fare exploit dell'input.

L'exploit HTTP che si effettua quando si vuole realizzare questo tipo di attacco, permette all'attaccante di poter accedere a cartelle ad accesso ristretto (accessibili solo con determinati privilegi) ed eseguire comandi all'esterno della web directory o della working directory (CWD). L'esecuzione di questi comandi porta all'accesso malevolo di alcuni file localizzati sul server remoto.

L'obiettivo dell’attacco è utilizzare un'applicazione specifica per poter guadagnare, in modo non autorizzato, i privilegi di accesso al file system. Questo attacco sfrutta un buco di sicurezza invece di sfruttare un bug nel codice (il software si comporta esattamente come ci si aspetta). Sfruttando la vulnerabilità all'attacco Directory traversal è possibile raggiungere dei dati al di fuori della root directory, come il file shadow delle password o altri file contenenti dati importanti per scatenare un attacco contro il sistema vulnerabile.

Directory traversal è anche conosciuto come attacco ../ (dot dot slash), directory climbing e backtracking. Alcune forme di questo attacco sono anche dette attacchi in forma canonica, normale o standard.

La seguente tabella riporta l'area di sicurezza dell'applicazione che è stata violata e l'impatto che descrive i problemi tecnici che possono nascere se l'attaccante sfrutta la vulnerabilità dell'applicazione attaccata.

Un esempio tipico di applicazione vulnerabile in PHP è:

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

Un attacco contro questo sistema consiste nell'inviare la seguente richiesta HTTP:

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

Generando la seguente risposta ottenuta dal server:

HTTP/1.0 200 OK
Content-Type: text/html
Server: Apache

root:fi3sED95ibqR6:0:1:System Operator:/:/bin/ksh 
daemon:*:1:1::/tmp: 
phpguru:f8fk3j1OIf31.:182:100:Developer:/home/users/phpguru/:/bin/csh

I caratteri ../ ripetuti dopo il percorso /home/users/phpguru/templates/ permettono alla funzione include() di saltare direttamente alla root directory, e successivamente di includere nel percorso il file delle password di Unix,  /etc/passwd. Non c'è un numero prestabilito di caratteri ../ poiché, più se ne mettono e più è alta la probabilità di raggiungere la cartella home dell'applicazione web.

Il file Unix /etc/passwd è un comune file usato per dimostrare il directory traversal, poiché è spesso usato dai crackers per provare a craccare le password che contiene o meglio conteneva.

Tuttavia, nei sistemi Unix più recenti, il file passwd non contiene più gli hash delle password. Sono invece salvate nel shadow file che non può essere letto dagli utenti che non possiedono i sufficienti privilegi sulla macchina. Il file passwd è comunque ancora utilizzato per l'enumerazione degli account sulla macchina (users), infatti mostra gli account degli utenti del sistema.

La seguente lista mostra alcune delle stringhe utilizzate per l'attacco directory traversal:

Comunemente nei sistemi Unix-like per effettuare l'attacco si utilizzano i caratteri ../.

Nei sistemi  Microsoft Windows e DOS per effettuare l'attacco si utilizzano le sequenze di caratteri ..\ o ../. ^[1]

Ogni partizione del disco ha una root directory separata da quella delle altre partizioni (per esempio chiamata C:\ per una partizione del disco C) e non esiste una root directory comune a tutte le partizioni.

Questo tipo di attacco è causa delle numerose vulnerabilità che affliggono l'ambiente Microsoft. ^[2][3]

Appartiene alla famiglia dei canonicalization problems detti anche problemi in forma canonica, normale o standard.

Alcune applicazioni web analizzano la query string in cerca di caratteri pericolosi come:

• ..
• ..\
• ../

per prevenire l'attacco directory traversal. 

Tuttavia, la query string è decodificata nell'URI prima dell'utilizzo. Dunque, queste applicazioni sono vulnerabili al percent encoded directory traversal (o URL encoding) come questi che seguono:

• %2e%2e%2f che si traduce in ../
• %2e%2e/ che si traduce in ../
• ..%2f che si traduce in ../
• %2e%2e%5c che si traduce in ..\

Appartiene alla famiglia dei canonicalization problems detti anche problemi della forma canonica, normale o standard.

Bruce Schneier e Jeffrey Streifling classificano la codifica UTF-8 come una fonte di vulnerabilità e vettore di attacco.^[4]

Quando Microsoft abbracciò il supporto a Unicode per i suoi Web server, introdusse una nuova modalità di codifica ../ nel sorgente, causando uno scavalcamento dei sistemi di prevenzione agli attacchi directory traversal. 

Sono chiamati Multiple percent encodings e sono di seguito riportati:

• %c1%1c
• %c0%af

Rispettivamente tradotti nei caratteri / o \.

I percent encodings erano decodificati dal web server di Microsoft nei corrispondenti 8-bit di caratteri. Questo, storicamente ha permesso di cambiare il comportamento adottato da Windows e DOS che tradizionalmente usava la forma canonica degli 8-bit di caratteri basata sulla codifica ASCII.

Tuttavia, la forma originaria di UTF-8 non era canonica, e parecchie stringhe codificate risultano traducibili nella stessa stringa. Microsoft sviluppò il sistema di verifica anti-traversal senza impiegare UTF-8 in forma canonica, e dunque senza rendere noto che quegli (HEX) C0AF e (HEX) 2F , sopra elencati, risultavano essere lo stesso carattere quando si effettuava il controllo sulle stringhe. Un percent encodings malformato, come %c0%9v risultava comunque utilizzabile. ^[5]

L'utilizzo dei file archivio, come il formato zip, facilitano gli attacchi directory traversal: i file nell'archivio possono essere creati in modo da sovrascrivere i file del file system in backtracking. Il codice che decomprime l'archivio può essere scritto per verificare che il percorso dei file nell'archivio non dia inizio al path traversal. 

Un possibile algoritmo per prevenire il directory traversal potrebbe essere:

1. Processare le request URI che non risultano nella richiesta di un file al server, e.g.: eseguendo un hook (intercettare le chiamate alle funzioni) nel sorgete, prima di continuare di seguito. 
2. Quando viene effettuata una richiesta URI per un file o una cartella, costruire il path completo di quel file o cartella e se esiste, normalizzare tutti i caratteri (e.g.: convertire tutti i caratteri %20 in spazi).
3. Si assume ora che sia noto, completo, normalizzato e conosciuto il percorso della cartella Document Root e che la lunghezza della stringa associata al path sia lunga N. Assumendo inoltre che nessun file al di fuori della cartella possa essere servito.
4. Assicurarsi che i primi N caratteri del percorso completo del file richiesto siano esattamente quelli del percorso di Document Root.
5. In caso affermativo, far restituire il file.
6. In caso non affermativo, restituire un errore, dato che la richiesta è chiaramente fuori dal range di ciò che il web server dovrebbe essere autorizzato a servire.
7. Usando una codifica fissa (hard coded) predefinita per l'estensione del file da appendere al path, non limita comunque lo scopo dell'attacco ai file aventi quell'estensione.

<?php
include($_GET['file'] . '.html');

L'utente può usare il carattere \0 (NULL, indicando la fine della stringa) dopo la variabile $_GET di php bypassando così tutto ciò che si trova dopo la variabile stessa.

• Accertarsi che i nomi dei file passati al sistema operativo del web server vengano processati nella maniera esatta;
• Non salvare file contenenti informazioni sensibili all'interno della cartella principale dell'applicazione web;
• Per i server Windows IIS, la cartella principale dell'applicazione web non dovrebbe trovarsi nella partizione di sistema, per evitare che venga propagato ricorsivamente l'attacco anche alle cartelle di sistema.

• Quando si utilizzano delle chiamate al file system, evitare di lavorare con variabili che contengono l'input dell'utente;
• Utilizzare gli indici anziché utilizzare le porzioni effettive dei nomi dei file direttamente all'interno del codice;
• Assicurarsi che l'utente non possa fornite tutte le parti del path, ma circondarlo con il proprio path code;
• Validare l'input dell'utente solamente se si tratta di qualcosa di ben conosciuto, non ripulirlo dai metacaratteri ma eliminarlo;
• Usare le chroot jails e le politiche di accesso al codice per restringere gli accessi dove i file possono essere ottenuti o salvati;
• Se non si può evitare di usare variabili che contengono l'input dell'utente nella stessa porzione di codice dove si effettuano operazioni sul file system, normalizzare l'input prima di usarlo nei file di interfaccia alle APIs come la funzione normalize() di Java.

• Chroot jails può essere soggetto a directory traversal se usando il comando chroot questo viene creato in modo errato. Altri possibili vettori di attacco del directory traversal sono i file descriptors alle cartelle al di fuori delle jail (ambienti isolati dal sistema, dove far girare comandi o macchine virtuali). Anche le working directory (o CWD) sono un possibile vettore di attacco.

• TOOLS: DotDotPwn – The Directory Traversal Fuzzer – [1]
• Conviction for using directory traversal. [2] [3]
• Bugtraq: IIS %c1%1c remote command execution
• Cryptogram Newsletter July 2001 [4].

• Open Web Application Security Project
• The WASC Threat Classification – Path Traversal
• Directory Traversal - Hackers Tribe
• CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
• File System - OWASP path traversal
• Nozioni su directory traversal attack - HackTips

Portale Sicurezza informatica: accedi alle voci di Teknopedia che trattano di sicurezza informatica