Jaa

Vulnerabilità della sicurezza di ASP.NET: domande frequenti

  • Artikkeli

Questo post è una traduzione del post di Scott Guthrie, che fa seguito al suo primo post, in cui si descrive un workaround per una vulnerabilità della sicurezza di ASP.NET .

Due giorni fa è stato pubblicato un post che descrive una vulnerabilità della sicurezza di ASP.NET. All’interno vi è discusso un workaround che si consiglia di implementare per aiutare a prevenire eventuali attacchi che sfruttino tale vulnerabilità.

Sotto trovate una lista delle domande più comuni che riguardano questa vulnerabilità.

Microsoft sta per rilasciare un update con una fix a questa vulnerabilità?

Sì. Microsoft sta lavorando ad un update che verrà distribuito via Windows Update appena verrà testato e sarà pronto per la distribuzione.

Fino alla disponibilità dell’update, verranno pubblicati dei workaround (come quelli descritti nel post descritto all’inizio) che possono essere applicati immediatamente per aiutare a proteggersi da questa vulnerabilità. Tenete presente che il workaround è temporaneo e non sarà più necessario una volta pubblicata la fix. Ha l’obiettivo di fornire un immediato aiuto fino al rilascio dell’update.

E’ un problema di ASP.NET o di una vulnerabilità del sistema di crittografia?

E’ una vulnerabilità che riguarda come ASP.NET usa il sistema di crittografia che in alcune circostanze può rivelare informazioni utili ad un attacco tramite i codici di errori nella risposta http. L’uso che attualmente fa ASP.NET dei padding per la cifratura può essere sfruttato da un eventuale intruso. Questa vulnerabilità verrà corretta da un update sulla sicurezza.

Questa vulnerabilità affligge sia ASP.NET WebForm e ASP.NET MVC?

Sì, il tipo di attacco che è stato mostrato pubblicamente può essere portato a termine su tutti i tipi di applicazioni ASP.NET, sia ASP.NET WebForms che ASP.NET MVC.

Riguarda anche SharePoint?

Sì, il tipo di attacco che è stato mostrato pubblicamente può essere usato anche contro SharePoint 2010. Il team di SharePoint ha da poco pubblicato un post, che descrive un workaround che può essere utilizzato fino al rilascio dell’update.

Come si mostra un attacco sulla rete o nei log?

L’attacco mostrato in pubblico fa in modo che il web server generi migliaia (probabilmente centinaia di migliaia) di errori http 500 e 404 in risposta alle richieste di attacchi malevoli.

Potete usare filtri nel firewall o nei sistemi di rilevamento delle intrusioni sulla rete per trovare andamenti simili o bloccare gli attacchi da questi client. Il modulo Dynamic IP Restrictions module in IIS7 può anche essere usato per bloccare questi tipi di attacco.

Un tentativo di attacco potrebbe anche generare migliaia di warning nell’ application event log, simile a questo:

Event code: 3005

Event message: An unhandled exception has occurred.

Event time: 11/11/1111 11:11:11 AM

Application information:

    Application domain: c1db5830-1-129291000036654651

    Application Virtual Path: /

Exception information:

    Exception type: CryptographicException

    Exception message: Padding is invalid and cannot be removed.

Notate che questo warning può essere generato anche in caso di non-attacchi (ad esempio in caso in cui una web farm ci siano delle chiavi non allineate o un motore di ricerca stia seguendo dei link in modo non corretto), quindi un’eventuale presenza non sta ad indicare necessariamente un attacco.

L’eccezione, inoltre, non sta a indicare che un eventuale attacco abbia avuto successo. Utilizzando il workaround dei <customErrors> ci si può proteggere da eventuali attacchi e evitare che vengano mostrati questi dettagli o altri che possano essere sfruttati a fini malevoli.

Che cosa fa il woraround dei <customErrors>? Il workaround che potete usare per proteggere le applicazioni da eventuali attacchi è abilitare i <customErrors> di ASP.NET e configurare esplicitamente di ritornare sempre lo stesso errore nella risposta, indipendentemente dal tipo di errore che si è verificato nel server. Mappando tutte le pagine di errore in una singola pagina di errore, si rendere più difficile portare a termine un attacco distinguendo i tipi di errori che si verificano sul server.

Se state usando ASP.NET 3.5 SP1 o ASP.NET 4 il workaround fornisce ulteriori protezioni aiutando a mitigare contro attacchi che fanno analisi sui tempi di risposta. Il workaround usa l’opzione redirectMode="ResponseRewrite" nei <custom errors> introducendo dei tempi di risposta casuali. Questo approccio rende difficile stabilire il tipo di errore che si è verificato sul server misurando i tempi di risposta nel ricevere l’errore.

Posso configurare una pagina di errore custom 404 e un default redirect per tutti gli altri errori?

No. Facendo questo permetti ancora ad un attacco di distinguere tra errori 404 e gli altri. Rendere difficile la distinzione degli errori è un comportamento cruciale per mitigare l’attacco. Tenete presente che il workaround è temporaneo e non sarà più necessario una volta pubblicata la fix. Ha l’obiettivo di fornire un immediato aiuto fino al rilascio dell’update.

Sono vulnerabile se ho un mio modulo custom degli errori?

Se la risposta che viene generata dal modulo non permette al client di distinguere il tipo di errore sia dal contenuto che dal tempo in cui l’errore viene riportato, allora un tale modulo è adeguato e può rimpiazzare il workaroud. Se una delle due condizioni viene a mancare allora il modulo non è sufficiente. Invece deve essere sempre mandato lo stesso errore nella risposta per tutti gli errori che si possono verificare fino al rilascio dell’update.

Mi riguarda questo tipo di attacco se non memorizzo dati sensibili nel mio viewstate?

Sì. L’attacco mostrato pubblicamente può anche portare a rivelare informazioni del file web.config, comprese informazioni sensibili e non cifrate. Devi comunque applicare il workaround per bloccare l’attacco di tipo “padding oracle”. L’update correggerà questa vulnerabilità.

Quali sono le raccomandazioni da seguire per proteggere i miei dati nel web.config?

E’ sempre buona regola cifrare dati sensibili all’interno del file web.config. In questo modo anche se il contenuto del file fosse esposto, il contenuto non potrebbe essere usato. Questo documento su MSDN descrive come cifrare il web.config http://msdn.microsoft.com/en-us/library/zhhddkxy(VS.80).aspx. Questo tutorial fornisce altri esempi di come proteggere il contenuto del file: http://www.4guysfromrolla.com/articles/021506-1.aspx .

Perché ottengo un errore lanciando un file di script .vbs per la rilevazione della vulnerabilità?

Nel post iniziale di ScottGu, si faceva riferimento ad uno script .vbs che poteva essere usato contro un server per identificare una qualsiasi applicazione che aveva bisogno di aggiornare la sezione dei <customErrors> come descritto nel workaround.

Su IIS 7 questo script richiede che sia installata la management compatibility di IIS 6 per eseguire lo script. Per abilitarla, lancia l’Add/remove programs su una workstation e l’ Add Web Server Role Services su un sistema operativo server e selezionare IIS 6.0 Management Compatibility sotto “Internet Information Services”. Se questa componente è già installata lanciate lo script con privilegi amministrativi.

Conclusione

Vi terremo aggiornati sulla situazione. Potete leggere di più su questa vulnerabilità da questi link.

Domande specifiche su questa vulnerabilità possono essere inviate a questo forum.