Quanto è grave questa nuova vulnerabilità di sicurezza ASP.NET e come posso risolverla?

Ho appena letto in rete una vulnerabilità di sicurezza recentemente scoperta in ASP.NET. Puoi leggere i dettagli qui.

Il problema risiede nel modo in cui ASP.NET implementa l'algoritmo di crittografia AES per proteggere l'integrità dei cookie generati da queste applicazioni per archiviare informazioni durante le sessioni dell'utente.

Questo è un po 'vago, ma qui è una parte più spaventosa:

La prima fase dell'attacco richiede alcune migliaia di richieste, ma una volta che ha successo e l'attaccante ottiene le chiavi segrete, è totalmente invisibile. Le conoscenze crittografiche richieste sono molto basilari.

Tutto sommato, non ho abbastanza familiarità con il tema della sicurezza / crittografia per sapere se questo è davvero così serio.

Quindi, tutti gli sviluppatori ASP.NET dovrebbero temere questa tecnica che può possedere qualsiasi sito Web ASP.NET in pochi secondi o cosa?

In che modo questo problema influisce sullo sviluppatore ASP.NET medio? Ci riguarda affatto? Nella vita reale, quali sono le conseguenze di questa vulnerabilità? E, infine: esiste qualche soluzione alternativa che previene questa vulnerabilità?

Grazie per le tue risposte!

EDIT: Fammi riassumere le risposte che ho ricevuto

Quindi, questo è fondamentalmente un tipo di attacco "padding oracle". @Sri ha fornito un'ottima spiegazione sul significato di questo tipo di attacco. Ecco un video scioccante sul problema!

Informazioni sulla gravità di questa vulnerabilità: Sì, è davvero serio. Consente all'attaccante di conoscere la chiave della macchina di un'applicazione. Quindi, può fare alcune cose molto indesiderate.

• In posizione della chiave della macchina dell'app, l'utente malintenzionato può decrittografare i cookie di autenticazione.
• Ancora peggio, può generare cookie di autenticazione con il nome di qualsiasi utente. Pertanto, può apparire come chiunque sul sito. L'applicazione non è in grado di distinguere tra te o l'hacker che ha generato un cookie di autenticazione con il tuo nome.
• Gli consente anche di decrittografare (e anche generare) i cookie di sessione , sebbene non sia pericoloso come il precedente.
• Non così grave: può decrittografare il ViewState crittografato delle pagine. (Se usi ViewState per archiviare dati riservati, non dovresti farlo comunque!)
• Abbastanza inaspettato : con la conoscenza della chiave della macchina, l'attaccante può scaricare qualsiasi file arbitrario dall'applicazione Web, anche quelli che normalmente non possono essere scaricati! (Incluso Web.Config , ecc.)

Ecco alcune buone pratiche che non risolvono il problema ma aiutano a migliorare la sicurezza generale di un'applicazione Web.

• È possibile crittografare i dati sensibili con Configurazione protetta
• Usa solo i cookie HTTP
• Prevenire gli attacchi DoS

Ora concentriamoci su questo problema.

• Scott Guthrie ha pubblicato una voce al riguardo sul suo blog
• Post sul blog FAQ di ScottGu sulla vulnerabilità
• Aggiornamento di ScottGu sulla vulnerabilità
• Microsoft ha un avviso di sicurezza a riguardo
• Comprensione della vulnerabilità
• Ulteriori informazioni sulla vulnerabilità

La soluzione

• Abilita customErrors e crea una singola pagina di errore a cui vengono reindirizzati tutti gli errori . Sì, anche 404s . (ScottGu ha detto che la differenziazione tra 404s e 500s è essenziale per questo attacco.) Inoltre, nel tuo Application_Erroro Error.aspxmetti del codice che fa un ritardo casuale. (Genera un numero casuale e usa Thread.Sleep per dormire così a lungo.) Ciò renderà impossibile all'aggressore decidere cosa è successo esattamente sul tuo server.
• Alcune persone hanno raccomandato di tornare a 3DES. In teoria, se non si utilizza AES, non si riscontra la debolezza della sicurezza nell'implementazione di AES. A quanto pare, questo non è affatto raccomandato .

