Cybercriminali, per sconfiggerli devi conoscerli

“Conosci il tuo nemico”.

Questa antica frase del generale cinese Sun Tzu riguardava la guerra fisica, ma è valida ancora oggi per il mondo online. Se vuoi proteggere i tuoi asset digitali, è fondamentale conoscere in che modo i tuoi nemici, gli hacker malintenzionati, potrebbero attaccarli.

Questa esortazione descrive appieno l’obiettivo del “Software Vulnerability Snapshot“, un recente rapporto realizzato dal Synopsys Cybersecurity Research Center (CyRC), che analizza i dati ottenuti da 4.400 test condotti su 2.700 applicazioni sia web che mobile, file di codice sorgente e sistemi mirati.

I test si sono concentrati sulla conoscenza del nemico e sono stati realizzati grazie ai servizi di Application Security Testing (AST) di Synopsys, progettati per sondare le applicazioni in esecuzione in modo simile a come lo farebbe un attaccante reale, e perciò, in grado di identificare ed evidenziare le vulnerabilità critiche da correggere.

I test invasivi “black box” e “gray box” includevano test dinamici di sicurezza delle applicazioni (DAST), analisi di test di sicurezza delle applicazioni mobili (MAST) e penetration test – attacchi simulati, progettati per valutare la sicurezza di un’applicazione o di un sistema.

DAST e MAST sono strumenti automatizzati che trovano difetti nel codice in esecuzione, mentre i penetration test vengono eseguiti manualmente e consentono alle organizzazioni di trovare e correggere le vulnerabilità nella fase finale di sviluppo del software o dopo il deployment.

I test hanno rilevato numerosi problemi: il 95% delle applicazioni presentava almeno una vulnerabilità o una configurazione errata e il 25% delle vulnerabilità rilevate erano a rischio elevato o critico. L’unico aspetto confortante di percentuali così alte di errori è quello di dimostrare la validità degli strumenti di analisi utilizzati poiché lo scopo dei test di sicurezza del software è quello di trovare le vulnerabilità affinché vengano risolte prima che i malintenzionati possano individuarle e sfruttarle.

Come afferma il rapporto, “le organizzazioni devono testare le proprie applicazioni Web nello stesso modo in cui lo faranno gli attaccanti, quindi identificare ed eliminare le vulnerabilità prima che vengano sfruttate da agenti esterni”.

Emerge inoltre che le probabilità che il software che stai creando e/o utilizzando abbia dei difetti sono prossime al 100% e che un quarto di questi difetti sono in grado di causare danni significativi se non identificati e corretti con prontezza

Dal report di Synopsys emergono dati allarmanti

I ricercatori di CyRC hanno scoperto che il 77% degli obiettivi presentava vulnerabilità che compaiono nella lista top 10 dell’Open Web Application Security Project (OWASP).

Tra le peggiori in questo elenco ci sono le vulnerabilità che consentono il cross-site scripting (XSS), in grado di consentire agli attaccanti di accedere a risorse e dati delle applicazioni. Synopsys AST services ha rilevato che il 22% degli obiettivi presi in esame dal test era esposto a vulnerabilità XSS riflesse, memorizzate o basate su DOM (Document Object Model), che possono consentire agli hacker di iniettare un payload dannoso in una pagina web.

Altre vulnerabilità a rischio critico, come l’esecuzione di codice in modalità remota e l’SQL Injection, consentono agli attaccanti di eseguire codice su un’applicazione Web o su un server applicativo con il fine di accedere a dati sensibili.

Quali sono i modi migliori per garantire la sicurezza del software?

Il rapporto contiene diversi punti chiave che possono aiutare le organizzazioni a conoscere meglio i propri nemici e ad adottare misure efficaci per sconfiggerli. Di seguito alcuni consigli per migliorare la security posture:

Utilizza tutti gli strumenti di test disponibili

Strumenti diversi funzionano in modi diversi e sono perciò in grado di individuare un numero maggiore di punti deboli all’interno del software. Le organizzazioni dovrebbero usarli tutti.

Oltre a DAST, MAST e penetration test menzionati in precedenza, i test di sicurezza delle applicazioni statiche (SAST) sono in gradi di segnalare i difetti nel codice mentre viene scritto e l’analisi della composizione del software (SCA) aiuta ad individuare le componenti open source e la loro provenienza, quale versione viene utilizzata e se contengono vulnerabilità note o conflitti di licenza.

