techday: hackers vs. developers - le sql injection - simone onofri
TRANSCRIPT
Hackers vs Developers Le SQL Injec4onSimone Onofri -‐ Techub S.p.A.
v0.1
Introduzione
h;p://onofri.org/u/hvdsqli
Agenda
• Introduzione • Breve Storia della SQL Injec4on • Come a;accare • Come difendersi • Q&A e Conclusioni
Breve storia della SQL Injec4on
Web e SQL Injec4on
Tecnicamente le prime SQL InjecBon hanno cominciato ad essere presenB sul web da
quando i vari interpreB hanno permesso alle pagine web di mostrare daB collegandosi ai
database e quindi mostrarne i daB. Pensiamo a PHP (1995) e ad ASP (1996).
La prima famosa SQL Injec4on
Risale al 1998 da un arBcolo firmato da Rain Forest Puppy su Phrack “NT Web Technology
VulnerabiliBes” che conBene diverse vulnerabilità che dipendono dalle tecnologie
Web. SELECT * FROM table WHERE x=1 SELECT * FROM table WHERE y=5
La risposta alla prima famosa SQL Injec4on
“Secondo loro (il vendor) quello di cui sBamo per parlare non è un problema”
— Rain Forest Puppy -‐ Phrack Issue #54
La famosa raccomandazione
“Non date per scontato che l’input dell’utente sia ok quando (lo inserite) in query SQL”
— Rain Forest Puppy -‐ Phrack Issue #54
2003/2004 (a;acks)
2007 (vulnerabili4es)
2010 (risks)
2013 (risks)
Unvalidated Input Cross Site Scrip4ng (XSS) Injec4on Injec4on
Broken Access Control Injec4on Flaws Cross-‐Site Scrip4ng (XSS) Broken Authen4ca4on and Session Management
Broken Authen4ca4on and Session Management
Malicious File Execu4on Broken Authen4ca4on and Session Management Cross-‐Site Scrip4ng (XSS)
Cross Site Scrip4ng (XSS) Flaws
Insecure Direct Object Reference
Insecure Direct Object References
Insecure Direct Object References
Buffer Overflows Cross Site Request Forgery (CSRF)*
Cross-‐Site Request Forgery (CSRF) Security Misconfigura4on
Injec4on Flaws Informa4on Leakage and Improper Error Handling Security Misconfigura4on Sensi4ve Data Exposure
Improper Error Handling Broken Authen4ca4on and Session Management
Insecure Cryptographic Storage
Missing Func4on Level Access Control
Insecure Storage Insecure Cryptographic Storage
Failure to Restrict URL Access
Cross-‐Site Request Forgery (CSRF)
Denial of Service Insecure Communica4ons Insufficient Transport Layer Protec4on
Using Known Vulnerable Components
Insecure Configura4on Management
Failure to Restrict URL Access
Unvalidated Redirects and Forwards
Unvalidated Redirects and Forwards
morale?
E’ stata compromessa (almeno per la terza volta
negli ulBmi anni) l’azienda di Telecomunicazioni Pakistana,
controllata dallo stato, tramite una SQL Injec4on
Cosa dicono i trend sulla sicurezza?
“gli aZaccanB tendono a sfruZare vulnerabilità che sono presenB a causa di pra4che di
sicurezza basilari inadeguate” — Rapporto Melani
Database e interrogazioni
Cosa sono i database relazionali?
I database o basi di daB sono degli archivi organizzaB tramite delle relazioni. I daB sono contenuB all’interno di alcune tabelle che hanno delle intestazioni (campi) in cui i daB sono organizzaB in delle righe (o record).
Cos’è SQL?
SQL (Structured Query Language) è un linguaggio struZurato per eseguire
interrogazioni a un database relazionale. Possiamo avere una serie di query esempio per richiedere dei daB (SELECT), inserirli (INSERT), aggiornarli (UPDATE) e cancellarli (DELETE).
Altri 4pi di query servono per creare o cancellare database, utenB, tabelle o sono comandi come es. per spegnere il database.
Logica booleana
Le query si basano sulla logica booleana, ripassiamo brevemente l’OR e l’AND:
Perchè devo sapere queste cose?
Per eseguire delle SQL InjecBon è necessaria una conoscenza approfondita di SQL, dei
database e più nello specifico del linguaggio supportato dal database uBlizzato
dall’applicazione che sBamo aZaccando.
Come a;accare con le SQL Injec4on
Authen4ca4on bypass
Authen4ca4on Bypass by SQL Injec4on
• E’ un Bpico aZacco “vecchio sBle”. • Non è ovviamente sempre possibile, dipende da come è scriZa la query che verifica l’autenBcazione.
• L’impaZo è estremamente criBco, è infa` possibile personificare gli utenB.
Come funziona?
• AnzituZo è fondamentale capire la query che è “dietro” la richiesta.
• Tipicamente la pagina di login è qualche cosa come: • SELECT * FROM users WHERE use_name = ‘simone’ AND use_password = “pwd”;
• Che cerca una corrispondenza tra il nome utente e la password inserita tramite GET/POST.
• Se inseriamo quindi come username: • simone’—
• La query sarà: • SELECT * FROM users WHERE use_name = ‘simone’— ‘AND use_password = “pwd”
• Quindi viene verificato solo se l’utente esiste o meno.
Come funziona?
• Se però non conosciamo lo username, al neZo di quelli Bpici come “admin”, “administrator”, o se si uBlizza 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 tuZo il contenuto della tabella users trovando sicuramente almeno una corrispondenza.
Avvertenze
• A;enzione: quando fate le prove con OR 1=1, se ci sono molB record nella tabella è possibile che il server impieghi molto tempo a rispondere, oppure potrebbe andare in Bmeout, è consigliabile uBlizzare una strategia del Bpo 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 (MALE), quando si cerca il bypass infa` è più probabile trovare una SQL InjecBon nello username.
• Perché tuZo questo probabile? Ogni applicazione è diversa.
Probing
Quando si verificano le SQL Injec4on
Le vulnerabilità di Bpo InjecBon si verificano quando da4 non valida4 vengono inviaB come parte di una richiesta verso un interprete, permeZendo di eseguire richieste o comandi
normalmente non previsB dall’applicazione. L’impaZo di queste vulnerabilità è spesso alto e permeZe di
compromeZere il sistema o i daB.
Consigli sulle SQL Injec4on
•Fai il reverse engineering della query •Capisci il linguaggio dell’interprete •Comprendi la logica •Sii creaBvo/a
Passo dopo passo (come ispirazione)
1.Verifica il Bpo di dato che l’applicazione si aspeZa (es. numero, stringa, data, uuid ecc..). 2.Cerca di capire e “rompere” la query uBlizzando caraZeri Bpici dei delimitatori (es. ‘, ’’, “), numeri posiBvi e negaBvi, aZenzione ai LIKE e alle date. 3.IdenBfica le differenze nelle risposte (es. daB caricaB, errori, pagine bianche).
Esempio
•Applicazione che visualizza le noBzie: •hZp://www.example.com/news.php?id=123
•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 aZenzione ai DoS •AND 1=1— e AND 1=0— valutando la differenza nelle risposte
•Dato che è un numero supponiamo non siano necessarie delle parentesi, ma dobbiamo considerare che se la query è complessa possiamo lasciare aperte es. delle parentesi.
Fingerprin4ng/Reverse
Engineering
Fingerprin4ng e Reverse Engineering
Una volta idenBficata la presenza potenziale di una SQL InjecBon è necessario verificarla e quindi sfruZarla. E’ di cruciale importanza capire almeno: •Il 4po di dato che sBamo manipolando •Il 4po di query dove siamo dentro •Dove siamo nella query •Il Bpo di database
Capire il 4po di dato
•Lo possiamo valutare navigando nell’applicazione e vedendo quali sono i daB che normalmente l’applicazione si aspeZa, Bpicamente:
•Numeri •Stringhe •Date •IdenBficaBvi
Capire il 4po di query
Anche in questo caso il contesto applicaBvo è importante. SBamo: •Visualizzando dei daB? > SELECT •Modificando/Aggiornando dei daB? > UPDATE •Cancellando dei daB? > DELETE A"enzione a query mul0ple eseguite dalla stessa pagina
Capire dove siamo nella query
Consideriamo sempre che possiamo essere in più punB della query, quindi la nostra manipolazione può avere effe`
differenB.
SELECT * FROM tabella WHERE campo = valore ORDER BY campo
Capire il 4po di database
Passo non poco difficile è capire il Bpo di database (es. Microsow, Oracle, Postgre, DB2…) e la sua versione specifica, in quanto alcune funzionalità sono previste solo per determinate 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_RECEIVED-‐@@PACK_RECEIVED • MySQL: CONNECTION_ID()-‐CONNECTION_ID()
• Commen4 di MySQL: • Se MySQL trova questo commento /*!32302 and 1=0*/ lo eseguirà solo se la sua versione è maggiore o uguale alla 3.23.02
Exploi4ng
Come sfru;are le vulnerabilità
Una volta oZenute le informazioni sulla query e sul database possiamo procedere con lo sfruZamento. E’ possibile uBlizzare differenB 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 capendo quando l’applicazione: •Esegue il nostro codice, inserendo delle condizioni di vero o falso (seleziona solo alcuni daB) •La query non è correZa (es. WSOD)
Errori 4pici
•ORA-‐01756: quoted string not properly terminated •You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near ‘' •Error: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ''' at line •Unclosed quotaBon mark awer the character string ''.
La tecnica UNION
•La UNION è una delle tecniche più comuni per l’estrazione di daB. •L’operatore UNION è uBlizzato per combinare i risultaB di più query: la prima è quella inclusa dall’applicazione, la seconda è quella da cui vogliamo estrarre i daB. •Quando facciamo una UNION dobbiamo considerare che:
•Le due query devono avere lo stesso numero di colonne (es. ORA-‐01789: query block has incorrect number of result columns) •Le colonne nella stessa posizione devono essere dello stesso Bpo o uno compaBbile. (es. ORA-‐01790: expression must have same datatype as corresponding expression). NULL è spesso nostro amico •Dobbiamo conoscere almeno il nome di una tabella (ecco anche perchè facciamo il fingerprinBng).
Come fare?
•Trova il nome di una tabella che esiste e cui hai accesso (es. DUAL in Oracle o anche nulla in MS-‐SQL) •Capisci il numero di colonne:
•‘ UNION SELECT NULL— •‘ UNION SELECT NULL, NULL— •‘ UNION SELECT NULL, NULL, NULL—
•Trova almeno un Bpo di dato come stringa •‘ UNION SELECT ‘a’, NULL, NULL—
•Estrai le informazioni •UNION SELECT banner, NULL, NULL from v$version
Tool automa4ci
Strumen4 automa4ci
•Esistono numerosi strumenB automaBci tramite i quali è possibile idenBficare e sfruZare le SQL InjecBon. •E’ bene comunque imparare a sfruZarle a mano! •Non sempre gli strumenB automaBci 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 sfruZare la vulnerabilità.
Sqlmap
•Sqlmap è uno dei più potenB strumenB per le SQL InjecBon, consideriamo il nostro target testasp. •Scaricare: hZp://sqlmap.org/ •Lanciare:
•python sqlmap.py -‐u “hBp://testasp.vulnweb.com/showthread.asp?id=1" •python sqlmap.py -‐u "hBp://testasp.vulnweb.com/showthread.asp?id=1" -‐-‐users •python sqlmap.py -‐u "hBp://testasp.vulnweb.com/showthread.asp?id=1" -‐-‐passwords •python sqlmap.py -‐u "hBp://testasp.vulnweb.com/showthread.asp?id=1" -‐-‐dbs
Difendersi dalle SQL Injec4on
A;acco
Vulnerabilità
<?php
// parameters
$author = $_GET['author'];
$sql_inline = "SELECT * FROM blogs_table WHERE blogger_name = '$author'";
$res = $dbh->query($sql_inline);
?>
Contromisura
<?php
// parameters
$author = $_GET['author'];
$sql_prep = "SELECT * FROM blogs_table WHERE blogger_name = ?";
$res = $dbh->prepare($sql_prep);
$res->bindParam(1, $author, PDO::PARAM_STR, 16);
$res->execute();
?>
Suggerimen4
E’ possibile miBgare questa vulnerabilità uBlizzando API parametriche per interfacciarsi agli interpreB oppure regole di validazione a whitelist per verificare il dato. Inoltre, prima della validazione, bisogna eseguire una normalizzazione (canonicalizaBon) e codificare correZamente il dato (encoding), quindi applicare le regole specifiche dell’interprete per gesBre i cara;eri speciali (escaping), come ad esempio:
•CaraZeri per la delimitazione delle stringhe (es. ‘ “ )
•CaraZeri o sequenze intepretate (es. % -‐-‐ # /*) •Operatori o funzioni (es. AND OR NOT SLEEP || CHR +)
FAQ
Frequently Asked Ques4ons
• I database NoSQL sono vulnerabili? Si
• Esistono altri Bpi di InjecBon? Si es. LDAP, ORM, XML InjecRon, XXE, SSI, XPath, XQuery, SPARQL, IMAP/SMTP, Code, Command
• Se uso il framework X sono invulnerabile? No, dipende da come si usa
• Come posso prevenire? Query parametriche*, validazione whitelist/blacklist*
• Un Web ApplicaBon Firewall mi protegge? Ni*
• Su una Web App HTML5 posso avere SQL InjecBon? Si, se si usano i Web Database
• Come si fa la SQL InjecBon sul database X? (dove X è il tuo database)Leggi il manuale e trova le funzioni del database (e versione) specifica
Q&A e Conclusioni
Mobile App
GRAZIE!
;-‐)http://onofri.org/ http://twitter.com/simoneonofri http://it.linkedin.com/simoneonofri http://slideshare.net/simoneonofri
DOMANDE
?http://onofri.org/ http://twitter.com/simoneonofri http://it.linkedin.com/simoneonofri http://slideshare.net/simoneonofri