Trovare vulnerabilità nei principali browser è facile o no?

È una gara tra le persone che vogliono risolvere le vulnerabilità e le persone che vogliono sfruttarle. Trovare le vulnerabilità è difficile: scrivere codice corretto è molto più difficile che scrivere codice quasi corretto .

Supponiamo (numeri tirati fuori dal nulla) che il 99% dei difetti di sicurezza nei prodotti rilasciati siano trovati e riparati dagli autori stessi o riportati privatamente agli autori. Ciò significa che l'1% dei difetti di sicurezza è reso pubblico attraverso un exploit (un zero-day ). Hai solo sentito parlare degli exploit pubblicizzati, non di quelli che sono tranquillamente risolti - così che l'1% è tutto ciò che senti. Gli autori e gli analisti devono risolvere ogni singola vulnerabilità al fine di creare un prodotto completamente sicuro; gli "hacker" devono solo trovare una vulnerabilità non risolta.

Ma in realtà è peggio: anche nel caso del 99%, quando gli autori rilasciano una nuova versione, non tutti aggiorneranno immediatamente. C'è un'altra corsa: la corsa tra sfruttamento e patching. Una volta disponibile l'aggiornamento, i cracker possono studiare le differenze con la versione precedente e creare exploit per versioni precedenti che le persone sono ancora in esecuzione. Questo lascia un sacco di macchine esposte.

Esistono diverse tecniche per cercare le vulnerabilità, utilizzate da entrambe le parti allo stesso modo. Fuzzing è uno di questi: prova ad inserire dati casuali in un programma e verifica se reagisce in modo interessante. Ad esempio, se il programma si blocca (che di per sé è spesso una negazione del servizio), studia il modo in cui si blocca con attenzione; spesso elaborando i dati di input ti consente di eseguire l'escalation per l'esecuzione di codice arbitrario. Un altro approccio è analisi statica : esegui analisi automatiche sul codice sorgente o codice compilato, per cercare pattern sospetti (ad esempio, cerca deselezionata accesso agli array) o verificare l'assenza di determinati tipi di comportamento scorretto (ad es. dimostrare che tutti gli accessi agli array sono deselezionati). L'analisi statica può essere integrata da revisioni manuali, per cercare aspetti che gli strumenti automatizzati non siano sufficienti a rilevare (ad esempio, verificare che tutti i file temporanei siano creati in modo sicuro). L'esperienza aiuta, ovviamente - a volte qualcuno penserà "hey, questo è un problema difficile, mi chiedo se gli sviluppatori abbiano capito bene la causa".

Raccomando di leggere la presentazione del processo di audit di OpenBSD e di esaminare ulteriormente il progetto OpenBSD. Questo è un progetto open source, con discussioni aperte e fanno della sicurezza una priorità. Non conosco una presentazione più completa del loro processo di controllo della sicurezza; puoi scoprire di più a riguardo sfogliando le loro mailing list .

Più in generale, guarda gli annunci di sicurezza per il software open source (ad esempio una distribuzione Linux). Quando viene annunciata una patch di sicurezza, guarda la descrizione della vulnerabilità, all'origine originale e alla patch. Cerca di capire quali modelli possono essere problematici, come sono stati trovati (l'annuncio di vulnerabilità spesso ha un link a un resoconto più dettagliato) e come sono stati corretti.

Fammi provare ad affrontare la parte "patching" della tua domanda: Trovare i problemi - almeno nel software - è un ordine di grandezza più facile di correggerli . Considera la lista più breve possibile di ostacoli da superare:

0) È un bug o una funzione?
1) È questo il vero difetto o solo la manifestazione di un problema più profondo?
2) Il problema è abbastanza grave da giustificare una correzione?
3) Questo è ancora risolvibile? (ad esempio se il tuo programma è stato scritto supponendo che supportare le date oltre l'anno 2038 sia inutile o che nessuno avrebbe mai avuto bisogno di un file più grande di 4 GB , potrebbe essere necessaria una completa riscrittura

4) Se risolviamo questo problema, qualsiasi cosa dipenda dal comportamento si romperà - è accettabile, abbiamo bisogno di escogitare soluzioni alternative, quali sono le probabilità che tali soluzioni alternative abbiano i loro stessi bug?
5) "Risolvere un bug introduce sempre almeno due nuovi bug"
6) C'è un budget (di tempo e denaro) per correggere il bug, testare e distribuire la correzione?

