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.

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.

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.

Pillole di #penetrationtest

Perché affannarsi a cercare vulnerabilità di software e servizi quando la maggiore fonte di vulnerabilità é l'uomo?

Una delle più comuni fonti di vulnerabilità per una applicazione web è la cattiva configurazione della sicurezza dell'ambiente dove questa è pubblicata. La più diffusa misconfiguration è la disponibilità all'accesso pubblico di directory vitali per l'applicazione (o l'azienda).

Google dorks e motori di ricerca specializzati quotidianamente dimostrano l'enorme quantità di siti web mal protetti che rilevano porzioni o parti intere degli stessi al primo bot che passa (googlebot, bingbot, ecc).

Se l'applicazione web non è però pubblica, queste fonti di verifica possono mancarci. Allora possiamo contare su uno degli strumenti di analisi che ci fornisce il progetto OWASP: Dirbuster. Con i suoi dizionari (costruiti sulla base dell'osservazione proprio delle più comuni misconfiguration su Internet) ci consente di trovare (con un semplice attacco a dizionario) accessi non previsti a documenti o parte dell'applicazione tramite directory esposte. Dirbuster è una applicazione Java provvista di semplice e chiara GUI, pertanto non sarà difficile usarla.

I dizionari sono in genere disponibili in /usr/share/dirbuster/wordlist e deve essere scelto uno prima di iniziare la ricerca: possiamo utilizzare anche un nostro dizionario specializzato per l'obiettivo.

Pillole di #penetrationtest

Molti sanno che quando si parla di vulnerabilità si parla di "Common Vulnerabilities and Exposure" (CVE). Ma questa è solo una parte della verità.

Questo infatti è solo un database che tiene traccia, mediante degli identificatori, delle descrizioni delle vulnerabilità, esistenti o ancora da individuare. Infatti gli identificatori CVE (CVE-YYYY-XXXXX, dove YYYY è l'anno di riferimento e XXXXX un progressivo) vengono assegnati anche in assenza di una vulnerabilità, sono "riservati", assegnati all'uso futuro per centri di analisi e vendor che potranno utilizzarli per descrivere una vulnerabilità.

Provate ad esempio il seguente https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-1000, creato il 06-11-2020, alla data del 30-04-2021 ancora non è assegnato.

Il CVE fornisce solo una "descrizione", ma non è da se capace di consentire l'individuazione di una vulnerabilità, perché questa deve essere legata ad un contesto d'uso, un hardware, un sistema operativo o un software: questo è il compito dello standard "Common Platform Enumeration" (CPE) ed in particolare alle regole di CPE Naming.

Quindi il vero database delle vulnerabilità è quello che tenga conto di CVE per specifici CPE, e questo è quanto fa il database "National Vulnerability Database" (NVD) del NIST: https://nvd.nist.gov/vuln/data-feeds

Pillole di #penetrationtest

La fase di ricognizione sulle informazioni tecniche di un dominio parte certamente dal database whois: mediante questo (ovvero l'omonimo tool) possiamo ottenere, indicando il nome di dominio, oltre ad informazioni non tecniche, i nomi dei name server autorevoli per tale dominio (cosa possibile anche con query DNS, ma vogliamo concentrarci su un unico strumento).

Da questi nomi (sempre con whois) possiamo ricavare gli indirizzi pubblici che questi occupano; usando nuovamente whois per ciascuno di questi indirizzi, troveremo il NetRange o CIDR delle reti in possesso dall'organizzazione proprietaria del dominio, rilevando così la sua superficie di attacco complessiva (in termini di indirizzi).

La ricognizione non si ferma qui. Di questo dominio vorremmo sapere si più, ma una ricerca DNS Reverse Lookup molto probabilmente sarà infruttuosa, perché fornirà dei nomi di host che non corrispondono alle aspettative (non troveremo mai, ad esempio, www.google.com).

A questo punto non resta che eseguire una ricerca a dizionario dei potenziali nomi di sotto-domini e host che caratterizzano l'ecosistema del dominio in esame. Per far questo possiamo utilizzare programmi come dnsmap, fierce, dnsrecon e sublist3r. Il vantaggio degli ultimi due è che utilizza anche fonti aperte (motori di ricerca) per trovare nomi di sott-domini riferibili al dominio in esame.

#AnalisiForense
Nella precedente pillola abbiamo volutamente lasciato qualche dubbio:
L’autenticazione con valore legale dei file, siti web, testi, immagini, fotografie, video prevede l’apposizione di una marca temporale a fini di atti probatori.
La marca temporale (digital timestamp) rappresenta l’evoluzione del vecchio timbro all’ufficio postale.
Ogni file può essere oggetto di validazione temporale, file di testo, immagini, suoni, filmati, software.
Quindi, la marcatura temporale è il processo di generazione e apposizione di una marca temporale su un documento informatico.
Dal punto di vista tecnico, consiste di un file contraddistinto da un titolo identificativo, conservato unitamente al documento cui si riferisce.
La Marca Temporale è un servizio offerto da un Certificatore Accreditato che permette di associare data e ora certe e legalmente valide ad un documento informatico.
Una funzione crittografica di hash è un algoritmo che produce come output una sequenza di numeri e lettere di dimensioni variabili il digest.
L’impronta di hash di un documento informatico può essere paragonata ad una impronta digitale e quindi ad una caratteristica che lo identifica in maniera univoca, apporre la marcatura temporale gli attribuisce una validità legale.

#AnalisiForense
Spesso è necessario acquisire intere pagine WEB.
Questo torna utile in caso di reati quali ingiuria, minacce, stalking e diffamazione.
L’acquisizione forense di una pagina web viene eseguita utilizzando particolari accorgimenti tecnici che ne validano il contenuto ad una data certa e, impedendone la manipolazione del contenuto, collegandolo alla data d’acquisizione.(Funzioni di #Hash)
Un esempio d'acquisizione fatta in casa con gli strumenti di #Chrome:
Tasto funzione F12, per invocare gli strumenti.
CTRL+SHIFT+P apre la finestra di comando, digitare #Screenshot e scegliere tra le opzioni presenti, esempio:
"Capture full size screenshot", viene generato un file png della pagina web di partenza.
Buon divertimento.
Ps. nella prossima pillola completiamo il discorso sull'acquisizione.