Scansione delle vulnerabilità e sviluppo sicuro. Parte 1

Nel corso dell'attività professionale, sviluppatori, pentester e esperti di sicurezza si trovano ad affrontare processi come Vulnerability Management (VM) e (Secure) SDLC.
Queste frasi nascondono diversi set di pratiche e strumenti utilizzati, che sono interconnessi, anche se i loro utilizzatori differiscono.

Il progresso tecnico non è ancora arrivato al punto da sostituire l'uomo con un unico strumento per condurre analisi di sicurezza su infrastrutture e software.
È interessante capire perché sia così e quali problemi si devono affrontare.

Processi

Il processo di Vulnerability Management è destinato al monitoraggio continuo della sicurezza dell'infrastruttura e alla gestione delle patch.
Il processo di Secure SDLC è progettato per supportare la sicurezza dell'applicazione durante lo sviluppo e l'operatività.

Una parte simile di questi processi è il Vulnerability Assessment, ovvero la valutazione delle vulnerabilità, la scansione delle vulnerabilità.
La principale differenza nella scansione all'interno di VM e SDLC è che nel primo caso l'obiettivo è scoprire vulnerabilità note in software di terze parti o nella configurazione. Ad esempio, una versione obsoleta di Windows o la stringa community predefinita per SNMP.
Nel secondo caso, l'obiettivo è scoprire vulnerabilità non solo nei componenti di terze parti (dipendenze), ma soprattutto nel codice del nuovo prodotto.

Questo genera differenze negli strumenti e negli approcci. A mio avviso, il compito di identificare nuove vulnerabilità nell'applicazione è significativamente più interessante, poiché non si riduce a fingerprinting delle versioni, raccolta di banner, attacchi brute force, ecc.
Per una scansione automatizzata di vulnerabilità delle applicazioni di alta qualità, sono necessari algoritmi che tengano conto della semantica dell'applicazione, del suo scopo e delle minacce specifiche.

Un analizzatore infrastrutturale può spesso essere sostituito da un timer, come ha detto avleonov. . Il senso è che statisticamente puoi considerare la tua infrastruttura vulnerabile se non l'hai aggiornata, ad esempio, da un mese.La scansione, così come l'analisi della sicurezza, può essere eseguita sia come black box che come white box.

Strumenti

Black Box

Nel black box scanning, lo strumento deve essere in grado di interagire con il servizio attraverso le stesse interfacce utilizzate dagli utenti.

.

Gli scanner di infrastruttura (Tenable Nessus, Qualys, MaxPatrol, Rapid7 Nexpose, ecc.) cercano porte di rete aperte, raccolgono "banner", determinano le versioni del software installato e cercano nella loro base di conoscenze informazioni su vulnerabilità in quelle versioni. Tentano anche di scoprire errori di configurazione, come password di default o accesso aperto ai dati, crittografie SSL deboli, ecc.

Gli scanner di applicazioni web (Acunetix WVS, Netsparker, Burp Suite, OWASP ZAP, ecc.) sono in grado di identificare anche componenti noti e le loro versioni (ad esempio, CMS, framework, librerie JS). I principali passaggi dello scanner sono crawling e fuzzing.
Durante il crawling, lo scanner raccoglie informazioni sulle interfacce esistenti dell'applicazione e sui parametri HTTP. Durante il fuzzing, vengono inseriti nei parametri scoperti dati mutati o generati al fine di provocare un errore e scoprire una vulnerabilità.

Questi scanner di applicazioni appartengono alle categorie DAST e IAST — rispettivamente Dynamic e Interactive Application Security Testing.

White Box

Con la scansione whitebox ci sono più differenze.
Nel processo di VM, agli scanner (Vulners, Incsecurity Couch, Vuls, Tenable Nessus, ecc.) viene spesso dato accesso ai sistemi, eseguendo una scansione autenticata. In questo modo, lo scanner può estrarre le versioni dei pacchetti installati e i parametri di configurazione direttamente dal sistema, senza doverli indovinare dai banner dei servizi di rete.
La scansione risulta più precisa e completa.

Se parliamo di scansione whitebox (CheckMarx, HP Fortify, Coverity, RIPS, FindSecBugs, ecc.) delle applicazioni, si parla generalmente di analisi statica del codice e dell'uso di strumenti appropriati della classe SAST — Static Application Security Testing.

Problemi

Ci sono molti problemi con la scansione! Con la maggior parte di essi mi trovo ad affrontare personalmente nel contesto della fornitura di servizi per costruire processi di scansione e sviluppo sicuro, così come durante l'analisi della sicurezza.