Alcuni altri pensieri

• Sembra che non tutti pensino che la soluzione alternativa sia abbastanza buona.

Grazie a tutti coloro che hanno risposto alla mia domanda. Ho imparato molto non solo su questo problema, ma sulla sicurezza web in generale. Ho contrassegnato la risposta di @ Mikael come accettata, ma anche le altre risposte sono molto utili.

Cosa devo fare per proteggermi?

[Aggiornamento 29/09/2010]

Bollettino Microsoft sulla sicurezza

Articolo KB con riferimento alla correzione

ScottGu ha collegamenti per i download

[Aggiornamento 25/09/2010]

Mentre aspettiamo la correzione, ieri ScottGu ha pubblicato un aggiornamento su come aggiungere un ulteriore passaggio per proteggere i tuoi siti con una regola URLScan personalizzata.

Inoltre, aggiungi un periodo di inattività casuale nella pagina degli errori per evitare che l'attaccante cronometri le risposte per ulteriori informazioni sull'attacco.

In web.config

<configuration>
 <location allowOverride="false">
   <system.web>
     <customErrors mode="On" defaultRedirect="~/error.html" />
   </system.web>
 </location>
</configuration>

Ciò reindirizzerà qualsiasi errore a una pagina personalizzata restituita con un codice di stato 200. In questo modo un utente malintenzionato non può consultare il codice di errore o le informazioni di errore per le informazioni necessarie per ulteriori attacchi.

È anche sicuro da impostare customErrors mode="RemoteOnly" , in quanto reindirizzerà i client "reali". Solo la navigazione da localhost mostrerà errori .Net interni.

La parte importante è assicurarsi che tutti gli errori siano configurati per restituire la stessa pagina di errore. Ciò richiede di impostare esplicitamente l' defaultRedirectattributo nella <customErrors>sezione e assicurarsi che non siano impostati codici per stato.

Cosa c'è in ballo?

Se un utente malintenzionato riesce a utilizzare l'exploit menzionato, può scaricare file interni dall'applicazione Web. In genere web.config è un obiettivo e può contenere informazioni riservate come le informazioni di accesso in una stringa di connessione al database, o persino un collegamento a un database sql-express automatizzato di cui non si desidera ottenere qualcuno. Ma se stai seguendo le migliori pratiche usi la Configurazione protetta per crittografare tutti i dati sensibili nel tuo web.config.

Collegamenti a riferimenti

Leggi il commento ufficiale di Microsoft sulla vulnerabilità all'indirizzo http://www.microsoft.com/technet/security/advisory/2416728.mspx . In particolare la parte "Soluzione alternativa" per i dettagli di implementazione su questo problema.

Anche alcune informazioni sul blog di ScottGu , incluso uno script per trovare app ASP.Net vulnerabili sul tuo server web.

Per una spiegazione su "Comprensione degli attacchi Oracle di riempimento", leggi la risposta di @ sri .

Commenti sull'articolo:

L'attacco che Rizzo e Duong hanno implementato contro le app ASP.NET richiede che l'implementazione della crittografia sul sito Web abbia un oracolo che, quando viene inviato il testo cifrato, non solo decodificherà il testo, ma darà al mittente un messaggio sul fatto che il riempimento nel testo cifrato è valido .

Se il riempimento non è valido, il messaggio di errore ricevuto dal mittente gli fornirà alcune informazioni sul modo in cui funziona il processo di decrittazione del sito.

Affinché l'attacco funzioni, deve essere vero quanto segue:

• L'applicazione deve fornire un messaggio di errore in merito al riempimento non valido.
• Qualcuno deve manomettere i cookie crittografati o il viewstate

Quindi, se nella tua app restituisci messaggi di errore leggibili come "Qualcosa è andato storto, per favore riprova" , dovresti essere al sicuro. Leggere un po 'i commenti sull'articolo fornisce anche informazioni preziose.

