Security Assessment: casi pratici e risultati - Elaborato finale in Reti di Calcolatori
←
→
Trascrizione del contenuto della pagina
Se il tuo browser non visualizza correttamente la pagina, ti preghiamo di leggere il contenuto della pagina quaggiù
Facoltà di Ingegneria Corso di Studi in Ingegneria Informatica Elaborato finale in Reti di Calcolatori Security Assessment: casi pratici e risultati Anno Accademico 2018/2019 candidato Nappi Marco matr. N46/1914
Ringrazio il prof. Pescape, lo Staff del CSI
la mia famiglia, e i miei amici
che mi hanno guidato e supportato
anche nei momenti più bui.
Insegnandomi a credere in me
e nelle mie capacità
2Indice
Introduzione 5
1 Vulnerabilità WEB 7
1.1 Cross-Site Scripting (XSS) . . . . . . . . . . . . . . . . . . . . . . 7
1.1.1 XSS-reflected . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.1.2 XSS DOM Based . . . . . . . . . . . . . . . . . . . . . . . 8
1.1.3 XST: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.1.4 XSS stored: . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.1.5 Blind XSS: . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2 Clickjacking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3 CSRF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.4 Broken Acces Controll . . . . . . . . . . . . . . . . . . . . . . . . 9
1.5 Local File Inclusion (LFI) . . . . . . . . . . . . . . . . . . . . . . 10
1.6 File Upload Vulnerabilty . . . . . . . . . . . . . . . . . . . . . . . 10
1.7 Open Redirect . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.8 SQL Injection (SQLi) . . . . . . . . . . . . . . . . . . . . . . . . 11
1.8.1 SQL Injection . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.8.2 Blind SQL injection . . . . . . . . . . . . . . . . . . . . . 11
1.8.3 SQL Injection Login Bypass . . . . . . . . . . . . . . . . . 12
1.8.4 NOSQL injection . . . . . . . . . . . . . . . . . . . . . . . 12
1.9 Code Injection . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.10 User-Enumeration . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.10.1 Bruteforce-wordlist . . . . . . . . . . . . . . . . . . . . . . 12
1.10.2 Automated . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.11 Doungerous HTTP Methods . . . . . . . . . . . . . . . . . . . . . 13
1.12 Metadata Issue . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2 Web Pentesting 14
2.1 Fasi di un Penetration Testing . . . . . . . . . . . . . . . . . . . 14
2.2 Metodologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.1 Metodologia per rilevare Cross Site Scripting (XSS) . . . 14
2.2.2 Metodologia per rilevare Click-Jacking . . . . . . . . . . . 18
2.2.3 Metodologia per rilevare una Cross-Site Request forgery
CSRF o XSRF . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3 Metodologia Per Testare Broken Acces Controll . . . . . . . . . . 19
2.3.1 Metodologia Per Testare LFI . . . . . . . . . . . . . . . . 19
2.3.2 Metodologia per Testare FileUploadVulnerabilty . . . . . 20
2.4 Metodologia di Test per OpenRedirect: . . . . . . . . . . . . . . . 21
3INDICE
2.4.1 Metodologia Per testare SQLi . . . . . . . . . . . . . . . . 21
2.4.2 Code injection . . . . . . . . . . . . . . . . . . . . . . . . 24
2.4.3 User-Enumeration . . . . . . . . . . . . . . . . . . . . . . 24
2.4.4 Doungerous HTTP Methods . . . . . . . . . . . . . . . . 25
2.4.5 Metadata issue . . . . . . . . . . . . . . . . . . . . . . . . 25
2.5 Tools for Pentesting . . . . . . . . . . . . . . . . . . . . . . . . . 25
Conclusioni 27
Bibliografia 28
4Introduzione
La sicurezza informatica o cyber security è una branca dell’informatica che ha un
ampio spettro di contenuti. La sicurezza informatica si occupa dell’informatica
in tutte le sue applicazione dal ramo WEB al ramo emebedded con lo scopo di
tutelare l’utente finale. Negli ultimi anni l’importanza della sicurezza informatica
sta crescendo con rapidità al punto tale che dal 2016 la NATO riconosce internet
come zona di guerra operativa. Nel cyber security si sono individuati tre aspetti
fondamentali: Confidenzialità, integrità e disponibilità, nota anche come triade
CIA (Confidentiality, Integrity, Disponibilità). Il modello CIA è un modello
progettato per guidare le politiche di sicurezza delle informazioni all’interno
di un’organizzazione. Il modello è a volte indicato anche come la triade AIC
(disponibilità, integrità e Confidenzialità). Gli elementi della triade sono consi-
derati i tre pilastri della sicurezza. In questo contesto, la Confidenzialità è un
insieme di regole che limita l’accesso alle informazioni, l’integrità è la garanzia
che le informazioni sono affidabili e accurate, e la disponibilità è una garanzia di
accesso affidabile alle informazioni da parte di persone autorizzate.
Confidenzialità La Confidenzialità equivale all’incirca alla privatezza. Le
misure adottate per garantire la Confidenzialità sono progettate per impedire
che le informazioni sensibili raggiungano le persone sbagliate, assicurando al
contempo che le persone giuste possano effettivamente ottenerle: L’accesso deve
essere limitato alle persone autorizzate a visualizzare i dati in questione. È
comune, inoltre, che i dati siano classificati in base alla quantità e al tipo di
danno che potrebbe essere fatto nel caso in cui cadesse in mani non intenzionali.
Misure più o meno severe possono quindi essere attuate in base a tali categorie.
A volte la tutela della Confidenzialità dei dati può richiedere una formazione
specifica per coloro che sono a conoscenza di tali documenti. La formazione
può aiutare le persone autorizzate a familiarizzare con i fattori di rischio e come
premunirsi contro di loro. Ulteriori aspetti della formazione possono includere
password forti e buone pratiche relative alle password e informazioni sui metodi
di ingegneria sociale, per evitare che le regole di gestione dei dati vengano piegate
con buone intenzioni e risultati potenzialmente disastrosi.
Integrità L’integrità consiste nel mantenere la coerenza, l’accuratezza e l’affi-
dabilità dei dati per l’intero ciclo di vita. I dati non devono essere modificati
durante il trasporto e devono essere adottate misure per garantire che i dati non
possano essere alterati da persone non autorizzate (ad esempio, in violazione
della Confidenzialità). Queste misure comprendono l’attuazione di tecniche di
controllo relative ai file e al controllo degli accessi degli utenti. Tecniche di
5CAPITOLO 0. INTRODUZIONE
controllo della versione può essere utilizzato per evitare che modifiche errate o
cancellazioni accidentali da parte di utenti autorizzati diventino un problema.
Inoltre, è necessario disporre di alcuni mezzi per rilevare eventuali modifiche dei
dati che potrebbero verificarsi a seguito di eventi non causati dall’uomo, come
un impulso elettromagnetico (EMP) o il crash del server. Alcuni dati possono
includere checksum, anche crittografici, per la verifica dell’integrità. I backup o
le ridondanze devono essere disponibili per ripristinare lo stato corretto dei dati
interessati.
Disponibilità La Disponibilità è garantita al meglio mantenendo rigorosamen-
te tutto l’hardware, eseguendo riparazioni hardware immediatamente quando
necessario e mantenendo un ambiente operativo correttamente funzionante che
sia libero da conflitti software. È inoltre importante eseguire tempestivamente
tutti gli aggiornamenti di sistema necessari. È altrettanto importante fornire
un’adeguata larghezza di banda di comunicazione e prevenire il verificarsi di colli
di bottiglia. Ridondanza, RAID anche i cluster ad alta Disponibilità possono
attenuare le gravi conseguenze in caso di problemi hardware. Il disaster recovery
rapido e adattivo è essenziale per gli scenari peggiori; tale capacità dipende
dall’esistenza di un piano completo di disaster recovery (DRP). Le misure di
protezione contro la perdita di dati o le interruzioni delle connessioni devono
includere eventi imprevedibili, quali disastri naturali e incendi. Per evitare la
perdita di dati a causa di tali eventi, una copia di backup può essere conservata
in un luogo geograficamente isolato, magari anche in una cassaforte resistente
al fuoco e all’acqua. Apparecchiature di sicurezza aggiuntive o software come
firewall e server proxy possono proteggersi dai tempi di inattività e dati irrag-
giungibili a causa di azioni dannose come gli attacchi DOS (denial-of-service) e
le intrusioni di rete.
CentroServiziInformatici(CSI)
Le vulnerabilità successivamente descritte sono state cercate dal sottoscritto
attraverso le metodologie, anch’esse descritte successivamente, nella rete dell’u-
niversità di Napoli, gestita dal CSI, sulla quale ho potuto svolgere un’attività di
Pentest Web. Il pentesting di una applicazione WEB è uno delle due branche
del PT (penetration Testing)[8] che indaga gli applicativi web, sia in maniera
passiva che in maniera attiva, in modo da trovare eventuali difetti dovuti sia
ad una sbagliata progettazione che ad eventuali obsolescenza degli applicativi
utilizzati. Colui che effettua un Penetration Testing è detto Penetration Tester
questa figura sfrutta Metodologie e tool per trovare vulnerabilità nell’applicativo
Web definito come target
6Capitolo 1
Vulnerabilità WEB
In Questo capitolo si provvederà ad introdurre e successivamente vedere nel
dettaglio le più comuni vulnerabilità web quali: XSS, Clickjacking, Client side
Reforgery (CSRF), Broken Access Controll (BAC), Local File Inclusion, Fi-
le Upload Vulnerability, Open-Redirect, SQL Injection, Code injection, User
Enumeration, Dangeours HTTP Mehtods, metadata issue.
1.1 Cross-Site Scripting (XSS)
Gli attacchi Cross-Site Scripting (XSS) rientrano nella categoria di attacchi
chiamata "data injection”, in cui gli script dannosi vengono iniettati, sotto forma
di codice HTML e javascript, in siti web altrimenti affidabili. Gli attacchi XSS si
verificano quando un Penetration tester utilizza un’applicazione web per inviare
codice dannoso, generalmente sotto forma di script lato browser, a un altro utente
finale. I difetti che permettono il successo di questi attacchi sono abbastanza
diffusi e si verificano ovunque un’applicazione web riflette l’input di un utente
nella generazione all’interno della propria pagina web senza prima convalidarlo
o codificarlo. Un Penetration tester può usare un XSS per inviare uno script
dannoso ad un utente ignaro. Poiché il browser utilizzato dell’utente non ha
modo di discernere tra script malevoli e non lo script verrà eseguito. Lo script
dannoso una volta eseguito darà accesso al Penetration Tester a qualsiasi cookie,
token di sessione o altre informazioni sensibili conservate dal browser e utilizzate
da quel sito. In alcuni casi questi script possono anche riscrivere il contenuto
della pagina HTML. Esistono diverse categorie di XSS: XSS-reflected, XSS-DOM
based, XST, Stored-XSS e Blind XSS
1.1.1 XSS-reflected
Gli attacchi del tipo XSS-reflected sono quelli in cui lo script iniettato viene
riflesso dal server web, ad esempio in un messaggio di errore, nei risultati della
ricerca o in qualsiasi altra risposta che include alcuni o tutti gli input inviati al
server come parte della richiesta. Gli attacchi XSS reflected vengono consegnati
alle vittime attraverso un URL inviato ad esempio in un messaggio di posta
elettronica. Quando un utente viene indotto a cliccare su un link dannoso per
navigare il sito dannoso, il codice iniettato viene eseguito attraverso il sito web
7CAPITOLO 1. VULNERABILITÀ WEB
vulnerabile, che riflette l’attacco al browser dell’utente. Il browser esegue il
codice perché proviene da un server "fidato".
1.1.2 XSS DOM Based
L’attacco XSS DOM Based [1], è un attacco XSS in cui la payload, ovvero il
codice malevolo, dell’attacco viene eseguita come risultato della modifica del
"ambiente" del DOM nel browser della vittima utilizzato dallo script lato client
originale, in modo che l’esecuzione del codice lato client produca un risultato
"inaspettato". In particolare, la pagina stessa (la risposta HTTP) non cambia,
ma il codice lato client contenuto nella pagina viene eseguito in modo diverso a
causa delle modifiche dannose che si sono verificate nell’ambiente DOM. Questo
è in contrasto con altri attacchi XSS (stored o reflected), in cui la payload
dell’attacco viene posizionato nella pagina di risposta (grazie ad un difetto di
progettazione/programmazione lato server).
1.1.3 XST:
Un attacco Cross-Site Tracing (XST) comporta l’uso di Cross-site Scripting (XSS)
e dei metodi TRACE o TRACK HTTP. Secondo l’RFC 2616[2], TRACE permette
al cliente di vedere cosa viene ricevuto all’altro capo della catena di richiesta
e di utilizzare quei dati per testare o per informazioni diagnostiche. Il metodo
TRACK funziona allo stesso modo ma è specifico del server web IIS di Microsoft.
XST potrebbe essere usato come metodo per rubare i cookie dell’utente tramite
Cross-site Scripting (XSS) anche se il cookie ha il flag "HttpOnly" impostato e/o
espone l’intestazione di autorizzazione dell’utente. Il metodo TRACE, anche
se apparentemente innocuo, può essere utilizzato con successo in alcuni scenari
per rubare le credenziali degli utenti legittimi. Questa tecnica di attacco è
stata scoperta da Jeremiah Grossman nel 2003, nel tentativo di aggirare il tag
HttpOnly che Microsoft ha introdotto in Internet Explorer 6 SP1 per proteggere
i cookie dall’accesso tramite JavaScript. Infatti, uno degli schemi di attacco
più ricorrenti nel Cross Site Scripting è quello di accedere all’oggetto document.
cookie e inviarlo a un server web controllato dall’aggressore in modo che possa
dirottare la sessione della vittima. Il flag HttpOnly di un cookie vieta a codice
JavaScript di modificare il valore di quest’ultimo. Tuttavia, il metodo TRACE
può essere utilizzato per aggirare questa protezione e accedere al cookie anche
in questo scenario. I moderni browser impediscono ora che le richieste TRACE
vengano effettuate tramite JavaScript, ma sono stati scoperti altri modi di inviare
richieste TRACE con i browser, come l’utilizzo di Codice Java che tramite socket
invia una richiesta HTTP.
1.1.4 XSS stored:
L’attacco XSS più dannoso è il cosiddetto XSS Stored detta anche XSS Persistente.
Gli attacchi XSS stored comportano che un Penetration tester inietta uno script
(chiamato payload) che viene memorizzato in maniera persistente sull’applicazione
ad esempio all’interno di un database. Un esempio classico è uno script dannoso
inserito da un aggressore in un campo di commento su un blog o in un post di un
forum. Quando una vittima naviga verso la pagina web interessata in un browser,
il payload XSS viene caricato come parte della pagina web (proprio come un
8CAPITOLO 1. VULNERABILITÀ WEB
commento legittimo). Ciò significa che le vittime finiranno inavvertitamente
per eseguire lo script dannoso ogni volta che la pagina viene visualizzata in un
browser.
1.1.5 Blind XSS:
Gli attacchi del tipo Blind XSS sono una variante dell’attacco XSS-stored. La
Blind XSS, cosi come la tipologia stored viene salvata in maniera persistente
nel back end del sito "vittima", con la differenza che lo script dannoso viene
eseguito quando una pagina contente codice Javascript dinamico richiama un
determinato parametro il cui valore sarà il nostro payload. Ciò rende le Blind
XSS più difficili da individuare e molto più efficaci.
1.2 Clickjacking
Il ClickJacking, noto anche come "UI redress attack", avviene quando un Pene-
tration tester usa più livelli trasparenti o opachi, contenuti in un iframe full-page,
per indurre un utente a cliccare su un pulsante o link su un’altra pagina quando
intendeva cliccare sulla pagina di livello superiore. In questo modo l’”hijacking"
del click può essere utilizzato per reindirizzare la vittima su un sito web contente
script malevoli. Usando una tecnica simile, anche i tasti possono essere dirottati.
Con una combinazione attentamente studiata di fogli di stile, iframe e caselle
di testo, un utente può essere indotto a credere di aver digitato la password
della propria e-mail o conto bancario, quando in realtà sta digitando in un frame
invisibile controllato dall’aggressore.
1.3 CSRF
Cross-Site Request Forgery (CSRF)[6] è un attacco che obbliga l’utente finale
ad eseguire azioni indesiderate su un’applicazione web in cui è attualmente
autenticato. Gli attacchi CSRF hanno come obiettivo specifico le richieste di
cambiamento di stato, non il furto di dati, poiché l’aggressore non ha modo di
vedere la risposta alla richiesta falsificata. Con un piccolo aiuto di ingegneria
sociale (come l’invio di un link via e-mail o chat) ad Esempio un aggressore può
indurre gli utenti di un’applicazione web ad eseguire azioni a scelta dell’aggressore.
Se la vittima è un utente normale, un attacco CSRF di successo può costringere
l’utente ad eseguire richieste di modifica dello stato come il trasferimento di
fondi, la modifica dell’indirizzo e-mail e così via. Se la vittima è un account
amministrativo, il CSRF può compromettere l’intera applicazione web.
1.4 Broken Acces Controll
Il controllo degli accessi, a volte chiamato autorizzazione, è il modo in cui
un’applicazione web tipicamente concede l’accesso a determinati contenuti e/o
funzionalità ad alcuni utenti e non ad altri. Questi controlli vengono eseguiti
dopo l’autenticazione e regolano ciò che gli utenti sono autorizzati a fare. Il
controllo degli accessi sembra un problema semplice, ma è difficile da imple-
mentare correttamente. Il modello di controllo accessi di un’applicazione web è
9CAPITOLO 1. VULNERABILITÀ WEB
strettamente legato al contenuto e alle funzioni che il sito fornisce. Inoltre, a gli
utenti possono essere attribuiti una serie di gruppi o ruoli con abilità o privilegi
diversi. Gli sviluppatori spesso sottovalutano la difficoltà di implementare un
meccanismo affidabile di controllo degli accessi. Molti di questi schemi non sono
stati progettati deliberatamente, ma si sono semplicemente evoluti insieme al
sito web. In questi casi, le regole di controllo degli accessi sono inserite in varie
posizioni in tutto il codice. Man mano che il sito si avvicina all’implementazione,
l’insieme di regole ad hoc diventa così ingombrante che è quasi impossibile da
capire. Molti di questi schemi di controllo degli accessi non sono difficili da
scoprire e sfruttare. Spesso, tutto ciò che è necessario è creare una richiesta di
funzioni o contenuti che non dovrebbero essere concessi. Una volta scoperto un
difetto, le conseguenze di un sistema di controllo dell’accesso difettoso possono
essere devastanti. Oltre a visualizzare contenuti non autorizzati, un aggressore
potrebbe essere in grado di modificare o cancellare contenuti, eseguire funzioni
non autorizzate o addirittura assumere l’amministrazione del sito. Un tipo
specifico di problema di controllo degli accessi sono le interfacce amministrative
che consentono agli amministratori del sito di gestire un sito su Internet. Tali
funzioni sono spesso utilizzate per consentire agli amministratori del sito di
gestire in modo efficiente gli utenti, i dati e i contenuti del loro sito. In molti
casi, i siti supportano una varietà di ruoli amministrativi per consentire una
granularità più fine dell’amministrazione del sito. A causa del loro potere, queste
interfacce sono spesso gli obiettivi principali per l’attacco sia da parte di estranei
che di addetti ai lavori.
1.5 Local File Inclusion (LFI)
Local File Inclusion (LFI), o semplicemente file Inclusion, si riferisce a un attacco
attraverso il quale un hacker può ingannare l’applicazione web per includere file
sul server web sfruttando funzionalità che includono dinamicamente file o script
locali. La conseguenza del successo di un attacco LFI include Directory Traversal
e Information Disclosure così come Remote Code Execution. Ovvero l’attaccante
può ricavare informazioni sensibili (Information Disclosure) o vistare il sito come
se fosse un insieme di directory (Directory Traversal) o ancora eseguire comandi
relativi ad uno specifico sistema operativo (Remote Code Execution. In genere, la
Local file Inclusion (LFI) si verifica quando un’applicazione ottiene il percorso del
file che deve essere incluso come input senza trattarlo come input non attendibile.
Ciò consentirebbe di fornire un file locale all’istruzione di inclusione.
1.6 File Upload Vulnerabilty
I file caricati rappresentano un rischio significativo per le applicazioni. Il primo
passo in molti attacchi è quello di ottenere del codice sorgente del sistema da
attaccare. Quindi l’attacco deve solo trovare un modo per far eseguire il codice.
L’uso del caricamento di un file aiuta il Penetration tester a compiere il primo
passo. Le conseguenze di un upload di file senza restrizioni possono variare,
dall’acquisizione completa del sistema, un file di sistema o database sovraccarico,
all’inoltro di attacchi a sistemi di back-end, attacchi lato client o semplicemente
ad un crash del server. Dipende da cosa fa l’applicazione con il file caricato e
10CAPITOLO 1. VULNERABILITÀ WEB
soprattutto da dove viene memorizzato. Ci sono davvero due classi di problemi.
La prima è con i metadati dei file, come il percorso e il nome del file. Determinate
metodologie di metadati possono indurre l’applicazione a sovrascrivere un file
critico o a salvare il file in una cattiva posizione. È necessario quindi convalidare
i metadati con estrema attenzione prima di utilizzarli. La seconda classe di
problema è la dimensione del file o il contenuto. La gamma di problemi qui
dipende interamente da ciò per cui il file viene utilizzato. Per proteggersi da
questo tipo di attacco, si dovrebbe analizzare tutto ciò che l’applicazione fa con
i file e riflettere attentamente su quali elaborazioni e interpreti sono coinvolti.
1.7 Open Redirect
Re indirizzamenti e forward non convalidati, detti anche Open redirect, sono
possibili quando un’applicazione web accetta input non attendibili che potrebbero
indurre l’applicazione web a reindirizzare la richiesta a un URL contenuto
all’interno di un input. Modificando l’input URL in quello di un sito dannoso, un
aggressore può lanciare con successo una truffa di phishing e rubare le credenziali
dell’utente. Poiché il nome del server nel link modificato è identico al sito
originale, i tentativi di phishing possono avere un aspetto più affidabile. Gli
attacchi non convalidati di re-indirizzamento e inoltro possono anche essere
utilizzati per creare in modo dannoso un URL che passerebbe il controllo di
accesso dell’applicazione e quindi inoltrare l’aggressore a funzioni privilegiate
alle quali normalmente non sarebbe in grado di accedere.
1.8 SQL Injection (SQLi)
1.8.1 SQL Injection
Un attacco SQL injection consiste nell’inserimento o "iniezione" di una query
SQL attraverso i dati di input dal client all’applicazione. Un’iniezione SQL può
permettere di leggere dati sensibili dal database, modificare i dati del database
(Insert/Update/Delete), eseguire operazioni di amministrazione sul database
(come lo spegnimento del DBMS), recuperare il contenuto di un dato file presente
sul file system DBMS e in alcuni casi inviare perfino di inviare comandi al sistema
operativo. Gli attacchi SQL injection sono un tipo di attacco di iniezione, in cui
vengono sfruttati commandi SQL in cui l’attaccante inietta del codice malevolo
in modo da raggiungere il suo obbiettivo.
1.8.2 Blind SQL injection
L’iniezione SQL Blind[5] è un tipo di attacco SQL Injection che pone domande
vere o false al database e determina la risposta in base alla risposta delle
applicazioni. Questo attacco è spesso utilizzato quando l’applicazione web è
configurata per mostrare messaggi di errore generici, ma non ha attenuato
il codice vulnerabile all’iniezione SQL. Quando un Penetration tester sfrutta
l’iniezione SQL, a volte l’applicazione web visualizza messaggi di errore dal
database lamentando che la sintassi di SQL Query non è corretta. Blind SQL
injection è quasi identico al normale SQL Injection, l’unica differenza è il modo
in cui i dati vengono recuperati dal database. Quando il database non invia i dati
11CAPITOLO 1. VULNERABILITÀ WEB
alla pagina web, un aggressore è costretto a rubare i dati ponendo al database
una serie di domande vere o false. Questo rende più difficile, ma non impossibile,
lo sfruttamento della vulnerabilità di SQL Injection.
1.8.3 SQL Injection Login Bypass
Un attacco SQL injection può essere sfruttato per eludere il controllo di alcune
form di login facendo in modo, tramite la sintassi SQL, che il risultato della
query effettuata al database sia True oppure facendo in modo di eliminare dalla
query il controllo della password[3].
1.8.4 NOSQL injection
Un attacco NOSQL injection [7]consiste nell’inserimento o "iniezione" di una
query NOSQL attraverso i dati di input dal client all’applicazione. Un’iniezione
NOSQL può leggere dati sensibili dal database, modificare i dati del database
(Insert/Update/Delete), eseguire operazioni di amministrazione sul database
(come lo spegnimento del DBMS), recuperare il contenuto di un dato file presente
sul file system DBMS e in alcuni casi inviare comandi al sistema operativo. Gli
attacchi SQL injection sono un tipo di attacco di iniezione, in cui i comandi
NOSQL vengono iniettati in ingresso al piano dati per effettuare l’esecuzione di
comandi NOSQL predefiniti.
1.9 Code Injection
Code Injection è il termine generale per i tipi di attacco che consiste nell’iniettare
codice che viene poi interpretato/eseguito dall’applicazione. Questi tipi di attac-
chi sono di solito resi possibili dalla mancanza di un’adeguata convalida dei dati
di input/output. Code Injection si differenzia dal Command Injection in quanto
un aggressore è limitato solo dalla funzionalità del linguaggio iniettato stesso.
Se un Penetration tester è in grado di iniettare codice PHP in un’applicazione e
farla eseguire, è limitato solo da ciò di cui PHP è capace. L’iniezione dei comandi
consiste nello sfruttare il codice esistente per eseguire i comandi, solitamente nel
contesto di una shell.
1.10 User-Enumeration
la User Enumeration è un attacco che sfrutta errori di progettazione/programmazione
per enumerare gli utenti di un determinato applicativo web. Ne esistono due
tipologie:
1.10.1 Bruteforce-wordlist
L ’attacco "user enumeration" utilizza la tecnica di bruteforce (ovvero provare
tutte le possibili combinazioni di simboli) o delle wordlist(dizionari) su form di
registrazione, login e di recupero password. La strategia di questo attacco e
semplice consiste nel compilare un form, provocando un errore, e vedere se il
messaggio di errore specifica l’esiste o meno dell’utente.
12CAPITOLO 1. VULNERABILITÀ WEB
1.10.2 Automated
Per alcuni CMS (content management system) come concrete5 e Wordpress sono
noti degli errori di progettazione che permettono di automatizzare l’attacco e
di renderlo molto più efficiente ed efficace infatti basta effettuare delle richieste,
utilizzando curl come strumento, aumentando l’indice utilizzato con passo 1.
Esempio C5:
http: https://myconcrete5site/profile/nome/date/20
Nel caso di Wordpress bisogna aggiungere alla pagina home il parametro author
con un valore numerico da 1 a n. Una volta inviata tale richiesta la pagina
caricherà la pagina dell’autore.
Esempio Wordpress:
http://mywordpresssite.com/? author=1
-> restituirà ->
http://mywordpresssite.com/author/nome
1.11 Doungerous HTTP Methods
Il protocollo HTTP offre una serie di metodi che possono essere utilizzati per
eseguire azioni sul server web. Molti di questi metodi sono progettati per aiutare
gli sviluppatori a implementare e testare le applicazioni HTTP. Gli stessi metodi
però possono essere utilizzati per scopi nefasti se il server web non è configurato
correttamente.
PUT: Questo metodo permette ad un client di caricare nuovi file sul server web.
Un aggressore può sfruttarlo caricando file dannosi, o semplicemente utilizzando
il server della vittima come archivio di file.
DELETE: Questo metodo permette ad un client di cancellare un file sul server
web. Un Penetration tester può sfruttarlo come un modo molto semplice e diretto
per deturpare un sito web o per montare un attacco DoS.
TRACE: Questo metodo ritorna semplicemente al client qualsiasi stringa
inviata al server, ed è usato principalmente per scopi di debug. Questo metodo,
originariamente considerato innocuo, può essere utilizzato per eseguire l’attacco
conosciuto come Cross Site Tracing XST Descritto nella sezione 1.1.
1.12 Metadata Issue
Un corretto comportamento di una funzione che permette di caricare immagini
e/o PDF sarebbe quello di eliminare tutti i metadati che contengono informazioni
sensibili .Ad esempio per le immagini dati relativi alla geo localizzazione, data
,dati relativi al modello e marca del cellulare , nel caso dei file PDF le eventuali
informazioni contenute nei metadati come : orario dell’ultima modifica compreso
fuso orario(ciò permette una grossolana geo-localizzazione ,nome utente ,tipo
di sistema operativo e nome e versione con cui è stato modificato il PDF .
Tutte queste informazioni possono essere utilizzate sia nel campo dell’ingegneria
sociale sia come una sorta di fingerprinting (Fase del Web Pentesting spiegata
nel Capitolo successivo.
13Capitolo 2
Web Pentesting
2.1 Fasi di un Penetration Testing
• 1) Fingerprinting
La prima fase essenziale per eseguire un buon PT. Consiste nel ricavare
più informazioni possibili sul target del PT, utilizzando per lo più azioni
passive o i cosiddetti "lateral movements", attraverso svariate tecniche e
diversi tool che variano a seconda dell’applicativo utilizzato.
• 2) exploitation
La fase "exploitation" consiste nel rielaborale tutte le informazioni acquisite
attraverso la prima fase ed individuare eventuali punti deboli dell’appli-
cativo web da sfruttare per trovare e verificare la presenza di eventuali
vulnerabilità. In questa fase i CVE (Common Vulnerabilities and Ex-
posures) sono di grosso aiuto per il tester poiché indicano dei difetti di
progettazione presenti in alcuni componenti degli applicativi web di uso
comune ed il percorso da svolgere per confermare la vulnerabilità.
• 3) Post-exploitation
Ultima e più delicata fase del PT. In questa fase il tester utilizza le
vulnerabilità trovate nella fase precedente per ottenere privilegi maggiori e
nel caso più eclatante il controllo del server su cui gira l’applicativo WEB.
2.2 Metodologie
2.2.1 Metodologia per rilevare Cross Site Scripting (XSS)
E’ necessario fare un primo discrimine in base alla richiesta HTTP effettuata dalla
pagina che può essere una richiesta di tipo GET o una richiesta di tipo POST
.Se vogliamo testare l’esistenza di un XSS scatenata da una richiesta di tipo
GET basta effettuare del fuzzing su parametri della richiesta concatenando una
stringa contente i caratteri speciali ad un parametro e vedere se la nostra stringa
di test viene riflettuta nella pagina e se i caratteri vengono codificati o "escaped"
.Se la stringa viene riflettuta senza modifica sarà facile per il Penetration tester
generare una payload efficace. Un Penetration tester si può trovare in tre casi,
presupponendo che la propria stringa di test venga riflettuta senza modifica.
14CAPITOLO 2. WEB PENTESTING
Caso 1) La propria stringa di test è riflessa nel body della pagina HTML.
Caso 1.a) Se la stringa di test è riflessa al di fuori di un campo HTML il
Penetration tester può utilizzare ho il tag script per eseguire uno script JS o la
combinazione di un event handler e di un qualsiasi tag HTML.
Caso 1.b) Se la stringa è riflessa in un tag HTML il Penetration tester ha
due opzioni. La prima è di chiudere "prematuramente" il tag in cui la stringa di
test è riflessa per poi aprire un tag proprio come nel caso 1. a). Ciò può destare
sospetti nella vittima poiché cambierà la struttura della pagina e come essa verrà
renderizzata. In alternativa il Penetration tester può decidere di iniettare nel
tag in cui la stringa è riflessa e quindi scatenare l’esecuzione di uno script.
Caso 2) La propria stringa di test viene riflessa in un blocco di codice javascript.
Caso2.a) In questo caso il Penetration tester può studiare il funzionamento
dello script e modificarlo a suo piacimento per eseguire codice maligno .Nel
caso la propria stringa di test venga riflessa in un blocco di codice ma come
una variabile di tipo stringa , il Penetration tester può sfruttare il meccanismo
del linguaggio Javascript di gestione del concatenamento delle stringhe .Esempi
concreti di payload efficaci sono stringhe del tipo:
"-alert()-" , "*alert()*" , "^alert()^".
Caso2.b) Nel caso il Penetration tester non riesca a intuire come modificare il
codice Javascript, in cui è riflessa la propria stringa di test, può chiudere il blocco
di codice prematuramente, compromettendo il funzionamento della pagina e
successivamente iniettare la propria payload.
Caso 3) La propria stringa di test è riflessa nella pagina HTML nel tag head.
Da notare che in questo caso il Penetration tester non può far uso degli event
handler messi a disposizione del HTML.
Caso3.a) Nel caso la propria stringa è riflessa nel tag head e più precisamente
nel tag title il Penetration tester e costretto a chiudere il tag title per poi iniettare
la propria payload.
Caso3.b) Se la stringa del Penetration tester è riflessa in un tag meta il
Penetration tester ha due alternative chiudere il tag meta ed inserire un tag
script per far eseguire il codice maligno oppure ricorrere all’uso di sofisticate
payload specifiche per i tag meta.
Nel caso che il Penetration tester voglia iniettare una stringa di test in una
richiesta POST ciò richiede un passaggio in più rispetto ad iniettare una stringa
di test in una richiesta GET. Il Penetration tester può utilizzare due tecniche
ovvero:
Caso 1) L’attaccante intercetta la richiesta di tipo POST attraverso un proxy
e quindi concatena la stringa di test a uno o più valori del parametro della
richiesta POST modificandola.
15CAPITOLO 2. WEB PENTESTING
Caso 2) L’attaccante può esaminare il codice sorgente per trovare i nomi degli
input e quindi usarli come parametri di una richiesta GET.
WAF Bypass
Per bypassare eventuali WAF (Web Application Firewall) o regole definite
dall’admin del sito è utile conoscere le seguenti tecniche[4]:
• nel caso il tag venga eliso dalla nostra stringa di test del tipo
provare a modificare il tag in modo che non rientri tra nella blacklist del
firewall modificando il tag nei seguenti modi:
1) provando a mischiare caratteri maiuscoli e minuscoli. Il WAF potrebbe
essere impostato per elidere solo la stringa e quindi non bloccare
un tag script del genere . In alternativa è possibile ricorrere alla
codifica di una o più lettere nella codifica url ovvero. Ad esempio inviando
un input del genere .
2) In alcuni casi è possibile utilizzare anche il WAF a proprio vantaggio.
Infatti sapendo che verrà eliminata la stringa si può iniettare
la seguente stringa in modo da ottenere un tag script
correttamente composto usando i WAF.
3) Un’altra tecnica consiste di modificare il tag script da a
.
4) Nel caso ogni tag completo, anche se non contiene nulla, venga eliso
il waf è bypassabile usando l’inizio del commento multi-riga html come
chiusura del tag ovveroCAPITOLO 2. WEB PENTESTING
Esempio:
Con si otterrà lo stesso risultato di:
o
• Un’altra tecnica per non utilizzare il doppio apice nella propria payload è
sfruttare un template nativo del linguaggio Javascript, introdotto nel ES6,
nominato Template Litterals che permette l’uso sia di espressioni in una
stringa sì di stringhe multi riga. Il carattere speciale che è utilizzato per
definire l’inizio e la fine del template citato in precedenza è il backtick o
accento grave in italiano.
Esempio:
La seguente payload è corretta e funzionante poiché il linguaggio interpreta
ogni riga del template come una stringa, quindi ‘XSS‘ restituisce "XSS".
• Un ulteriore ostacolo per il Penetration tester causato da un WAF o dalla
logica dell’applicativo web può essere l’elisione della parte di una stringa
dopo uno spazio. Per evitare ciò il Penetration tester può utilizzare la
codifica url dello spazio %20 oppure l’utilizzo di caratteri che svolgono la
funzione dello spazio come il carattere + oppure il carattere /. È utile
ricordare che il carattere + non può essere usato nella sua versione in
codifica url %2c a differenza del carattere / che può essere usato in codifica
url.
• Il WAF dell’applicativo web può bloccare anche l’utilizzo degli event hand-
ler elidendoli. Per riscontrare se esiste una blacklist di event handler il
Penetration tester può utilizzare la seguente tecnica empirica che consistite
nel verificare se il controllo del WAF è basato sulla tipologia dei caratteri
o sul numero degli stessi che seguono le lettere "on”. Per effettuare questo
controllo l’attaccante deve fare più richieste modificando la stringa di test.
A titolo illustrativo considerare i seguenti esempi.
Esempio 1:
I)
Contenuto della prima stringa di test: “onxxx” -> non si rilevano differenza
tra la stringa di test e la stringa riflessa dalla WebApp.
II)
Contenuto della seconda stringa di test “onxxxx” -> non si rilevano diffe-
renza tra la stringa di test e la stringa riflessa dalla WebApp.
III)
Contenuto della terza stringa di test “onxxxxx” -> si rilevano differenza
tra la stringa di test e la stringa riflessa dalla WebApp
Da ciò l’attaccante può ricavare che il WAF non si basa su una blacklist ma
sul numero di caratteri che seguono la stringa "on”. Di conseguenza il Pe-
netration tester e costretto ad usare event handler composti da 3-4 caratteri.
Esempio 2)
I->X)
stringa di test onxxx fino a onxxxxxxxxxx ->no modifiche alla stringa di
17CAPITOLO 2. WEB PENTESTING
test rilevate.
Da ciò si riscontra che esiste una blacklist di event handler per bypassare ciò
l’attaccante può sfruttare: relativamente nuovi tag introdotti dal HTML5
poiché sono poco noti gli event handler specifici associati. Il Penetration
tester può sfruttare che linguaggio Javascript può essere usato come uno
pseudo protocollo. Si può eseguire codice javascript anche attraverso un
link.
Esempio:
• Se il WAF dell’applicazione blocca uno specifico carattere url-encoded
l’attaccante può ricorrere alla tecnica detta "Double encoding" la quale
consiste nel codificare, come dice, il nome due volte il carattere scelto
facendo ciò si può bypassare il WAF e il carattere verrà renderizzato
correttamente.
Esempio
Single encoding del carattere " (doppio apice) -> %22
Double encoding del carattere " (doppio apice) -> %2522
Da notare che i browser moderni decodificano una solo volta quindi dopo
la prima decodifica rimarrà la seguente stringa %22 che corrisponde al
carattere doppio apice.
• Nel caso il carattere %2f venga reso innocuo da un WAF il penetration tester
può sfruttare un comportamento dei moderni browser che trasformano il
carattere %5c nel carattere %2f.
2.2.2 Metodologia per rilevare Click-Jacking
Due sono le condizioni fondamentali per il Clickjacking. La prima è la presenza
di una HtmlInjection la seconda il valore dell’Header X-Frame-Options settato
in uno dei seguenti valori: “allow-from https://example.com/” - “sameorigin”
Come noto questa vulnerabilità sfrutta il tag HTML5 iframe creandone un
iframe a tutta pagina trasparente. Per verificare la presenza del Clickjacking
l’attaccante non deve fare altro che controllare gli header dell’host .Ciò può essere
fatto attraverso una richiesta tramite il comando curl oppure osservando le varie
richieste e le rispettive risposte del server attraverso un proxy per controllare
se è possibile fare un HTML injection , è possibile concatenare una stringa di
test agli n parametri della pagina e poi ispezionare la pagina per verificare che
la stringa di test è stata riflessa senza caratteri "escaped" o codificati.
2.2.3 Metodologia per rilevare una Cross-Site Request for-
gery CSRF o XSRF
Per verificare l’esistenza di una CSRF l’attaccante deve studiare attentamente le
richieste HTTP, per lo più POST, che permettono di modificare dei parametri
collegati ad un account. Se le richieste di modifica non contengono un CSRF-
Token è contengono un identificativo dell’account facilmente individuabile, come
nome-utente o un identificativo numerico.
Considerare una richiesta POST con i seguenti parametri: Methods=UpdateAccount\id=12345\nome=marco\co
18CAPITOLO 2. WEB PENTESTING
&password=Passw0rd1&email=marco.nappi@studenti.unina.it
Si noti quanto è semplice cambiare l’utente target della richiesta modificando
il carattere id. In modo del tutto analogo il Penetration tester può modificare
facilmente tutti i parametri. Se uno di questi parametri è vulnerabile ad XSS il
Penetration tester può "consegnare" l’XSS alla vittima senza sforzo.
Se nella richiesta compaiono i parametri usati per il login la CSRF può essere
usata per rubare l’account della vittima in modo semplice e veloce, infatti al
Penetration tester basterà cambiare il parametro email e il parametro password
per ottenere il controllo dell’account della vittima.
2.3 Metodologia Per Testare Broken Acces Con-
troll
Testare una Web Application per trovare un BAC dipende molto dalla logica
dell’applicativo in sé. Il caso più noto di BAC è il login Bypass ovvero in un’ap-
plicazione web il pannello di login può essere sfruttato per accedere conoscendo
solo l’username della vittima. Questa tipologia di BAC sfrutta la logica del
linguaggio SQL concatenando col nome utente una stringa che ritorna sempre
True e escludendo dalla query la password attraverso l’uso del commento SQL.
Un’altra tecnica per sfruttare il BAC è tramite l’utilizzo dei Google Dork. I
Google Dork sono degli strumenti per filtrare meglio il contenuto delle query
svolte da Google. Se un sito è configurato male attraverso i Google Dork il
Penetration tester può ottenere mail e password attraverso le seguenti query:
"inurl:http://www.target.com AND intext: password"
può indicare l’endpoint in cui sono contenute tutte le password mentre
"inurl:http://www.target.com AND intext:@host.com"
fornirà la pagina, se accessibile pubblicamente, dove sono contenuti gli indirizzi
email degli utenti registrati sul sito. Per trovare eventuali BAC possono essere
utili strumenti di Directory listing, i quali sfruttano o wordlist oppure la meto-
dologia di tipo bruteforce, poiché molte volte di gestori dei siti rendono privati i
path ma non gli endpoint. Un ulteriore tecnica per testare la presenza o meno
di un BAC e quella di studiare le richieste e i cookie della pagina che spesso
presentano parametri o cookie che descrivono i privilegi dell’utente. Modificando
i valori, il penetration tester può scatenare una privalage escalation e come
conseguenza accedere a contenuti che in teoria sarebbero non consentiti. Un
ulteriore tecnica per scatenare un BAC consiste nello sfruttare le OpenRedirect.
Sfruttando le Open redirect e possibile bypassare le restrizioni imposte dal admin.
Un caso molto banale di BAC avviene quando il gestore non modifica password
di default di un servizio contenuto nell’applicazione web, essendo le password di
default di dominio pubblico il Penetration tester può semplicemente utilizzare e
accedere a servizi ai quali in teoria non potrebbe.
2.3.1 Metodologia Per Testare LFI
In linea teorica un Penetration tester potrebbe testare ogni parametro per la
presenza o meno di una LFI, ma basandosi sui nomi e sui valori dei parame-
tri è possibile scartare la maggior parte dei parametri e concentrarsi su quelli
che ritiene possano avere più alta probabilità ad essere affetti da un LFI. In
19CAPITOLO 2. WEB PENTESTING
generale i parametri che con più probabilità possono essere affetti da LFI so-
no quelli che contengono un path o una pagina web come valore, ad esempio
http://www.target.com/? page=index.php
Per verificare la presenza di un LFI per prima cosa deve stabilire il tipo di
sistema operativo Unix o Windows poiché la stringa di test varia a differenza di
quest’ultimo.
Un esempio di stringa di test nel caso il server sia un server Unix è
/../../../../../../../etc/passwd
mentre un esempio di stringa di test nel caso il server sia un server Windows:
\..\..\..\..\..\..\..\..\boot.ini
Chiunque abbia dimestichezza con il terminale e/o powershell può capire le
azioni intrinseche nella stringa di test. Infatti /../ può essere visto come il
comando unix cd .. mentre \..\ può essere visto come il comando della power-
shell dir \..\. Tutti e due comandi indipendentemente dal sistema operativo
compiono un’azione basilare ovvero risalire al nodo superiore del path. Le
stringhe di test possono contenere n+1 volte la stringa /../ poiché l’obbiettivo
dell’attaccante e di raggiungere la radice o root del path per poi spostarsi, nel
caso Unix, nella cartella etc per poi aprire il file passwd che contente le password,
non in chiaro, di tutti i gruppi e di tutti gli utenti del sistema. Un attacco LFI
può essere sfruttato sia per vedere i contenuti della pagina scritta in PHP sia
per eseguire codice php. In particolare i wrapper php sono fondamentali per
eseguire le azioni precedentemente citate. Inoltre questi ultimi possono essere
usati anche per bypassare eventuali filtri imposti dal WAF. Un altro utilizzo di
un attacco LFI può essere quello di caricare dei file sul server che ospita il web
application. Se il Penetration tester riesce ad ottenere l’accesso attraverso un
LFI ai log di un qualunque servizio quest’ultimo può trasformare una LFI in un
command execution iniettando in qualunque header codice php. Per modificare
una richiesta un Penetration tester deve utilizzare un proxy. Una volta inviata
la richiesta con header contente file php, il Penetration tester non deve fare altro
che visualizzare, tramite LFI, la pagina di log a cui ha accesso.
2.3.2 Metodologia per Testare FileUploadVulnerabilty
E sempre bene ricordare che una fila upload vulnerability può avvenire solo
nel caso il webmaster abbia messo a disposizione una funzionalità di upload
nell’applicativo web. Tre aspetti provocano una fila upload vulnerability:
• 1) Tipologia di file
Un buon amministratore web dovrebbe valutare con cautela quali file
l’utente possa caricare per esempio dovrebbe limitare le tipologie di file
che l’utente possa caricare solo a file innocui ovvero solo contenuto mul-
timediale. Per fare ciò l’amministratore può imporre dei controlli sui file
che l’utente voglia caricare. I controlli sui file possono essere basati su
estensione del file, MIME del file e su l’header Content-Type.
Chiaramente Un Penetration tester può bypassare semplicemente i controlli
sull’estensione del file creando un file con una doppia estensione come per
esempio exploit.php.jpg. Inoltre essendo il controllo basato su una whitelist
o su una blacklist un Penetration tester può trovare un’estensione poco
usata o comunque ignorata dall’amministratore della pagina web. Ad
20CAPITOLO 2. WEB PENTESTING
esempio
file.php -> bloccato invece file.php3 e file. php5 -> non bloccato
file.php -> bloccato invece file.php.jpg -> non bloccato
Se non implementato bene il controllo sulla tipologia del file basato sul
MIME del file può essere facilmente by-passabile. Ad esempio un Pene-
tration tester intenzionato caricare un file php attraverso una funzionalità
di upload che permette il caricamento esclusivamente di immagini con
controllo basato su MIME può modificare il suo file php aggiungendo come
prima riga il MIME di un altro tipo di file consentito (Es. .gif ovvero
GIF89;). Se invece il controllo e basato sul header Content-Type il Pe-
netration tester può intercettare la richiesta con un proxy e modificare
l’header. Così facendo non avrà problemi a caricare il file maligno.
• 2) Dimensioni file
Caricare un file di grosse dimensioni può causare un Denial of Service(DOS),
anche involontario al server su cui si sta tentando di caricare il file.
• 3) Nome File
Il nome del file può sembrare innocuo ma può causare svariati problemi
all’applicativo web poiché se il nome del file viene riflesso in una pagina
può essere usato dal Penetration tester per eseguire una XSS di tipo stored.
2.4 Metodologia di Test per OpenRedirect:
Per verificare la possibilità di un Open Redirect su un’applicazione web un
penetration tester può sfruttare un proxy in modo da verificare tutte le richieste
HTTP e estrarre le richieste contenenti come parametri degli indirizzi http. Una
volta identificate le eventuali richieste il Penetration tester può semplicemente
inviare una richiesta modificando l’url dell’indirizzo nel parametro cosi da reindi-
rizzare la vittima ad un sito malizioso.
Un secondo modo per realizzare un attacco Open redirect è sfruttare un HTML
injection che l’attaccante non riesce a trasformare in una XSS ad esempio:
CLICK ME. Un terzo modo per reindi-
rizzare un utente verso un altro sito web e utilizzare una XSS che esegue codice
javascript. Questo è più efficace rispetto ad un open redirect scatenata da un
HTML injection poiché l’attaccante può predisporre l’open redirect in modo che
scatti in caso di alcune azione dell’utente oppure può far scattare l’open redirect
non appena la pagina abbia finito di caricarsi.
Esempio:
Payload nel caso sia riflessa nel body della pagina e non in un tag
2.4.1 Metodologia Per testare SQLi
IL primo approccio per testare possibilità di effettuare un attacco del tipo
SQL injection è quello di modificare i parametri inserendo caratteri speciali
che potrebbero essere interpretati dal DBMS sottostante dell’applicativo WEB.
Esistono due principali categorie di SQL injection: Error Based e Blind. Le
SQL injection di tipo Error based sono le più semplice da rilevare e sfruttare a
proprio vantaggio poiché nel momento in cui un Penetration tester scopre un
21CAPITOLO 2. WEB PENTESTING
SQL injection error based verrà’ renderizzato un warning o un error contente
la Query inviata al database che ha scatenato l’errore e anche il database che è
utilizzato dall’applicativo Web.
Metodologia per testare SQLi Error Based La metodologia su come tro-
vare un eventuale SQL injection Error based è relativamente semplice se si ha
una conoscenza di come è strutturata un Query nel linguaggio SQL. Infatti al
Penetration tester basterà inserire o un singolo apice ’ o un doppio apice “, ciò
dipende da quale dei vari DB è utilizzato, per scatenare un errore SQL.
La parte più farraginosa di SQL injection non è la scoperta ma bensì sfruttare
questa vulnerabilità’ per avere accesso ai dati, file dell’applicativo e la possibilità
di caricare o rimuovere eventuali file di qualunque formato.
Esempio
La richiesta http://www.target.com? id=1 non scatena alcun errore
invece la richiesta http://www.target.com? id=1’ o http://www.target.com? id=1"
scatena errore MYSQL
Una volta che il Penetration tester ha scoperto la vulnerabilità dovrà procedere
a scoprire quale tabella interroga la query e quante colonne ha quest’ultima.
Per scoprire quante colonne compongono la tabella il Penetration tester dovrà
procedere iniettando il comando order by n1,n2,n3,...,n per poi troncare la
query in anticipo con un carattere che nel linguaggio SQL inizia un commento
ovvero : #,/*,-- Il carattere cancelletto detto anche hash ,%23 o #, il Penetration
tester dovrà ricordare di codificarlo in url-encoding poiché se non codificato
il carattere # esclude tutti i parametri alla sua destra dalla richiesta al server.
Il Penetration tester dovrà procedere utilizzando il comando order by fino a
raggiungere l’indice n+1 non presente sulla tabella che scatenerà un errore SQL
e l’attaccante saprà’ che il numero di colonne corrisponde ad n.
Esempio:
http://www.target.com?id=1 order by 1/* no errore SQL
http://www.target.com?id=1 order by 2/* no errore SQL
http://www.target.com?id=1 order by 3/* no errore SQL
http://www.target.com?id=1 order by 4/* no errore SQL
http://www.target.com?id=1 order by 5/* errore SQL -> tabella composta
da 4 colonne Una volta scoperto il numero delle colonne presenti sulla tabella il
Penetration tester deve scoprire quante di esse può sfruttare per ottenere infor-
mazioni usando il costrutto Union. Inviando una richiesta dopo aver iniettato
il codice SQL union all select 1,...,n/* il Penetration tester visualizzerà nella
pagina gli indici che identificano le colonne della tabella su cui si sta effettuando
la query.
Esempio:
http://www.target.com?id=1 union all select 1,2,3,4 /*
Da ora in avanti il Penetration tester dovrà’ procedere o per esperienza o utiliz-
zando delle wordlist. Infatti ora il Penetration tester dovrà procedere a trovare il
nome della tabella del Database di cui vuole ottenere le informazioni. Esempio:
http://www.target.com?id=1 union all select 1,2,3,4 from tabella/*
se la tabella esiste la pagina caricherà normalmente altrimenti il Penetration
tester dovrà iterare il procedimento fino a che la pagina carichi correttamente.
Una volta scoperto il nome della tabella, il prossimo passo è dedurre i nomi
delle colonne che formano la tabella. Per verificare se la tabella presa in esame
22CAPITOLO 2. WEB PENTESTING
contenga la colonna con un determinato nome il Penetration tester deve solo
cambiare leggermente la query iniettata usando al posto di uno dei numeri il
presunto nome della colonna.
Esempio:
http://www.target.com?id=1 union all select 1,2,colonna,4 from tabella/*
se il nome della tabella esiste sulla pagina web al posto del numero verrà visua-
lizzato il primo valore della colonna. Per far in modo di far rvisualizzare tutti i
valori della colonna si può utilizzare la seguente payload:
http://www.target.com?id=1 union all select 1,2,concat(colonna),4 from
tabella/*
Metodologia per testare SQli Blind Le SQL injection di tipo Blind sono
più difficili da rilevare che da sfruttare. Testare la possibilità di effettuare o
meno di un SQL injection di tipo Blind può essere difficile da rilevare infatti
le SQL injection Blind non visualizzano sulla pagina dell’applicativo web un
errore ma bensì si manifesteranno attraverso una lieve modifica della pagina web
un’immagine leggermente spostata o testo non formattato correttamente. Un
ulteriore difficoltà è aggiunta dal fatto che il Penetration tester non disporrà
della query né del nome del database in uso. Per scoprire versione e modello
del DB in uso il penetration tester dovrà sfruttare le proprie conoscenze dei
Database. l’attaccante inoltre potrà porgere solo query il cui risultato sarà vero
o falso, intesi secondo la Logica Booleana.
Per verificare la possibilità o meno di una Blind SQL injection si può utilizzare
la seguente tecnica: concatenare al, parametro AND 1=1 o AND 1=2 in modo
che il risultato della query sia un valore booleano Esempio:
http://www.target.com?id=1 AND 1=1 -> La pagina carica correttamente
http://www.target.com?id=2 AND 1=2 -> La pagina caricherà con qualche
difetto grafico
Il passo successivo consiste nel trovare il nome della tabella da cui si vuole
ottenere dati. Come in un SQL Injection Error Based si procede per tentativi
utilizzando la seguente payload, and (select 1 from _tabella limit 0,1)=1, conca-
tenata al parametro vulnerabile
Esempio:
http://www.target.com/?id=3 and (select 1 from tabella limit 0,1)=1
Se la tabella esiste e quindi la query da come risultato il valore booleano True
la pagina caricherà correttamente. Se la tabella non esiste (e quindi otterremo
come risultato False) la pagina caricherà con dei piccoli difetti
Seguendo la logica della SQL injection di tipo Error Based una volta ottenuto
il nome della tabella il Penetration tester deve ottenere il nome della colonna
con la seguente payload ricavata modificando la precedente: and (select sub-
string(concat(1,colonna),1,1) from tabella limit 0,1)=1
Esempio
http://www.target.com/?id=3
and (select substring(concat(1,colonna),1,1) from tabella limit 0,1)=1
Se la query darà come risultato false la pagina caricherà con qualche difetto e si
avrà la conferma che non esiste la colonna in quella determinata tabella.
A differenza della SQL injection Error Based esistono n passaggi successivi infatti
nella SQL injection Blind il primo valore della colonna non verrà renderizzato
nella pagina ma dovremmo ricavarlo carattere per carattere attraverso l’uso di
23Puoi anche leggere
