Amo ELMAH - questo è uno quelle librerie che è sia bella nella sua semplicità, ma potente in quello che ti permette di fare. Combinano la potenza di ELMAH con la comodità di NuGet e si può essere installato e funzionante con l'errore assolutamente inestimabile registrazione e la gestione letteralmente in un paio di minuti.
Eppure, come dice il vecchio adagio, con un grande potere derivano grandi responsabilità e se non sei responsabile di come si implementano ELMAH, sei anche solo un paio di minuti di distanza dal fare il dirottamento di sessione della vostra applicazione ASP.NET - e molti altri exploit - molto, molto facile. Cosa c'è di più, le applicazioni vulnerabili sono solo una semplice ricerca su Google di distanza. Lasciatemi dimostrare.
Aggiornamento: Voglio mettere in chiaro proprio sulla parte anteriore che il fuori della configurazione casella ELMAH non fa nulla di quello che stai per leggere possibile. E 'solo quando ELMAH è configurato per esporre i log in remoto e non adeguatamente protetto che le cose vanno male.
La proposta di valore ELMAH
Alcuni retroscena primo; ELMAH è l'errore di registrazione Moduli e gestori scritto dal molto intelligente Atif Aziz ed è molto popolare. Quanto è popolare? E 'attualmente il pacchetto 14 più scaricato da NuGet :
Ciò significa che al momento della scrittura, ci sono stati 42.429 download della biblioteca.
Ho il sospetto che la popolarità ha molto a che fare con quanto sia semplice da implementare. Prima di tutto, è possibile aggiungere ELMAH per la vostra applicazione ASP.NET, senza ricompilare, è solo una questione di alcune voci web.config e compresa la biblioteca ELMAH.
In secondo luogo, è molto facile per registrare gli errori di una serie di diversi meccanismi di stoccaggio permanente tra cui il default in memoria negozio e per SQL Server (fra gli altri) per la longevità un po 'di più. Una volta che il web.config è impostato, succede solo automagicamente .
In terzo luogo, è molto semplice da configurare ELMAH a fuoco è spento una e-mail quando qualcosa va storto. Non c'è niente come essere in grado di contattare in realtà un utente con un "Ehi, vedo che avevi un problema" messaggio cinque minuti dopo che hanno avuto problemi. La gente ama questo genere di proattività!
In quarto luogo, è molto facile per recuperare le voci di registro, è sufficiente staccare, per il percorso / elmah.axd delle app che invoca un gestore bel po 'di tirare fuori i messaggi recenti di qualunque repository che stai usando.
E, infine, registra ELMAH sono cose molto, molto utile in loro per aiutare realmente risolvere il problema. Ma a quanto pare, hanno anche roba molto, molto utile in loro per aiutare i cattivi rompere l'applicazione che ci porta allo scopo del post di oggi.
Hacker-friendly info in ELMAH
Cominciamo approfondire i dettagli di ciò che ELMAH ci dà, o in questo caso oggi, quello che dà l'hacker. Ecco un esempio di ciò che esce da tale gestore elmah.axd:
In realtà, si può vedere questo per lei oltre a http://isnot.asafaweb.com/elmah.axd
Questo luogo particolare è quello che uso come banco di prova per ASafaWeb e le suevolutamente insicuro (più su quello a breve). Ciò che vedete nell'immagine sopra è una richiesta per il percorso "/ blah.aspx" che non esiste quindi è causando un HTTP 404 "NOT FOUND", che viene catturato da ELMAH. Fin qui, tutto bene.
Drill-down in tale errore, vedremo una traccia dello stack che comincia a rivelare l'implementazione interna del codice in cui è verificato l'errore. Tenete a mente questo è totalmente indipendente dalla configurazione personalizzata errori della app, è possibile attivare e specificare un valore predefinito reindirizzamento a una pagina di errore e ELMAH sarà ancora log di quello che vedete qui sotto - che è la bellezza di esso!
Ora scorri verso il basso un po 'e raggiungere l'interessante sezione - variabili del server:
Ho evidenziato due sezioni qui e voglio fare riferimento ad essi dal basso verso l'alto:
- La variabile "AUTH_USER" è impostata su "admin". Questo è il nome dell'utente autenticato quando è verificato l'errore. In altre parole, sappiamo che era l'amministratore connesso in quel momento.
- Il cookie ". ASPXAUTH". Nel caso in cui questo non sia già noto, uno sguardo attraverso il mio post su OWASP Top 10 per gli sviluppatori NET parte 9:. insufficiente protezione Transport Layer
Leggi il post? A destra, così ora avrete una buona idea di dove sta andando questo post -. ASPXAUTH il cookie viene utilizzato per mantenere lo stato di un utente autenticato quando il sito web utilizza il provider di appartenenze ASP.NET per l'autenticazione.
Identificazione di un obiettivo
Il punto cruciale di questo exploit centri intorno al fatto che molte persone non sono adeguatamente proteggere i registri ELMAH sul loro sito e che è facilmente rilevabile. In effetti è così facile da scoprire, è solo una questione di una semplice ricerca su Google perinurl: elmahtr.axd ASPXAUTH
Oh ragazzi, questo è un sacco di risultati - 11.000 pagine di registro non protetti ELMAH ! con informazioni cookie di autenticazione Sostituire la "ASPXAUTH" criteri di "Log di errore per" che appare nella parte superiore di ogni risorsa elmah.axd e il risultato è attualmente 192.000. Ouch! Certo, alcuni di questi sono risultati per il sito stesso e alcuni sono semplicemente pagine circa ELMAH ma in qualunque modo si taglia, ci sono un enormenumero di siti di mettere i loro privati esposti al pubblico!
Questo è il vostro classico Googledork o in altre parole, una ricerca con cura artigianale che si trasforma fino risultati relativi alla configurazione negligente. Tenete presente anche che questo è ovviamente solo i risultati accessibili al pubblico, che Google ha indicizzato, quanti altri siti sono là fuori esponendo i loro registri ELMAH che semplicemente non sono state indicizzate? Dopo tutto, elmah.axd normalmente non è una risorsa pubblicizzati; Google deve sapere che è lì e richiedere esplicitamente la risorsa per l'indicizzazione.
Sfruttando il sito
Ora per la cosa interessante - sfruttando le informazioni di cui sopra di sfruttare effettivamente il sito. Lasciatemi dipingere uno scenario che mette la facilità e la praticità di questo nel contesto:
Indossando il cappello di hacker male, ho appena fatto la ricerca di Google e identificato sopra il sito che voglio sfruttare. Posso vedere dai log che il cookie ASPAUTH viene catturato quindi so che autenticazione basata su form è in uso o in altre parole, il sito ha qualcosa che si vuole proteggere. Da questa ricerca da solo c'è un buon cambiamento che ho potuto trovare un token valido ASPXAUTH da utilizzare nel mio esercizio dirottamento.
Ma cosa succede se il registro è solo utilizzando le impostazioni predefinite in memoria di storage ed è stato recentemente lavata? Oppure non ci sono errori di recente con un cookie ASPAUTH che è ancora valido? Nessun problema, solo un po 'di ingegneria sociale è necessario per contribuire a generare un nuovo messaggio di errore. Trovare informazioni di contatto per il proprietario del sito è di solito semplice, proviamo un messaggio come questo (sto assumendo @ asafaweb è il bersaglio):
L'inserimento del carattere "<" nell'URL causerà la convalida della richiesta al fuoco - tutto il resto del messaggio è solo destinato a costruire un senso di urgenza (il messaggio) e di legittimità (il dominio dell'URL). Ora, naturalmente, l'utente deve essere autenticato al fine di ottenere un nuovo cookie ASPAUTH, ma è probabile che sono o già registrati o si utilizza una lunga durata di timeout per salvarle la registrazione di nuovo in Anche se non sono, un messaggio allo stesso modo artigianale con un link ad una pagina di amministrazione potrebbe facilmente prendere cura di questo.
Ora è solo una questione di guardare l'attaccante ELMAH fino a una voce del registro nuovo appare. Il cookie auth sarà simile a questa:
.ASPXAUTH=3C886BA2344099338361C921C846EAF4E02F2A88E5E7EDE6838705928F7BB7C6FF469D35FEB1532C44B81DB38F200DEE08B6ED0E6121B945C659E932D8CE8B69FFF09E7B59DBE4820873DBD7891DD6B6BC4A486F35A2F99849017A6C72D9C6A44517D9AFDC731B3A3C55596E79732806F7DDDF9F
Con la nostra cappello degli hacker, andiamo ora prendere questo valore e creare un nuovo cookie con il nome e il valore dall'alto. Questo diventa molto semplice con una estensione del browser come modificare questo cookie :
Potete vedere il "Log In" testo dietro la finestra di cookie in modo questo browser non è sicuramente autenticato prima di aggiungere il cookie. Ma se l'hacker invia il cookie e aggiorna la pagina:
E ci avete - l'hacker è loggato come amministratore! Questo non dare loro l'amministratore la password , ma li fa tutti i diritti di utente admin . A seconda del sistema, questo può dare loro i diritti per visualizzare o creare altri account, gestire i permessi, visualizzare i dati finanziari, ecc ecc Usate la vostra immaginazione.
Ma aspettate - c'è di più
Un registro pubblicamente esposto ELMAH è abbastanza grave vulnerabilità di business saggio. Non c'è solo il rischio di dirottamento di sessione come spiegato qui, ad esempio, c'è il rischio di rivelare la struttura interna del database semplicemente cercando SqlException :
O come su un mucchio di istruzioni SQL - questo è proprio quello che si vuole ottenere un inizio grande testa su un attacco di iniezione:
E che dire semplicemente cercando "password" - non hai nemmeno bisogno di guardare oltre la finestra di ricerca su alcuni di questi:
Vuoi trovare siti che utilizzano una particolare libreria in cui una zero-day è stato appena scoperto? E questo è assolutamente, positivamente solo un esempio - sono solo la raccolta di una biblioteca popolare che non sarebbero normalmente individuabile semplicemente la consultazione del sito:
Ma naturalmente non è solo sulla ricerca di errori esistenti che potrebbero essere di interesse, una volta che un attaccante sa che un sito è di esporre i log ELMAH possono poi andare a cercare tutta una serie di altri attacchi e ottenere un feedback immediato su quello che sta succedendo internamente! Come conveniente è quello?!
Ma c'è anche tutta una serie di altri piccoli frammenti che possono venire in valore per i malvagi, URL di riferimento, percorso fisico del sito sul server, percorso fisico del sito sulla macchina dove è stato compilato (spesso macchina dello sviluppatore) , i nomi ei valori di tutti i cookies, l'indirizzo IP dei visitatori del sito e così via e così via. I registri ELMAH sono un vero e proprio tesoro di informazioni.
La protezione contro questo attacco
Questo è in realtà solo un semplice caso di controlli di accesso o in OWASP parlare, Errore di limitazione dell'accesso URL . Questo non è - e mi veramente sottolinearlo - non è una vulnerabilità di ELMAH .
Nel caso in cui i provider di appartenenze e di ruolo sono in uso, la correzione è nulla di più complesso di una semplice voce di autorizzazione in web.config:
< location path = " elmah.axd " > < system.web > < autorizzazione > < permettere ruolo = " Admin " /> < negare utenti = " * " /> </ autorizzazione > </ system.web > </ location >
Ecco, niente di più. Quelle 192.000 siti dalla ricerca Googledork non hanno questo! Ognuno di questi siti è facilmente vulnerabile agli attacchi di cui sopra. Sono anche esponendo tracce dello stack interno e le variabili del server che possono portare ad attacchi di altre nature. Questa è una grave vulnerabilità di configurazione seria.
Oh, e nel caso in cui non è già evidente, protezione livello di trasporto non fa assolutamente nulla per mitigare questo rischio, significa solo un attaccante in grado di caricare i vostri dati di log sensibili tramite una connessione criptata:)
Un aiuto da ASafaWeb
In tutta onestà a quelli con i registri ELMAH pubblicamente di fronte, questo è davvero facile da sbagliare. La facilità di implementazione offre ELMAH lo rende potente e potenzialmente vulnerabili allo stesso tempo. Nel fatto che spesso la storia con NET in generale;. Caratteristiche come gli errori personalizzati e tracce dello stack può essere facilmente esposto interamente per caso.
Il mese scorso ho lanciato ASafaWeb con l'intento di fornire uno strumento gratuito per verificare facilmente per ASP.NET vulnerabilità di configurazione relativi. Oggi sono felice di aggiungere anche una scansione per l'accessibilità al pubblico di ELMAH.
Sono molto attenti a eventuali scansioni aggiungo a ASafaWeb. Di solito questo significa un'ulteriore richiesta HTTP (come è il caso della scansione ELMAH), e questi sono piccoli esercizi molto costoso in termini di durata si aggiunge a una scansione. Ma nel caso di ELMAH, la prevalenza della biblioteca combinata con l'enorme numero di siti insicuri e la facilità di implementazione rende un buon candidato da aggiungere.
Ecco come funziona: il sito ASafaWeb ti permette di collegare sia un URL (questo può essere un qualsiasi URL accessibili al pubblico) o in alternativa, eseguire una scansione contro il sito di esempio di cui ho parlato sopra e hanno evidenziato di seguito:
Quando la scansione funziona, ci sono una serie di richieste HTTP al fine di testare i vari aspetti della sicurezza del sito. ASafaWeb si mostra ciò che le specifiche richieste sono state poi lo stato di ogni singola scansione. A volte più di una richiesta HTTP viene utilizzato per una scansione o una singola richiesta può essere riutilizzato attraverso scansioni multiple:
Cliccando sul fallimento "ELMAH log" scan salta poi noi in fondo alla pagina per i dettagli della scansione incluso il percorso con la vulnerabilità e come risolvere il problema (essenzialmente le informazioni nel post precedente):
Si può collegare direttamente nel profondo la scansione del sito di prova , se volete vederlo in azione ora.
Riassunto
Nel caso in cui non ho fatto perfettamente chiaro le prime volte, questo non è un difetto in ELMAH, in realtà penso che sia uno strumento fantastico e lo uso molto in ASafaWeb:https://asafaweb.com/elmah.axd
Ops, non è possibile accedere a tale però, è possibile?! E questo è davvero il punto che sto facendo - ELMAH può essere implementato in modo sicuro e sopra tutto c'è alcun modo una raccomandazione non usarlo. Ma per favore, per favore, applicare un po 'di diligenza dovuta e bloccarlo in modo corretto.
Se si fanno scoprire i registri ELMAH erano pubblicamente visibili poi decidere di bloccare giù, c'è ancora il rischio reale che hanno già indicizzati e le versioni cache sono ancora disponibili, in effetti ho visto più volte quando si ricerca per questo post. Se siete in questo campo, si vuole prendere una buona occhiata a cosa c'è nel vostro (ora sicura) i registri ELMAH e considerare quali informazioni possono essere state esposte ed è ora ricercabili attraverso vari motori di ricerca (ricordate, non è solo Google) .
Nessun commento:
Posta un commento