Già nel settembre dello scorso anno abbiamo visto l'emergere della vulnerabilità imbottitura oracolo che improvvisamente ha un sacco di sviluppatori ASP.NET molto nervoso. La preoccupazione reale con questa vulnerabilità è che in realtà non era molto che si possa fare a livello di codice al di là di un paio di modifiche poco - quello che era realmente necessario era per le patch per avere installato sul server e veloce .
Il problema allora era che, beh, non si poteva sempre fidarti del tuo fornitore di hosting .Hosting provider prendere tutti i tipi di forme diverse; server aziendali gestite da gruppi IT, macchine dedicate con gli host dedicato, condiviso co-affittato macchine e ora sempre più spesso, le soluzioni cloud based. Ma una cosa è rimasta costante e che è stato che la patch di Microsoft ha subito rilasciato necessario per ottenere sulla macchina.
Allora ho parlato sul mio blog su come rilevare a distanza i patch. Ma quello che non parlavaera che avevo scritto un app per automatizzare questo controllo. Come molti con la responsabilità di una serie di siti, ero troppo occupati a fare le cose che sono patchati per ottenere quel piccolo pezzo di software in una forma adatta per la condivisione. Oggi le cose sono un po 'diversa ...
Benvenuti ASafaWeb (di nuovo)
Ho introdotto ASafaWeb al mondo solo poche settimane fa. L'obiettivo era creare una molto semplice, molto facile consumo e gratuito strumento che permetterebbe di eseguire la scansione alla ricerca di vulnerabilità di configurazione di ASP.NET e aiutare ad educare gli sviluppatori. Ciò che non ho detto fino ad ora è che ASafaWeb ha le sue origini ai tempi vulnerabilità oracolo imbottitura, i concetti che ho usato per automatizzare le scansioni allora sono stati riutilizzati e, mentre la base di codice è tutto nuovo, lo scopo rimane.
Che cosa questo significa per la situazione hash DoS è che è stato molto semplice per aggiungere una scansione per la vulnerabilità di ASafaWeb. Si prega di notare che questa non è una scansione che sfrutta la vulnerabilità , piuttosto è una scansione che verifica la presenza della patch di Microsoft. Più su quello a breve, cerchiamo di ricapitolare in fretta su ciò che questa situazione hash DoS è tutto per primo.
Di fondo: qual è l'hash DoS e perché dovrebbe interessarti?
Questo è in realtà un attacco semplice ed elegante piccolo con conseguenze potenzialmente gravi. Il modo migliore per capire veramente di cosa si sta per vedere il video qui sotto diAlessandro Klink e Julian Zeri dal Chaos Communication Congress di Berlino all'inizio di questa settimana:
Comprendere tutto questo? Bene! No? Ecco il tl; versione dr:
Una tabella hash è una struttura dati che associa chiavi a valori. E 'una struttura particolarmente efficiente di dati ed è d'uso comune attraverso molti linguaggi di programmazione. Questa struttura dati è utilizzato in ASP.NET per memorizzare i parametri ricevuti in una richiesta POST (quello che avevamo normalmente pensiamo come "dati del modulo"). Fin qui, tutto bene.
Il problema è però che quando due o più stringhe sono hash, c'è il potenziale per creare ciò che è indicato come un collisione hash che significa semplicemente i due ingressi discreti valori sia finire con lo stesso valore hash. Questo da solo non è un grosso problema e non ci sono meccanismi integrato nel framework come ASP.NET per gestire questo scenario quando si verifica.
Ma il vero problema è che se si creano collisioni abbastanza hash dai parametri di forma abbastanza allora la CPU va, bene, un po 'di noci. Come i dadi? Questi due scivoli dai ragazziriassumere quanto pochi sono i dati necessari da inviare al fine di mantenere un sacco di CPU troppo occupato a fare altro:
Ora, il problema è che una volta che le CPU sono troppo occupati a fare qualsiasi lavoro legittimo, è effettivamente un attacco denial of service o "DoS". In termini semplici, il vostro sito è farcito, ma semplicemente non risponde più.
Ma il vero problema è che sfruttando questa vulnerabilità è morto semplice , tutto quello che dovete fare è inviare i dati del modulo diritto di un sito vulnerabile. C'è già un esempio molto semplice di come sfruttare questa contro PHP qui . In questo esempio, ci sono 65.536 valori forma (beh in realtà, sono solo nomi senza alcun valore), quindi non stiamo parlando di piccoli numeri qui. Questo è ciò che stiamo cercando:
- EzEzEzEzEzEzEzEz =
- & EzEzEzEzEzEzEzFY =
- & EzEzEzEzEzEzEzG8 =
- & EzEzEzEzEzEzEzH% 17 =
- ...
Sarebbe un gioco da ragazzi per costruire una richiesta HTTP in questo modo quindi è una vulnerabilità molto facilmente sfruttato davvero.
Patch di Microsoft
Alessandro e Giuliano effettivamente rivelato la vulnerabilità a Microsoft il 29 novembre, ben prima della loro presentazione. Fortunatamente c'è stato abbastanza tempo per una patch per essere preparato ed è ora disponibile come parte del Microsoft Security Bulletin MS11-100 , insieme a un paio di altri pezzi.
Nel video qui sopra, è suggerito che le tecniche di mitigazione potrebbe includere modifiche al comportamento di hashing, l'applicazione di un limite ai cicli della CPU richiesta potrebbe consumare e limitando il numero di parametri che possono essere inviati ad una pagina. E 'quest'ultimo che Microsoft ha implementato nel loro patch.
Testing della patch
Ciò che Microsoft ha fatto è impostare il limite di variabili forma in una richiesta POST a 1.000. Non più di questo e si sta andando ad un errore che sembra proprio così:
Beh in realtà, si dovrebbe avere errori personalizzati configurato correttamente in modo che i visitatori non vedere un errore come questo. Lo schermo di cui sopra è dal sito di prova volutamente insicuro per ASafaWeb a isnot.asafaweb.com e ho appena postato 1.001 variabili forma ad esso. Questo sito gira su AppHarbor che in maniera molto efficienteapplicata questa patch entro poche ore è stato rilasciato.
Il modo in cui il test per la patch funziona è che i messaggi ASafaWeb semplicemente una richiesta con 1.001 nomi in sequenza incrementando forma variabile in questo modo:
- 0 =
- & 1 =
- & 2 =
- & 3 =
- ... Tutta la strada fino a "& 1000 ="
Questo non è destinato a provocare una collisione hash! Questo è molto importante come il gol con ASafaWeb è sempre stato quello di bel gioco con i siti la scansione. Questa richiesta è semplicemente destinato a vedere se il sito processi felicemente la richiesta o se si genera un errore. Come messaggi di errore possono prendere tutte le forme e le forme e può essere restituito entro un successo codice di stato HTTP (a 200), ASafaWeb sta cercando di vedere che la risposta di questa richiesta è diversa da quella risposta da una semplice richiesta GET alla stessa pagina.
Prima che le risposte vengono confrontati, un po 'di pulizia va avanti per eliminare le differenze biologiche avrai da legittime richieste successive alla stessa pagina (ad esempio pubblicità diversa, Stati Vista, ID di forma, ecc) Questo è lo stesso processo utilizzato di test per la convalida delle richieste di applicazioni web forme e ha dimostrato di essere abbastanza affidabile, anche se non infallibile.
Riassunto
Ho cercato di girare intorno a questa scansione piuttosto in fretta perché so le persone sono ansiose e vogliono testare i loro siti. Ho assorbito il più possibile da Alessandro e Giuliano, Microsoft e il flusso infinito di tweet comunità e credo che le informazioni di cui sopra - e il test ASafaWeb scan - è accurato. Ho anche provato un sacco di siti che conosco o fare o non hanno installato la patch ed i risultati della scansione sono stati coerenti con lo stato delle patch note. Ma, come sempre, se sbaglio in un punto qualsiasi, per favore fatemelo sapere, così posso fare le cose sul binario giusto.
Nessun commento:
Posta un commento