La persona che scopre un problema di sicurezza spesso lo segnala prima al fornitore del software o allo sviluppatore. Questo dà al fornitore del software il tempo di risolvere il problema prima della pubblicazione. Quindi, dopo che è stato risolto, il bug viene divulgato pubblicamente. Questo processo è chiamato divulgazione responsabile.

A volte, qualcuno non rivela lo zero-day al fornitore di software ma lo usa per hackerare altri sistemi. In questo modo si possono avvisare le società di sicurezza e divulgare il bug, bruciando lo zero-day.

Non credo che la tua dichiarazione "la maggior parte delle volte, 0day è usato per mesi dai cappelli neri " è vero. Questo è vero per alcuni problemi di sicurezza, ma molti bug zero-day vengono rilevati per la prima volta da hacker white-hat. Non direi che gli hacker black hat siano davanti agli hacker white hat. Entrambi riscontrano problemi di sicurezza e alcuni di questi si sovrappongono. Tuttavia, l'attacco è più facile della difesa in quanto l'attacco deve trovare solo un bug e la difesa deve correggere tutti i bug.

Quando viene pubblicato uno 0day, come può un amministratore proteggere la sua applicazione / sito web tra il momento in cui lo 0day viene pubblicato e lo sviluppo della patch?

Usano soluzioni temporanee fino al rilascio di una patch.

Quando viene fuori la notizia di uno 0day, spesso vengono pubblicate varie soluzioni alternative che rompono l'exploit eliminando alcuni prerequisiti per abusare della vulnerabilità. Ci sono molte possibilità:

• La modifica di un'impostazione di configurazione può disabilitare la funzionalità vulnerabile.

• La disattivazione dei servizi vulnerabili, quando pratico, può prevenire lo sfruttamento.

• L'attivazione di misure di sicurezza non predefinite potrebbe interrompere l'exploit.

Ogni bug è diverso e ogni la mitigazione è diversa. Un amministratore con una buona conoscenza della sicurezza può trovare soluzioni alternative se vengono rilasciati dettagli sufficienti sulla vulnerabilità. La maggior parte degli amministratori, tuttavia, guarderà agli avvisi sulla 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 suoi server non useranno comunque DRM. Una vulnerabilità in Apache, d'altra parte, potrebbe essere qualcosa di cui dovrebbero preoccuparsi. Un buon amministratore di sistema sa cos'è e non è un fattore di rischio.

Inoltre, la maggior parte delle volte, questo stesso 0day viene utilizzato per mesi dai blackhat, quindi i blackhat sono davanti ai whitehats?

I cappelli bianchi sono più sofisticati, ma i cappelli neri sono più efficienti.

Se i blackhat siano o meno davanti ai whitehat è una domanda molto soggettiva. Blackhats userà qualunque cosa funzioni. 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é esistono già bypass ASLR onnipresenti e non sofisticati. Whitehats d'altra parte ha bisogno di pensare a soluzioni e effettivamente convincere il fornitore di software a prendere sul serio il rapporto. Ciò non influisce quasi nella stessa misura sui blackhat, poiché spesso possono iniziare a trarre vantaggio dalla loro scoperta nel momento in cui lo fanno. Non hanno bisogno di aspettare una terza parte.

Dalla mia esperienza, i blackhat hanno spesso un vantaggio significativo. Ciò è principalmente dovuto al fatto che la cultura attuale tra i cappelli bianchi è quella di cacciare e schiacciare i singoli insetti. Meno enfasi viene posta sull'eliminazione di intere classi di bug e, quando lo è, vengono create mitigazioni sub-par e over-hyped (come KASLR). Ciò significa che i blackhat possono pompare 0 giorni più velocemente di quanto possano essere riparati, poiché viene prestata così poca attenzione alla superficie di attacco e ai vettori di sfruttamento che continuano ad essere utilizzati e riutilizzati.

Quando uno zero-day viene rilasciato o pubblicato, viene fornito con più di un semplice nome e icona di fantasia. Ci sono dettagli su come lo zero-day viene utilizzato per sfruttare il sistema. Questi dettagli costituiscono la base della risposta del difensore, incluso il modo in cui la patch deve essere progettata.

