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

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

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

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