Scannerizzazione delle vulnerabilità e sviluppo sicuro. Parte 1

Nell'ambito della professione, sviluppatori, pentester e esperti di sicurezza si trovano a dover affrontare processi come il Vulnerability Management (VM) e il (Secure) SDLC.
Questi termini nascondono diversi set di pratiche e strumenti utilizzati, che si intrecciano tra loro, anche se i loro utilizzatori variano.

Il progresso tecnico non è ancora arrivato al punto da poter sostituire un'analisi umana della sicurezza delle infrastrutture e del software con un unico strumento.
È interessante capire perché ciò accada e quali problemi si devono affrontare.

Processi

Il processo di Vulnerability Management è pensato per il monitoraggio continuo della sicurezza delle infrastrutture e della gestione delle patch.
Il processo di Secure SDLC è progettato per garantire la sicurezza delle applicazioni durante lo sviluppo e l'operatività.

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

Questo genera differenze negli strumenti e negli approcci. A mio parere, la ricerca di nuove vulnerabilità nell'applicazione è significativamente più interessante, poiché non si riduce a identificare le versioni, raccogliere banner, tentare password, ecc.
Per una scansione automatizzata di alta qualità delle vulnerabilità delle applicazioni, sono necessari algoritmi che considerano la semantica dell'applicazione, il suo scopo e le minacce specifiche.

Un scanner infrastrutturale può spesso essere sostituito da un timer, come ha detto avleonov. Il punto è che, puramente statisticamente, puoi considerare la tua infrastruttura vulnerabile se non l'hai aggiornata, ad esempio, per un mese.

Strumenti

La scansione, così come l'analisi della sicurezza, può essere eseguita sia come black box che come white box.

Black Box

Durante la scansione blackbox, lo strumento deve essere in grado di interagire con il servizio attraverso gli stessi interfacce usate dagli utenti.

I 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 conoscenza informazioni sulle vulnerabilità in queste versioni. Tentano anche di identificare errori di configurazione, come password di default o accesso aperto ai dati, cifrature SSL deboli, ecc.

I scanner di applicazioni web (Acunetix WVS, Netsparker, Burp Suite, OWASP ZAP, ecc.) possono anch'essi identificare componenti e versioni conosciute (ad esempio, CMS, framework, librerie JS). I principali passaggi di un scanner sono il crawling e il fuzzing.
Durante il crawling, lo scanner raccoglie informazioni sulle interfacce esistenti dell'applicazione e sui parametri HTTP. Nel fuzzing, vengono inseriti dati mutati o generati in tutti i parametri rilevati per provocare un errore e scoprire vulnerabilità.

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

White Box

Durante la scansione whitebox ci sono maggiori differenze.
Nel processo di scansione delle VM, scanner come Vulners, Incsecurity Couch, Vuls, Tenable Nessus, ecc., spesso ottengono accesso ai sistemi eseguendo una scansione autenticata. In questo modo, lo scanner può estrarre le versioni dei pacchetti installati e le impostazioni di configurazione direttamente dal sistema, senza dover indovinare tramite banner di servizi di rete.
La scansione risulta così più precisa e completa.

Quando parliamo di scansione whitebox (CheckMarx, HP Fortify, Coverity, RIPS, FindSecBugs, ecc.) delle applicazioni, ci riferiamo generalmente all'analisi statica del codice e all'uso di strumenti appropriati di classe SAST — Static Application Security Testing.

Problemi

Ci sono molteplici problemi legati alla scansione! La maggior parte di essi la affronto personalmente nel contesto della fornitura di servizi per la creazione di processi di scansione e sviluppo sicuro, così come durante le analisi di sicurezza.

Metterò in evidenza 3 principali gruppi di problemi, confermati anche da conversazioni con ingegneri e responsabili dei servizi di sicurezza informatica in diverse aziende.

Problemi di scansione delle applicazioni web