Ad esempio, con WannaCry / EternalBlue, la vulnerabilità è stata trovata dalla NSA e hanno tenuto la conoscenza per sé (lo stesso accade nella comunità criminale dove le vulnerabilità possono essere scambiate mercato nero). Sono trapelati i dettagli, che hanno 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.

È così che gli amministratori si proteggono. L'applicazione di patch è solo una parte della "gestione delle vulnerabilità". Ci sono molte cose che un amministratore può fare per gestire le vulnerabilità anche se non può o non vuole applicare la patch.

Nel caso WannaCry, l'NHS non ha applicato patch, ma non ha nemmeno impiegato le altre difese che si sarebbero protette da sole.

Una parte importante del mio lavoro è progettare mitigazioni della vulnerabilità per sistemi a cui non è possibile applicare patch per vari motivi aziendali. L'applicazione di patch è la soluzione migliore, in generale, ma a volte semplicemente non è possibile al momento della patch.

... i blackhat sono davanti ai whitehat?

Questo pone un problema interessante. Se un blackhat trova un problema e lo condivide solo con altri blackhat (o altri membri della comunità dell'intelligence), significa che i blackhat, complessivamente , sono in vantaggio sui whitehats? Sì. Una volta che uno zero-day viene esposto, perde il suo potere (questo è il punto centrale per rivelarlo). Quindi, mantenerlo segreto, gli dà potere.

I blackhat sono più abili o usano tecniche migliori dei whitehat? No. Ma i segreti condivisi conferiscono ai blackhats più potere, complessivamente.

Quando viene pubblicato uno 0day, come può un whitehat proteggere la sua applicazione / sito web tra il momento in cui lo 0day viene pubblicato e lo sviluppo della patch?

A volte ci sono soluzioni alternative che risolvere o mitigare il problema.

• A volte è possibile disabilitare alcune funzionalità o modificare alcune impostazioni nel software che fanno sì che l'exploit non funzioni più. Ad esempio, l'infezione con il Morris Worm del 1988 potrebbe essere prevenuta creando una directory / usr / tmp / sh . Questo ha confuso il worm e gli ha impedito di funzionare.
• A volte l'exploit richiede un qualche tipo di interazione da parte dell'utente. In tal caso puoi avvisare gli utenti di non farlo. (" Non aprire le email con oggetto ILOVEYOU"). Ma poiché gli esseri umani sono umani, di solito questa soluzione non è molto affidabile.
• A volte l'attacco è facile da identificare sulla rete, quindi puoi bloccarlo con qualche regola del firewall più o meno complicata. Il virus Conficker, ad esempio, mirava a una vulnerabilità nel servizio di chiamata a procedura remota di Windows. Di solito non c'è alcun motivo per cui questa funzionalità sia accessibile dall'esterno della rete locale, quindi era possibile proteggere un'intera rete semplicemente bloccando le richieste esterne alla porta 445 TCP.
• A volte è possibile sostituire il software vulnerabile con un'alternativa. Ad esempio, la nostra organizzazione installa due diversi browser Web su tutti i client Windows. Quando uno di loro ha una vulnerabilità nota, gli amministratori possono disattivarlo tramite criteri di gruppo e dire agli utenti di utilizzare l'altro fino al rilascio della patch.
• Come ultima risorsa, puoi semplicemente staccare la spina sui sistemi vulnerabili. Se i sistemi non disponibili causano più o meno danni rispetto a quelli online e aperti agli exploit è una considerazione aziendale che devi valutare in ogni singolo caso.

Ma a volte nessuna di queste è un'opzione praticabile. In tal caso puoi solo sperare che ci sarà presto una patch.

Inoltre, la maggior parte delle volte, questo stesso 0day viene utilizzato per mesi dai blackhat, quindi i blackhat sono davanti ai whitehat?

Accade abbastanza frequentemente che sviluppatori / whitehats scoprano una possibile vulnerabilità di sicurezza nel loro software e la correggano prima che venga sfruttata. Il primo passaggio della divulgazione responsabile è informare gli sviluppatori in modo che possano correggere la vulnerabilità prima di pubblicarla.

Ma di solito non si sente parlare di questo nei media. Quando il punto 59 delle note sulla patch per SomeTool 1.3.9.53 legge "risolto un possibile overflow del buffer durante l'elaborazione di file foobar malformati" di solito non è particolarmente interessante.

Un'altra difesa fondamentale è il monitoraggio e la conoscenza del sistema.

Dove sono i tuoi segreti preziosi e chi ha accesso ad essi.

Se qualcuno cerca 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é?

Monitora le persone che si connettono agli indirizzi IP esterni. Elimina e / o blocca tutte le porte e i protocolli esterni che non sono in uso.

Nessun utente legittimo si connetterà al tuo server web su altro che 80 o 443. A meno che tu non abbia aggiunto servizi aggiuntivi. Potresti considerare di bloccare questi IP per un po 'di tempo. A volte, l'IP fa parte di pool dinamici e non puoi sempre risolvere un problema con una lista nera, quindi devi semplicemente rilasciare i pacchetti.

Se la tua azienda fa affari solo in 1 paese, forse dovresti semplicemente bloccare tutti gli altri paesi.

È possibile utilizzare whois per trovare il proprietario globale dell'intervallo di indirizzi IP e, se presente, utilizzare le informazioni di contatto dell'amministratore per avvisare il proprietario. Possono rintracciarlo alla loro fine. (Vale la pena provare)

Dovresti ricevere una notifica quando un sistema viene contattato da un altro sistema in modo imprevisto. Dopo il primo potresti ricevere un sacco di notifiche, ma se i computer sono sulla tua rete, puoi indagare su entrambi i lati. Quindi eliminalo o inseriscilo nella lista bianca come previsto per il traffico.

Questi strumenti di monitoraggio ti informeranno anche sulle scansioni delle porte, a meno che tu non abbia un team di sicurezza autorizzato, nessun altro dovrebbe eseguire la scansione delle porte.

Guarda per eventi regolari e se si fermano misteriosamente perché?

Controlla la macchina per le infezioni. Se i servizi sono disabilitati, dovresti essere avvisato in anticipo in modo che le modifiche siano previste 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 temporaneamente il sistema è 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 i bug in anticipo prima degli hacker. Quindi hai la possibilità di mitigare l'attacco alle tue condizioni. Notificare il manutentore del sistema di effetti in modo che possano correggerlo. Se è open source, puoi chiedere a qualcuno di correggerlo.

I sistemi di rilevamento delle intrusioni e snort possono anche esaminare e potenzialmente bloccare gli hack in arrivo rilevando modelli sospetti.

per trovare un prodotto alternativo per sostituire quello vulnerabile a seconda della gravità del problema.

Come sempre mantenere aggiornato il tuo software aiuta a proteggerti.

In questo modo puoi bloccare attività sospetta, finché non si determina la sua legittimità.

La maggior parte dei potenziali exploit richiede una catena di vulnerabilità per essere eseguita. Leggendo lo zero-day non ancora corretto, è ancora possibile identificare altre vulnerabilità o pre-condizioni che lo zero-day richiederebbe.

Per difendersi dalla minaccia di (diciamo) un attacco RDP dall'esterno rete (errore di autenticazione RDP zero-day pubblicato), non consentire RDP da off-site. Se non hai davvero bisogno di RDP dall'esterno, questa è un'opportunità per correggere una svista. Oppure, se è necessario disporre di RDP da off-site, forse è possibile identificare una whitelist di IP da cui consentire queste connessioni e restringere l'apertura nel firewall.

Allo stesso modo, per difendersi da una minaccia RDP interna (e in una certa misura esterna), limitare la capacità degli utenti A) di eseguire RDP, B) macchine di eseguire RDP, C) la rete di passare RDP, D) macchine per accettare 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 in quelli interni, lavora per rafforzare la tua rete contro un exploit di autenticazione RDP anche senza una patch.

