Potrebbe essere una domanda sciocca, ma gli hacker utilizzano strumenti disponibili pubblicamente per trovare le vulnerabilità. Quindi perché le aziende, prima di rilasciare i loro prodotti (Windows, Adobe ecc.), Usano gli stessi strumenti per trovare quelle vulnerabilità e risolverle?
Non capisco. Mi manca qualcosa?
Lo stanno facendo, o almeno ci si aspetta che lo facciano, come parte del loro Software Development Life Cycle (SDLC).
In termini di gestione delle vulnerabilità, una buona pratica sarebbe quella di eseguire prima una revisione del codice sorgente (statico / dinamico) e di scansionare il loro prodotto usando un scanner di vulnerabilità . Si noti che esistono anche altri passaggi per applicare un SDLC sicuro, come la modellazione delle minacce, le linee guida per la codifica sicura ecc. Che dovrebbero essere eseguite anche.
Nella vita reale , questo è il 90% delle volte considerato un'attività "inutile", perché richiede risorse ma non genera entrate né aggiunge nuove funzionalità all'applicazione.
Oltre alla risposta di ack_, c'è una significativa curva di apprendimento nell'uso di questi strumenti. Come tester di penetrazione, il tempo speso per eliminare i falsi positivi e le vulnerabilità non sfruttabili spesso richiede altrettanto (se non più) tempo di tentare di sfruttare un attacco. Aggiungete a ciò il tempo necessario per diventare abili nell'utilizzo di questi strumenti e vi troverete a cercare di occupare un'altra posizione IT a tempo pieno. Per esempio Hydra dovrebbe essere uno strumento semplice da usare, ma nella mia esperienza è un PITA reale. Gli strumenti automatici sono un ottimo punto di partenza, ma non così vicino come un ingegnere esperto.
Loro (dovrebbero) fare, specialmente le aziende che devono conformarsi ad alcuni standard di sicurezza come il settore delle carte di pagamento: PCI-DSS o iso 27001. Devono disporre di un SDLC sicuro che incorpora un training di codifica sicuro, revisione del codice da parte di un esperto di sicurezza (bianco test in scatola) e test di penetrazione periodici (test black box) eseguiti anche da società esterne. Anche l'intera rete e non solo le applicazioni vanno sottovalutate.
I bug del software vengono scoperti principalmente attraverso il controllo del codice sorgente, il reverse engineering e il fuzzing. Fuzzer è lo strumento che può essere definito come "lo strumento hacker" di cui hai parlato. Google spende migliaia di ore a sfocare cromo e altri software critici prima del rilascio. Adobe sta seguendo queste pratiche anche dopo l'orribile abuso di vulnerabilità all'interno del proprio prodotto Reader. Il motivo per cui la maggior parte delle aziende di medie o piccole dimensioni non può permettersi di utilizzare questi strumenti in modo efficace è:
Di solito, nella sicurezza, pensiamo che i bug di sicurezza siano molto importanti e dovrebbero essere trattati con la massima importanza. I team di software non la pensano così. Proprio come Haroon Meer menzionato nella Troopers15 keynote la scorsa settimana, i boss che ricevono bonus e promozioni in base alle versioni dei prodotti software, quando vengono trovati bug dopo mesi o anni, o hanno lasciato l'azienda o si trovano in una posizione intoccabile.
Inoltre, quando è stata l'ultima volta che una società è fallita dopo che sono stati trovati bug di sicurezza nel loro software? I software Adobe, Oracle, IE, Flash e CMS hanno quasi illimitato l'arrivo di bug di esecuzione di codice in modalità remota ogni mese, ma l'attività di nessuna di queste società viene eseguita. Questo è il motivo per cui le aziende non dedicano tempo e sforzi a mitigare le vulnerabilità. Semplicemente non è di importanza commerciale.
Personalmente, utilizzo strumenti e tecniche avversarie per testare i miei sistemi, reti e app di destinazione. Per il livello Web, ad esempio, strumenti come Acunetix WVS sono stati storicamente archiviati da criminali online.
Metasploit è un cattivo esempio di questo scenario proposto dall'interrogante (e come accennato in alcuni dei commenti). Un esempio migliore potrebbe essere l'utilizzo della simulazione dell'avversario tramite il Malleable C2 di Cobalt Strike per riutilizzare gli IoC reali e avversari reali come il traffico di rete e gli hash dei file di malware su disco (o anche in memoria).
Le tecniche di ingegneria sociale, o in realtà qualsiasi TTP, possono essere abbinate a eventi realistici. Questo è più dello scopo di un'analisi di squadra rossa, da utilizzare durante un esercizio di cyber, che in un test di penetrazione. I test di penetrazione cercano di comprendere la prospettiva di un insider di fiducia, come lo sviluppatore stesso, non quello di un semplice utente non intenzionale, come ad esempio tramite spear phishing, attacchi waterhole o simili.
Leggi altre domande sui tag static-analysis vulnerability code-review fuzzing