• Archivia un ID sessione nel cookie crittografato
• Archivia i dati reali nello stato della sessione (persistente in un db)
• Aggiungi un'attesa casuale quando le informazioni dell'utente sono errate prima di restituire l'errore, quindi non puoi cronometrarle

In questo modo un cookie dirottato può essere utilizzato solo per recuperare una sessione che molto probabilmente non è più presente o invalidata.

Sarà interessante vedere cosa viene effettivamente presentato alla conferenza Ekoparty, ma in questo momento non sono troppo preoccupato per questa vulnerabilità.

Comprensione degli attacchi Oracle di riempimento

Supponiamo che la tua applicazione accetti una stringa crittografata come parametro, indipendentemente dal fatto che il parametro sia un cookie, un parametro url o qualcos'altro non è rilevante. Quando l'applicazione tenta di decodificarlo, ci sono 3 possibili risultati:

1. Risultato 1 : la stringa crittografata è stata decodificata correttamente e l'applicazione è stata in grado di dargli un senso. Significato, se la stringa crittografata era un numero di conto di 10 cifre, dopo la decrittografia l'applicazione ha trovato qualcosa come "1234567890" e non "abcd1213ef"

2. Risultato 2 : il padding era corretto, ma dopo la decrittazione la stringa ottenuta era incomprensibile e l'app non riusciva a capire. Ad esempio, la stringa è stata decodificata in "abcd1213ef", ma l'app si aspettava solo numeri. La maggior parte delle app mostrerà un messaggio come "Numero account non valido".

3. Risultato 3 : il riempimento era errato e l'applicazione ha generato un messaggio di errore. La maggior parte delle app mostrerà un messaggio generico come "Si è verificato un errore".

Affinché un attacco di Padding Oracle abbia esito positivo, l'attaccante deve essere in grado di effettuare diverse migliaia di richieste e deve essere in grado di classificare la risposta in uno dei 3 bucket precedenti senza errori.

Se queste due condizioni sono soddisfatte, l'autore dell'attacco può eventualmente decrittografare il messaggio e quindi crittografarlo nuovamente con qualsiasi cosa desideri. È solo una questione di tempo.

Cosa si può fare per prevenirlo?

1. La cosa più semplice: qualsiasi cosa sensibile non dovrebbe mai essere inviata al client, crittografata o non crittografata. Tienilo sul server.

2. Assicurati che il risultato 2 e il risultato 3 nell'elenco sopra appaiano esattamente gli stessi per l'attaccante. Non dovrebbe esserci modo di capire l'uno dall'altro. Questo non è poi così facile - un attaccante può discriminare usando un qualche tipo di attacco temporizzato.

3. Come ultima linea di difesa, avere un Web Application Firewall. L'attacco all'oracolo di riempimento deve fare diverse richieste che sembrano quasi simili (cambiando un bit alla volta), quindi dovrebbe essere possibile per un WAF catturare e bloccare tali richieste.

PS Una buona spiegazione di Padding Oracle Attacks è disponibile in questo post del blog . Disclaimer: NON è il mio blog.

Da quello che ho letto fino ad ora ...

L'attacco consente a qualcuno di decrittografare i cookie sniffati, che potrebbero contenere dati preziosi come i saldi bancari

Hanno bisogno del cookie crittografato di un utente che ha già effettuato l'accesso, su qualsiasi account. Devono anche trovare dati nei cookie - spero che gli sviluppatori non memorizzino i dati critici nei cookie :). E c'è un modo che ho di seguito per non lasciare che asp.net memorizzi i dati nel cookie di accesso.

Come si può ottenere il cookie di un utente che è online se non mette le mani sui dati del browser? O annusare il pacchetto IP?

Un modo per impedirlo è quello di non consentire il trasporto dei cookie senza la crittografia SSL.

<httpCookies httpOnlyCookies="true" requireSSL="true" />

Anche un'altra misura è quella di impedire la memorizzazione dei ruoli nei cookie.

