Scansione delle vulnerabilità e sviluppo sicuro. Parte 1

Nell'ambito della loro attività professionale, sviluppatori, pentester e specialisti della sicurezza devono occuparsi di processi come la gestione delle vulnerabilità (VM), SDLC (sicuro).
Sotto queste frasi si trovano diversi insiemi di pratiche e strumenti utilizzati che sono intrecciati, sebbene i loro utenti differiscano.

Il progresso tecnico non ha ancora raggiunto il punto in cui uno strumento possa sostituire una persona per analizzare la sicurezza delle infrastrutture e del software.
È interessante capire perché è così e quali problemi si devono affrontare.

processi

Il processo di gestione delle vulnerabilità è progettato per il monitoraggio continuo della sicurezza dell'infrastruttura e della gestione delle patch.
Il processo Secure SDLC ("ciclo di sviluppo sicuro") è progettato per mantenere la sicurezza dell'applicazione durante lo sviluppo e il funzionamento.

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

Ciò crea differenze negli strumenti e negli approcci. A mio parere, il compito di trovare nuove vulnerabilità in un'applicazione è molto più interessante, poiché non si riduce a versioni con impronte digitali, raccolta di banner, password forzate, ecc.
Per una scansione automatizzata di alta qualità delle vulnerabilità delle applicazioni, sono necessari algoritmi che tengano conto della semantica dell'applicazione, del suo scopo e delle minacce specifiche.

Uno scanner dell'infrastruttura può spesso essere sostituito con un timer, come ho detto avleonov. Il punto è che, da un punto di vista puramente statistico, puoi considerare la tua infrastruttura vulnerabile se non la aggiorni, diciamo, per un mese.

Strumenti

La scansione, come l'analisi della sicurezza, può essere eseguita utilizzando una scatola nera o una scatola bianca.

Black Box

Durante la scansione blackbox, lo strumento deve essere in grado di funzionare con il servizio attraverso le stesse interfacce attraverso le quali gli utenti lavorano con esso.

Gli scanner dell'infrastruttura (Tenable Nessus, Qualys, MaxPatrol, Rapid7 Nexpose, ecc.) cercano porte di rete aperte, raccolgono "banner", determinano le versioni del software installato e cercano nella knowledge base informazioni sulle vulnerabilità in queste versioni. Tentano anche di rilevare errori di configurazione come password predefinite o accesso a dati aperti, cifrature SSL deboli, ecc.

Gli scanner di applicazioni Web (Acunetix WVS, Netsparker, Burp Suite, OWASP ZAP, ecc.) possono anche identificare componenti noti e le loro versioni (ad esempio CMS, framework, librerie JS). Le fasi principali dello scanner sono la scansione e il fuzzing.
Durante la scansione, lo scanner raccoglie informazioni sulle interfacce delle applicazioni esistenti e sui parametri HTTP. Durante il fuzzing, i dati mutati o generati vengono inseriti in tutti i parametri rilevati per provocare un errore e rilevare una vulnerabilità.

Tali scanner di applicazioni appartengono alle classi DAST e IAST, rispettivamente Dynamic e Interactive Application Security Testing.

Box bianco

Ci sono più differenze con la scansione whitebox.
Come parte del processo VM, agli scanner (Vulners, Incsecurity Couch, Vuls, Tenable Nessus, ecc.) viene spesso concesso l'accesso ai sistemi eseguendo una scansione autenticata. Pertanto, lo scanner può scaricare le versioni dei pacchetti installati e i parametri di configurazione direttamente dal sistema, senza indovinarli dai banner dei servizi di rete.
La scansione è più accurata e completa.

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

Problematica

Ci sono molti problemi con la scansione! Devo occuparmi personalmente della maggior parte di loro nell'ambito della fornitura di un servizio per la creazione di processi di scansione e sviluppo sicuri, nonché durante lo svolgimento di attività di analisi della sicurezza.

Evidenzierò 3 gruppi principali di problemi, che sono confermati dalle conversazioni con ingegneri e responsabili dei servizi di sicurezza delle informazioni in una varietà di aziende.

Problemi di scansione delle applicazioni Web

