di  -  giovedì 9 aprile 2009

Nel campo della sicurezza informatica, un incidente rappresenta generalmente un tentativo, riuscito o meno, di sfruttare una o più vulnerabilità allo scopo di penetrare i sistemi attaccati, o di condizionarne il funzionamento.

Meno di un mese fa l’Internet Storm Center del SANS Institute ha pubblicato un’interresante analisi di un incidente informatico in cui vengono tirati in ballo diversi attacchi in punti relativamente deboli di un web server, che hanno portato, alla fine, alla compromissione completa del sistema stesso.

Riproporrò quindi la descrizione dell’incidente, con ulteriori analisi, perché molto significativa per comprendere come un semplice errore di design di un’applicazione possa avere effetti devastanti e perché utile per capire le dinamiche di attacco di un server e, quindi, da cosa bisogna proteggersi.

I tre principali principali attori di questa storia sono una web application in ASP.NET vulnerabile, un sistema operativo Microsoft Server 2008 non completamente aggiornato e l’ultima linea di difesa di un sistema: un anti-virus.

La storia inizia, come molte storie simili, con un’applicazione web contentente una vulnerabilità, in questo caso potremmo definirlo un errore di design. Essa infatti non validava adeguatamente i file che permetteva di caricare sul server.

È un errore molto comune, anche perché non facile da risolvere. Alcuni sviluppatori controllano il campo Content-Type degli header HTTP, che risulta però facilmente modificabile dall’attaccante. Altri verificano l’estensione del file caricato, ma spesso il check risulta bypassabile o comunque poco significativo vista la possibilità di creare, per esempio, immagini GIF (solitamente consentite in upload) contenenti nei commenti codice interpretabile ed eseguibile lato server.

L’attaccante ha quindi caricato sul server una webshell .NET, ASPXspy. Le webshell sono applicazioni web, scritte in un linguaggio comprensibile dall’interprete correntemente installato sul server web (PHP, ASP, JSP, etc.), che consentono l’upload di file, la loro esecuzione, la navigazione all’interno del filesystem del server, la visione del contenuto dei file e tanti altri comandi molto pericolosi se eseguiti da un malintenzionato.

A questo punto l’attaccante aveva un buon controllo del server web, Microsoft Internet Information Services (IIS), ma non ancora completo siccome esso girava con un utente non privilegiato.

Per diventare amministratore, l’attaccante ha quindi sfruttato una vulnerabilità, scoperta dal noto ricercatore Cesar Cerrudo, che permette ad un utente non privilegiato di eseguire comandi sotto l’account SYSTEM.

L’exploit, rilasciato ad ottobre scorso, funziona sia su Windows Server 2003 che sul 2008 e dopo la sua esecuzione crea una backdoor sul server. A questo punto il gioco è praticamente finito, l’attaccante ha accesso completo al server con i massimi privilegi e installa un trojan e un keylogger.

Anche l’ultima linea di difesa, l’anti-virus, ha fallito. Benché spesso gli AV contengano delle signature per rilevare gli exploit, in questo caso è chiaro che qualcosa non ha funzionato.

L’autore dell’incident response ha dato in pasto al servizio offerto da VirusTotal l’eseguibile malevolo, risultato: nessun anti-virus su 39 è stato in grado di rilevarlo. Piuttosto atterrente.

Quello che storie come questa, tutt’altro che rare, ci dovrebbero insegnare è che le applicazioni web, prima linea di difesa, devono essere scritte in modo sicuro (OWASP insegna), che Microsoft deve prestare maggiore attenzione alle vulnerabilità locali che consentolo una privilege escalation e deve rilasciare patch specifiche, non semplici workaround, e che le case produttrici di anti-virus dovrebbero agire in maniera più proattiva e meno reattiva, seguendo con più attenzione lo sviluppo degli exploit e migliorando i propri motori euristici.

Tutti i dettagli omessi non sono disponibili per ragioni di riservatezza.

8 Commenti »

I commenti inseriti dai lettori di AppuntiDigitali non sono oggetto di moderazione preventiva, ma solo di eventuale filtro antispam. Qualora si ravvisi un contenuto non consono (offensivo o diffamatorio) si prega di contattare l'amministrazione di Appunti Digitali all'indirizzo info@appuntidigitali.it, specificando quale sia il commento in oggetto.

  • # 1
    Octane
     scrive: 

    Al solito la prima buona norma resta il buon controllo lato server delle informazioni immesse dall’utente (url compresi ;) )

  • # 2
    pabloski
     scrive: 

    e la seconda è la scelta di un OS che fornisca un minimo di sicurezza

    guarda caso chissà perchè quando si parla di server web attaccati spunta sempre Windows

    eppure Linux ha uno share di molto superiore

    almeno adesso sappiamo che Linux è il meno vulnerabile non perchè è meno diffuso, ma perchè è progettato meglio

  • # 3
    Cael
     scrive: 

    E chissà perchè i solito troll scrivono senza mai leggere le notizie…Eppure è scritto che il sistema non è aggiornato.

  • # 4
    Lorenzo
     scrive: 

    @pabloski (OT)
    giusto perchè certa gente non impara mai… http://it.wikinews.org/wiki/Scoperta_prevedibilit%C3%A0_nel_generatore_di_numeri_casuali_della_versione_Debian_di_OpenSSL

  • # 5
    atome
     scrive: 

    Ha quanto ho capito leggendo la KB microsoft principale e quelle collegate, l’exploit è legato a MS-DTC.
    Comunque buona parte di quanto descritto nel workaround dovrebbe essere la norma, vedi utente adhoc per IIS.
    Per quanto riguarda Linux, il sistema perfetto non esiste. Viene bucato anche lui in ambito web, ne più ne meno quanto IIS.
    Molto spesso i problemi di sicurezza sono relativi più a incompetenza progettuale/sistemistica.

  • # 6
    D
     scrive: 

    Al solito, gli aggiornamenti SI DEVONO FARE SEMPRE QUANDO ESCONO e non quando si vuole. Non c’è nessun “Bill” che vi controlla il disco da remoto se fate un aggiornamento, ma piuttosto ce ne sta uno che vi sta offrendo una patch ad un problema perchè voi l’avete pagato comprando la licenza del sistema (l’avete comprata, vero ? O c’è una piccola coda di paglia che sta fumando… ?)

  • # 7
    Andrea R
     scrive: 

    I file caricati vanno spostati fuori dalla docroot o se proprio serve averli sullo stesso sito nel .htaccess della cartella degli upload si disabilita php.
    Ops ho dato la soluzione per apache e php!

  • # 8
    AVSIM: come non gestire la sicurezza di un sito Web - Appunti Digitali
     scrive: 

    […] A parte il fatto che non si può sapere con facilità e certezza se si è stati compromessi o meno (non sempre l’attaccante è così stupido da cancellare tutto, è più facile che rubi silenziosamente i dati che gli interessano), bisogna anche considerare che se ti è andata bene per un certo tempo, non puoi inferire che ciò che fai va bene, puoi essere stato solo fortunato, mentre devi concludere che hai sbagliato qualcosa se capita un incidente informatico. […]

Scrivi un commento!

Aggiungi il commento, oppure trackback dal tuo sito.

I commenti inseriti dai lettori di AppuntiDigitali non sono oggetto di moderazione preventiva, ma solo di eventuale filtro antispam. Qualora si ravvisi un contenuto non consono (offensivo o diffamatorio) si prega di contattare l'amministrazione di Appunti Digitali all'indirizzo info@appuntidigitali.it, specificando quale sia il commento in oggetto.