TechDay: Hackers vs. Developers - Le SQL Injection - Simone Onofri
•
4 recomendaciones•1,060 vistas
Codemotion Training: l'intervento di Simone Onofri al Tech Day del 21 gennaio 2015. Email: training@codemotion.it Twitter: @CodemotionTR
Recomendados
Recomendados
Más contenido relacionado
Similar a TechDay: Hackers vs. Developers - Le SQL Injection - Simone Onofri
Similar a TechDay: Hackers vs. Developers - Le SQL Injection - Simone Onofri (20)
Más de Codemotion
Más de Codemotion (20)
TechDay: Hackers vs. Developers - Le SQL Injection - Simone Onofri
- 1. Hackers vs Developers Le SQL Injec4on Simone Onofri -‐ Techub S.p.A. v0.1
- 2. Introduzione
- 5. Agenda • Introduzione • Breve Storia della SQL Injec4on • Come a;accare • Come difendersi • Q&A e Conclusioni
- 6. Breve storia della SQL Injec4on
- 7. 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).
- 8. 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
- 9. 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
- 10. 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
- 11. 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
- 12. morale?
- 13. E’ stata compromessa (almeno per la terza volta negli ulBmi anni) l’azienda di Telecomunicazioni Pakistana, controllata dallo stato, tramite una SQL Injec4on
- 14. 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
- 16. 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).
- 17. 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.
- 18. Logica booleana Le query si basano sulla logica booleana, ripassiamo brevemente l’OR e l’AND:
- 19. 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.
- 20. Come a;accare con le SQL Injec4on
- 22. 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.
- 23. 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.
- 24. 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.
- 25. 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.
- 26. Probing
- 27. 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.
- 28. Consigli sulle SQL Injec4on •Fai il reverse engineering della query •Capisci il linguaggio dell’interprete •Comprendi la logica •Sii creaBvo/a
- 29. 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).
- 30. 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.
- 32. 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
- 33. 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
- 34. 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
- 35. 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
- 36. 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
- 37. Exploi4ng
- 38. 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)
- 39. 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 ''.
- 40. 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).
- 41. 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
- 42. Tool automa4ci
- 43. 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à.
- 44. 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
- 45. Difendersi dalle SQL Injec4on
- 46. A;acco
- 47. Vulnerabilità <?php // parameters $author = $_GET['author']; $sql_inline = "SELECT * FROM blogs_table WHERE blogger_name = '$author'"; $res = $dbh->query($sql_inline); ?>
- 48. 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(); ?>
- 49. 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 +)
- 51. FAQ
- 52. 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
- 54. Mobile App