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

MITRE Corporation, con il supporto governativo (US-CERT e la Divisione Nazionale di Sicurezza Cyber del Dipartimento di Sicurezza interna) ha definito un sistema di classificazione per le debolezze e vulnerabilità dei software, nel senso del codice sorgente, ossia osservando e classificando quegli errori introdotti durante la fase di progettazione e sviluppo che portano alle conseguenti vulnerabilità note e individuabili mediante CVE.

Questo sistema è il Common Weakness Enumeration (CWE), anche questo covernato da un sistema numerico, benché non inteso come puro ordinale.

L'intento del sistema è supportare tutti quei metodi (anche automatici) per il controllo e la prevenzione di questi errori nei software: si tratta invero di strumenti e metodi collegati all'attività di Code Review, ma da pentester dobbiamo saper maneggiare questo ulteriore sistema di classificazione quando vogliamo comunicare la fonte della vulnerabilità e supportare gli sviluppatori nella fase di soluzione. Il sistema è alla versione 3.2 dal 2019 e contiene oltre 800 categorie di debolezze e vulnerabilità software (https://cwe.mitre.org)

Prendendo spunto da alcune delle debolezze prese dalla classifica le Top25 del 2019 redatta sempre dal Mitre, possiamo portare un esempio dell'importanza del CWE nel nostro lavoro nell'individuare le cause delle più note vulnerabilità (Buffer Overflow, XSS e SQL Injection e path traversal). Lo standard indica le seguenti debolezze: CWE-119 (Impropria Limitazione delle Operazioni all'interno dei Limiti di un Buffer di Memoria - Buffer Overflow), CWE-79 (Impropria Neutralizzazione dell'Input Durante la Generazione della Pagina Web - XSS), CWE-89 (Impropria Neutralizzazione di Elementi Speciali utilizzati in un Comando SQL - SQL Injection), CWE-22 (Impropria Limitazione dei Nomi di Percorso in una Directory Specifica - Path Traversal).

Quindi, come si evince da questo breve esempio, dopo aver individuato una vulnerabilità (CVE) se da questa è deducibile un CWE, mediante questo potrà essere definita una strategia per la fase di remediation.

Top Ten Owasp - Injection
The Open Web Application Security Project (aka OWASP) è un'organizzazione no profit nata per migliorare la sicurezza del sofware.
Tra le tante bellissime cose fatte esiste uno studio noto come "Top Ten Owasp" che elenca le 10 vulnerabilità più diffuse nelle applicazioni software.
Sebbene questo elenco risale al 2017 e non è ancora stato aggiornato rimane di un'attualità sorprendente andando ad elencare le principali falle applicative.
Al primo posto, anche se non si tratta di una vera e propria classifica, troviamo l'Injection.
La più sentita nominare è la sql injection ma con questo termine si intende quando un dato non legittimo viene inviato ad un interprete come parte di un comando o query. Questo dato può ingannare l'interprete ed essere eseguito con l'effetto di esporre dati del sito attaccato. L'injection può essere SQL, HTML, XML, LDAP etc...
Tornando all'SQL il classico esempio è quello di prendere in query string uno userid con:

IdUtente= getRequestString("UserId")
TestoSql= "Select * from utenti where UserId = " + IdUtente

Se l'applicazioni non effettua i necessari controlli prima di passare l'IdUtente alla riga successiva, un attaccante potrebbe passare in querystring:
IdUtente = 20 or 1=1
con l'effetto di vedere eseguita la query sql Select * from utenti where UserId =  20 or 1=1 con la possibile esposizione dei dati di tutti gli utenti.