E questo è tutto prima che la politica aziendale si concretizzi - dopo tutto, alcune aziende sono state conosciute per rifiutarsi di riconoscere le segnalazioni di bug e giocare a morte (per qualsiasi ragione).

Alcuni altri pensieri:

Se i giovani hacker sono in grado di rilevarli, perché gli analisti della sicurezza non possono ottenerli e correggerli?

Ricorda

• per un dato prodotto ci sono un numero fisso di persone che creano e aggiustano il prodotto e un numero quasi illimitato di persone disponibili per rompere o sfruttare il prodotto. Il numero di persone che cercano di rompere il prodotto può essere approssimativamente correlato alla popolarità del prodotto, alla sua prevalenza e alla natura delle informazioni che gestisce o protegge. Quindi - molte persone stanno cercando di distruggere IE (molto popolare), software di banking online (alto valore) e non molte persone stanno cercando di rompere un prodotto di nicchia creato per uno scopo oscuro.

• "Il giovane hacker scopre un grosso bug nel prodotto" è un titolo grande . Considera le tue fonti quando sembra che solo i giovani stiano trovando bug. "Il vecchio croccante si rompe il prodotto nel corso degli affari" non venderà alcun documento online. I giovani hacker stanno scoprendo bug e stanno facendo notizia. I vecchi hacker sono in genere definiti "analisti della sicurezza" e molti di loro hanno lavori che implicano la ricerca silenziosa di exploit (solo un po 'di ironia sulla lingua).

• La correzione di un bug non è poi così difficile. Risolvere un bug e non rompere nient'altro è spesso abbastanza difficile. Peggio ancora sono i bug che derivano da un uso improprio che semplicemente non può essere risolto.

Inoltre, sogno di trovare una vulnerabilità in un software importante, come IE o Chrome. È facile? È sistematico o è casuale? Quali libri devo leggere per rilevarli a tempo debito?

Se sei particolarmente interessato ai browser web, ti suggerisco di familiarizzare con la tecnologia che circonda il Web: HTML, Java Script, Active X, AJAX, SSL, DNS, CSS - qualsiasi cosa e tutto ciò che viene passato e elaborato dal browser web. Una comprensione approfondita di queste tecnologie e di come funzionano i browser è la chiave di quest'area.

Non c'è un libro. Non c'è nemmeno una lista di lettura. Questa area cambia VELOCE - le nuove correzioni ai principali browser vengono pubblicate con estrema frequenza, nuove tecnologie e nuovi browser escono ogni anno. Il ciclo di sviluppo in quest'area è in realtà più veloce del ciclo di pubblicazione per qualsiasi cosa tranne un e-Book. È possibile ottenere una lettura di fondo decente sulle tecnologie che ho menzionato, ma molto presto vorrete leggere gli attuali standard WWW (come www.w3c.org) in modo da conoscere i dettagli aggiornati su queste tecnologie.

L'hacking è sia sistematico che casuale. Devi sapere abbastanza sul dominio in cui stai hacker per essere in grado di fare ragionevolmente buone ipotesi su cosa provare per trovare un exploit. Quasi tutti i prodotti moderni possono essere troppo complicati per provare assolutamente input e output ogni , quindi sarà necessario un certo grado di indovinare per tentare una probabile area di vulnerabilità. Le migliori analisi che conosco sono quelle che vedono il sistema nel suo insieme e sono in grado di eseguire rapidamente il drill nella maggior parte delle aree e vedere come i fattori congiunti ambientali possono contribuire a rendere un prodotto vulnerabile.

Ora so come programmare in C / C ++ / Java. Posso facilmente imparare Assembly.

Onestamente, non vedo come l'Assemblea ti aiuterà. A volte, aiuta a conoscere la lingua del codice base del prodotto - SE è possibile accedervi. Ma la cosa più importante è sapere cosa dovrebbe fare il prodotto, ed essere in grado di analizzarlo in modo efficace per capire dove non riesce a fare ciò che deve fare, o dove ciò che sta facendo sta producendo indesiderabili risultati.

Le risposte qui sono fantastiche. Ecco un altro modo per pensarci.

Tutti i software hanno bug. Un tasso di difetto standard è 2-10 difetti per mille righe di codice; alcuni di questi saranno difetti rilevanti per la sicurezza (di diversa gravità). I browser hanno milioni di linee di codice. Quindi, per quanto ne sappiamo, un tipico browser potrebbe avere centinaia o migliaia di difetti di sicurezza in agguato, in attesa di essere scoperti.

Supponiamo che nel browser ci siano 500 vulnerabilità di sicurezza sconosciute, che non sono state ancora scoperte. Diciamo che se inserisci 500 ore di lavoro (fuzzing, revisione del progetto, revisione del codice, ecc.), Scoprirai una vulnerabilità, una disegnata a caso dal pool di 500 vulnerabilità.

Quanto tempo ci vuole perché un utente malintenzionato trovi la sua prima vulnerabilità precedentemente sconosciuta? 500 ore = 3 mesi-persona.

Quanto tempo ci vuole perché un difensore trovi tutte le vulnerabilità, in modo che possano essere riparate? Almeno 500 * 500 = 250.000 ore = 125 anni-persona. In realtà, questa è una sottostima. A causa di un fenomeno matematico noto come problema del tagliando del tagliando, il numero effettivo è più di 500 * log (500) * 500 = 1,5 milioni di ore = 776 anni-persona. Questo non tiene nemmeno conto della quantità di lavoro per risolvere i problemi una volta trovati, per testare le correzioni, per spingerli fuori agli utenti - o la probabilità che alcune delle correzioni possano introdurre nuovi problemi. In pratica, la situazione difficile del difensore è persino peggiore di quanto questo possa suggerire.

Quindi puoi vedere che l'attaccante ha un enorme vantaggio sul difensore. Con un po 'di sforzo, l'attaccante può trovare una vulnerabilità (dal momento che l'attaccante non si cura di quello che trova, qualsiasi farà); mentre ci vuole un enorme sforzo per trovare e risolvere tutti i difensori. Poiché il difensore deve trovare tutte le vulnerabilità, mentre l'attaccante deve solo trovarne uno, l'attaccante ha un enorme vantaggio.