1. Difficoltà di implementazione. Affinché ciò sia efficace, gli scanner devono essere distribuiti, configurati, personalizzati per ciascuna applicazione, assegnato un ambiente di test per le scansioni e implementati nel processo CI/CD. Altrimenti si tratterà di un’inutile procedura formale che produrrà solo falsi positivi
2. Durata della scansione. Anche nel 2019, gli scanner fanno un pessimo lavoro di deduplicazione delle interfacce e possono passare giorni a scansionare migliaia di pagine con 10 parametri ciascuna, considerandole diverse, sebbene lo stesso codice ne sia responsabile. Allo stesso tempo, la decisione sull’implementazione in produzione all’interno del ciclo di sviluppo deve essere presa rapidamente
3. Raccomandazioni scadenti. Gli scanner forniscono consigli abbastanza generali e lo sviluppatore non sempre riesce a capire rapidamente come ridurre il livello di rischio e, soprattutto, se è necessario farlo in questo momento o se non è ancora spaventoso
4. Impatto distruttivo sull'applicazione. Gli scanner potrebbero eseguire un attacco DoS su un'applicazione e possono anche creare un gran numero di entità o modificare quelle esistenti (ad esempio, creare decine di migliaia di commenti su un blog), quindi non dovresti avviare sconsideratamente una scansione in produzione
5. Bassa qualità del rilevamento delle vulnerabilità. Gli scanner utilizzano solitamente una serie fissa di payload e possono facilmente trascurare una vulnerabilità che non rientra nello scenario di comportamento noto dell'applicazione.
6. Lo scanner non comprende le funzioni dell'applicazione. Gli stessi scanner non sanno cosa siano “Internet banking”, “pagamento”, “commento”. Per loro ci sono solo collegamenti e parametri, quindi un enorme strato di possibili vulnerabilità della logica aziendale rimane completamente scoperto; non penseranno a fare una doppia cancellazione, a spiare i dati di qualcun altro tramite ID o ad aumentare il saldo arrotondando
7. Lo scanner non comprende la semantica delle pagine. Gli scanner non sono in grado di leggere le FAQ, non sono in grado di riconoscere i captcha e da soli non capiranno come registrarsi e quindi effettuare nuovamente l'accesso, che non è possibile fare clic su "disconnetti" e come firmare le richieste quando si modificano i parametri valori. Di conseguenza, la maggior parte dell'applicazione potrebbe non essere sottoposta a scansione.

Problemi con la scansione del codice sorgente

1. Falsi positivi. L’analisi statica è un compito complesso che comporta molti compromessi. Spesso la precisione deve essere sacrificata e anche i costosi scanner aziendali producono un numero enorme di falsi positivi
2. Difficoltà di implementazione. Per aumentare la precisione e la completezza dell'analisi statica, è necessario perfezionare le regole di scansione e la scrittura di queste regole può richiedere troppo lavoro. A volte è più semplice trovare tutti i punti del codice con qualche tipo di bug e risolverli piuttosto che scrivere una regola per rilevare tali casi
3. Mancanza di supporto per le dipendenze. I grandi progetti dipendono da un gran numero di librerie e framework che estendono le capacità del linguaggio di programmazione. Se la knowledge base dello scanner non contiene informazioni sui "sink" in questi framework, diventerà un punto cieco e lo scanner semplicemente non capirà nemmeno il codice
4. Durata della scansione. Trovare vulnerabilità nel codice è un compito complesso in termini di algoritmi. Pertanto, il processo potrebbe richiedere molto tempo e richiedere risorse informatiche significative.
5. Bassa copertura. Nonostante il consumo di risorse e il tempo di scansione, gli sviluppatori dello strumento SAST devono ancora scendere a compromessi e analizzare non tutti gli stati in cui potrebbe trovarsi il programma
6. Riproducibilità dei risultati. Indicare la linea specifica e lo stack di chiamate che portano a una vulnerabilità è ottimo, ma in realtà spesso lo scanner non fornisce informazioni sufficienti per verificare la presenza di una vulnerabilità dall'esterno. Dopotutto, il difetto potrebbe risiedere anche in un codice morto, irraggiungibile per un utente malintenzionato

Problemi di scansione dell'infrastruttura

