Tutte le applicazioni web, seppur a livelli diversi, si basano su liste di controllo degli accessi per la protezione dei dati. Attaccare le ACL è spesso più facile che compromettere i token di autenticazio-ne e accesso (di cui abbiamo già ampiamente discusso autenticazio-nel paragrafo 2.3.1).
47
3.3.1 Directory traversal
Letteralmente “attraversamento della directory”, la directory traversal è un attacco comunemente utilizzato per bypassare le ACL e ottenere l’accesso non autorizzato a directory riservate. Questo attacco prende di mira le pagine che fanno uso di template o fanno riferimento ad altri file inclusi nel web server. Usando i caratteri “../” (dot-dot-slash), usati nella navigazione dei sistemi, si può infatti, risalire da una sottodirectory ad una directory superiore. Un tipico esempio di vulnerabilità in un’applicazione PHP è la seguente:
1. $template = content.PHP';
2. if (isset($_COOKIE['TEMPLATE']))
3. $template = $_COOKIE['TEMPLATE'];
4. include ("/home/users/PHPguru/templates/" . $template);
Un attacco contro un sistema del genere può essere svolto con la seguente richiesta HTTP:
GET /vulnerable.PHP HTTP/1.0
Cookie: TEMPLATE=../../../../../../../../../../../etc/passwd
I ripetuti “../” inseriti alla fine della stringa di inclusione hanno fatto attraversare le directory fino al file Unix che contiene le password.
Alcuni sistemi effettuano dei controlli di validazione sul file incluso o aggiungono pezzi di stringhe all’input finale (tipicamente estensioni) per evitare l’inclusione di file sospetti. Per esempio, l’applicazione potrebbe posporre alla stringa il suffisso di un file immagine (.jpg, .gif, ecc.) per cui l’inclusione risulta in qualcosa del tipo:
include ("/home/users/PHPguru/templates/".$template.".jpg");
Questo tipo di protezione è facilmente aggirabile aggiungendo il carattere %00 alla fine del file che vogliamo includere. %00 è la rappresentazione in codifica URL del carattere nullo, il quale rappre-senta il carattere di fine stringa in linguaggi come il C. Linguaggi come Perl o PHP non interpreta-no %00 come delimitatore di stringa, ma il sistema operativo sì, essendo scritto in C/C++. L’inclusione fa accesso al file system, quindi l’applicazione web interagisce con una qualche funzio-ne del sistema operativo. Pertanto la stringa apparentemente innocua:
../../../../../../../../../../../etc/passwd%00.jpg
In realtà dà accesso al file delle password.
Fortunatamente, i server più utilizzati, come Apache, forniscono dei sistemi di protezione a questo tipo di attacco. Altre contromisure adottabili consistono nella validazione massiccia degli input che includono file. In particolare è fondamentale filtrare i caratteri punto e slash rappresentati sia in Unicode che in esadecimale, adottare degli appropriati sistemi di controllo degli accessi alle directo-ry sensibili e se possibile, evitare il più possibile inclusioni di file dinamiche.
3.3.2 Horizontal Privilege Escalation
L’horizontal privilege escalation è lo sfruttamento di una vulnerabilità di autorizzazione per guada-gnare i privilegi di un utente con uguali o minori privilegi. Consideriamo per esempio un’applicazione commerciale.
In seguito alla registrazione del nostro nuovo account, il server restituisce la seguente risposta:
HTTP/1.x 302 Object moved
48
Set-Cookie: UserID=2366239; path=/ Set-Cookie: ShopperID=193096346; path=/
Set-Cookie: 20214200UserName=foo@foo.com; path=/ Date: Wen, 12 Oct 2010 18:13:23 GMT
Server: Microsoft-IIS/6.0 X-Powered-By: ASP.NET Location: https://secure2.site.com/secure/MyAcctBillingSuccess.asp?r=1 Content-Length: 185 Content-Type: text/html Cache-Control: private
Tra i cookies, spiccano i due ShopperID e UserID. Questi cookie potrebbero servire per eseguire dei controlli di autorizzazione, pertanto si rimuovono individualmente uno alla volta e si vede come risponde il server. Immaginiamo che la rimozione del cookie ShopperID causi un HTTP 302, ossia un messaggio di redirect che indica che quel token era necessario all’autorizzazione. A questo punto è sufficiente modificare i valori e replicare il cookie al server, osservando le risposte del sito. Per esempio si guarda come cambia la pagina con i dettagli del nostro account. Data la natura del valo-re, possiamo immaginare che si tratti di un contatore che indica il numero di account, ed essendo il nostro account l’ultimo creato, proviamo a decrementarlo:
Set-Cookie: ShopperID=193096345;
Inviamo la richiesta al server, e il risultato è che stiamo impersonando un altro utente, con tutti i suoi privilegi e le sue informazioni personali. Provando diversi valori, un attaccante può risalire a ogni account, raccoglierne i dati personali e impersonare il suo profilo liberamente.
3.3.3 Vertical privilege escalation
Il vertical privilege escalation è la capacità di guadagnare accesso a un account di livello superiore o con maggiori permessi. Esistono quattro scenari perché questo accada:
Ruoli modificabili – l’applicazione permette impropriamente di modificare il ruolo dell’utente.
Manomissione dell’account – avviene quando un utente non autorizzato riesce a
manomet-tere la sessione di un altro utente con privilegi maggiori.
Sfruttare altre falle di sicurezza – guadagnare l’accesso tramite falle di sicurezza a sezione amministrative del sito che permettono la modifica dei permessi.
Funzioni di amministrazione insicure – funzioni di amministrazione che non hanno degli
adeguati controlli di autorizzazione.
Ruoli modificabili
Come già visto più volte, molte applicazioni web salvano le informazioni di autorizzazione, come livello di permessi o ruoli, in locazioni facilmente modificabili dall’utente. Prendiamo per esempio il seguente cookie:
Auth=897ec5aefa56fd4fe5a4f65es3af1e9af4e56s4fa6e1fa84f9sa4f56e4saf8e9asf89; x=d1sa56d1a891ds5a6d15sa6;
Y=sad49a489ds1ad591sa89d4;
role=ee11cbb19052e40b07aac0ca060c23ee
Il campo role è subito evidente, ma apparentemente non suggerisce molto. La cosa migliore da fare in caso di valori poco intellegibili è svolgere un’analisi differenziale (come spiegato nel paragrafo 3.2). Provando un secondo account otteniamo il seguente risultato:
49 Auth=897ec5aefa56fd4fe5a4f65es3af1e9af4e56s4fa6e1fa84f9sa4f56e4saf8e9asf89; t=0; v=5sa61d6a1d65a1d56sa1d56; Y=sad49a489ds1ad591sa89d4; role=ee11cbb19052e40b07aac0ca060c23ee
Il campo role non è cambiato. Questo ci fa subito capire che il valore utilizzato per identificare il ruolo è una stringa statica, probabilmente una parola che identifica un ruolo in particolare o qualco-sa di simile. Inoltre, si contano 32 caratteri, il che fa penqualco-sare ad una possibile codifica MD5. A que-sto punto non ci resta che prendere un dizionario dei più comuni nomi utilizzati per indicare il ruolo di amministratore, convertirli in MD5 con uno dei tanti software presenti sul web e aspettare una risposta che non sia un HTTP 302. Dopo un po’ di tentativi, si scopre che la parola giusta per accedere con privilegi superiori era 09348c20a019be0318387c08df7a783d, ovvero supervisor. Giu-sto per completezza, si può facilmente intuire a cosa corrispondeva la stringa originale
ee11cbb19052e40b07aac0ca060c23ee: alla parola user.
Manomissione dell’account
Questa tecnica si basa sull’horizontal privilege escalation. Se la numerazione degli account è eseguita sequenzialmente, è facile risalire a un account con poteri amministrativi, poiché solitamente è il primo a essere creato.
Sfruttare altre falle di sicurezza
Accedere a un sistema tramite altre falle di sicurezza come SQL injection, spesso è più che sufficien-te a modificare quello che serve per salire di ruolo. Il capitolo 2 definisce molsufficien-te di quessufficien-te vulnerabi-lità.
Funzioni di amministrazione insicure
Molto spesso le funzioni amministrative di un’applicazione web non sono autenticate o autorizzare correttamente. Si consideri per esempio un’applicazione con cui si richiama uno script tramite POST. L’applicazione suppone irragionevolmente che lo script sia accessibile solamente dalla por-zione amministrativa del sito, la quale richiede una qualche forma di autenticapor-zione. Naturalmente però, un potenziale intruso potrebbe con un pizzico di fortuna e tanta dedizione, risalire alla direc-tory che contiene quello script ed eseguirlo come utente normale.