Directory traversal attack

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'immagine descrive come un attacco directory traversal possa, tramite i caratteri ../ aggiunti nel path, uscire dalla cartella root dell'applicazione web e raggiungere la cartella root del web server. Le frecce rappresentano il flusso utilizzato dall'attacco per raggiungere i file shadow o passwd.

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.

Conseguenze comuni dell'attacco

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.

Area di sicurezza violata	Impatto
Integrità Confidenzialità Disponibilità (dei dati o delle informazioni)	Impatto tecnico: esecuzione di codice non autorizzata. L'attaccante può essere in grado di creare o sovrascrivere file importati che sono normalmente usati per eseguire codice, come librerie o programmi.
Integrità	Impatto tecnico: modifica di cartelle o file. L'attaccante può sovrascrivere o modificare un file che è usato normalente per eseguire del codice o mantenere dati importanti. Se il file che viene modificato è utilizzato per meccanismi di sicurezza, l'attaccante li può aggirare. Per esempio, può aggiungere un nuovo account utente alla fine del file delle password (/etc/passwd o shadow file) consentendogli di bypassare il sistema di autenticazione.
Confidenzialità	Impatto tecnico: lettura di file o cartelle. L'attaccante può leggere i contenuti di un file e rendere noti i dati sensibili. Anche in questo caso, se il file è utilizzato per implementare meccanismi di sicurezza, l'attaccante può aggirarli. Per esempio, leggendo il file delle password, il malintenzionato può condurre un attacco di forza bruta per indovinare la password ed entrare in un account del sistema.
Disponibilià	Impatto tecnico: DOS: Crash, Uscita o riavvio. L'attaccante può essere in grado di sovrascrivere, eliminare o corrompere file come programmi, librerie o dati importanti. Questo può impedire al sistema di lavorare. Se il file che viene attaccato, si tratta di un file utile al meccanismo di protezione, come l'autenticazione, questo potenzialmente potrebbe bloccare tutti gli utenti del sistema.

Esempio

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.

Le varianti dell'attacco directory traversal

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

Directory traversal in ambiente Unix

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

Directory traversal in ambiente Microsoft Windows

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]

URI encoded directory traversal

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 ..\

Unicode / UTF-8 encoded directory traversal

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]

Zip/Archive traversal attacks

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. 

Possibili metodi per la prevenzione del directory 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.

Come identificare se si è vulnerabili

• 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.

Come proteggersi

• 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.

Altri attacchi

• 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.