Questo è uno dei motivi per cui la gente dice "non puoi incastrare sulla sicurezza dopo il fatto" o "non puoi testare la sicurezza in". Se hai creato il software con pratiche di sicurezza inferiori, non è probabile che una quantità ragionevole di test dopo il fatto sia sufficiente.

Le risposte di cui sopra sono davvero grandiose e vorrei aggiungere qualcosa dal punto di vista della complessità computazionale, in particolare per affrontare la questione della ricerca di vulnerabilità in qualsiasi caso generale (o in un dato codice). L'idea è simile alla ricerca di ostruzioni, che in un certo senso "dimostrano" che un calcolo non può essere completato in tempo "realistico" (tempo polinomiale). Ora trovare un algoritmo del tempo polinomiale in grado di fornire l'esistenza di una famiglia di ostruzione sembra irrealizzabile.

Una famiglia di ostruzioni è semplicemente un insieme di etichette di ostruzione in cui ogni etichetta indica un'ostruzione ben definita ed esplicitamente costruita. Quindi immagina uno scenario in cui conosciamo tutti i membri di questo set, quindi possiamo facilmente correggerli, ma altrimenti per trovare membri di questo set, dovresti provare ogni combinazione possibile che non sia realistica. In pratica, trovarli sembrerebbe casuale ma ci possono essere indizi su una particolare procedura in cui possono sorgere vulnerabilità, quindi possiamo sicuramente trovare alcuni membri, ma non tutti.

Trovare vulnerabilità zero-day è ancora più difficile, tuttavia, come vedo in altre risposte, ci sono alcune checklist che possono essere utilizzate per assistervi nel processo. Nel complesso è ancora un caso da non perdere, alcune persone impiegano anni per trovarle mentre altre le trovano relativamente rapidamente.

Un'altra connessione che vedo è soprattutto con i browser, potrebbe essere più facile in un certo senso trovare vulnerabilità poiché ci sono così tanti componenti nel browser stesso, come forse già sapete, il database di metasploit continua ad accumularsi con quelli. In modo che forse un buon punto di partenza e se posso suggerire, rintracciare una vulnerabilità specifica e leggere su come è stato trovato, quindi cercare di trovare da soli, che ti darebbe buone pratiche. Buon divertimento :)