Evidenzierò 3 gruppi principali di problemi, confermati anche da discussioni con ingegneri e responsabili dei servizi di sicurezza in diverse aziende.

Problemi con la scansione delle applicazioni web

1. Difficoltà nell'implementazione. È necessario configurare e personalizzare gli scanner per ogni applicazione, assegnare un ambiente di test per le scansioni e integrarli nel processo CI/CD affinché funzioni in modo efficace. Altrimenti, diventerà una procedura formale inutile, producendo solo falsi positivi.
2. Durata della scansione. Nel 2019, gli scanner hanno ancora difficoltà con la deduplicazione delle interfacce e possono impiegare giorni a scansionare mille pagine con 10 parametri ciascuna, considerandole diverse, sebbene siano gestite dallo stesso codice. È fondamentale prendere rapidamente decisioni di deploy in produzione nel ciclo di sviluppo.
3. Raccomandazioni scarse. Gli scanner forniscono raccomandazioni piuttosto generali e non sempre il programmatore può comprendere rapidamente come ridurre il livello di rischio, e soprattutto, se è necessario farlo subito o se può attendere.
4. Impatto distruttivo sull'applicazione. Gli scanner possono facilmente condurre attacchi DoS sull'applicazione e possono creare un numero elevato di entità o modificare quelle esistenti (ad esempio, generare decine di migliaia di commenti su un blog), quindi non è consigliabile eseguire scansioni in produzione senza riflessione.
5. Bassa qualità nell'individuazione delle vulnerabilità. Gli scanner utilizzano solitamente un insieme fisso di payload e possono facilmente trascurare una vulnerabilità che non rientra negli schemi di comportamento che conoscono.
6. Incomprensione delle funzionalità dell'applicazione da parte dello scanner. Gli scanner non sanno cosa siano internet banking, pagamenti o commenti. Per loro esistono solo link e parametri, quindi una vasta gamma di potenziali vulnerabilità nella logica aziendale rimane completamente scoperta; non capiranno come eseguire un addebito doppio, visualizzare dati altrui tramite ID o manipolare il saldo tramite arrotondamento.
7. Incomprensione della semantica delle pagine da parte dello scanner. Gli scanner non sanno leggere le FAQ, non riconoscono i captcha, non capiranno come registrarsi e che è necessario effettuare nuovamente il login, che non si deve cliccare su 'logout', e come firmare le richieste quando si modificano i valori dei parametri. Di conseguenza, gran parte dell'applicazione potrebbe rimanere completamente non scansionata.

Problemi nella scansione del codice sorgente.

1. Falsi positivi. L'analisi statica è un compito complesso, che richiede di fare molti compromessi. Spesso si deve sacrificare la precisione, e anche scanner enterprise costosi generano un'enorme quantità di falsi positivi.
2. Difficoltà nell'implementazione. Per aumentare la precisione e la completezza dell'analisi statica, è necessario migliorare le regole di scansione, e scrivere queste regole può risultare troppo impegnativo. A volte è più semplice trovare tutti i punti nel codice con un certo bug e correggerli, piuttosto che scrivere una regola per rilevare tali casi.
3. Mancanza di supporto per le dipendenze. Progetti grandi dipendono da un gran numero di librerie e framework, che ampliano le possibilità del linguaggio di programmazione. Se nel database di conoscenza dello scanner non ci sono informazioni sui punti critici (“sinks”) in questi framework, questo diventerà un punto cieco e lo scanner non capirà nemmeno il codice.
4. Durata della scansione. La ricerca di vulnerabilità nel codice è un compito complicato anche in termini di algoritmi. Pertanto, il processo può richiedere molto tempo e considerabili risorse computazionali.
5. Bassa copertura. Nonostante il consumo di risorse e la lunghezza della scansione, gli sviluppatori di strumenti SAST devono comunque affrontare compromessi e non analizzare tutti gli stati in cui può trovarsi un programma.
6. Riproducibilità delle scoperte. Indicare una linea specifica e uno stack di chiamate che portano a una vulnerabilità è fantastico, ma in realtà spesso lo scanner non fornisce informazioni sufficienti per verificare la presenza di una vulnerabilità dall'esterno. Infatti, il difetto può trovarsi anche in codice morto, non raggiungibile da un attaccante.

Problemi di scansione dell'infrastruttura.