1. Difficoltà nell'implementazione. I scanner devono essere configurati, personalizzati per ogni applicazione, dedicare un ambiente di test per le scansioni e integrarsi nel processo CI/CD per essere efficaci. Altrimenti, rischiano di diventare una procedura formale inutile che produce solo falsi allarmi.
2. Durata della scansione. Anche nel 2019, i scanner hanno difficoltà nella deduplicazione delle interfacce e possono impiegare giorni per scansionare mille pagine con 10 parametri ciascuna, considerandole diverse, anche se sono gestite dallo stesso codice. Tuttavia, è necessario prendere decisioni rapide sui deployment in produzione durante il ciclo di sviluppo.
3. Raccomandazioni limitate. I scanner forniscono raccomandazioni piuttosto generiche, e non sempre gli sviluppatori possono capire rapidamente come ridurre il livello di rischio, e soprattutto, se è necessario farlo immediatamente o se si può aspettare.
4. Impatto distruttivo sull'applicazione. I scanner possono effettivamente realizzare un attacco DoS sull'applicazione e possono generare un numero elevato di entità o modificare quelle esistenti (ad esempio, creando decine di migliaia di commenti in un blog), quindi non è consigliabile avviare scansioni in produzione senza giudizio.
5. Bassa qualità nella rilevazione delle vulnerabilità. I scanner solitamente utilizzano un insieme fisso di payload e possono facilmente trascurare una vulnerabilità che non rientra nello scenario di comportamento noto dell'applicazione.
6. Incomprensione delle funzionalità dell'applicazione da parte dello scanner. Gli scanner non sanno cosa siano un "internet banking", un "pagamento", o un "commento". Per loro esistono solo link e parametri, quindi una vasta gamma di potenziali vulnerabilità logiche di business rimane completamente scoperta: non si accorgono di effettuare una doppia transazione, non riescono a visualizzare dati di altri utenti tramite ID o a gonfiare il saldo tramite arrotondamenti.
7. Incomprensione della semantica delle pagine da parte dello scanner. Gli scanner non possono leggere FAQ, non riescono a riconoscere i captcha, non capiscono come registrarsi e che è necessario effettuare il login di nuovo, non sanno che non si può cliccare su "logout" e come si devono 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 spesso numerosi compromessi. Spesso si deve sacrificare la precisione, e anche i costosi scanner enterprise 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 la scrittura di queste regole può rivelarsi troppo laboriosa. Talvolta è più semplice trovare tutte le aree nel codice con qualche bug e correggerle piuttosto che scrivere una regola per rilevare tali casi.
3. Mancanza di supporto per le dipendenze. Progetti grandi dipendono da un numero significativo di librerie e framework che ampliano le capacità del linguaggio di programmazione. Se nella base di conoscenza dello scanner non ci sono informazioni sui punti pericolosi («sinks») in questi framework, questo diventa un punto cieco, e lo scanner non riuscirà nemmeno a comprendere il codice.
4. Durata della scansione. La ricerca di vulnerabilità nel codice è un compito difficile anche in termini di algoritmi. Pertanto, il processo può richiedere del tempo e richiedere sostanziali risorse computazionali.
5. Basso tasso di copertura. Nonostante il consumo di risorse e la durata della scansione, gli sviluppatori di strumenti SAST devono comunque scendere a compromessi e analizzare non tutti gli stati in cui può trovarsi un programma.
6. Riproducibilità dei risultati. Indicare una riga 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 della vulnerabilità dall'esterno. Infatti, il difetto può trovarsi anche nel codice morto, inaccessibile a un attaccante.

Problemi di scansione dell'infrastruttura.

