Attaccare Internet Information Server 6 con il bug WebDAV

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.

7 Commenti

  1. 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?

  2. 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’è… 😛

2 Trackbacks / Pingbacks

  1. Technotizie.it
  2. Attaccare Internet Information Server 6 con il bug WebDAV …

I commenti sono bloccati.