Progetto finanziato con fondi POR FESR 2014/2020 - ASSE PRIORITARIO I
“RICERCA SCIENTIFICA, SVILUPPO TECNOLOGICO E INNOVAZIONE”.
R.3.2. - ALLEGATO RELAZIONE TECNICO SCIENTIFICA FINALE
Report sul penetration testing per la valutazione della sicurezza del sistema
Progetto cluster SardCoin - Resp. Scient.: Prof. Michele Marchesi
Il presente documento illustra il procedimento di penetration test della piattaforma Sardcoin.
Il primo capitolo è un’introduzione al penetration test: spiega cos'è, quali sono le tipologie di penetration test più comuni e quali sono le fasi principali del test. Il secondo capitolo mostra quali delle metodologie presentate sono adatte al contesto di Sardcoin, definendo gli obiettivi, gli strumenti da utilizzare e motivando le scelte tecniche adottate. Il terzo capitolo presenta i risultati, correlati da screenshot dell’output dei tool utilizzati, e discute le vulnerabilità individuate. Infine, il capitolo conclusivo offre strategie per migliorare la sicurezza di Sardcoin.
1. Introduzione al penetration test 1.1. Tipologie di penetration test 1.2. Fasi del penetration test 2. Penetration testing di Sardcoin
2.1. Scelta della tipologia di test 2.2. Definizione delle fasi del test 3. Esecuzione del test e analisi dei risultati
3.1. Pianificazione 3.2. Scansione
3.2.1. Analisi statica 3.2.2. Analisi dinamica
4. Strategie per migliorare la sicurezza di Sardcoin
1. Introduzione al penetration test
In ambito informatico il penetration test è una tipologia di test del software che valuta la sicurezza di un sistema informatico simulando una serie di attacchi al sistema. Il test cerca vulnerabilità nel sistema e prova a sfruttarle, con l’obiettivo di stabilire se i meccanismi di difesa presenti sono sufficienti a respingere gli attacchi.
Il presente capitolo spiega i concetti principali relativi al penetration testing: quali sono le tipologie di test possibili e le fasi che lo caratterizzano.
1.1. Tipologie di penetration test
Il penetration test può essere eseguito dall’esterno o dall’interno del sistema.
1. Test esterno
Gli obiettivi del test esterno sono risorse del sistema visibili nella rete, come ad esempio applicazioni web, siti, email e DNS. L’obiettivo è ottenere degli accessi non autorizzati ed estrarre informazioni di valore.
2. Test interno
In un test di tipo interno, il tester ha accesso all’applicazione senza le restrizioni del firewall, in modo da simulare un attacco al sistema dall’interno. Questo permette di riprodurre uno scenario nel quale sono state rubate le credenziali a un dipendente, ad esempio a seguito di un attacco di tipo phishing.
Un penetration test può essere condotto in modi diversi, a seconda del livello di informazione che viene messo a disposizione del tester.
1. Blind testing
In questa modalità di testing l’unica informazione che viene fornita al tester è il nome dell’organizzazione che deve essere testata. L’obiettivo di questo tipo di test è fornire un’idea più precisa di come potrebbe svolgersi un vero attacco al sistema.
2. Double-blind testing
Un test double-blind è un blind test dove inoltre il personale addetto alla sicurezza del sistema non viene notificato della simulazione di attacco. Come accade nei comuni attacchi informatici, gli addetti alla sicurezza non hanno tempo per prepararsi prima che si svolga l’attacco. Questo tipo di test offre una visione più chiara di quali sono realmente le difese che potrebbero trovare gli attaccanti.
3. Targeted testing
L’ultima modalità di test prevede che il tester e il personale addetto alla sicurezza del sistema lavorino insieme alla simulazione di attacco. Questo consente di avere dei feedback rapidi durante lo svolgimento dell’attacco e capire meglio sia il punto di vista dell’attaccante (il tester) che dei difensori.
1.2. Fasi del penetration test
Un penetration test si articola nelle seguenti fasi.
1. Pianificazione
Il primo stadio del test è caratterizzato da:
a. Definizione degli obiettivi del test, quali sistemi devono essere testati e con quali metodologie.
b. Acquisizione delle informazioni (indirizzi ip, server, macchine virtuali) per capire come lavorano gli obiettivi e quali possono essere le potenziali vulnerabilità.
2. Scansione
Nella seconda fase si testa come il sistema risponde a diversi tentativi di intrusione.
Questo può essere fatto utilizzando:
a. Analisi statica - Ispezione del codice attraverso tool automatici per capire come si comporterà quando in esecuzione.
b. Analisi dinamica - Ispezione del codice durante la sua esecuzione. Questo tipo di analisi offre informazioni in tempo reale sulle performance del sistema.
3. Accesso al sistema
Questo stadio utilizza attacchi come cross-site scripting e SQL injection per scoprire vulnerabilità. Il tester quindi prova a sfruttare le vulnerabilità individuate per ottenere privilegi di sistema non autorizzati, rubare dati, intercettare il traffico e valutare il danno che può essere causato.
4. Mantenimento dell’accesso
L’obiettivo di questa fase è valutare se le vulnerabilità individuate consentono di mantenere un accesso persistente al sistema. Si cerca di capire se è possibile infiltrarsi in profondità nel sistema informatico attaccato, in modo da continuare a rubare dati sensibili anche mesi dopo che l’attacco è stato compiuto.
5. Analisi dei risultati
I risultati del penetration test sono illustrati in un report che dettaglia:
a. Le specifiche vulnerabilità che sono state sfruttate.
b. I dati sensibili che sono stati ottenuti.
c. La quantità di tempo che il tester è stato in grado di rimanere nel sistema.
Tali informazioni sono poi analizzate dal personale addetto alla sicurezza che si occupa di applicare delle patch alle vulnerabilità segnalate e proteggere il sistema contro attacchi futuri.
2. Penetration testing di Sardcoin
Il presente capitolo applica al contesto di Sardcoin i concetti presentati nell’introduzione, con il duplice obiettivo di spiegare come è stato condotto il test e motivare le scelte progettuali adottate.
2.1. Scelta della tipologia di test
Nella fase attuale del progetto Sardcoin è stata realizzata tutta l’infrastruttura software e le risorse pubblicamente visibili in rete (come macchine virtuali, sito web, frontend, backend, API, blockchain). I dettagli di gestione e amministrazione del sistema (come firewall, account amministratori, dipendenti), dipenderanno invece da chi prenderà in carico la gestione del progetto. Nel contesto attuale test interno ed esterno sono quindi molto simili. Il software backend è eseguito in una macchina virtuale AWS di cui è stata creata una copia a disposizione del tester per installare ed eseguire i tool di penetration testing. Nonostante l’esecuzione di alcuni tool avvenga in locale, il test eseguito può essere considerato di tipo esterno, poiché gli obiettivi del test sono esclusivamente risorse accessibili all’esterno (backend, IP, porte, API).
L’obiettivo principale dei test blind e double-blind è cercare di capire quali risultati può realmente raggiungere un attaccante. Anche se questo permette di testare lo scenario di attacco più comune, l’efficacia del test è fortemente legata alla bravura del tester nell’individuare le vulnerabilità e al tempo a sua disposizione. Il vero attaccante potrebbe infatti individuare ulteriori vulnerabilità che il tester non è riuscito a scoprire. Il vantaggio di un targeted testing è una semplificazione del lavoro del tester, fornendogli maggiori informazioni sul sistema. Ciò consente al tester di alleggerire l’attività di raccolta delle informazioni a favore delle attività di analisi dei dati raccolti e di studio delle vulnerabilità individuate.
Per questi motivi, per Sardcoin è necessario svolgere un Test Esterno di tipo Targeted Testing.
2.2. Definizione delle fasi del test
Con riferimento alle fasi del penetration test presentate nel capitolo precedente, viene di seguito illustrata la metodologia con la quale verrà condotto il penetration test di Sardcoin.
1. Pianificazione
a. Obiettivo del test.
La piattaforma Sardcoin è composta da 3 componenti fondamentali: frontend, backend, blockchain. L’obiettivo del test è la componente backend.
b. Acquisizione delle informazioni - Architettura di Sardcoin.
Il backend è un servizio ospitato su una macchina virtuale AWS pubblicamente accessibile all’indirizzo 172.31.9.4. La stessa macchina virtuale ospita anche il sito web pubblico di Sardcoin www.sardcoin.eu . Le altre due componenti del progetto, comunque non coinvolte nel test, non sono contenute nella macchina
virtuale oggetto della simulazione di attacco. Precisamente, la blockchain è ospitata da una macchina virtuale differente, mentre il frontend è la parte client dell’app che sarà utilizzata dagli utenti, ed è quindi eseguita dai loro dispositivi.
c. Acquisizione delle informazioni - tool di ispezione.
Partendo dall’indirizzo ip fornito, ulteriori informazioni sul sistema saranno raccolte attraverso tool come Nmap relativamente a: dispositivi collegati alla rete, porte aperte all’indirizzo dato, servizi attivi, sistema operativo e versione dei software installati.
2. Scansione
La scansione sarà principalmente di tipo dinamico utilizzando dei tool come OWASP Zed Attack Proxy e SqlMap che lavoreranno sulla piattaforma durante l’esecuzione del codice. Tuttavia, considerando che Sardcoin è un progetto open source disponibile all’indirizzo https://github.com/sardcoin/ , verranno sfruttate anche le informazioni prodotte dai tool di analisi statica di Github e mostrate online nell’apposito pannello all’indirizzo https://github.com/sardcoin/sardcoin-core/security.
3. Accesso al sistema
Se verranno rilevate delle vulnerabilità che possono portare all’accesso al sistema, verranno utilizzati tool per l’exploit automatico delle vulnerabilità. I software dipenderanno dal tipo di vulnerabilità individuate.
4. Mantenimento dell’accesso
Questa fase verrà eseguita solo se è stato possibile ottenere un accesso alla fase precedente e al momento non richiede l’utilizzo di particolari tool.
5. Analisi dei risultati
L’analisi dei risultati ottenuti dalle simulazioni di attacco con i tool descritti è presentata nel capitolo seguente.
3. Esecuzione del test e analisi dei risultati
Il presente capitolo mostra il risultato dell’esecuzione dei tool nelle diverse fasi. Dove possibile, sono inseriti screenshot dei comandi e dei relativi risultati. Come anticipato nel precedente capitolo, l’esecuzione di alcuni tool avviene in locale nel sistema target.
3.1. Pianificazione
Per acquisire maggiori informazioni sul sistema, come anticipato nella fase di pianificazione, si utilizza il tool Nmap.
Il primo test effettua uno scan degli indirizzi IP connessi alla rete della macchina target.
Il risultato del test indica che c’è un solo device connesso, la macchina virtuale. Questo è lo scenario ottimale dal punto di vista della sicurezza. Infatti, la presenza di ulteriori dispositivi avrebbe aumentato la superficie di attacco poiché una vulnerabilità di tali dispositivi si sarebbe potuta ripercuotere sulla macchina virtuale collegata alla stessa rete.
Il prossimo test effettua uno scan di tutte le 65536 porte all’indirizzo dato al fine di individuare tutte le porte aperte.
Anche in questo caso l’esito del test indica un buon livello di sicurezza: sono aperte solo le porte dei servizi essenziali del backend e non ci sono ulteriori porte aperte che potrebbero essere sfruttate da eventuali attaccanti.
I successivi comandi rilevano il sistema operativo utilizzato della macchina e le versioni dei principali software utilizzati.
Il tool ha rilevato il sistema operativo utilizzato (Ubuntu), la versione del sistema e del kernel.
Ha inoltre individuato altri software e le relative versioni, come OpenSSH per gestire le
connessioni in SSH dagli amministratori e il web server Apache httpd per gestire il sito web ospitato nella macchina. Tutti i software rilevati dai precedenti comandi stanno utilizzando delle versioni aggiornate, per le quali non sono note vulnerabilità.
3.2. Scansione
3.2.1. Analisi statica
Nella prima parte della fase di scansione vengono presentati i risultati prodotti dai tool di analisi statica di Github.
Come anticipato nel capitolo precedente, il codice del progetto Sardcoin è open source. Il codice è diviso in tre progetti distinti gestiti tramite tre repository Github: backend, frontend, e blockchain. In ogni repository, Github analizza le dipendenze del codice sorgente (ad esempio le librerie esterne utilizzate e le loro versioni), confrontandole con un elenco di librerie a cui sono associate delle vulnerabilità che sono state riscontrate nel tempo. Se qualche dipendenza del progetto è presente nell’elenco, il Dependabot di Github la segnala nel pannello corrispondente (visibile solo agli autori) evidenziando il livello di criticità rilevato. La seguente immagine rappresenta la lista di segnalazioni riportate dal Dependabot per il repository del backend (contenente il codice del software sottoposto a penetration testing).
Vengono segnalate sei dipendenze, alcune hanno un livello di criticità elevato. Cliccando su ogni dipendenza è possibile vedere i dettagli della vulnerabilità. Nei dettagli è presente una descrizione testuale della vulnerabilità e vengono proposti dei suggerimenti su come risolverla.
In alcuni casi è sufficiente utilizzare una versione più aggiornata della dipendenza, in altri non ci sono versioni aggiornate che correggano il problema e viene raccomandato l’utilizzo di una dipendenza alternativa. Tutte le vulnerabilità indicate possono condurre ad attacchi di tipo XSS. Nelle due seguenti figure sono rappresentate le dipendenze con livello di criticità maggiore: nel primo caso è necessario utilizzare una dipendenza alternativa.
Anche se il pannello del Dependabot non è accessibile pubblicamente, le vulnerabilità indicate dovrebbero essere sistemate, utilizzando versioni più aggiornate (o alternative) per ogni dipendenza indicata nell’elenco.
3.2.2. Analisi dinamica
La seconda parte della scansione è eseguita tramite tool di analisi dinamica, eseguiti sulla macchina virtuale durante l’esecuzione del servizio backend di Sardcoin.
Il software OWASP Zed Attack Proxy ispeziona i contenuti esposti all’indirizzo ip fornito al fine di rilevare vulnerabilità. L’esecuzione ha prodotto la seguente lista di alert.
Accedendo ai dettagli dei singoli alert si nota che fanno riferimento a pagine del sito web di Sardcoin e nessuna delle vulnerabilità indicate ha un livello di criticità elevato.
Il prossimo test utilizza il tool sqlmap per cercare vulnerabilità di tipo SQL-injection ed eventualmente provare a sfruttarle, al fine di recuperare i dati presenti nel database. Dopo aver ispezionato accuratamente il sito di Sardcoin, il tool è stato identificato un’unica pagina dove è possibile eseguire il tool. La pagina accetta un solo parametro, che costituisce quindi l’unico ponte di ingresso per l’esecuzione del tool.
Il risultato del software mostra che il parametro è sicuro e non vulnerabile ad attacchi di tipo SQL-injection.
4. Strategie per migliorare la sicurezza di Sardcoin
Basandosi sui consigli anticipati nell’analisi dei risultati al capitolo precedente, il presente capitolo riassume le strategie per migliorare la sicurezza del sistema Sardcoin.
In generale, non sono state individuate criticità preoccupanti nella piattaforma, gran parte delle analisi non ha proprio evidenziato alcuna vulnerabilità. Le uniche aree che richiedono un intervento sono le dipendenze analizzate in maniera automatica da Github. Per questo motivo si consigliano le seguenti strategie per migliorare la sicurezza del sistema.
1. Risolvere tutti gli alert indicati dal Dependabot del repository relativo al backend di Github (sardcoin-core), utilizzando versioni aggiornate delle dipendenze (quando disponibili) oppure delle dipendenze alternative non soggette a nuovi alert di sicurezza.
2. Svolgere lo stesso compito anche nel repository relativo al frontend (sardcoin-ui) dove sono attualmente presenti due vulnerabilità (di livello minore). Nel terzo repository (sardcoin-blockchain) attualmente non sono segnalate vulnerabilità.