<roleManager enabled="true" cacheRolesInCookie="false">

Ora, riguardo ai cookie che non sono sicuri per le pagine normali, è necessario un po 'di più pensando a cosa hai lasciato fare al tuo utente e cosa no, come ti fidi di lui, quale controllo extra puoi fare (ad esempio se vedi un cambiamento sull'ip , forse smetti di fidarti di lui fino a quando non accedi nuovamente dalla pagina di sicurezza).

Riferimento:
un hacker può rubare il cookie da un utente e accedere con quel nome su un sito web?

Come controllare da dove provengono gli attacchi e non restituire informazioni. Ho scritto qui un modo semplice per impedire il riempimento non valido e la registrazione allo stesso tempo per rintracciare gli aggressori: CryptographicException: Il riempimento non è valido e non può essere rimosso e la convalida del viewstate MAC non è riuscita

Il modo per rintracciare l'attaccante è verificare che il riempimento non sia valido. Con una semplice procedura puoi rintracciarli e bloccarli - hanno bisogno di alcune migliaia di chiamate sulla tua pagina per trovare la chiave!

Aggiornamento 1

Ho scaricato lo strumento che suppone che trovi il KEY e decifrare i dati, e come ho detto la sua trap sul codice sopra che controlla il viewstate . Dai miei test questo strumento ha molti altri da correggere, ad esempio non è possibile scansionare lo stato di visualizzazione compresso così com'è e il suo arresto anomalo nei miei test.

Se qualcuno prova a utilizzare questo strumento o questo metodo, il codice sopra riportato può rintracciarli e puoi bloccarli fuori dalla tua pagina con un codice semplice come questo "Previeni Denial Of Service (DOS)" , o come questo codice per prevenire Negazione di servizio .

Aggiornamento 2

Sembra da quello che ho letto fino ad ora che l'unico pensiero che sia davvero necessario per non dare informazioni sull'errore e semplicemente posizionare una pagina di errore personalizzata e se ti piace puoi semplicemente creare e un ritardo casuale a questa pagina.

un video molto interessante su questo problema.

Quindi tutto quanto sopra è più misura per più protezioni ma non è necessario al 100% per questo particolare problema. Ad esempio, utilizzare ssl cookie è risolvere il problema snif, non memorizzare nella cache i ruoli nei cookie è utile non inviare e recuperare cookie di grandi dimensioni, ed evitare quelli che hanno tutti pronto a decifrare il codice, per posizionare il ruolo di amministratore il suo biscotto.

Il viewstate traccia solo un'altra misura per trovare l'attacco.

Ecco la risposta alla SM. Tutto si riduce a "utilizzare una pagina di errore personalizzata" e non ti daremo alcun indizio.

EDIT
Ecco alcune informazioni più dettagliate da scottgu.

Aggiunta delle risposte di ScottGu tratte dalla discussione su http://weblogs.asp.net/scottgu/archive/2010/09/18/important-asp-net-security-vulnerability.aspx

È interessato IHModule personalizzato invece di customErrors?

D: Non ho un elemento dichiarato nel mio web.config, ho invece un IHttpModule all'interno della sezione. Questo modulo registra l'errore e reindirizza a una pagina di ricerca (per 404) o a una pagina di errore (per 500). Sono vulnerabile?

A: Consiglio di aggiornare temporaneamente il modulo per reindirizzare sempre alla pagina di ricerca. Uno dei modi in cui funziona questo attacco è la ricerca di una differenziazione tra 404 e 500 errori. Restituire sempre lo stesso codice HTTP e inviarlo nello stesso posto è un modo per aiutarlo a bloccarlo.

Si noti che quando la patch viene rilasciata per risolvere questo problema, non sarà necessario farlo (e è possibile ripristinare il vecchio comportamento). Ma per ora consiglierei di non differenziare tra 404 e 500 per i clienti.

Posso continuare a utilizzare diversi errori per gli errori 404 e 500?

D: Presumo che possiamo ancora definire una pagina 404 personalizzata oltre al reindirizzamento predefinito in caso di errore, senza violare i principi sopra descritti?

