5 interessanti tendenze della sicurezza di Verizon del 2012 violazione dei dati del report

Poche settimane fa ci fu un grande documento rilasciato da Verizon (sì, la grande telco americana) dal titolo Verizon 2012 Data Breach Investigations report . Questo fine settimana alla Conferenza AppSec OWASP Asia Pacifica , mi sono seduto su un talk da Mark Goudie da Verizon che ha contribuito a mettere l'intera relazione in prospettiva. Ora, questa è una relazione molto interessante, perché invece di parlare di vulnerabilità (cioè potenziali rischi), stanno in realtà guardando exploit, questo è fatti duri, la gente!

Questa relazione si basa su 855 incidenti nel 2011 (non essere confuso con l'anno nel titolo!) E perché Verizon lo fa ogni anno, c'è un sacco di dati su come le tendenze stanno cambiando. E 'anche 80 pagine di fatti concreti che possono essere un bel po' per digerire.Ma ci sono alcuni veramente interessanti nuggets in là per coloro che prendono un po 'di interesse per la sicurezza. Lasciatemi cherry-pick alcuni dei buoni.

1. Le violazioni sono (quasi) non è più provenienti dall'interno dell'organizzazione

Non molto tempo fa che la credenza comune (e c'erano un sacco di numeri appoggiano questo up), era che una porzione significativa di violazioni derivava dall'interno dell'organizzazione. Dipendenti scontenti, i ammutinati opportunisti, quelli off di pascoli più verdi afferrare una manciata di dati sulla loro via d'uscita - qualunque cosa - ma è ormai una storia molto diversa:

Chi c'è dietro violazioni dei dati?
Il 98% derivava da agenti esterni (+6%)	Nessuna grande sorpresa qui; estranei stanno ancora dominando la scena del furto di dati aziendali. Criminalità organizzata sono stati all'altezza delle loro malefatte tipiche ed erano dietro la maggior parte delle violazioni nel 2011. Gruppi di attivisti hanno creato il loro giusta quota di miseria e caos anche l'anno scorso, e hanno rubato più dati di qualsiasi altro gruppo. Il loro ingresso sul palco anche servito a cambiare il paesaggio un po 'per quanto riguarda le motivazioni che stanno dietro violazioni. Mentre il buon vecchio avidità e avarizia sono ancora i motori primi, dissenso ideologico e schadenfreude ha un ruolo più importante in tutto il carico di lavoro. Come ci si potrebbe aspettare con un aumento attaccanti esterni, la percentuale di incidenti insider rifiutato ancora una volta quest'anno ad un relativamente scarso 4%.
4% dipendenti coinvolti interni (-13%)
<1% commesso da partner commerciali (<>)
58% di tutti i furti di dati legato a gruppi di attivisti

Tornando al commento precedente che gli attacchi in precedenza spesso provenienti dall'interno, dare un'occhiata a come i dati è cambiato nel tempo:

Minaccia gli agenti nel tempo per cento delle violazioni:

O, per dirla in altro modo, violazioni originarie internamente sono ormai solo il 12% di quello che erano qualche anno fa e violazioni da parte dei partner sono vicino inesistente. I cattivi sono ora veramente bene e all'esterno dell'organizzazione - ma sono ancora ottenere il poll

Oh - e nel caso ti stai chiedendo perché il 98% più il 4% più l'1% ammonta a più del 100%, alcune violazioni abbracciano entrambi i giocatori esterni ed interni. Per esempio, qualcuno esterno socialmente qualcuno ingegneri interna a divulgare le proprie credenziali. Ha senso adesso!

2. Hacktivisti stanno diventando seriamente cattive notizie

Questo non dovrebbe essere una sorpresa, ma il numero di cui sopra è ancora allarmante, il 58% dei furti di dati era legata alle persone che pretendono di svolgere le loro attività illegali sulla base di una qualche forma di credenza attivista. Francamente, quando si guarda demografica di coloro che vengono colti in flagrante (spesso adolescenti o primi anni '20), ho il sospetto che, mentre queste persone sono facilmente si allegando a gruppi hacktiviste come anonimo e LulzSec, è di più guadagnando un po 'di notorietà e avendo qualche lulz di quello che è sulla lotta per una causa.

Dalla relazione:

Il cambiamento più significativo che abbiamo visto nel 2011 è stato l'aumento di "hacktivism" contro le organizzazioni più grandi in tutto il mondo.

Indipendentemente dalle motivazioni di hacker attivisti, resta il fatto che ci sia un'ondata di persone là fuori la fila per prendere un colpo a quasi ogni sito web che possono mettere le mani su. Non hanno bisogno l'incentivo finanziario di criminali veri o gli obiettivi politici e militari degli Stati nazionali, hanno solo bisogno di un bersaglio facile. Francamente, per proprietari di siti web, questo il targeting indiscriminata dovrebbe essere piuttosto preoccupante.

3. La maggior parte delle violazioni sono legate al furto delle credenziali semplice

Ecco un interessante, come pensi che la maggior parte degli hack sono in corso in questi giorni? Alcuni funky SQLI? Subdolo exploit 0-day? Non proprio:

Azione tipi di minacce per numero di violazioni

Varietà	Categoria	Violazioni
L'uso di credenziali di accesso rubate	Hacking	30%
Backdoor (consente l'accesso remoto / controllo)	Malware	18%
Sfruttamento delle backdoor o di comando e canale di controllo	Hacking	17%
Manomissione	Fisico	17%
Keylogger / Form-grabber / Spyware (acquisire i dati da attività degli utenti)	Malware	13%
Pretexting (classico social engineering)	Sociale	12%
La forza bruta e gli attacchi del dizionario	Hacking	8%
SQL injection	Hacking	8%
Phishing (o qualsiasi tipo di ishing *)	Sociale	8%
Comando e controllo (ascolta ed esegue i comandi)	Malware	8%

L'utilizzo di credenziali rubate è, relativamente parlando, fuori dal grafico. Quasi un terzo delle violazioni coinvolto il furto di credenziali (tra gli altri vettori - un altro di questi fa-non-add-up-to-100 scenari%), che è abbastanza sorprendente. Dico questo perché le credenziali, ovviamente, una volta che si ottengono, il termine "hack" si può essere molto ingenuo davvero.

Naturalmente il problema più grande che si pone è: "Come sono queste le credenziali rubate?" La relazione allude a keylogger e spyware che sono da biasimare in modo nuovo, queste violazioni sono spesso il risultato di una serie di incidenti si aprono varie porte che conducono fino ai dati di eventuali violazione.

4. Tu sei così più probabilità di essere socialmente ingegnerizzato da parlare con qualcuno che via e-mail

Il social engineering è ciò che accade via e-mail, giusto? Intendo dire che c'è una credenza comune che la moderna ingegneria sociale è qualcosa che ha le sue radici prevalentemente on-line - o forse era solo la mia convinzione. I numeri, tuttavia, dipingono una storia molto diversa:

Vettori sociali per cento delle violazioni all'interno di Social

Ciò che mi sembra sorprendente, con questi numeri è che i vettori di telefono e di persona sia in realtà coinvolgono parlando e verbalmente impegnarsi con la vittima. Il velo di anonimato fornito via e-mail e siti di networking sociale non c'è, l'attaccante deve rispondere sul posto con credibilità ed effettivamente convincere la loro vittima di divulgare informazioni o svolgere attività che non avrebbero (o almeno non dovrebbe ) normalmente non .

D'altra parte, nessuno si aspetta l'inquisizione spagnola , far sentire la voce - o anche un volto - ad un attaccante dà loro un enorme gambe-up nel corso di un e-mail di phishing casuale quando si tratta di stabilire effettivamente una certa credibilità. Di recente ho lettoSpirito Kevin Mitnick nei fili e se si considera con quanta facilità è riuscito a conquistare la fiducia e sfruttare la natura buona condotta le sue vittime contro il loro giudizio migliore, le cifre di cui sopra, forse non sembrano poi così sorprendente.

5. Violazioni richiede solo pochi minuti ma sono scoperti dopo mesi - e poi prendono molto tempo per risolvere

Quanta fatica ci si effettivamente prendere di violare un bersaglio vulnerabile? A quanto pare si può misurare in minuti:

Timespan di eventi per cento delle violazioni

La maggior parte significativa dei risultati che rientrano nella categoria "Minutes" suggeriscono che la maggior parte delle violazioni registrate da Verizon sono cose molto semplici. Stiamo parlando di 85% di loro prendendo minuti o anche meno (presumo "Seconds" implicherebbe una qualche forma di automazione).

Ma l'altro fatto straordinario: ecco quanto tempo ci vuole per scoprire in realtà il compromesso dopo il fatto: "Mesi" è molto sanguinosa tempo! Così qualcuno si è rotto dentro, rubati i dati e per il momento te ne accorgi, sono andati looooong.

L'ultima riga è anche preoccupante perché si dice che più della metà del tempo che ci vuolealmeno qualche settimana per tappare completamente il buco e tornare al business as usual.Pensate l'impatto sul business di questo - stiamo prendendo un importante risultato negativo in molti di questi casi.

Sai cosa più interessante è stat? E 'quello che non è nel grafico sopra, ma sarebbe semplicemente intitolato "Gli attacchi che sono stati mai scoperti ". Ora, naturalmente, per sua stessa natura non abbiamo mai andremo a vedere questo tracciato, ma il fatto stesso che il più delle volte non prende mese per scoprire una violazione, ci sono indubbiamente un numero significativo che vanno da scoprire. Forever. In effetti, la relazione fa un accenno a questo:

Noi ipotizziamo che i reati di insider molti non vengono denunciati perché l'organizzazione non è a conoscenza di loro, o perché decidono per motivi politici da gestire internamente.

Ti fa meraviglia che è stato nei vostri sistemi, senza mai neanche accorgersi, non è vero?

Altri bocconcini interessanti

Sulla conformità PCI:

Dobbiamo ancora sentire il mantra comune "Come avrei potuto, sono stati violati? I'm-compliant!" Non possiamo sottolineare abbastanza che mentre la conformità aiuta sicuramente la sicurezza dell'unità, il rispetto della sicurezza non è uguale.

Qualcuno davvero pensa che sia compatibile con PCI da solo significa che sei "unhackable"?!Ho il sospetto che i grandi appelli adesivo di conformità a coloro che forse non hanno un grande apprezzamento dei punti più fini di sicurezza del software e sono questi stessi individui che sono citati in precedenza. Proprio sayin '.

Sulla varietà di attacchi di hacking:

Come ogni anno, una manciata di tecniche dominano le classifiche.Generalmente, la hit parade può essere suddivisa in gli attacchi di autenticazione, e attacchi tecnici che ignorano o rompere l'autenticazione del tutto.

Ora questo copre tutto da sfruttare default (yes - di default!) Credenziali o indovinare, l'utilizzo delle credenziali rubate e brute sistemi di autenticazione forzatura. E 'interessante accostare questo con la OWASP Top 10 , senza l'iniezione, non XSS (la "Top 2"), piuttosto il suo terzo sulla lista - "Errore di autenticazione e gestione delle sessioni".

Relativa agli attacchi contro organizzazioni di grandi dimensioni:

Quindi, per quanto riguarda le organizzazioni più grandi? Sicuramente sono molto più difficili da infiltrare, giusto? Purtroppo, i nostri dati sembrano suggerire il contrario, ma non sembra che i criminali informatici devono lavorare molto più duramente di compromettere le organizzazioni più grandi di quanto non facciano per quelli più piccoli.

Francamente, penso che le ipotesi circa le organizzazioni più grandi che sono obiettivi di attacchi più duri è una follia. Sappiamo da studi precedenti che la stragrande maggioranza delle violazioni si verificano a livello di software e il mio punto di vista - che alcune controversie maggio - è che gli sviluppatori sono gli sviluppatori sono gli sviluppatori. Mi spiego: questi ragazzi (di cui mi considero uno), sono quelle che introducono i vulns e, mentre alcune organizzazioni investire di più nella loro istruzione di sicurezza di altri, non vedo alcuna prova che le organizzazioni più grandi prendono la competenza sicurezza dei loro sviluppatori più seriamente di organizzazioni più piccole. Le cifre sembrano sostenere questo.

Il social engineering:

Lo "strato di carbonio" del patrimonio informativo (l'utente) è notoriamente suscettibile di tattiche sociali come l'inganno, la manipolazione e intimidazioni, minacce e gli agenti più esperti sanno come usare questo a loro vantaggio.

Mi piace questo perché non ho mai sentito parlare di utenti cui si fa riferimento come "strato di carbonio" prima. Nizza :)

Corso Visual Studio - Corsi Visual Studio
Corso .Net- Corso Dot.Net - Corso Vb.net
Corso C# - Corso PHP - Corso Joomla

67% dei siti Web ASP.NET hanno gravi vulnerabilità di sicurezza di configurazione relativi

In realtà, è ancora peggio - è davvero 67,37% - ma cerchiamo di non spaccare il capello oltre che in questo momento. Il punto è che è un numero spaventosamente alto per quello che equivale a vulnerabilità di configurazione molto semplici. I numeri sono per gentile concessione di ASafaWeb , l'analizzatore automatico di sicurezza per i siti web ASP.NET, che è uno scanner gratuito on-line su asafaweb.com .

Quando ho costruito ASafaWeb, l'ho progettato dalla terra fino a anonimamente registrare risultati della scansione. L'anonimato significa che non so quali siti vengono scansionati o che sta facendo la scansione, ma io non so il risultato di ogni scansione che mi permette di aggregare questi in alcuni dati significativi.

Lasciate che vi guiderà attraverso questi risultati e offrire un po 'di comprensione da dove le cose vanno male, quando siti Web ASP.NET vengono pubblicati. Speriamo che questo sarà un po 'di "call to action", che aiuta gli sviluppatori a capire dove potrebbero aver bisogno di fare un po' di tweaking nelle loro applicazioni.

Analisi

Per prima cosa, l'analisi esclude quanto segue:

1. Esegue la scansione sul sito di prova ASafaWeb .
2. Esegue la scansione di siti non identificati come un sito web ASP.NET (questo è identificato dalle intestazioni di risposta, tutte le pagine di errore idonei a rivelare il quadro o la presenza dello stato di visualizzazione sul sito). Naturalmente è possibile - anzi è auspicabile - che le intestazioni non esporre queste informazioni, ma è anche estremamente raro.
3. Esegue la scansione eseguito prima 1 gennaio di quest'anno o dal 1 aprile in poi (lo chiamano quarto pulito). Tutti i risultati sono da gennaio / febbraio / marzo.

Quello che voglio fare è dare un quadro di come il vostro sito web media ASP.NET è configurato in modo tale criterio di filtro è molto importante. Portate via queste cose e ora abbiamo un campione di 7.184 scansioni da analizzare.

Una cosa da tenere a mente è che le scansioni ASafaWeb non sono infallibile; falsi positivi accadere. Non molto, intendiamoci, ma è un fattore. Un altro fattore è che le scansioni sono state migliora come vari casi limite o opportunità generali di miglioramento sono identificati.Ad esempio, la settimana scorsa ho aggiunto il supporto per messaggi di errore in altre lingue. Prima di allora - e inclusi nel campione nelle statistiche in questo post è venuto da - uno schermo classico giallo della morte in tedesco non sarebbe stato classificato come un errore.

Allo stesso modo, proprio questo fine settimana ho aggiunto un po 'di intelligenza in giro per il modo in cui si verificano le scansioni contro gli URL con un percorso sotto di loro. Il problema è che quando si vede un URL come http://mysite.com/foo, non so se foo è la radice delle app o se si deve andare tutta la strada al proprio dominio. Se è la radice app, questo è il percorso in cui le risorse, come il tracciamento e l'ELMAH sarà trovato, ma se non lo è, si è salire di un livello. E devi farlo senza fare eccessivi (e molto costoso) le richieste HTTP.Tricky.

Quindi il punto è che questi numeri sono dalla parte conservatrice.

Errori personalizzati e le tracce dello stack

Quando si parla di errori personalizzati in un certo senso di sicurezza, ci sono in realtà due distinte questioni di cui stiamo parlando:

1. L'nodo customErrors del web.config hanno l'attributo mode impostato su "On" o "RemoteOnly". In caso contrario, avremo una schermata giallo della morte con stack completo .
2. L'nodo customErrors del web.config la defaultRedirect impostato su una pagina valida.

In altre parole, è lo schermo giallo della morte (YSOD) fare una comparsa. Come di aggiornamento per chi ha familiarità con ASP.NET e una breve introduzione per coloro che non lo sono, ecco quello che una pagina di errore simile quando entrambe le voci di cui sopra non sono configurati correttamente:

Ora il grosso problema con il messaggio di errore è al di sopra che stiamo fuoriuscita di codice interno al mondo esterno. Questo dà un attaccante un enorme vantaggio in quanto possono cominciare a sondare l'applicazione e scoprire come la cosa è mettere insieme che a sua volta equipaggia meglio a identificare le vulnerabilità. In particolare in applicazioni in cui la gestione degli errori è scarsa (come lanciare dati non attendibili a un tipo particolare, senza un "try-parse" approccio style), questo è un grave rischio.

Ma scorrere verso il basso un po 'più e c'è anche questo:

Ora, questo risale a un recente post dal titolo Shhh ... non lasciate che i vostri header di risposta parlare a voce troppo alta . In questo post ho parlato del rischio se la divulgazione di informazioni di cose come IIS, ASP.NET MVC e le versioni tramite le intestazioni. Non importa quanto in silenzio si configurano le intestazioni, se il vostro errore personalizzato non sono configurati si sta andando ad essere fuoriuscita di informazioni sulla versione comunque.

In questo scenario, il web.config è effettivamente dichiarare gli errori personalizzati come questo:

< customErrors mode = " Off " />

Ruotando gli errori personalizzati off, le bolle di errore interni fino al browser e il sito è in senso figurato sorpreso con i pantaloni calati intorno alle sue caviglie. Accensione errori personalizzati sulle cose migliora, ma non da un sacco:

Ok, quindi l'analisi dello stack e implementazione interna del codice è andato, ma stiamo ancora rivelare che l'applicazione non può gestire la richiesta: è un'eccezione in senso letterale e non gestita, e che è solo conoscenze sufficienti per iniziare un ulteriore sondaggio.

Ecco cosa vogliamo veramente vedere:

< customErrors mode = " On " defaultRedirect = " ~ / Error.aspx " />

Quando un reindirizzamento di default è definito, si finisce con qualcosa di più simile a questa:

Ora, naturalmente, che normalmente si basa questo sul modello del tuo sito ed essere un po 'più amichevole su di esso - come ho fatto con ASafaWeb - ma si ottiene l'idea. Definendo la pagina vorremmo l'applicazione di servire quando le cose vanno male, evitiamo di rivelare il fatto che l'errore non viene gestita. Siamo in grado di configurare gli errori personalizzati per servire le pagine di errore diversi in base a diversi codici di stato HTTP (si potrebbe desiderare di gestire una "Pagina non trovata" 404 in modo diverso, per esempio), ma fintanto che YSOD non sta facendo un aspetto, che è quello che stiamo a parlare qui.

Ci sono altri scenari in cui avere gli errori personalizzati avanti senza un default reindirizzare drammi cause. Ad esempio, un paio di anni fa abbiamo avuto l'intera questione padding oracle che conducono a Scott Guthrie fornire indicazioni molto esplicito :

Non è sufficiente per attivare semplicemente CustomErrors o hanno impostato a RemoteOnly.

Anche se l'episodio è ora veramente bene e dietro di noi, serve come un piccolo promemoria che è necessario mantenere le applicazioni bloccate non nel miglior modo possibile solo per proteggere contro le vulnerabilità che conosciamo oggi, ma quelli che devono ancora fare un aspetto. Ho visto anche molti rapporti di penetration tester e gravi aziendali grado dinamici strumenti di analisi di sicurezza che chiamano tutto questo, insistendo sul fatto che non YSODs fanno la loro comparsa indipendentemente dal fatto che sono accompagnati da una traccia dello stack o meno.

Un'ultima cosa: il UX di un YSOD fa schifo! Dare una bella pagina di errore amichevoli e mantenere gli utenti più felice di quello che sarebbe altrimenti quando qualcosa va storto.

Questa lunga introduzione è stato quello di impostare il contesto, perché non configurato correttamente gli errori personalizzati è dove la parte del leone dei problemi mentire. Diamo un'occhiata:

Relativamente questo ritorno al preambolo su come funziona errori personalizzati, il 16% dei siti li hanno spenti del tutto, mentre un altro 32% li hanno acceso, ma non hanno una pagina di reindirizzamento di default definito. Questo è enorme - stiamo parlando di quasi la metà di tutti i siti web ASP.NET che hanno una tale configurazione di base fondamentalmente sbagliato.

Richiesta di convalida

Avanti è la convalida della richiesta o, come mi piace fare riferimento ad esso, . NET piccola rete di sicurezza XSS . La convalida delle richieste così com'è oggi (e cambia un po 'domani), significa che una richiesta con un carico potenzialmente dannoso, ad esempio che si può trovare in un attacco XSS riflettenti (di solito) il divieto di esecuzione. Ad esempio:

Nota: la stringa di query nell'URL - ASP.NET ha intrappolato così presto e ha deciso che è una cattiva notizia quindi la pagina di errore (anche se ovviamente questo sarebbe normalmente reindirizza a una pagina di errore amichevole). La cosa grandiosa di convalida della richiesta è che anche se si sa assolutamente niente di XSS (che è uno scenario allarmante comune), c'è un certo livello di difesa offerti dal framework.

Prima che qualcuno diventi troppo arrogante sui meriti di convalida richiesta, non è un sostituto per il tipo di pratiche mi parla in parte 2 della mia serie di OWASP. sviluppatori NET , vale a dire la convalida whitelist e la codifica di uscita corretta. Ciò che fa è esattamente quello che ho accennato in precedenza, ti dà una rete di sicurezza se altre buone pratiche vengono ignorati.

Richiesta di convalida è attivata per impostazione predefinita e si deve esplicitamente disattivare nel file web.config per disattivarlo:

< pagine validateRequest = " falso " />

Oppure disattivare a livello di pagina:

<% @ Pagina Language = "C #" ValidateRequest = "false" %>

Perché fate questo? Uno dei casi d'uso più comuni per farlo è quello di permettere tag HTML per essere inviati al server, ad esempio quando si utilizza un editor di testo RTF.Naturalmente questo è un caso d'uso perfettamente valido, ma si tratta di rischi ...

Il che ci porta direttamente al DotNetNuke. Vedete DNN si spegne tutto il sito, perché ogni singola pagina è un po 'mini sistema di gestione dei contenuti. Ottengo che - c'è un comprensibile caso d'uso per questo - ma significa anche che ricevono i loro asini proverbiali consegnato loro da vulnerabilità XSS semplici che altrimenti sarebbero catturati da la convalida delle richieste.

Allora, qual è la risposta a un problema come DNN di? Utilizzare ASP.NET 4.5. Aspetta - che cosa?! Stiamo per ottenere alcuni miglioramenti molto importanti in tutto il supporto per le richieste non convalidate il che significa che un prodotto come DNN sarà in grado di lasciare la convalida della richiesta acceso ma richiesta di accedere ai dati specifici di una chiamata "non validati", che non invoca la convalida delle richieste. Questo significa che possono lasciarlo acceso e ottenere che la tutela implicita grazie a caratteristiche come la ricerca, ma non ho capito nel modo del loro CMS.

Ma ci sono molte, molte occorrenze di sviluppatori poco ripieno up. Essi spegnerlo attraverso il sito, perché una caratteristica admin poco è stato bloccato o che ripetono ciecamente la guida forum senza capire l'impatto. Per questo motivo i risultati simile a questa:

La prima cosa che si può notare qui è che la dimensione del campione è più piccolo - quasi la metà. Questo si spiega in parte nel titolo e causa del modo in forme siti web di gestire la convalida della richiesta, è facile solo per aggiungere un payload maligno per la stringa di query come ho fatto a immagine del browser in precedenza. Questo viene processato e richiesta di convalida (si spera) incendi. Non così con MVC (o, ovviamente, un sito web HTML puro), quindi a meno che ci sia stato di visualizzazione in formato sorgente del sito, questo test non viene eseguito.

Hash DoS

Chi si ricorda DoS hash ? Solo un po 'più di tre mesi fa, questo era il exploit dimostrato da ricercatori in Germania, oltre che significava un ben fatto richiesta HTTP POST con una grande collezione di variabili form appositamente costruiti potrebbe causare alcuni piuttosto gravi collisioni hash. Il problema con le collisioni hash è che sono computazionalmente costosi e se è possibile causare abbastanza di loro, il server inizia ad avere problemi a fare le cose in realtà è destinata a fare. La linea di fondo era che appena un singolo cura artigianale richiesta HTTP potrebbe chiudere le cose. Ouch!

Microsoft ha reagito rapidamente e rilasciato e rilasciato MS11-100 , un critico out-of-bandpatch. Ora che po '"out-of-band" è importante, in genere Microsoft rilascia una serie di patch per il secondo Martedì di ogni mese che è diventato noto come Patch Martedì . Le organizzazioni IT si aspettano questo e si organizzano attorno a gestire queste versioni. Per Microsoft di rilasciare una patch out-of-band significa che ci vuole molto, molto seriamente, tanto che non vedono l'ora possibile fino a quando la patch Martedì prossimo.

Questo rende il grafico che segue un po 'straordinario:

Ci sono alcune avvertenze con questo risultato in quanto è un po 'difficile da provare: in primo luogo, la scansione viene eseguita inviando 1.001 variabili di form sul sito, più di quanto la soglia è prima la patch calci e causa un errore di uno che è quello che noi' stavi cercando di accertare è stato installato. In secondo luogo, l'oggetto Request.Form deve essere accessibile in modo che questo evento si verifichi. Questo avverrà in modo implicito in una web app forme, ma in un'applicazione MVC, è dipendente dalla realizzazione del sito.

In breve, le scansioni MVC significano un sacco di avvertimenti, dove ASafaWeb essenzialmente scuse e dice: "Io non sono sicuro" così ho in base ai risultati puramente intorno ai siti web delle forme. Dato che si siede su un modello identico ad altri siti di hosting ASP.NET e abbiamo una buona dimensione del campione, l'elevata percentuale di computer senza patch dovrebbe riflettersi su tutta la linea comunque.

Ma naturalmente ci aspettiamo un sacco di siti a fallire molto presto come padroni di casa si precipitò per rattoppare i loro sistemi. Dopo tutto, questa è stata rilasciata proprio alla fine di dicembre quando le macchine di patching di solito non è la prima cosa nella mente degli amministratori maggior parte dei server. Vediamo come il tasso di fallimento è cambiato nel tempo:

Così abbiamo avuto il ritrovamento era inizialmente previsto ad alto contenuto di Jan, ma la cosa sorprendente è che nei due mesi successivi il tasso di fallimento di questa scansione è ancora molto elevata - 42% in realtà. In realtà c'è anche un incremento infinitamente piccolo da febbraio a marzo (circa 0,2%), così chiaramente ci sono un sacco di server restanti senza patch. Un po 'la gente di richiesta HTTP, che è tutto quello che serve ...

ELMAH

Il tutto ELMAH situazione della sicurezza è interessante. Per il familiare, lo stesso ottimi moduli Errore di registrazione e la biblioteca gestori è un modo popolare di catturare e rivedere gli errori che si verificano sul tuo sito web ASP.NET. Io lo uso molto in ASafaWeb me (tra l'altro).

Pochi mesi fa ho scritto su di sessione ASP.NET dirottamento con Google e ELMAH che, in breve, ha mostrato che vi sono stati molti, molti siti che espongono i registri ELMAH - che naturalmente, sono individuabili da Google - che contengono informazioni sufficienti per consentire di prendere sulla sessione di un altro utente autorizzato. In realtà, questo è solo l'inizio, perché non c'è abbastanza informazioni nei registri ELMAH a fare ogni sorta di altre cose nefasti.

C'è una panoramica completa di ciò che è in ELMAH nel link sopra, ma questa istantanea vi dà un senso rapido del livello di dettaglio che si può ottenere:

Comunque, la cosa che rende questo uno particolarmente interessante è che la guida di sicurezza sul sito ELMAH era sbagliato (da allora è stato posto rimedio), e se seguite lascerebbe comunque il ELMAH registra accessibile. Ovviamente si tratta di una situazione molto spiacevole e di conseguenza ci sono un sacco di siti web ELMAH abilitati là fuori che pensano di essere sicuro, ma non lo sono. Poi di nuovo, ci sono molti che non solo molto nemmeno pensato!

Ecco cosa ASafaWeb ha trovato:

Il numero totale di scansioni è un po 'inferiore rispetto a risultati precedenti, come il test ELAMH è stato aggiunto un certo punto del 4 gennaio% assomiglia ad un piccolo numero, ma si consideri anche che nel grande schema delle cose, ELMAH è installato solo in una piccola numero di siti web ASP.NET. Quale percentuale di questi non sono sicuri? 20%? 30%? Non sono sicuro, ma so che è una significativa parte dei siti che implementano ELMAH.

Tracciato

Se devo essere onesto, sono piacevolmente sorpreso da questo risultato:

Mentre è arrotondato a 0%, ci sono stati in realtà 34 scansioni che trovate lasciato su.Tracing è la sicurezza aziendale piuttosto seria saggia, che si presenta ogni sorta di succosi pezzi di informazioni, molte delle quali abbiamo visto di nuovo durante la scansione ELMAH:

Variabili del server, web form controllo della struttura, versione quadro e la tempistica degli eventi. Cose utili sia ai buoni e cattivi, ma per fortuna molto raramente esposta, secondo le statistiche.

Riassunto

Ecco la cosa con ogni singolo delle risultanze di cui sopra: sono assolutamente morto semplice da risolvere. Non si tratta di riscrivere il codice o ri-architecting siti web, si tratta di ottenere un paio di piccole impostazioni di configurazione di destra (e di assicurare il vostro ospite mantiene il loro ambiente patch nel caso di hash DoS).

Questo è uno di quelli " da grandi poteri derivano grandi responsabilità "scenari; ASP.NET è un ambiente incredibilmente potente che permette di fare cose incredibili con facilità, ma che la facilità si estende anche alla configurabilità e crea l'opportunità di lasciare buchi nei siti web senza neanche accorgersene.

Questo è un altro tema comune che vedo - gli sviluppatori che completamente e assolutamente capire tutto quello scritto sopra, ma ancora hanno siti vulnerabili. Ci vogliono solo un piccolo errore nelle trasformazioni di configurazione o di qualche distrazione quando il test e basta, lei è spalancata. Inoltre non c'è prova visiva della vulnerabilità esposta - si deve andare a cercare questi specificamente nel sito e la realtà è che questo non sempre avviene.

ASafaWeb è stato costruito per identificare le vulnerabilità in modo rapido e automatico e da tutti gli account, è trovato un sacco di loro. Ma c'è molto di più a venire - siti web non rimanere statica e controllare il vostro sito con un una tantum di scansione è buono per oggi, ma domani? Io non ho intenzione di rivelare troppo in questo momento, ma ci sara 'una soluzione molto elegante a questo proprio dietro l'angolo. Per ora, controllare il vostro sito e assicurarsi che nessuno di coloro po 'semplice - ma potenzialmente gravi - le configurazioni sono mancanti.

Corso Visual Studio - Corsi Visual Studio
Corso .Net- Corso Dot.Net - Corso Vb.net
Corso C# - Corso PHP - Corso Joomla