Pillole di #penetrationtest
Molti strumenti automatici di VA utilizzano come sistema di classificazione delle vulnerabilità lo standard CVSSv2, benché sappiamo esistere una versione CVSSv3.
La questione è complessa: da un lato abbiamo l'immenso lavoro "editoriale" che ha costituito le basi dati su cui si basano gli strumenti automatici, dall'altro alcune carenze evidenziate da molti vendors nel CVSSv2.
I rilievi hanno avuto un carattere esclusivo riguardante la valutazione del rischio che da una vulnerabilità deriva; le modifiche hanno così portato una maggiore granularità delle metriche con il fine di distinguere, ad esempio, quelle vulnerabilità che abbiano o meno bisogno di interazione utente, o che richiedano o meno un accesso fisico, oppure se una vulnerabilità possa essere alla base di movimenti laterali, ecc.
Ma il problema fondamentale per il CVSS è sempre stato l'impatto: questo infatti non può essere valutato in termini astratti (quindi collocato in basi dati universali), perché fondamentalmente questo può essere inteso solo relativamente ad una specifica organizzazione o azienda che potrebbe subire un attacco mediante una certa vulnerabilità, quindi un indicatore con carattere prevalentemente "soggettivo".
La soluzione a questo problema è stata la eliminazione (nel CVSSv3) di quelle che erano le metriche ambientali del CVSSv2 a favore di un secondo insieme di "metriche di base", noto come "vettore modificato": queste hanno ora lo scopo di adeguare il peso della vulnerabilità in ragione dell'oggetto di indagine, una sorta di "aggiustamento soggettivo" a quei parametri (di base) "oggettivi" forniti da indicatori pubblici. Allo scopo sono state inoltre aggiunte nuove metriche per indicare la rilevanza rispetto alla Riservatezza, Integrità e Disponibilità, che proprio in relazione ad un soggetto di analisi concreto hanno ragion d'essere.
Quindi, anche quando uno strumento automatico cominciasse a basare i suoi report su CVSSv3, questo "adeguamento" sarà comunque onere del pentester, così come in passato.
Pillole di #penetrationtest
La verifica delle vulnerabilità delle applicazioni web è cosa complessa: abbiamo già parlato della verifica della iniettabilità di codice SQL, ma le possibilità di compromissione sono ancora tante altre.
Gli strumenti per la VA tradizionali sono storicamente orientati ai sistemi ed ai servizi (quindi il server HTTP, non l'applicazione), e sono dunque poco o per niente capaci di eseguire verifiche sulle moderne applicazioni Web.
La ricerca e verifica del potenziale input utente vulnerabile (anche AJAX) è la maggiore sfida per una VA su applicazioni Web, e vista la complessità delle stesse tale operazione non è certamente realizzabile in modo sistematico manualmente.
Per questo risultano più affidabili gli strumenti detti "intercept proxy", ossia dei forward proxy HTTP che siano in gradi di analizzare in termini di VA il traffico passante. Questi in sostanza "osservano" il nostro uso dell'applicazione web e verificano per ogni "pagina" e per ogni "input" rilevato le possibili forme di compromissione (sqli,xss,lfi,rfi, ecc). In più possono sferrare dei veri e propri attacchi automatici sull'intera superficie di attacco rilevata grazie al nostro navigare.
Tra gli strumenti utilizzabili ricordiamo la Burp Suite (ma è un prodotto commerciale, la cui versione community è fortemente limitata) e OWASP Zed Attack Proxy, ZAP per gli amici, completamente open.
Entrambi gli strumenti sono realizzati in Java e sono abbastanza voraci di risorse (CPU e disco, specie se si conserva la sessione di lavoro, cosa utile per esami successivi dei risultati).
Dopo l'essere open, altri punti a favore di ZAP sono l'integrazione con Firefox sia per la configurazione come proxy che grazie ad una HUD, e una partenza semplificata delle analisi grazie ad un wizard che richiede semplicemente un URL.
In ogni caso il lavoro di indagine non si conclude con l'avvio di questi strumenti: sono sì potenti, ma capaci di generare report pletorici e pieni di falsi positivi. L'automazione non è sinonimo sempre di perfezione, pertanto un buon pentester dovrà "ripulire" questi report e renderli fruibili al suo Cliente.