A: No - fino a quando non rilasciamo una patch per la correzione reale, raccomandiamo la soluzione precedente che omogeneizza tutti gli errori. Uno dei modi in cui funziona questo attacco è la ricerca di una differenziazione tra 404 e 500 errori. Restituire sempre lo stesso codice HTTP e inviarlo nello stesso posto è un modo per aiutarlo a bloccarlo.

Si noti che quando la patch viene rilasciata per risolvere questo problema, non sarà necessario farlo (e è possibile ripristinare il vecchio comportamento). Ma per ora non dovresti distinguere tra 404 e 500 tra i clienti.

In che modo ciò consente l'esposizione di web.config?

D: In che modo ciò consente l'esposizione di web.config? Questo sembra abilitare solo la decodifica di ViewState, esiste un'altra vulnerabilità correlata che consente anche la divulgazione delle informazioni? Esiste un white paper che descrive in dettaglio l'attacco per una migliore spiegazione di ciò che sta accadendo?

A: L'attacco mostrato al pubblico si basa su una funzionalità di ASP.NET che consente di scaricare file (in genere javascript e css) e che è protetto con una chiave inviata come parte della richiesta. Sfortunatamente se sei in grado di forgiare una chiave puoi usare questa funzione per scaricare il file web.config di un'applicazione (ma non i file al di fuori dell'applicazione). Rilasceremo ovviamente una patch per questo - fino ad allora la soluzione precedente chiude il vettore di attacco.

EDIT: FAQ aggiuntive disponibili nel secondo blog post su http://weblogs.asp.net/scottgu/archive/2010/09/20/frequently-asked-questions-about-the-asp-net-security-vulnerability.aspx

IMO, non esiste una prevenzione generalizzata per questo, deve essere gestita caso per caso:

http://www.onpreinit.com/2010/09/aspnet-vulnerability-workaround-flawed.html

Alcuni link significativi:

• Advisory MS 2416728 sulla sicurezza (queste sono le informazioni ufficiali)
• Ulteriori informazioni dal team di ricerca e difesa sulla sicurezza di MS
  • "Comprensione della vulnerabilità ASP.NET" (17/09/2010)
  • "Ulteriori informazioni sulla vulnerabilità ASP.NET" (20/09/2010)
• Scott Gu: "Importante: vulnerabilità legata alla sicurezza ASP.NET" (18/09/2010)

[Per rispondere all'aspetto di gravità di questo (ciò che è stato pubblicato e le soluzioni alternative sono coperte da altre risposte).]

La chiave che viene attaccata viene utilizzata per proteggere sia i cookie di stato che quelli di sessione. Normalmente questa chiave viene generata internamente da ASP.NET con ogni nuova istanza dell'app Web. Ciò limiterà l'entità del danno alla durata del processo di lavoro, ovviamente per un'applicazione occupata potrebbero essere giorni (ovvero non un limite). Durante questo periodo l'attaccante può modificare (o iniettare) i valori in ViewState e modificare la propria sessione.

Ancora più seriamente se si desidera che le sessioni siano in grado di estendere la durata dei processi dei lavoratori o consentire alle web farm (ovvero tutte le istanze della farm in grado di gestire qualsiasi sessione utente) la chiave deve essere codificata, questo viene fatto in web.config:

[...]
  <system.web>
    <machineKey
        decryption="AES"
        validation="SHA1"
        decryptionKey="57726C59BA73E8A4E95E47F4BC9FB2DD"
        validationKey="158B6D89EE90A814874F1B3129ED00FB8FD34DD3"
      />

Quelle sono, ovviamente, chiavi appena create, utilizzo il seguente PowerShell per accedere al generatore di numeri casuali crittografici di Windows:

$rng = New-Object "System.Security.Cryptography.RNGCryptoServiceProvider"
$bytes = [Array]::CreateInstance([byte], 20)
$rng.GetBytes($bytes)
$bytes | ForEach-Object -begin { $s = "" } -process { $s = $s + ("{0:X2}" -f $_) } -end { $s}

(Utilizzando una lunghezza di array di 20 per la convalida e 16 per le chiavi di decrittazione.)

Oltre a modificare le pagine di errore pubbliche per non perdere l'errore specifico, sembrerebbe un buon momento per cambiare le chiavi di cui sopra (o cicli i processi di lavoro se sono in esecuzione da un po ').

[Modifica 21/09/2010: collegamenti aggiunti all'inizio]

Ho appena pubblicato la mia opinione completa su questo nel mio blog , dopo ulteriori ricerche sul problema. Penso che sia importante chiarire perché stanno arrivando a forgiare un cookie di autenticazione.

Voglio solo chiarire alcuni fatti:

1. attacco non ti consente di ottenere direttamente la chiave della macchina. Detto questo, è praticamente come aveva fatto, poiché consente di decrittografare i messaggi e di modificarli / crittografarne di nuovi.
2. il modo in cui ottenere le chiavi effettive è usando la loro capacità di modificare re / crittografare come in 1 e ottenere web.config. Sfortunatamente ci sono ragioni per cui alcuni inseriscono queste chiavi in ​​web.config a livello di sito (discussione diversa) e nel video di esempio traggono vantaggio dal fatto che è l'impostazione predefinita di DotnetNuke.
3. per ottenere tutto il web.config indica che stanno usando webresources.axd e / o scriptresources.axd. Pensavo che funzionassero solo con risorse incorporate, ma sembra che non sia così.
4. se l'app è asp.net MVC non abbiamo davvero bisogno di webresources.axd e / o scriptresources.axd, quindi quelli possono essere disattivati. Inoltre non utilizziamo viewstate. Detto questo, non mi è chiaro se una qualsiasi delle altre funzionalità di asp.net fornisce informazioni diverse con la soluzione alternativa in atto, cioè non so se il riempimento fornisce risultati non validi in errore mentre il riempimento include risultati validi nel ticket di autenticazione ignorato (non lo so se è o meno il caso) ... la stessa analisi dovrebbe essere applicata al cookie di sessione.
5. I ruoli del provider di appartenenze asp.net "memorizzano nella cache" i cookie, disattivalo.

Circa 1, dopo che i messaggi crittografati non possono essere arbitrari al 100%, è necessario tollerare un piccolo pezzo di immondizia da qualche parte nel messaggio, poiché nel messaggio è presente un blocco che decodifica il valore che non può essere controllato.

Infine, vorrei dire che questo problema è dovuto al fatto che ms non segue le proprie indicazioni in questo caso: una funzione si basa sul fatto che qualcosa inviato al client sia a prova di manomissione.

Più su:

Non so se il riempimento fornisce risultati non validi in caso di errore, mentre il riempimento genera risultati validi nel ticket di autenticazione ignorato (non so se è il caso o meno) ... la stessa analisi dovrebbe essere applicata al cookie di sessione.

Il cookie di autenticazione è firmato e dalle informazioni nel documento non dovrebbero essere in grado di generare un cookie firmato se non ottengono le chiavi effettive (come hanno fatto nel video prima di forgiare il cookie di autenticazione).

Come menzionato Aristos, per l'id di sessione nel cookie, è casuale per la sessione dell'utente, quindi dovrebbe essere annusato da un utente con il livello di sicurezza di destinazione e decifrato mentre quella sessione è attiva. Anche in questo caso, se fai affidamento sull'autenticazione per assegnare / autorizzare le operazioni dell'utente, l'impatto sarebbe minimo / dipenderà molto da ciò per cui Session viene utilizzata in quell'app.

Una patch per questo bug è stata rilasciata su Windows Update: http://weblogs.asp.net/scottgu/archive/2010/09/30/asp-net-security-fix-now-on-windows-update.aspx

Anche Asp.Net MVC è interessato da questo problema (come Sharepoint, ...)

Ho coperto la correzione per MVC qui: ASP.NET MVC è vulnerabile all'attacco di riempimento dell'oracolo?