Sto lavorando a una tesi sulla comunità degli hacker della sicurezza.
Quando viene pubblicato un 0day, in che modo un amministratore può proteggere la sua applicazione / sito Web tra il momento in cui viene pubblicato lo 0day e viene sviluppata la patch?
Inoltre, la maggior parte delle volte, questo stesso 0day viene usato per mesi dai blackhats, quindi i blackhats sono in testa ai whitehats?
La persona che scopre un problema di sicurezza spesso lo segnala prima al fornitore del software o allo sviluppatore. Ciò fornisce al fornitore del software il tempo di risolvere il problema prima della pubblicazione. Quindi, dopo che è stato corretto, l'errore è reso pubblico. Questo processo è chiamato divulgazione responsabile .
A volte, qualcuno non rivela lo zero-day al fornitore del software ma lo usa per hackerare altri sistemi. In questo modo, la società di sicurezza può rivelare il bug, masterizzare lo zero-day .
Non penso che la tua affermazione "la maggior parte delle volte, questo stesso 0day sia usato per mesi dai cappelli neri" è vero. Questo è vero per alcuni problemi di sicurezza, ma molti bug zero-day vengono trovati per la prima volta dagli hacker white-hat. Non direi che gli hacker black hat siano in vantaggio sui pirati informatici. Entrambi trovano problemi di sicurezza e alcuni di questi si sovrappongono. Tuttavia, il reato ha più facile della difesa in quanto l'infrazione ha solo bisogno di trovare un bug, e la difesa deve correggere tutti i bug.
When a 0day is published, how can an administrator secure his application/website between the time the 0day is published and the patch is developed ?
Utilizzano soluzioni alternative temporanee fino a quando non viene applicata una patch.
Quando esce la notizia di un giorno, ci sono spesso varie soluzioni alternative che rompono l'exploit eliminando alcuni prerequisiti per l'abuso della vulnerabilità. Ci sono molte possibilità:
La modifica di un'impostazione di configurazione può disabilitare la funzionalità vulnerabile.
Disattivare i servizi vulnerabili, quando possibile, può impedire lo sfruttamento.
L'attivazione di misure di sicurezza non predefinite potrebbe interrompere l'exploit.
Ogni bug è diverso e ogni mitigazione è diversa. Un amministratore con una buona conoscenza della sicurezza può trovare soluzioni alternative in caso di rilascio di dettagli sufficienti sulla vulnerabilità. La maggior parte degli amministratori, tuttavia, esaminerà gli avvisi di sicurezza pubblicati dal fornitore del software.
A volte, un amministratore non deve fare nulla . Questo può essere il caso se la vulnerabilità interessa solo una configurazione non predefinita o una configurazione che non è impostata sui loro sistemi. Ad esempio, una vulnerabilità nel sottosistema video DRM per Linux non deve preoccupare un amministratore di sistema con uno stack LAMP, poiché i loro server non utilizzeranno comunque DRM. Una vulnerabilità in Apache, d'altra parte, potrebbe essere qualcosa di cui dovrebbero preoccuparsi. Un buon sysadmin sa cosa è e non è un fattore di rischio.
Moreover, most of the time, this same 0day is used for months by blackhats, so are the blackhats ahead of whitehats ?
I whitehats sono più sofisticati, ma i blackhats sono più efficienti.
Se i blackhead sono in anticipo rispetto ai whitehats è una domanda molto soggettiva. I blackhats useranno qualunque cosa. Ciò significa che i loro exploit sono efficaci, ma sporchi e, a volte, non sofisticati. Ad esempio, mentre è possibile scoprire il layout ASLR di un browser tramite attacchi di canale laterale, questo non è realmente utilizzato in natura poiché i bypass ASLR onnipresenti e poco sofisticati esistono già. D'altra parte, i whitehats devono pensare a correzioni e in effetti convincere il fornitore del software a prendere sul serio il rapporto. Questo non ha alcun impatto sui blackhats quasi nella stessa misura, poiché spesso possono iniziare a beneficiare della loro scoperta nel momento in cui li realizzano. Non hanno bisogno di aspettare una terza parte.
Dalla mia esperienza personale, i blackhats hanno spesso un vantaggio significativo. Ciò è principalmente dovuto al fatto che la cultura attuale tra i whitehats è di cacciare e schiacciare singoli bug. Meno enfasi viene posta sullo schiacciamento di intere classi di bug e, quando lo sono, le mitigazioni sub-par e over-hyped sono ciò che viene creato (come KASLR). Ciò significa che i blackhats possono pompare 0 giorni più velocemente di quanto possano essere rattoppati, poiché viene prestata così poca attenzione alla superficie di attacco e ai vettori di sfruttamento che continuano a essere usati e riutilizzati.
Quando un giorno zero viene pubblicato o pubblicato, viene fornito con più di un semplice nome e icona. Vi sono dettagli su come lo zero-day viene utilizzato per sfruttare il sistema. Questi dettagli costituiscono la base della risposta del difensore, compreso il modo in cui la patch deve essere progettata.
Ad esempio, con WannaCry / EternalBlue , la vulnerabilità è stata rilevata dalla NSA e hanno tenuto a loro conoscenza ( lo stesso accade nella comunità criminale in cui le vulnerabilità possono essere scambiate sul mercato nero). I dettagli sono stati trapelati, che ha informato Microsoft su come creare la patch e ha anche informato gli amministratori su come difendersi da essa: disabilitare SMBv1 o almeno bloccare la porta SMB da Internet.
Ecco come gli amministratori si proteggono. L'applicazione delle patch è solo una parte della "gestione delle vulnerabilità". Ci sono molte cose che un amministratore può fare per gestire le vulnerabilità anche se non possono o non vogliono patchare.
Nel caso WannaCry, il NHS non ha applicato patch, ma non hanno nemmeno impiegato le altre difese che si sarebbero protette da sole.
Una parte importante del mio lavoro è la progettazione di attenuazioni della vulnerabilità per sistemi che non possono essere riparati per vari motivi commerciali. Patching è la soluzione migliore, in generale, ma a volte non è possibile al momento della patch.
... are the blackhats ahead of whitehats?
Questo pone un problema interessante. Se un blackhat trova un problema e lo condivide solo con altri blackhats (o altri membri della comunità dell'intelligence), vuol dire che i blackhats, in aggregato , sono in testa ai whitehats? Sì. Una volta che un giorno zero viene esposto, perde il suo potere (questo è il punto centrale di rivelarlo). Quindi, per tenerlo segreto, gli dà potere.
I blackhats sono più abili o usano tecniche migliori dei whitehats? No. Ma i segreti condivisi conferiscono ai blackhats più potere, in forma aggregata.
When a 0day is published, how can a whitehat secure his application/website between the time the 0day is published and the patch is developed?
A volte ci sono soluzioni alternative che risolvono o attenuano il problema.
/usr/tmp/sh . Questo ha confuso il worm e gli ha impedito di funzionare. Ma a volte nessuna di queste è un'opzione praticabile. In tal caso, puoi solo sperare che ci sarà presto una patch.
Moreover, most of the time, this same 0day is used for months by blackhats, so are the blackhats ahead of whitehats?
Capita abbastanza spesso che gli sviluppatori / i whitehats scoprano una possibile vulnerabilità di sicurezza nei loro software e li correggano prima che vengano sfruttati. Il primo passo della divulgazione responsabile è informare gli sviluppatori in modo che possano risolvere la vulnerabilità prima di pubblicarla.
Ma di solito non ne senti parlare nei media. Quando il punto 59 delle note di patch per SomeTool 1.3.9.53 legge "overflow del buffer possibile fisso durante l'elaborazione di file foobar malformati" che di solito non è particolarmente interessante.
La maggior parte degli exploit potenziali richiede una catena di vulnerabilità per poter essere eseguita. Leggendo lo zero-day non ancora assemblato, puoi comunque identificare altre vulnerabilità o pre-condizioni che il giorno zero richiederebbe.
Per difendersi dalla minaccia di (diciamo) un attacco RDP dall'esterno della rete (errore di autenticazione RDP zero-day pubblicato), non consentire RDP da fuori sede. Se non hai davvero bisogno di RDP dall'esterno, allora questa è una possibilità per correggere una svista. Oppure, se è necessario disporre di RDP dal di fuori del sito, è possibile identificare una whitelist di IP da cui consentire tali connessioni e restringere l'apertura del firewall.
Allo stesso modo, per difendersi da una minaccia RDP interna (e in qualche misura esterna), limitare la capacità di A) agli utenti di eseguire RDP, B) macchine per eseguire RDP, C) alla rete per passare RDP, D) alle macchine accetta RDP, E) utenti per consentire RDP. Quali VLAN dovrebbero avere la capacità di generare RDP in uscita? Quali macchine dovrebbero essere in grado di farlo? E così via.
Ognuno di questi passaggi, sia negli scenari esterni che interni, lavora per rafforzare la rete contro un exploit di autenticazione RDP anche senza patch.
Una mentalità di difesa approfondita ti consente di rompere la catena di vulnerabilità / condizioni richieste anche per uno zero-giorno senza patch per essere neutralizzato. A volte.
Ho intenzionalmente scelto un problema abbastanza facile qui solo per illustrare il punto.
Fonte: l'ho già fatto prima.
Il problema non è solo con zero-giorni. Ci sono un sacco di aziende che trascinano ancora le patch di 200 giorni per una moltitudine di ragioni (alcune buone, altre cattive).
Hai un ampio elenco di soluzioni, un altro è l'uso di patching virtuale . Solitamente crea una mitigazione per il problema prima che colpisca il servizio (l'ho imparato anni fa con un Trend Micro prodotto - nessun collegamento con loro ma l'ho testato e ha funzionato principalmente).
Un'altra difesa chiave è il monitoraggio e la conoscenza del tuo sistema.
Dove sono i tuoi preziosi segreti e chi può accedervi.
Se qualcuno tenta di connettersi al tuo server di posta sulla porta 80, bandiera rossa.
Perché il server di posta, all'improvviso, invia traffico a un IP insolito.
Il server di posta ora ha 10 volte il traffico perché?
Controlla le persone che si connettono agli indirizzi IP esterni. Elimina e / o blocca tutte le porte esterne e i protocolli che non sono in uso.
Nessun utente legittimo si connetterà al tuo server web su qualsiasi cosa tranne 80 o 443. A meno che tu non abbia aggiunto servizi aggiuntivi. Potresti considerare di bloccare questi IP per qualche tempo. A volte, l'IP fa parte dei pool dinamici e non è sempre possibile risolvere un problema con una lista nera, quindi basta rilasciare i pacchetti.
Se la tua azienda opera solo in 1 Paese, forse dovresti bloccare tutti gli altri Paesi.
È possibile utilizzare whois per trovare il proprietario globale dell'intervallo di indirizzi IP e, se presenti, utilizzare le informazioni di contatto dell'amministratore per informare il proprietario. Possono rintracciarli dalla loro parte. (Vale la pena provare)
Dovresti ricevere una notifica quando qualsiasi sistema viene contattato da un altro sistema in modo inaspettato. Dopo la prima puoi avere un sacco di notifiche, ma se i computer sono nella tua rete, puoi indagare su entrambi i lati. Quindi eliminalo o includilo in bianco come traffico previsto.
Questi strumenti di monitoraggio ti informano anche sulle scansioni delle porte, a meno che tu non abbia un team di sicurezza autorizzato che nessun altro debba effettuare la scansione delle porte.
Guarda gli eventi regolari e se si fermano misteriosamente perché?
Controllare l'infezione della macchina. Se i servizi sono disabilitati, devi essere avvisato in anticipo in modo che le modifiche siano attese e non misteriose.
Blocca il più possibile e controlla il resto.
Ora una volta che hai un attacco devi fare qualcosa al riguardo.
A volte spegnere il sistema temporaneamente è l'unica opzione. Forse hai bisogno di bloccare il loro indirizzo IP per un po '.
Devi ancora proteggere e monitorare tutti i tuoi servizi legittimi.
Oltre a monitorare la comunità per gli annunci di vulnerabilità. Dovresti avere dei penetration tester per trovare gli errori prima degli hacker. Quindi hai la possibilità di mitigare l'attacco alle tue condizioni. Notifica al manutentore del sistema di effetti in modo che possano correggerlo. Se è open source, puoi chiedere a qualcuno di correggerlo per te.
I sistemi di rilevamento delle intrusioni e lo snort possono anche esaminare e potenzialmente bloccare gli hack in arrivo rilevando i pattern sospetti.
Potrebbe essere necessario trovare un prodotto alternativo per sostituire quello vulnerabile a seconda della gravità del problema.
Come sempre tenere aggiornato il tuo software ti aiuta a proteggerti.
In questo modo puoi bloccare attività sospette, finché non ne determini la legittimità.
Relativamente pochi hack permettono all'utente malintenzionato di entrare in un sistema. La maggior parte sono bachi di "escalation di privilegi" che consentono a un utente malintenzionato di avere un maggiore controllo sul sistema dopo averne accesso. Ci sono tanti modi per ottenere il controllo amministrativo di una macchina una volta che un hacker ha accesso ad essa, che è più o meno una perdita di tempo per cercare di proteggere una macchina contro l'escalation dei privilegi. La tua migliore politica è quella di concentrarti sulla prevenzione degli hacker in primo luogo e sul monitoraggio della rete per intrusione.
Quasi tutte le intrusioni provengono da tre soli metodi. Vuoi spendere tutte le tue risorse di difesa cibernetica disponibili a difendersi da queste. Sono:
(1) Email di phishing contenenti PDF o PPT avvelenati. Ci sono tonnellate di zero giorni per il targeting di PDF e PPT, e la natura di entrambi questi formati di applicazione è tale che non c'è più o meno alcun modo per proteggersi da un trojan contemporaneo in uno dei due. Pertanto, hai fondamentalmente due opzioni: richiedere tutti gli allegati PDF / PPT per passare attraverso un processo di verifica, che non è pratico per la maggior parte delle organizzazioni, o per formare i tuoi dipendenti alle e-mail di veterinaria stesse che è l'opzione migliore nella maggior parte dei casi. Una terza opzione consiste nel testare tutti i PDF e i PPT inviati all'organizzazione in un ambiente sandbox dopo il fatto, ma questo è possibile solo per le organizzazioni avanzate, come le forze armate, non la società media. L'opzione 3, naturalmente, non impedisce l'intrusione, ma ti avverte immediatamente se si verifica una situazione.
(2) Vulnerabilità del browser. La stragrande maggioranza degli exploit basati su browser ha come target Internet Explorer, quindi puoi difendere probabilmente il 95% di questi solo impedendo agli utenti di utilizzare IE e richiedendo loro di utilizzare Chrome o Firefox. Puoi evitare il 99% degli exploit basati sul browser richiedendo agli utenti di utilizzare NoScript e addestrarli nel suo utilizzo, il che purtroppo non è pratico per la maggior parte delle organizzazioni.
(3) Vulnerabilità del server. Un esempio potrebbe essere il bug NTP di qualche anno fa. Puoi difenderti in gran parte da questi assicurandoti che tutti i server aziendali stiano girando su reti isolate (una "zona smilitarizzata") e che quei server siano stretti e non eseguano servizi inutili. In particolare, è necessario assicurarsi che tutti i server Web aziendali siano eseguiti da soli in ambienti isolati e che nulla possa entrare o uscire da tali ambienti senza che un utente esegua esplicitamente la copia in modo controllato.
Ovviamente ci sono molti exploit che non rientrano in queste categorie, ma è meglio spendere il tuo tempo per affrontare le tre classi di vulnerabilità sopra elencate.
Bene, è ok avere 0 giorni da un attaccante, il problema è quanti giorni zero hanno e quanto costa per loro bruciare tutti gli 0 giorni nella tua rete.
Se non si dispone di patch aggiornate, si riduce il costo per un utente malintenzionato di sviluppare una catena di uccisioni.
Quando ci pensi, come vorresti iniziare ad attaccare una rete? Diciamo che inizi con un attacco di phishing / attacco d'acqua.
Se si tratta di un attacco waterhole, potrebbe essere necessario trovare un flash in 0 giorni che consenta di eseguire codice nel browser, e quindi potrebbe essere necessario uscire dalla sandbox del browser per primo, che richiede un altro 0 giorni. E dopo potresti affrontare l'appcontainer, che richiede un altro exploit per raggiungere il privilegio del livello del sistema operativo. E ci sono meccanismi di protezione come SIP in macOS, significa che anche se si ha accesso root, non si può accedere alla memoria importante. Ciò significa che hai bisogno di un altro exploit del kernel 0day. Se è in esecuzione Windows 10 con cred guard e si sta prendendo di mira Lsass.exe, potrebbe essere necessario un altro 0day per attaccare l'hypervisor.
Quindi risulta che l'attacco è molto costoso e richiede un notevole sforzo di ricerca e, nel frattempo, mentre li sfrutti, potresti attivare un avviso di sicurezza.
Quindi, come difensore, assicurati di conoscere bene la tua rete, controlla i controlli di difesa in ogni singolo livello e dovresti essere in grado di difendersi da un attacco di 0 giorni.