1. Inventario insufficiente. Nelle grandi infrastrutture, specialmente quelle distribuite geograficamente, è spesso più difficile capire quali host devono essere scansionati. In altre parole, il compito di scansione è strettamente legato alla gestione delle risorse.
2. Scarsa priorizzazione. I scanner di rete spesso generano molti risultati con vulnerabilità che in pratica non sono sfruttabili, ma formalmente il loro livello di rischio è elevato. Il consumatore riceve un rapporto difficile da interpretare e non è chiaro cosa sia necessario correggere per primo.
3. Raccomandazioni limitate. Nel database delle conoscenze dello scanner ci sono spesso solo informazioni molto generali sulle vulnerabilità e su come risolverle, quindi gli amministratori dovranno attrezzarsi con Google. La situazione è leggermente migliore con gli scanner whitebox, che possono fornire comandi specifici per la correzione.
4. Lavoro manuale. Nelle infrastrutture possono essere presenti molti nodi, il che significa potenzialmente molte vulnerabilità, i cui report devono essere esaminati e analizzati manualmente ad ogni iterazione.
5. Scarsa copertura. La qualità della scansione dell'infrastruttura dipende direttamente dalla quantità di informazioni nel database delle vulnerabilità e delle versioni software. Tuttavia, si scopre, anche i leader di mercato non dispongono di un database esaustivo, e nei database delle soluzioni gratuite ci sono molte informazioni che mancano ai leader.
6. Problemi di 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, potrebbe comportarsi in modo imprevedibile a seguito dell'aggiornamento. Fondamentalmente sarà necessario eseguire test di integrazione su infrastrutture attive in produzione.

Approcci

E quindi, cosa si può fare?
In seguito, parlerò di esempi e di come affrontare molti dei problemi elencati, ma per ora indicherò le principali direzioni in cui è possibile lavorare:

1. Aggregazione di diversi strumenti di scansione. Se utilizzati correttamente, diversi scanner possono portare a un significativo aumento della base di conoscenza e della qualità dei rilevamenti. Si possono scoprire anche più vulnerabilità di quelle rilevate singolarmente da ciascun scanner, permettendo di valutare meglio il livello di rischio e di fornire più raccomandazioni.
2. Integrazione di SAST e DAST. Si può aumentare la copertura di DAST e l'accuratezza di SAST attraverso lo scambio di informazioni tra di loro. Dalle sorgenti si possono ottenere informazioni sui percorsi esistenti, mentre con DAST si può verificare se una vulnerabilità è visibile dall'esterno.
3. Machine Learning™. Nel 2015, io parlato (e ancora) ho parlato dell'applicazione della statistica per dare agli scanner l'intuizione di un hacker, e per velocizzarli. Questo è sicuramente un tema di sviluppo per l'analisi automatica della sicurezza in futuro.
4. Integrazione di IAST con test automatici e OpenAPI. Nel contesto del CI/CD-pipeline, è possibile creare un processo di scansione basato su strumenti che operano come proxy HTTP e test funzionali che funzionano su HTTP. I test e i contratti OpenAPI/Swagger forniranno allo scanner le informazioni mancanti sui flussi di dati, consentendo di eseguire la scansione dell'applicazione in vari stati.
5. Configurazione corretta. Per ogni applicazione e infrastruttura è necessario creare un profilo di scansione adeguato, che tengano conto del numero e della natura delle interfacce e delle tecnologie utilizzate.
6. Personalizzazione degli scanner. Spesso un'applicazione non può essere scansionata senza modifiche allo scanner. Un esempio è una gateway di pagamento, in cui ogni richiesta deve essere firmata. Senza scrivere un connettore per il protocollo del gateway, gli scanner continueranno a inviare richieste con firme errate. È anche necessario scrivere scanner specializzati per specifici tipi di vulnerabilità, come Riferimento Diretto Insecure a Oggetti
7. Gestione del rischio. L'uso di diversi scanner e l'integrazione con sistemi esterni, come Asset Management e Threat Management, consentiranno di utilizzare numerosi parametri per valutare il livello di rischio, così da fornire alla direzione un quadro adeguato sullo stato attuale della sicurezza nello sviluppo o nell'infrastruttura.

Rimanete sintonizzati e cambiamo il modo di affrontare la scansione delle vulnerabilità!

Fonte: habr.com