La conferma di Microsoft: un aggressore potrebbe avere acceso a dati importanti memorizzati sui serve. Ecco la soluzione temporanea in attesa del fix
Trovato un brutto spiffero in ASP.NET. Lo conferma Microsoft che ha pubblicato un bollettino ufficiale per spiegare l’entità del problema e la minaccia che potrebbe incombere su coloro che eseguono applicazioni .NET sui loro server web.
I tecnici di Microsoft hanno spiegato che un aggressore in grado di sfruttare la vulnerabilità presente in tutte le versioni di ASP.NET potrebbe riuscire ad avere accesso a dati importanti che, normalmente, sono crittografati da parte del server.
Il malintenzionato potrebbe così mettere gli occhi su “ViewState” (conserva lo stato della pagina dopo la sua ultima elaborazione ed è impiegato per mantenere informazioni sulla configurazione di ciascun controllo presente all’interno della medesima pagina) o leggere altre informazioni dal server web preso di mira (ad esempio, il contenuto del file web.config).
Dal momento che il colosso di Redmond ha già rilevato i primi attacchi nei confronti della vulnerabilità, i rappresentanti dell’azienda suggeriscono ad utenti ed amministratori di sistema di adottare alcune soluzioni temporanee, almeno sino a quando non verrà rilasciata una patch correttiva.
Una pratica soluzione temporanea
Sia Scott Guthrie che Pietro Brambati per il nostro Paese, hanno voluto offrire una disamina più puntuale del problema proponendo alcune soluzioni pratiche.
Innanzi tutto, viene precisato che la vulnerabilità recentemente individuata affligge tutti i generi di applicazioni ASP.NET (sia ASP.NET Web Forms che ASP.NET MVC) ed interessa anche SharePoint.
L’aggressore, inviando testo cifrato al server web quindi analizzando quanto ricevuto in risposta, può arrivare a carpire dati importanti esaminando l’errore restituito dallo stesso server.
A coloro che utilizzano ASP.NET su un web server, viene suggerito di abilitare la caratteristica “errori personalizzati” e fare in modo che le applicazioni in uso restituiscano sempre il medesimo messaggio d’errore.
Guthrie suggerisce le modifiche da apportare al file web.config di ciascuna applicazione ASP.NET per fare in modo che sia uno solo l’errore esposto da IIS quando ciò dovesse risultare necessario.
Per verificare il corretto funzionamento del “workaround“, è sufficiente digitare – nella barra degli indirizzi del browser -: http://vostrositoweb.abc/paginainesistente.aspx.
Se apparirà il messaggio d’errore “personalizzato” (si dovrà aver cura di digitare l’URL del sito web ed il nome di un file ASPX inesistente), si sarà al riparo da eventuali attacchi. Viceversa, nel caso in cui dovesse apparire un errore ASP.NET standard, significa che il server web è ancora potenzialmente vulnerabile (non si sono seguiti tutti i passi consigliati da Guthrie).
Un apposito script VBS preparato da Microsoft permette di stabilire rapidamente per quali applicazioni ASP.NET la direttiva “customErrors” risulti disattivata o comunque in quali situazioni venga esposto un messaggio d’errore differente a seconda dello specifico codice di stato.