Sii consapevole dei pericoli di terze parti

I prodotti software odierni sono assemblati più che scritti: includono una combinazione di codice proprietario, di terze parti e open source. E’ significativo sapere che circa il 77% di ogni codebase utilizza software open source. E questo, come qualsiasi altro software, è imperfetto.

Secondo il rapporto, le vulnerabilità delle librerie di terze parti – classificate come “critiche” all’interno della Top 10 di OWASP – sono state trovate in oltre il 20% dei penetration test e nel 25% dei SAST effettuati.
Risulta chiaro perciò che una organizzazione non può essere al sicuro se non conosce le versioni di tutti i componenti impiegati e/o il codice utilizzato non è supportato o aggiornato costantemente.

Crea una Bill of Materials del software (SBOM)

Un produttore di veicoli non rimarrebbe in attività a lungo se non tenesse traccia della provenienza dei suoi componenti. Tuttavia troppe organizzazioni hanno poca o nessuna idea di quali componenti siano presenti all’interno dei prodotti software che utilizzano, ignorando così una catena di approvvigionamento complessa che si struttura su tanti livelli arrivando a coinvolgere coinvolgendo centinaia, se non migliaia, delle cosiddette dipendenze e in grado di determinare una superficie di attacco molto ampia e perciò difficile da proteggere.

Un esempio dell’impatto che può avere una simile condotta lo abbiamo avuto lo scorso dicembre, quando con la scoperta di una vulnerabilità nella libreria di registrazione open source Apache Log4j, chiamata Log4Shell, gran parte delle organizzazioni hanno realizzato che non tenere traccia della supply chain può avere reali e devastanti ripercussioni. È proprio questo livello di criticità che rende utile e fondamentale uno SBOM, cioè l’inventario di ogni componente software che un’organizzazione utilizza, e restituisce il giusto valore a quello strumento indispensabile che è lo SCA (Software Composition Analysis), in grado di rintracciare i diversi componenti e di determinare se e quali di essi presentano delle vulnerabilità note.

Come si legge nel report, “visto che molte aziende che utilizzano centinaia di applicazioni o sistemi software, ognuna dei quali probabilmente dispone di centinaia o migliaia di diversi componenti di terze parti e open source, è urgentemente necessario un SBOM accurato e aggiornato per tenere traccia efficacemente di tali componenti“.

Oggi, la buona notizia è che si è finalmente raggiunta una maggiore consapevolezza, rispetto al passato, di questa problematica come dimostrato da un recente report di Synopsys “Walking the Line: GitOps and Shift Left Security“, che riporta un dato molto interessante: il 73% degli intervistati ha aumentato i propri sforzi per proteggere la supply chain del software all’interno della propria organizzazione.

A dimostrazione della indispensabilità di una strategia di sicurezza che preveda al proprio interno i strumenti sopra elencati arriva l’”Ordine esecutivo sul miglioramento della sicurezza informatica della nazione” del maggio 2021, dove il presidente Biden chiede esplicitamente alle organizzazioni, sia pubbliche che private, di creare e mantenere un elenco dei componenti integrati nei software (Software Bill of Materials, SBOM) confermando così la validità di tali soluzioni.

Non lasciare che i difetti a basso rischio diventino ad alto rischio

Le vulnerabilità etichettate come a basso rischio – generalmente ottengono tale classificazione perché è improbabile che causino molti danni o perché è implausibile che un utente malintenzionato possa sfruttarle – non sono da trascurare poiché, a seconda del profilo di un’organizzazione, tale vulnerabilità potrebbe diventare ad alto impatto o a probabilità elevata. Ne è un esempio la vulnerabilità Verbose Server Banners che, sebbene considerata a basso rischio, è in grado di fornire il nome del server, il tipo e il numero di versione, informazioni che potrebbero consentire agli aggressori di eseguire attacchi mirati su stack tecnologici specifici.

Seguire queste raccomandazioni può aiutare aziende ed organizzazioni a raggiungere obiettivi di messa in sicurezza del software difficilmente raggiungibili gli strumenti e le accortezze sopra citate.