Una mentalità di difesa in profondità consente di interrompere la catena di vulnerabilità / condizioni necessarie per contrastare anche uno zero-day senza patch. A volte.

Ho scelto intenzionalmente un problema abbastanza semplice qui solo per illustrare il punto.

Fonte: l'ho già fatto.

Relativamente pochi hack consentono all'aggressore di penetrare in un sistema. La maggior parte sono bug di "escalation dei privilegi" che consentono a un utente malintenzionato di avere un maggiore controllo sul sistema dopo avervi accesso. Ci sono così tanti modi per ottenere il controllo amministrativo di una macchina una volta che un hacker vi ha accesso, che è più o meno una perdita di tempo cercare di proteggere una macchina dall'escalation dei privilegi. La tua migliore politica è di concentrarti sull'impedire agli hacker di entrare in primo luogo e monitorare la tua rete per le intrusioni.

Quasi tutte le intrusioni provengono da soli tre metodi. Vuoi spendere tutte le tue risorse di difesa informatica disponibili per difenderti da questi. Sono:

(1) Email di phishing contenenti PDF o PPT avvelenati. Ci sono tonnellate di zero giorni che prendono di mira PDF e PPT, e la natura di entrambi questi formati di applicazioni è tale che non c'è più o meno modo di proteggersi da un trojan contemporaneo in nessuno dei due. Pertanto, hai fondamentalmente due opzioni: richiedere che tutti gli allegati PDF / PPT siano sottoposti a un processo di verifica, che non è pratico per la maggior parte delle organizzazioni, o per addestrare i tuoi dipendenti a controllare le e-mail da soli, che è l'opzione migliore nella maggior parte dei casi. Una terza opzione è 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 i militari, non per l'azienda media. L'opzione 3 ovviamente non impedisce l'intrusione, ma ti avvisa immediatamente se si verifica.

