Hackers vs Developers - SQL Injection - Attacco e Difesa
•
1 gefällt mir•1,174 views
Le SQL Injection, come attaccarsi e difendersi da questo tipo di vulnerabilità.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Andere mochten auch
Andere mochten auch (20)
Ähnlich wie Hackers vs Developers - SQL Injection - Attacco e Difesa
Ähnlich wie Hackers vs Developers - SQL Injection - Attacco e Difesa (20)
Mehr von Simone Onofri
Mehr von Simone Onofri (14)
Hackers vs Developers - SQL Injection - Attacco e Difesa
- 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 • FAQ, Q&A e Conclusioni
- 6. Breve storia della SQL Injec4on
- 7. Web e SQL Injec4on Tecnicamente le prime SQL InjecDon hanno cominciato ad essere presenD sul web da quando i vari interpreD hanno permesso alle pagine web di mostrare daD collegandosi ai database e quindi mostrarne i daD. Pensiamo a PHP (1995) e ad ASP (1996).
- 8. La prima famosa SQL Injec4on Risale al 1998 da un arDcolo firmato da Rain Forest Puppy su Phrack “NT Web Technology VulnerabiliDes” che conDene 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 sDamo 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 ulDmi anni) l’azienda di Telecomunicazioni Pakistana, controllata dallo stato, tramite una SQL Injec4on
- 14. Cosa dicono i trend sulla sicurezza? “gli aZaccanD tendono a sfruZare vulnerabilità che sono presenD a causa di pra4che di sicurezza basilari inadeguate” — Rapporto Melani
- 16. Cosa sono i database relazionali? I database o basi di daD sono degli archivi organizzaD tramite delle relazioni. I daD sono contenuD all’interno di alcune tabelle che hanno delle intestazioni (campi) in cui i daD sono organizzaD 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 daD (SELECT), inserirli (INSERT), aggiornarli (UPDATE) e cancellarli (DELETE). Altri 4pi di query servono per creare o cancellare database, utenD, 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 InjecDon è necessaria una conoscenza approfondita di SQL, dei database e più nello specifico del linguaggio supportato dal database uDlizzato dall’applicazione che sDamo aZaccando.
- 20. Come a;accare con le SQL Injec4on
- 22. Authen4ca4on Bypass by SQL Injec4on • E’ un Dpico aZacco “vecchio sDle”. • Non è ovviamente sempre possibile, dipende da come è scriZa la query che verifica l’autenDcazione. • L’impaZo è estremamente criDco, è infa` possibile personificare gli utenD.
- 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 Dpici come “admin”, “administrator”, o se si uDlizza 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 molD record nella tabella è possibile che il server impieghi molto tempo a rispondere, oppure potrebbe andare in Dmeout, è consigliabile uDlizzare una strategia del Dpo 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 InjecDon nello username. • Perché tuZo questo probabile? Ogni applicazione è diversa.
- 26. Probing
- 27. Quando si verificano le SQL Injec4on Le vulnerabilità di Dpo InjecDon si verificano quando da4 non valida4 vengono inviaD come parte di una richiesta verso un interprete, permeZendo di eseguire richieste o comandi normalmente non previsD dall’applicazione. L’impaZo di queste vulnerabilità è spesso alto e permeZe di compromeZere il sistema o i daD.
- 28. Consigli sulle SQL Injec4on •Fai il reverse engineering della query •Capisci il linguaggio dell’interprete •Comprendi la logica •Sii creaDvo/a
- 29. Passo dopo passo (come ispirazione) 1.Verifica il Dpo di dato che l’applicazione si aspeZa (es. numero, stringa, data, uuid ecc..). 2.Cerca di capire e “rompere” la query uDlizzando caraZeri Dpici dei delimitatori (es. ‘, ’’, “), numeri posiDvi e negaDvi, aZenzione ai LIKE e alle date. 3.IdenDfica le differenze nelle risposte (es. daD caricaD, errori, pagine bianche).
- 30. Esempio •Applicazione che visualizza le noDzie: •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 idenDficata la presenza potenziale di una SQL InjecDon è necessario verificarla e quindi sfruZarla. E’ di cruciale importanza capire almeno: •Il 4po di dato che sDamo manipolando •Il 4po di query dove siamo dentro •Dove siamo nella query •Il Dpo di database
- 33. Capire il 4po di dato •Lo possiamo valutare navigando nell’applicazione e vedendo quali sono i daD che normalmente l’applicazione si aspeZa, Dpicamente: •Numeri •Stringhe •Date •IdenDficaDvi
- 34. Capire il 4po di query Anche in questo caso il contesto applicaDvo è importante. SDamo: •Visualizzando dei daD? > SELECT •Modificando/Aggiornando dei daD? > UPDATE •Cancellando dei daD? > DELETE A"enzione a query mul0ple eseguite dalla stessa pagina
- 35. Capire dove siamo nella query Consideriamo sempre che possiamo essere in più punD della query, quindi la nostra manipolazione può avere effe` differenD. SELECT * FROM tabella WHERE campo = valore ORDER BY campo
- 36. Capire il 4po di database Passo non poco difficile è capire il Dpo 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 uDlizzare differenD 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 daD) •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 quotaDon mark awer the character string ''.
- 40. La tecnica UNION •La UNION è una delle tecniche più comuni per l’estrazione di daD. •L’operatore UNION è uDlizzato per combinare i risultaD di più query: la prima è quella inclusa dall’applicazione, la seconda è quella da cui vogliamo estrarre i daD. •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 Dpo o uno compaDbile. (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 fingerprinDng).
- 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 Dpo 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 strumenD automaDci tramite i quali è possibile idenDficare e sfruZare le SQL InjecDon. •E’ bene comunque imparare a sfruZarle a mano! •Non sempre gli strumenD automaDci 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ù potenD strumenD per le SQL InjecDon, 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 miDgare questa vulnerabilità uDlizzando API parametriche per interfacciarsi agli interpreD oppure regole di validazione a whitelist per verificare il dato. Inoltre, prima della validazione, bisogna eseguire una normalizzazione (canonicalizaDon) e codificare correZamente il dato (encoding), quindi applicare le regole specifiche dell’interprete per gesDre 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 Dpi di InjecDon? 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 ApplicaDon Firewall mi protegge? Ni* • Su una Web App HTML5 posso avere SQL InjecDon? Si, se si usano i Web Database • Come si fa la SQL InjecDon sul database X? (dove X è il tuo database) Leggi il manuale e trova le funzioni del database (e versione) specifica
- 54. Mobile App