Nessun risultato trovato
Il lavoro del programmatore cambia con il crescere della complessità dell’IT e sicuramente è stato reso più arduo dalle applicazioni sempre connesse e da Internet; quello del programmatore di siti web è ancor più complesso perché la sfida che lo attende oggi è scovare le vulnerabilità prima che le scoprano gli hacker.
Questo è importante perché spesso i programmatori partono dall’errata convinzione che il loro software sia libero da criticità e vulnerabilità; questo perché la Sicurezza Informatica non è semplice e non ci si improvvisa, anche perché lo scenario cambia in continuazione.
Spesso si scopre dell’esistenza di qualche problema solo quando si verifica.
La verità è che vengono scoperte molte vulnerabilità ogni giorno e che gli hacker studiano continuamente il modo di eludere quello che fa il programmatore, quindi l’azione preventiva è il primo passo da compiere nella direzione della sicurezza delle applicazioni, intendendo con ciò la progettazione fatta pensando già a dove potrebbe insinuarsi un attacco e a come prevenirlo, perché un’applicazione priva di falle è la prima buona pratica.
In questo tutorial verrà fatto il punto della situazione, esponendo la tecnica e fornendo riferimenti come il Progetto OWASP (https://owasp.org/) e il tool Acunetix utilizzato per il penetration testing.
Errate premesse che mettono a rischio la sicurezza informatica
Spesso ad esporre al rischio di un cyber-attacco è l’errata convinzione di aver sviluppato un software o un sito web in maniera impeccabile e senza falle nel sistema, però in realtà le falle ci sono ovunque: persino in Google nel 2018 è stata scoperta una grossa falla di sicurezza proprio nel motore di ricerca www.google.com, quindi se un colosso come Google ha avuto un problema del genere è chiaro che spostandosi verso il basso, probabilmente la situazione peggiora. Infatti si stima che più del 90% dei siti web sia vulnerabile, intendendo con siti web non necessariamente un intero sito ma una pagina o un URL che accetta dei parametri è un'applicazione potenzialmente a rischio, un input per un potenziale attaccante.
Un sito web online normalmente è in vista, cioè è accessibile costantemente, quindi è anche esposto ai tentativi di attacco e alle analisi che gli hacker possono portare attraverso strumenti che non è neppure difficile reperire in Rete. La media dei programmatori è invece convinta che i siti non siano esposti.
Però un sito specifico può essere attaccato perché ad esempio si punta a fare danno alla realtà che lo possiede; ma può anche essere scelto dagli hacker dopo una scansione che punta, ad esempio, a sondare il web alla ricerca di contenuti esposti e di vulnerabilità createsi perché chi lo ha realizzato ha scordato di attuare una protezione. Non va dimenticato che anche solo con le Google Dorks è possibile lanciare specifiche query attraverso cui trovare siti che hanno form di accesso, dati sensibili ecc. Figurarsi con strumenti che nascono per portare gli attacchi, anche solo ai fini del penetration testing (la pratica che serve a verificare quanto un server o un sito sia facile da “bucare”) e del Web Application Penetration Testing (test di effrazione delle applicazioni eseguite sul web).
Insomma, esistono dei bot che osservano ogni giorno la Rete e scansionano diversi siti alla ricerca delle vulnerabilità e delle falle di sicurezza.
Esistono quindi strumenti come bot e crawler che fanno scansioni di siti web in maniera casuale senza necessariamente un criterio e cercano di verificare con degli automatismi se le applicazioni web sono vulnerabili; una volta che sono vulnerabili non è detto che poi ci si trovi il sito criptato o i dati violati, ma magari, più semplicemente ci si può annidare una back door (quindi una sorta di Cavallo di Troia o, in parole povere, una porta aperta sul sito ma celata) che all'occorrenza può essere utilizzata da un malintenzionato ad esempio per lanciare un attacco DDOS, un attacco di phishing, creare spam o altro.
Magari il sito vulnerabile, tramite questa back door viene utilizzato come archivio di file per un altro sito illecito, quindi il malintenzionato di turno va a mettere i propri contenuti illegali lì e linka quel sito, così da essere al riparo in caso di ispezioni degli organi di Polizia o magari da arrecare danni al proprietario del sito che inconsapevolmente si trova a fare da host.
Un’altra errata premessa che induce in errore il programmatore web è quella che il suo sito è sicuro perché protetto da WAF (Web Application Firewall): questi praticamente sono strumenti che conoscono o evitano le vulnerabilità a monte, quindi sanno più o meno come sono scritte le vulnerabilità, come sono scritti gli attacchi e filtrano questi attacchi in modo che non arrivino mai sull’applicativo. Sono strumenti buoni per difendersi ma il loro problema è che non coprono tutto, perché un sito non può, per ovvi motivi, avere bloccati tutti gli accessi, altrimenti viene meno la sua funzione.
A riguardo si può fare un esempio con Imperva, che è un produttore di soluzioni di sicurezza tra cui anche soluzioni Web Application Firewall: il WAF non è un firewall perimetrale di rete ma è un firewall che di solito sta sulla macchina dove risiede il sito e quando arriva una richiesta la analizza e decide se darle seguito o bloccarla. Il WAF può essere anche all’esterno del sito: quando arriva una richiesta viene ridiretta ad esso e se è ritenuta valida la riporta sul sito che sta proteggendo. Un esempio di pagina di blocco di Imperva è proposto nell’immagine seguente (Error code 15).
Ebbene, testando Imperva, che pure è un prodotto di livello elevato, si è scoperto che passando una stringa di attacco per accedere ad esempio all’area riservata di un utente (una sorta di passepartout) mediamente intercetta e blocca l’attacco, però con qualche piccola variante alla stringa lo lascia passare.
In definitiva, attaccare è molto semplice, non certo una cosa da esperti: da esperti è difendersi, perché il compito dell’hacker oggi è facilitato dalla semplicità nel reperire le informazioni sulle vulnerabilità e i tool per effettuare gli attacchi.
Nell’ambito della vulnerabilità delle web application è importante conoscere la top ten list dell’OWASP, ossia quelle che tale organismo classifica come principali. OWASP è un’organizzazione no-profit o, più esattamente, un progetto mirato ad analizzare le vulnerabilità e redigere periodicamente rapporti dove indica quali sono le principali 10 vulnerabilità riscontrate nell’anno passato; l’immagine seguente propone uno screenshot relativo alla classifica delle principali vulnerabilità riscontrate nel 2017.
Cliccando su ognuna di esse si viene ridiretti a una pagina di approfondimento dove viene spiegato nel dettaglio di cosa si tratta e dalla quale si accede anche ad esempi.
Già sistemando queste 10 vulnerabilità si fa un grande passo avanti verso la sicurezza di un sito web perché si evita che coloro che possono trovare soluzioni Open Source disponibili sul web come Kali Linux eccetera (ma anche nel Dark Web) riescano a fare danni.
Chiaro che la classifica elenca le vulnerabilità comuni; poi ci sono vulnerabilità che possono derivare da versioni di software obsolete e altre cose che non possono essere classificate.
Passiamo ora a vedere alcuni di questi attacchi segnalati dall’OWASP, iniziando con l’Injection: ad esempio un attacco di SQL Injection è un codice che permette di interagire con il database dell’applicazione sul sito web attraverso una query costruita appositamente, ossia cambiando una variabile. In questo caso, mettendo una variabile volutamente errata, la query restituisce un errore, però questo è un chiaro segno che la variabile non viene filtrata e che quindi è possibile interagire tramite un link con l’intero database.
Se, ad esempio, si tentasse questa Injection su un sito di e-commerce dove nella query visualizzata dal browser (nell’URL) si vede l’ID di un prodotto e il sistema restituisce errore; questo errore sta già dando all’attaccante un’informazione, perché spesso fornisce indicazione su che tipo di errore si tratta e sicuramente ciò rappresenta un’indicazione. Questo non significa che il sito è completamente vulnerabile ma che lo potrebbe essere.
Teoricamente ogni input verso un sito può essere sfruttato per avere informazioni: ad esempio le password; infatti quando fa la login tramite uno username e una password il sistema verifica se l'account corrisponde a quello che è stato inserito nella pagina di login, fornendo comunque un feedback. Se indica un errore generico del tipo “bad username or password) è difficile capire come violare il sistema di autenticazione, mentre se già a video appare qualcosa tipo “invalid username” o “invalid password) sappiamo già quale dei due elementi richiesti è giusto e quale è da cambiare.
Sempre in tema di autenzicazione, se si va a modificare la password facendo credere al database che quella password sia sempre valida, quindi banalmente interrompendo la query e passando al sistema qualche carattere che che restituisce vero, si può accedere direttamente al relativo account.
Tramite questa tecnica è possibile iniettare codice SQL nel database e interagire con i dati contenuti nel database. Questo può comportare furto di dati perché l’Injection può essere inserimento di dati e quindi sostituzione all’interno di una tabella, sottrazione di dati, cancellazione di database, oppure elusione di password.
Un tipico esempio di effrazione di dati è la sostituzione dei link all’interno del database di prodotti, così quando un visitatore ci clicca viene diretto da un’altra parte: magari su un altro sito per aumentare i clic di qualcuno che si fa pagare a clic per le campagne pubblicitarie e via di seguito.
Molte delle vulnerabilità riscontrabili sono quelle verso gli attacchi di cross-site scripting (XSS): l’XSS permette di iniettare in un’applicazione del codice (tendenzialmente JavaScript) non previsto e questo permette di far eseguire del codice che non dovrebbe esserci.
Per testare l’effetto di questa vulnerabilità è possibile effettuare una simulazione su siti di ethical hacking che rendono disponibili pagine di test volutamente vulnerabili: un esempio è http://www.dvwa.co.uk.
Proprio su DVWA è possibile simulare un XSS su un form di blog dove si inseriscono dei commenti: si va ad aggiungere un commento quindi a mettere il nome e come messaggio si metterà uno script.
Quindi praticamente si potrebbe iniettare del codice malevolo al posto dell’alert chiamato alert(“xsl”) che fa apparire un pop-up con l’indicazione del numero del messaggio e i danni potrebbero essere molteplici, nel senso che si possono magari spiare le informazioni dell’utente corrispondente, vedere quanto visita il sito oppure apportare uno dei più diffusi attacchi che consiste nell’accedere ai cookie di sessione e quindi prelevare le informazioni della sessione attuale dell'utente e anche in questo caso entrare nel sito fingendosi un utente e senza saperne la password.
I cookie di sessione sono sostanzialmente un file di testo che viene creato in una cartella temporanea che sta sul profilo dell’utente durante la navigazione di un sito: per esempio l’utente che si è autenticato a un sito di e-commerce o qualsiasi altro sito che richiede credenziali di accesso. Quel file contenente i cookie di sessione può essere copiato e inserito in un altro computer e a quel punto l’utente fittizio (l’hacker…) potrebbe con quello accedere al sito senza doversi autenticare, perché di fatto in quel file ci sono informazioni tali da far ritenere al sito che l’utente è loggato.
Questo vuol dire che se un sito soffre soffre della vulnerabilità cross-site scripting un hacker può inserirgli un pezzo di codice contenente il comando che interagisce con i cookie (si chiama document.cookie) acquisendo il file che poi si invia magari per e-mail senza che l’utente se ne accorga; con il file, l’hacker potrebbe accedere nuovamente allo stesso sito perché sa da dove arriva la richiesta e fingersi l’utente. Ovviamente questo funziona solo se l’utente è già on-line.
Andiamo ora alla Command Injection che praticamente permette di sfruttare un punto debole dei linguaggi di back-end, i quali sono linguaggi che l’utente non vede ma che vengono eseguiti sul server. In molti casi questi linguaggi permettono di eseguire dei comandi di sistema, quindi con l’inclusione di un file inserito ad esempio caricando un file da un down-form apposito è possibile iniettare delle vere e proprie console per gestire l’intero server host dell’applicazione del sito a distanza, senza avere richiesto l’accesso.
Per esempio tramite Kali Linux si può scaricare una console per la gestione remota che può essere uploadata all’interno di un sito vulnerabile tramite, ad esempio, un form di upload di file che il sito prevede. Supponiamo si tratti di un sito che attraverso una sua pagina permette di caricare ad esempio dei curriculum, delle foto e altri contenuti (forum, siti di ricerca lavoro ecc.) senza che l’operazione sia assoggettata all’inserimento di credenziali.
Se il file non è correttamente gestito risulterà raggiungibile magari come URL e da lì sarà possibile lanciare dei comandi.
Supponiamo che la pagina web preveda l’upload di una foto e che questo contenuto caricato viene salvato in un’apposita cartella nel web server; se l’accesso a quella cartella non prevede l’acquisizione di permessi, è possibile caricare, anziché una foto, uno script creato nel linguaggio che utilizza il server (php o asp) cosicché sapendo la posizione nella quale vengono collocati i file caricati basta richiamare l’URL corrispondente e i file, per poter richiamare ed eseguite del codice di sistema, ad esempio che permette di vedere il contenuto delle cartelle, riavviare o mettere in shutdown il server così da mettere off-line il sito e tanto altro ancora. Magari tramite privilege escalation si può avere accesso completo al web server, installare FTP ecc.
Vediamo come si fa a individuare le vulnerabilità: esistono varie soluzioni, manuali e automatiche; manualmente ci si può mettere pagina per pagina a tentare una serie di combinazioni, quindi richiamare una pagina web contenente campi per l’inserimento di dati (per esempio le credenziali di accesso) e provare una serie di combinazioni partendo da quelle più comuni.
Ma esistono anche dei tool che permettono l’automazione di questi tentativi secondo schemi predeterminati e procedure ricavate dall’analisi delle vulnerabilità note.
Uno di questi strumenti è Acunetix, che consente di eseguire in maniera automatica dei penetration test in cui viene simulato un attacco da parte di un malinenzionato. L’obiettivo dell'attacco è realizzare un applicativo al fine di fornire informazioni sulle vulnerabilità che consentono o che consentirebbero a un potenziale attaccante reale di compromettere l’applicazione sotto l’aspetto della sicurezza dei dati. Il risultato del test è un report dettagliato sulle vulnerabilità individuate.
Il processo di penetration testing automatizzato tramite Acunetix si svolge in tre fasi:
Acunetix identifica le vulnerabilità di siti web e API e rispetto ai prodotti simili offre il più alto tasso di identificazione tra più di 4.500 vulnerabilità in app personalizzate, commerciali ed open source, con un tasso di falsi positivi prossimo allo 0%.
Grazie alla funzione AcuSensor (IAST - Interactive Application Security Testing) consente di trovare e testare input nascosti che non vengono trovati dalle scansioni black-box (DAST - Dynamic Application Security Testing).
Per eseguire il test, ossia la scansione, si inserisce il nome del sito da analizzare nell’apposita pagina, però questa scansione può essere eseguita soltanto se preventivamente è stato caricato il file AcuSensor all’interno della cartella di quel sito; questo perché Acunetix non nasce per fare analisi di vulnerabilità di qualsiasi sito web dove non si è autorizzati a farle, ma è uno strumento per testare i propri siti e quelli ai quali si è autorizzati ad accedere. Altrimenti si tratterebbe di uno strumento per hacker e non per gestori e sviluppatori di siti e applicazioni web.
Definito il target (ossia il sito da testare) nella casella “Target URL” della schermata di impostazione della scansione (immagine seguente) e fatte le impostazioni riguardanti il tipo di scansione (Scan Speed) e di agente, dal pulsante General si passa alla finestra “Choose Scanning Options”.
Qui si specifica dall’apposito menu a tendina proposto dalla finestra di dialogo il tipo di scansione (Full Scan, ossia scansione completa, High Risk Vulnerability e quindi ricerca delle sole vulnerabilità di grado severo ecc.) il tipo di report desiderato (immagine seguente) e l’eventuale schedulazione della scansione stessa.
Avviando l’analisi il sistema fa il crawling attraverso il quale legge tutti i file visibili all'interno del sito, ricostruisce la struttura e poi inizi a sottoporre ogni singola pagina a un test con oltre 6.500 e più vulnerabilità.
Quindi viene eseguita una scansione crawl del sito web sotto test e Acunetix ne ricava la struttura, come si può vedere nella struttura ad albero a sinistra nell’immagine seguente; Crawling avanzato e supporto all’autenticazione vi consentono di testare siti sviluppati in Javascript e SPA.
Alla fine Acunetix restituisce il report contenente l’elenco delle vulnerabilità individuate e spiega cosa ha fatto scattare l’alert. Fornisce inoltre il rimedio da adottare (la remediation).
Una volta che viene ricavata la struttura che riepiloga le vulnerabilità per tipologia (Blind SQL Injection, Cross Site Script ecc.) e vengono poi individuate le specifiche pagine che soffrono di quella di quella vulnerabilità, relativamente alle quali la console fornisce una serie di dettagli relativi anche al codice che può compromettere quella parte specifica.
Quindi attraverso la console vengono forniti degli esempi di codice malevolo che è stato utilizzato per testare quella pagina e per svelare che effettivamente ha quella debolezza, il che permette di imparare dalle scansioni.
Nella console o dashboard proposta nell’immagine seguente si può vedere che Acunetix ci dà report relativamente alle vulnerablità riscontrate, divise in tre livelli: critiche (High Severity), intermedie (Medium Severity) e poco rilevanti (Low Severity).
Notare che il report di Acunetix fornisce anche ulteriori informazioni utili: una volta trovata una vulnerabilità per cui il sito è facile da “bucare” e tale vulnerabilità è High Severity ma ha un livello di realizzazione (ossia di sfruttamento e attuabilità) low, abbiamo un’applicazione che chiunque, anche poco competente ma sfruttando dei tool che trova in Internet senza avere nessun tipo di competenza di sicurezza eccetera. Quindi nel report non è importante solo valutare il livello di severità, ma anche il livello di complessità nell’attuazione di quel di quel livello di criticità.
I report hanno varie utilità: ad esempio a una software-house serve per dimostrare eventualmente a un cliente che il suo prodotto ha superato un determinato test ed è certificato secondo gli standard di sicurezza IT, definiti anche nei report.
Acunetix fornisce anche un indicatore in cui visualizza lo stato di avanzamento del processo di remediation, ossia di rimozione delle vulnerabilità esistenti.
Inoltre la dashboard permette di tenere traccia dei problemi risolti allo scopo di comprendere se, dovessero ricomparire, quale ne è la ragione.
