Se il nemico supera le nostre difese, è il momento di entrare nella sua testa

Dicembre solitamente è un mese di statistiche e bilanci, e per curiosità sono andata a vedere quale sia il tipo di incidenti segnalati dal GARR-CERT all’interno della comunità GARR.

È risultato che, se si escludono le infrazioni di copyright, che non riguardano la security in senso stretto, il 35% degli incidenti è dovuto a vulnerabilità nelle applicazioni web. Non è una novità: da anni chi se ne intende le indica come uno dei "talloni di Achille" della sicurezza. Ad esempio, secondo Akamai, alla fine del 2017 gli attacchi verso web app erano aumentati del 10% e il maggior vettore di attacchi sono gli SQL injection.

Il 35% degli incidenti è dovuto a vulnerabilità nelle applicazioni web

Una delle risorse più esaurienti sull’argomento è la Open Security Application Project (OWASP), dove si possono trovare risorse e analisi approfondite su vulnerabilità, strumenti di penetrazione generici o specifici per alcuni tipi di software, linee guide pratiche per effettuare penetration test, proposte di standardizzazione delle procedure, e soprattutto immagini virtuali già pronte di ambienti e scenari vulnerabili per allenarsi in tranquillità e imparare. OWASP pubblica ogni 3-4 anni la Top10 Vulnerability, una statistica che, sulla base della diffusione della vulnerabilità e della disponibilità degli exploit, fornisce la matrice di rischio per individuare quelle più pericolose. Anche in questo caso si sono classificate al primo posto le SQL injection.

Vista la situazione piuttosto preoccupante, gli strumenti che solitamente utilizziamo nel nostro lavoro quotidiano per tentare di correre ai ripari, potrebbero non essere del tutto sufficienti: quello che più o meno tutti facciamo è cercare di chiudere al massimo i server (hardening), filtrare i pacchetti non necessari sul proprio router di frontiera, utilizzare un sistema di log remoto e protetto, implementare un sistema di monitoraggio, con un minimo di intelligenza in modo da potersi accorgere automaticamente di anomalie nel traffico (possibilmente).
Uno strumento che negli anni si è rivelato molto utile, anche per valutare il rischio all’interno della propria struttura, sono i vulnerability assessment tool, per citarne uno: OpenVAS. Questi programmi contengono un database con tutte le vulnerabilità note di ogni sistema operativo e applicazione, che sono gestite centralmente a livello mondiale dal Mitre CVE, e i relativi exploit, e scansionano e analizzano la nostra rete provandole tutte una a una. In questo modo per ogni macchina scansionata è possibile capire il tipo di vulnerabilità (nota) da cui è afflitta, con i possibili rimedi per rimetterla in sicurezza. Sebbene utilissimi anche per fare l’inventario di tutto quello che esponiamo alla rete, questi software hanno però numerosi limiti: innanzitutto si occupano solo di "vulnerabilità note e riconosciute", fra queste soltanto quelle di cui è stato implementato un test apposito o un exploit, perlopiù si limita a segnalare le versioni di software da aggiornare (HTTP Server, tomcat, MySQL, kernel e sistemi operativi, PHP e altri linguaggi), non analizza nel dettaglio le applicazioni non comuni, o quelle scritte in casa. A volte succede che il report di OpenVAS sia tutto verde, quindi siamo perfettamente allineati con tutti i CVE noti, ma il giorno dopo la macchina viene compromessa. Era possibile evitarlo? Come hanno fatto ad entrare? Se una macchina è completamente aggiornata (e hardenizzata e filtrata sul bordo), come è possibile che sia stata compromessa?

Simona Venuti, in forza al GARR-CERT, da anni diffonde la pratica del pen-test nella comunità GARR.

Quando gli strumenti che abbiamo sembrano non funzionare più, dobbiamo iniziare a ragionare come il nemico, concentrandoci sugli strumenti di attacco ai quali siamo vulnerabili e non su quelli di difesa: per questo si fanno i pentest.

Un pen(etration) test è la simulazione di un attacco vero ai danni dei nostri sistemi. Ci sono diversi tipi di pentest che un ente può decidere di fare, a seconda dello scopo che vuole ottenere. Ci sono quelli annunciati, in cui il personale è a conoscenza che un certo giorno o periodo verrà fatto il test, i blind, in cui il personale non viene informato e i double blind, in cui non lo sono nemmeno la dirigenza e l’ufficio IT.

Altri tipi di pentest differiscono per la quantità delle informazioni di partenza fornite: black box, in cui il pentester non ha nessuna informazione iniziale sulla struttura di rete e dei servizi in carico ad una organizzazione e deve scoprire tutto da solo, gray box in cui le informazioni sono parziali, white box in cui le informazioni fornite riguardano tutta la struttura di rete e delle macchine e crystal box in cui oltre alla struttura della rete viene anche fornito il codice sorgente delle applicazioni da testare.
Solitamente un pentest viene fatto a squadre: quello più semplice prevede soltanto la red team, cioè i cattivi che attaccano il sistema. A questi si può contrapporre una blue team, la squadra dei difensori che cercano di tappare le falle mentre vengono attaccate, solitamente impersonata dall’ufficio IT, e volte una violet o purple team, che facilita la condivisione delle informazioni tra le due.

Dal punto di vista operativo un pentest è un insieme di procedure ed esperimenti da fare "a caldo" e consiste innanzi a tutto in un accordo scritto fra organizzazione e pentester, dove vengono descritte nel dettaglio le procedure, cosa è in scope del test e cosa no, l’effettuazione dei test veri e propri tramite ricognizione delle vulnerabilità e exploit delle stesse, l’analisi dei risultati e dei rischi e la produzione di report, infine la descrizione di eventuali rimedi possibili. Dalla descrizione operativa si capisce bene che il pentest non è un software da prendere e utilizzare in una rete.

Dal punto di vista tecnico, stabilite le procedure, non c’è un modo univoco di fare il pentest di una applicazione: bisogna vedere quello che essa offre il linguaggio in cui è stata scritta, le informazioni che riusciamo a strapparle per utilizzarle in un attacco successivo. È un lavoro soprattutto di fantasia, e di esperienza: aver fatto molti pentest aiuta a capire cosa è meglio andare a cercare a seconda dell’applicazione che dobbiamo bucare. Dal momento che l’offensive security è diventata uno strumento molto utile e potente per la sicurezza di un sistema, ultimamente si sta cercando di standardizzare la procedura di testing. Vari enti internazionali cercano di stilare una checklist di cose da testare che miri a coprire ogni possibile falla: il NIST, ISECOM, OWASP stessa. Quest’ultima ha redatto una guida OWASP testing guide che ritengo molto valida.

Quando poi andiamo a parlare di tool che si possono utilizzare per fare pentest il discorso si complica ulteriormente: ogni possibile falla che possiamo rilevare ha un tool specifico per essere smascherata, per cui il pentester ha nella sua valigetta un numero impressionante di tool che possono essere utili; recentemente ho provato a fare un conteggio e ho trovato circa 150 programmi diversi che possono essere utilizzati a seconda di ciò che dobbiamo testare. Gli hacker li usano tutti con profitto!

In quest’ampia scelta, un tool che trovo particolarmente utile per controllare completamente le connessioni fra browser e server web alla ricerca di falle è BurpSuite, di cui potremmo avere occasione di parlare in futuro. Fondamentalmente, però, la prima cosa che serve è lavorare di strategia e allenarsi il più possibile su macchine create apposta per essere violate in un ambiente controllato.