(2) Vulnerabilità del browser. La stragrande maggioranza degli exploit basati su browser prende di mira Internet Explorer, quindi puoi difenderne probabilmente il 95% semplicemente impedendo agli utenti di utilizzare IE e richiedendo loro di utilizzare Chrome o Firefox. Puoi prevenire il 99% degli exploit basati su browser richiedendo agli utenti di utilizzare NoScript e addestrandoli al 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 ampiamente da questi assicurandoti che tutti i server aziendali siano in esecuzione su reti isolate (una "zona demilitarizzata") e che quei server siano stretti e non eseguano servizi non necessari. In particolare, vuoi assicurarti che tutti i server Web aziendali vengano eseguiti da soli in ambienti isolati e che nulla possa entrare o uscire da tali ambienti senza che un essere umano esegua esplicitamente la copia in modo controllato.

Ovviamente ci sono molti exploit che non rientrano in queste categorie, ma è meglio dedicare il tuo tempo ad affrontare le tre classi di vulnerabilità elencate sopra.

Bene, va bene avere 0 giorni da un utente malintenzionato, il problema è quanti zero giorni hanno e quanto costa bruciare tutti gli 0 giorni nella tua rete.

Se non disponi di patch aggiornate, riduce il costo per un attaccante per sviluppare una kill chain.

Quando ci pensi, come invieresti ad attaccare una rete? Supponiamo che tu inizi con un attacco di phishing / waterhole.

Se si tratta di un attacco waterhole, potrebbe essere necessario trovare un giorno 0 in flash che consente di eseguire codice nel browser, quindi potrebbe essere necessario uscire prima dalla sandbox del browser, che richiede un altro 0 giorno. E poi potresti dover affrontare appcontainer, che richiede un altro exploit per raggiungere i privilegi a livello di sistema operativo. E ci sono meccanismi di protezione come SIP in macOS, significa che anche se hai accesso root, non puoi accedere alla memoria importante. Ciò significa che hai bisogno di un altro exploit del kernel 0day. Se sta eseguendo Windows 10 con cred guard e stai prendendo di mira Lsass.exe, potresti aver bisogno di un altro giorno 0 per attaccare l'hypervisor.

Quindi si scopre che l'attacco è molto costoso e richiede molti sforzi di ricerca, e nel frattempo mentre li sfrutti, potresti attivare un avviso di sicurezza.

Quindi, come difensore, assicurati di conoscere bene la tua rete, avere controlli di difesa in ogni singolo livello e dovresti essere in grado di difenderti dagli attacchi 0 giorni.

Il problema non è solo con zero giorni. Ci sono molte aziende che continuano a trascinare patch di 200 giorni per una moltitudine di motivi (alcuni buoni, altri cattivi).

Hai un lungo elenco di soluzioni, un altro è usare virtuale patching. Di solito crea una mitigazione del problema prima che raggiunga il servizio (l'ho imparato anni fa grazie a un prodotto Trend Micro - nessun collegamento con loro ma l'ho testato e per lo più ha funzionato).