1. Inventario insufficiente. Nelle grandi infrastrutture, specialmente quelle geograficamente distribuite, è spesso difficile capire quali host debbano essere scansionati. In altre parole, il compito di scansione è strettamente correlato al compito di asset management.
2. Scarsa priorizzazione. Gli scanner di rete spesso producono molti risultati con difetti che, nella pratica, non sono sfruttabili, ma formalmente il loro livello di rischio è alto. Il consumatore riceve un rapporto che è difficile da interpretare e non è chiaro cosa debba essere corretto per primo.
3. Raccomandazioni scarse. Nella base di conoscenza degli scanner, spesso c'è solo una informazione molto generica sulle vulnerabilità e sui metodi per risolverle, quindi gli admin dovranno armarsi di Google. La situazione è leggermente migliore con gli scanner whitebox, che possono fornire un comando specifico per la correzione.
4. Lavoro manuale. Nelle infrastrutture possono esserci molti nodi, e quindi potenzialmente molti difetti, i report dei quali devono essere esaminati e analizzati manualmente ad ogni iterazione.
5. Scarsa copertura. La qualità della scansione dell'infrastruttura dipende direttamente dalla dimensione della base di conoscenza sulle vulnerabilità e sulle versioni del software. Tuttavia, si rivela essere, anche i leader di mercato non hanno una base di conoscenza esaustiva, e nelle basi delle soluzioni gratuite ci sono molte informazioni che non sono presenti nei leader.
6. Problemi con il patching. Nella maggior parte dei casi, il patching delle vulnerabilità nell'infrastruttura consiste nell'aggiornamento di un pacchetto o nella modifica di un file di configurazione. Un grande problema qui è che il sistema, specialmente se legacy, può comportarsi in modo imprevedibile a seguito di un aggiornamento. In sostanza, sarà necessario condurre test di integrazione su un'infrastruttura in produzione.

Approcci.

Cosa fare allora?
Parlerò più in dettaglio di esempi e di come affrontare molti dei problemi elencati nelle prossime parti, mentre per ora indico le principali aree su cui è possibile lavorare:

1. Aggregazione di diversi strumenti di scansione. Con un uso corretto di più scanner, è possibile ottenere un notevole aumento della base di conoscenza e della qualità del rilevamento. È possibile trovare anche più vulnerabilità rispetto alla somma di tutti gli scanner eseguiti singolarmente, mentre si può valutare con maggiore precisione il livello di rischio e fornire maggiori raccomandazioni.
2. Integrazione SAST e DAST. È possibile aumentare la copertura DAST e la precisione SAST grazie allo scambio di informazioni tra di essi. Dall'analisi del codice sorgente si possono ottenere informazioni sui percorsi esistenti, mentre con DAST si può verificare se la vulnerabilità è visibile dall'esterno.
3. Machine Learning™. Nel 2015, ho ha raccontato (e ancora) parlato dell'applicazione della statistica per fornire agli scanner l'intuizione di un hacker e velocizzarli. Questo rappresenta sicuramente un tema di sviluppo per l'analisi automatica della sicurezza in futuro.
4. Integrazione IAST con test automatici e OpenAPI. Nel contesto di un pipeline CI/CD è possibile creare un processo di scansione basato su strumenti che operano come proxy HTTP e test funzionali che lavorano via HTTP. I test e i contratti OpenAPI/Swagger forniranno allo scanner le informazioni necessarie sui flussi di dati, consentendo di scansionare l'applicazione in vari stati.
5. Configurazione corretta. Per ogni applicazione e infrastruttura è necessario creare un profilo di scansione adeguato, tenendo conto della quantità e della natura delle interfacce e delle tecnologie utilizzate.
6. Personalizzazione degli scanner. Spesso, non è possibile scansionare un'applicazione senza modifiche allo scanner. Ad esempio, un gateway di pagamento in cui ogni richiesta deve essere firmata. Senza scrivere un connettore per il protocollo del gateway, gli scanner tenteranno di inviare richieste con firme errate. È anche necessario scrivere scanner specializzati per specifici tipi di vulnerabilità, come Riferimento diretto a oggetti non sicuri
7. Gestione del rischio. L'utilizzo di diversi scanner e l'integrazione con sistemi esterni, come Asset Management e Threat Management, consentiranno di utilizzare molteplici parametri per la valutazione del livello di rischio, in modo che la direzione possa ottenere una visione adeguata dello stato attuale della sicurezza dello sviluppo o dell'infrastruttura.

Rimanete sintonizzati e cambiamo il mondo della scansione delle vulnerabilità!

Fonte: habr.com