1. Inventario insufficiente. Nelle grandi infrastrutture, soprattutto quelle separate geograficamente, è spesso più difficile sapere quali host scansionare. In altre parole, l'attività di scansione è strettamente correlata all'attività di gestione delle risorse
2. Scarsa priorità. Gli scanner di rete spesso producono molti risultati con difetti che non possono essere sfruttati nella pratica, ma formalmente il loro livello di rischio è elevato. Il consumatore riceve una segnalazione difficile da interpretare e non è chiaro cosa debba essere corretto prima.
3. Raccomandazioni scadenti. La knowledge base dello scanner spesso contiene solo informazioni molto generali sulla vulnerabilità e su come risolverla, quindi gli amministratori dovranno armarsi di Google. La situazione è leggermente migliore con gli scanner whitebox, che possono emettere un comando specifico per risolvere il problema
4. Fatto a mano. Le infrastrutture possono avere molti nodi, il che significa potenzialmente molti difetti, i cui report devono essere analizzati 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. In cui, risulta, anche i leader di mercato non dispongono di una base di conoscenze completa e i database delle soluzioni gratuite contengono molte informazioni di cui i leader non dispongono
6. Problemi con le patch. Molto spesso, l'applicazione di patch alle vulnerabilità dell'infrastruttura comporta l'aggiornamento di un pacchetto o la modifica di un file di configurazione. Il grosso problema qui è che un sistema, soprattutto uno legacy, può comportarsi in modo imprevedibile a seguito di un aggiornamento. In sostanza, dovrai condurre test di integrazione sull'infrastruttura live in produzione.

Gli approcci

Come può essere?
Nelle parti seguenti ti dirò di più sugli esempi e su come affrontare molti dei problemi elencati, ma per ora indicherò le direzioni principali in cui puoi lavorare:

1. Aggregazione di vari strumenti di scansione. Con l'uso corretto di più scanner è possibile ottenere un aumento significativo della base di conoscenze e della qualità del rilevamento. Puoi trovare ancora più vulnerabilità rispetto al totale di tutti gli scanner lanciati separatamente, mentre puoi valutare in modo più accurato il livello di rischio e formulare più raccomandazioni
2. Integrazione di SAST e DAST. È possibile aumentare la copertura del DAST e la precisione del SAST scambiando informazioni tra loro. Dalle fonti si possono ottenere informazioni sui percorsi esistenti e tramite DAST è possibile verificare se la vulnerabilità è visibile dall'esterno
3. Apprendimento automatico™. Nel 2015 I ho detto (e più) sull'utilizzo delle statistiche per fornire agli scanner l'intuizione di un hacker e velocizzarli. Questo sarà sicuramente foraggio per lo sviluppo di analisi di sicurezza automatizzate in futuro.
4. Integrazione di IAST con autotest e OpenAPI. All'interno della pipeline CI/CD è possibile creare un processo di scansione basato su strumenti che funzionano come proxy HTTP e test funzionali che funzionano su HTTP. Test e contratti OpenAPI/Swagger forniranno allo scanner le informazioni mancanti sui flussi di dati e consentiranno di scansionare l'applicazione in vari stati
5. Configurazione corretta. Per ogni applicazione e infrastruttura è necessario creare un profilo di scansione adeguato, tenendo conto del numero e della natura delle interfacce e delle tecnologie utilizzate
6. Personalizzazione dello scanner. Spesso non è possibile scansionare un'applicazione senza modificare lo scanner. Un esempio è un gateway di pagamento, in cui ogni richiesta deve essere firmata. Senza scrivere un connettore per il protocollo gateway, gli scanner bombarderanno senza pensare con richieste con la firma sbagliata. È inoltre necessario scrivere scanner specializzati per un tipo specifico di difetto, ad esempio Riferimento a oggetti diretti non sicuri
7. Gestione del rischio. L'uso di vari scanner e l'integrazione con sistemi esterni come Asset Management e Threat Management consentiranno l'utilizzo di molti parametri per valutare il livello di rischio, in modo che il management possa ottenere un quadro adeguato dell'attuale stato di sicurezza dello sviluppo o dell'infrastruttura

Restate sintonizzati e interrompiamo la scansione delle vulnerabilità!

Fonte: habr.com