Per quale motivo craccare una password quando un meccanismo di autenticazione può essere aggirato? I server Internet Information Server (IIS) prodotti da Microsoft, dalla versione 5.0 alla 6.0 sono vulnerabili a un attacco che in alcuni casi permette l’accesso a risorse protette aggirando l’autenticazione.
Al momento attuale non esistono patch per chiudere la falla ma Microsoft, che ha confermato il problema, nel security advisory 971492 fornisce alcune contromisure per mitigare la minaccia.
Il bug colpisce il sistema di autenticazione del componente WebDAV (Web-based Distributed Authoring and Versioning), un sistema (non attivo di default) per la gestione,la condivisione e il versionamento di documenti tramite web.
Una errore nella logica del controllo di sicurezza in concomitanza di particolari caratteri unicode, permette a un hacker di accedere a directory protette da password e quindi, uploadare, downloadare files; in particolari condizioni è possibile caricare script backdoor scritti in asp ed eseguirli, ottenendo un accesso remoto, seppur con privilegi limitati.
Sono già apparsi diversi exploit. Esiste anche un interessante video che mostra tutti i possibili attacchi, e le relative configurazioni vulnerabili:
Webdav IIS6 bypass and code execution from Thierry Zoller on Vimeo.
Questa vulnerabilità ha una natura assai curiosa. Si tratta di un errore di programmazione clamoroso, errore che non ci aspetteremmo di trovare in un software di questa portata: eppure c’è. La spiegazione del bug è abbastanza semplice: se nell’url passato al server è presente la sequenza unicode “%c0%af” l’autenticazione viene semplicemente ignorata e l’utente può tranquillamente procedere verso l’area protetta senza necessità di inserire credenziali!
Per quale motivo? Vediamo in sequenza come agisce l’autenticazione:
1. Esiste un file “protected.zip” in un’area del server accessibile tramite password
2. Il percorso completo è /protected/protected.zip
3. Il server analizza il percorso e si accorge che la cartella è protetta
4. Viene richiesta la password
Questa è la procedura normale. Se fossimo in grado di alterare la logica del punto 3, facendo credere al server che vogliamo accedere ad una risorsa pubblica, quando in realtà la risorsa è protetta avremmo accesso all’area riservata. Ma come?
Se mettessimo dei caratteri arbitrari aggiuntivi all’url con lo scopo di ingannare il server le cose funzionerebbero solo a metà:
1. Esiste un file “protected.zip” in un’area del server accessibile tramite password
2. Il percorso completo è /protected/protected.zip
3. Noi passiamo un url leggermente modificato per aggirare il controllo: /protected@@/protected.zip
4. Il server analizza il percorso e si accorge che la cartella non è protetta
5. Viene effettuata la decodifica unicode. Non ci sono caratteri unicode
6. Il server si accorge che l’indirizzo /protected@@/protected.zip non esiste
Evidentemente non funziona, otteniamo semplicemente un file not found. Ma se invece inserissimo dei caratteri che confondo il server nella prima fase, ma che vengono rimossi prima che venga effettuato l’effettivo recupero della risorsa richiesta avremmo ottenuto l’obiettivo:
1. Esiste un file “protected.zip” in un’area del server accessibile tramite password
2. Il percorso completo è /protected/protected.zip
3. Noi passiamo un url leggermente modificato per aggirare il controllo, utilizzando i caratteri unicode: /protected%c0%afprotected.zip
4. Il server analizza il percorso e si accorge che la cartella non è protetta(!)
5. Viene effettuata la decodifica unicode, “%c0%af” diventa “/”, ovvero “/protected%c0%afprotected.zip” diventa “/protected/protected.zip”
6. Il server recupera la risorsa e ce la consegna senza tante storie
Insomma, il controllo di sicurezza viene effettuato prima della conversione unicode. La codifica unicode maschera il vero url alla funzione di verifica, ma prima del recupero della risorsa l’url viene modificato e riportato all’originale. A questo punto è troppo tardi, la strada è già spianata.
Questo bug ricorda un bug molto più grave che tra il 2000 e il 2001 fece strage tra i server IIS4 e IIS5. Quella volta l’impatto fu molto più grande perché il bug aprì le porte all’esecuzione di comandi da remoto in modo estremamente semplice. Chi all’epoca si occupava di hacking se lo ricorderà molto bene. Questa volta l’impatto dovrebbe essere molto più limitato, considerando che WebDAV deve essere esplicitamente attivato, e per ottenere gli effetti più nefasti si devono verificare diverse condizioni.
PillolHacking.Net: I Migliori Articoli di Maggio 2009
Si chiude Maggio e vi segnalo quelli che secondo me sono stati i migliori articoli di PillolHacking di... Risolvere i Problemi di Accesso alle Risorse Condivise
Tentate di accedere al vostro Windows Xp tramite rete ma ottenete un Access Denied Error 5? Cerchiamo... Craccare Facebook con fbruteforcer
Se non si riesce a craccare un account di Facebook sfruttando un bug, attuando qualche trucco di... TYPSoft FTP Server: ftp server portatile
TYPSoft FTP Server è un leggero e veloce server ftp che non richiede installazione. Facile, dotato di...
mag 25, 2009 at 11:55:43
Splendido resoconto.
A++
mag 25, 2009 at 15:54:58
A bocca aperta!
mag 25, 2009 at 19:11:33
Gran bella spiegazione, bravissimo!
mag 25, 2009 at 20:02:30
Fantastico!!Angelor sei sempre il migliore!
Solo una domanda: come ha fatto qualcuno a farsi venire in mente di sostuire la “/” con i caratteri unicode?
mag 27, 2009 at 20:11:45
Ciao Angelo, come vedi ogni tanto una capatina la vengo a fare!
Volevo complimentarmi per l’ottimo articolo.
Mi sa che lo provo su un Windows Server che ho a disposizione, così per vedere com’è…
mag 30, 2009 at 20:12:56
Ciao Erriko, sei sempre il benvenuto! Ne ho sentiti diversi che hanno avuto la tua stessa idea