1 / 34

SQLrand: Preventing SQL Injection Attacks

Seminario AVP a.a. 2006/2007:. SQLrand: Preventing SQL Injection Attacks. Stephen W. Boyd & Angelos D. Keromytis. Columbia University. Elia Gaglio 809477 & Mirco Tonin 804425. code injection attacks. sql injection attacks. Code injection attacks.

tyrell
Download Presentation

SQLrand: Preventing SQL Injection Attacks

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Seminario AVP a.a. 2006/2007: SQLrand: Preventing SQL Injection Attacks Stephen W. Boyd & Angelos D. Keromytis Columbia University Elia Gaglio 809477 & Mirco Tonin 804425

  2. code injection attacks sql injection attacks Code injection attacks • “SQL injection attack”è un’istanza dei code injection attacks • Code injection attacks: classe di attacchi che sfruttano il buffer overflow • analisi di un attacco basato sul buffer overflow: • definizione informale: un buffer overflow si verifica ogni qual volta l’insieme dei dati è più grande del buffer ove dovranno essere memorizzati • conseguenza: sovrascrittura della porzione di memoria successiva al buffer, contenente istruzioni macchina necessarie ad una normale esecuzione del programma

  3. Buffer Overflow (1/3) • Contesto fondamentale per il verificarsi di un BOF: chiamata ad una funzione • Esempio. Consideriamo il seguente scenario: • architettura Intel x86 (32 bits): • registri, salvati nello stack, coinvolti nel BOF: • EBP (Base Pointer)(4 bytes): puntatore alla base della porzione dello stack che stiamo utilizzando • EIP (Instruction Pointer) (4 bytes): puntatore all’istruzione successiva • crescita dello stack verso indirizzi bassi di memoria • “buff”: buffer di 8 caratteri (8 bytes) • chiamata alla funzione del C, gets: legge dallo standard input, copia quanto letto in “buff” senza fare nessun controllo se la stringa inserita sia più grande del buffer di destinazione OBIETTIVO: sfruttare gets per sovrascrivere i registri EBP e EIP salvati sullo stack, alterando così il normale flusso di esecuzione del programma l’attaccante deve conoscere l’architettura del sistema target

  4. . buff[0]: 1 1 byte . buff[1]: 2 buff[2]: 3 buff[3]: 4 riempimento dello stack buff[4]: 5 buff[5]: 6 buff[6]: 7 buff[7]: 8 4 bytes buffer overflow stringa in input: 12345678aaaabbbb 0x61616161 0x62626262 Buffer Overflow (2/3) (animata) 0x00000000 programma C: assembler: • 1. void leggistringa(void){ • 2. char buff[8]; • 3. gets(buff); • 4. } • 5. • 6. int main(void){ • 7. leggistringa(); • return(0); • 9. } 00401258 push ebp 00401250 call 00401258 00401255 ………… . EBP aaaa: 61616161 EIP: 00401255 bbbb: 62626262 indirizzi alti All’uscita della funzione, avremo che EIP=0x62626262EBP=0x61616161

  5. code injection attack Buffer Overflow (3/3) • Cosa succede? • La cpu tenterà di eseguire l’istruzione che si trova all’indirizzo contenuto nel registro EIP ovvero 0x62626262, incorrendo in uno di questi casi: • il numero esadecimale 0x62626262 rappresenta un indirizzo che va fuori dall’intero spazio di memoria dedicato al processo segmentation fault • 0x62626262 è un indirizzo valido per il processo in esecuzione. Tale indirizzo potrebbe puntare a del codice maligno inserito da un attaccante

  6. code injection attacks sql injection attacks unix shell commands Perl code injection Contromisura: ISR • all’interno dei code injection attacks, ricadono alcuni tipi di attacchi recenti e poco conosciuti: • SQL injection • Unix command line • Perl code injection • sebbene le tecniche usate in ogni tipo d’attacco differiscono tra loro, tutte hanno un denominatore comune: • l’attaccante inserisce e fa eseguire codice di sua scelta: codice macchina, shell commands, SQL queries,… • da tale fatto, si ricava che alla base di ogni code injection attack c’è la conoscenza da parte dell’attaccante circa l’ambiente / linguaggio interpretato di programmazione del sistema target • contromisura: un approccio generale di prevenzione verso qualsiasi code injection attack: Instruction-Set Randomization

  7. applicazione del metodo ISR al linguaggio SQL nostro articolo Un pò di storia… • inquadramento storico: • anno 2003 Columbia University : • Countering Code-Injection Attacks With Instruction-Set Randomization Gaurav S. Kc, Angelos D. Keromytis, Vassilis Prevelakis • anno 2004 Columbia University: • SQLrand: Preventing SQL Injection Attacks Stephen W. Boyd, Angelos D. Keromytis

  8. ENCODINGKEY ENCODED INSTRUCTION STREAM CPU xor decoded instruction stream Instruction-Set Randomization • per ogni processo, attraverso una chiave di codifica la più grande possibile, viene creato un insieme unico di istruzioni randomizzate • tali nuove istruzioni andranno a sostituire il codice sorgente del programma originale • verrà creato un ambiente di esecuzione unico per il running process così che l’attaccante non conosce il “linguaggio” usato e di conseguenza non puo’ “speak” alla macchina (non conosce la key di randomizzazione) • due alternativi approcci nell’uso della chiave per la codifica/decodifica (architettura x86 a 32 bits): • XOR bit a bit tra istruzione e chiave: D xor KEY = E E xor KEY= D (codifica e decodifica hanno la stessa chiave) attacco brute force: 232 • trasposizione randomizzata (basata sulla chiave) dei bit: (la chiave di decodifica sarà l’inversa) attacco brute force: 32! ( 32! >> 232) => sicurezza maggiore • in ogni caso, una chiave di 32 bits è sufficiente per una protezione verso attacchi di code injection

  9. ram SO CPU PCB: registers: GAVL P efP DkeyP Esecuzione di un randomized program • ISR è focalizzato primariamente su attacchi contro remote services (http, dns,…): attacchi che non richiedono un local account sul sistema target • Esecuzione di un generico programma: • il codice di ciascun processo (P) è caricato dal rispettivo file eseguibile memorizzato su disco (efP) • tale ‘executable file’ contiene all’interno dell’header, l’appropriata chiave di decodifica (DkeyP) del processo caricato in memoria • nel frattempo, il sistema operativo estrae la chiave di decodifica dall’header dell’eseguibile e la memorizza nel rispettivo Process Control Block del processo • quando la cpu eseguirà il processo P, la chiave di decodifica (DkeyP) sarà presa dal PCB e copiata in un speciale registro del processore • ciò avviene attraverso un’istruzione privilegiata GAVL che permette un accesso in sola scrittura nel speciale registro di CPU. DkeyP DkeyP disco

  10. Ambiente di esecuzione (1/2) • per quei programmi che non sono stati randomizzati, viene fornita una speciale chiave (chiave nulla), che quando caricata attraverso l’istruzione GAVL, disabilita il processo di decodifica • l’esecuzione delle randomization instructions, necessita della scelta tra due possibili soluzioni: l’introduzione di un ambiente di esecuzione protetto che emuli una CPU convenzionale l’utilizzo di una apposita categoria di processori programmabili (e.g. TransMeta Crusoe, alcuni ARM-based systems) • sandboxing environment sarà composto da: • un CPU emulator: bochs (emulatore open source architetture x86) • sistema operativo • l’insieme di processi che si vuole proteggere

  11. Performance • risultati sperimentali: tempo di esecuzione (in secondi) per identici file binari su Bochs e una macchina Linux (sulla quale è stato fatto girare bochs) • ftp & sendmail (processi I/O intensive): • una perdita contenuta nelle performance • fibonacci (CPU intensive application): • tremendo slowdown (inaccettabile)

  12. ISR su altri linguaggi (1/2) • Le idee e i concetti, introdotti al fine di ottenere un’esecuzione sicura delle istruzioni macchina, sono state estese per garantire la sicurezza d’esecuzione di diverse tipologie di programmi: • Perl files: • utilizzo dello script Perltidy: • input: ns. programma perl P foreach $k (sort keys %$tre){ $v = $tre ->{$k}; die ``duplicate key $k\n’ ’ if defined $list {$k}; push @list, @{ $list{$k} }; } • output: programma P’, dove ad ogni costrutto perl in P è stata appesa la chiave (‘tag’) foreach123456789 $k (sort123456789 keys %$tre){ $v =123456789 $tre ->{$k}; die123456789 ``duplicate key $k\n’ ’ if123456789 defined123456789 $list {$k}; push123456789 @list, @{ $list{$k} }; } • la chiave (‘tag’) viene fornita via a command line argument • è necessario una modifica dell’analizzatore lessicale dell’interprete Perl, affinchè possa riconoscere le keywords seguite dal corretto ‘tag’

  13. ISR su altri linguaggi (2/2) • Script Unix: • utilizzo di uno script CGI per la generazione di randomized bash scripts • ogni shell command dello script unix avrà in append la chiave di randomizzazione (‘tag’) • l’interprete bash dovrà essere modificato al fine di riconoscere le nuove keywords (commad+tag) #!/bin/sh if987654 [ x$1 ==987654 x””; then987654 echo987654 “Must provide directory name.” exit987654 1 fi987654 /bin/ls987654 –l $1 exit987654 0

  14. SQL Injection Attacks: • SQL Injection Attacks: • SQL Injection Attacks è un code injection attack verso un DB… • Attacchi orientati verso script CGI che creano dinamicamente query SQL • OBIETTIVO: carpire/modificare/inserire informazioni verso un DB interfacciato da una web application • Diverse tipologie di attacco possibile, le quali sfruttano vulnerabilità differenti…

  15. Esempi di SQL Injection Attacks [1/5] • CONTESTO: pagina di login ad un servizio web, realizzata mediante un’applicazione CGI (si richiedono username e password) • Nel momento in cui l’utente inserisce i dati viene generata la query: “select * from mysql.user where username = ’ ” . $uid . ” ’ and password = password(’ ” . $pwd . ” ’);” • Un eventuale utente maligno inserendo nel campo username la stringa ‘or 1=1; --’causa la generazione da parte dello script della query: “select * from mysql.user where username = ’ ’ or 1=1; --’ ’ and password = password(’_any_text_’);”

  16. Esempi di SQL Injection Attacks [2/5] (animata) • CONTESTO: applicazione ASP che si interfaccia tramite driver ODBC SQL Server Driver ad un generico DBMS • Esiste la possibilità di attaccare il DB sfruttando i messaggi di errore forniti: • Se l’utente inserisse un username fasullo aaa’ verrebbe invocata la URL: • http://127.0.0.1/login.asp?userid=aaa‘ • L’apice finale porterebbe però al seguente messaggio di errore: • Microsoft OLE DB Provider for ODBC Drivers error '80040e14' • [Microsoft][ODBC SQL Server Driver][SQL Server]Unclosed quotation mark before the character string 'aaa' AND password = ''. • /login.asp, line 7 password

  17. Esempi di SQL Injection Attacks [3/5] (animata) • Si può sfruttare la conoscenza acquisita per invocare una nuova URL fittizia in modo da ottenere il nome delle colonne di una tabella: • http://127.0.0.1/login.asp?userid=ddd'%20group%20by%20(password)-- • Microsoft OLE DB Provider for ODBC Drivers error '80040e14' • [Microsoft][ODBC SQL Server Driver][SQL Server]Column 'tblUsers.username' is invalid in the select list because it is not contained in either an aggregate function or the GROUP BY clause. • /login.asp, line 7 tblUsers username password • Il procedimento prosegue fino a quando tutti i nomi delle colonne sono scoperti…

  18. Esempi di SQL Injection Attacks [4/5] (animata) • http://127.0.0.1/login.asp?userid=aaa'%20group%20by%20(username)-- • Microsoft OLE DB Provider for ODBC Drivers error '80040e14' • [Microsoft][ODBC SQL Server Driver][SQL Server]Column 'tblUsers.lastloggedin' is invalid in the select list because it is not contained in either an aggregate function or the GROUP BY clause. • /login.asp, line 7 • E’ anche possibile determinare il tipo relativo a ciascuna colonna della tabella: • http://127.0.0.1/login.asp?userid=aaa'%20compute%20sum(username)-- • Microsoft OLE DB Provider for ODBC Drivers error '80040e07' • [Microsoft][ODBC SQL Server Driver][SQL Server]The sum or average aggregate operation cannot take a nvarchar data type as an argument. • /login.asp, line 7 tblUsers lastloggedin username password nvarchar

  19. Esempi di SQL Injection Attacks [5/5] (animata) • Dopo aver a disposizione la struttura della tabella sarà possibile da parte dell’attaccante inserire un nuovo account fasullo nel DB: • http://127.0.0.1/login.asp?userid=aaa' insert into tblusers(username,password,lastloggedin,status) values ('jsmith','secret','Oct 31 2000 8:52PM','foo')-- tblUsers status lastloggedin username password nvarchar nvarchar nvarchar date secret jsmith Oct 31 2000 8:52PM foo

  20. SQL Injection Attacks – alcune soluzioni • Come si possono fronteggiare gli SQL Injection Attacks? • Accorgimenti per aumentare la sicurezza dell’applicazione (uso di caratteri di escape, filtraggio dei messaggi di errore, limitare la lunghezza dei campi di input, ecc.); • Utilizzo di costrutti “safe” (es. Prepared statement): • Libreria per la gestione in automatico della formattazione dei tipi rappresentabili nel DBMS (stringhe, date, ecc.) • Garantisce una sicurezza sull’esatta sintassi della query SQL risultante PreparedStatement ps = conn.prepareStatement (“SELECT * FROM mysql.user WHERE username = ? AND password = ?”); String user = req.getParameter(“userid”); String pwd = req.getParameter(“password”); ps.setString(1, user); ps.setString(2, pwd); ResultSet rs = ps.executeQuery();

  21. SQL Injection Attacks – SQL Randomization [1/6] • Si possono inoltre utilizzare delle tecniche specializzate molto interessanti, SQL Randomization: • Soluzione efficace per fronteggiare SQL Injection Attacks • Tecniche e principi derivati dall’ Instruction Set Randomization • Query randomizzate prodotte dallo script CGI • SQL Randomization • Necessità di modificare l’interprete SQL del DB (in analogia all’approccio seguito per ISR) • introduzione di un ling. sql modificato • riscrittura dei precedenti programmi • Possibilità di usare: • una key per ogni applicazione • keys differenti per applicazioni differenti • Introduzione di un proxy per effettuare la de-randomizzazione delle query

  22. SQL Injection Attacks – SQL Randomizations [2/6] • Introduzione di un proxy per de-randomizzare le query prodotte lato client: • In questo modo le query prodotte lato client saranno comprensibili dall’interprete SQL del DB • Il proxy lavora esclusivamente a livello sintattico, effettuando anche il filtraggio dei messaggi di errore provenienti dal DB

  23. SQL Injection Attacks – SQL Randomizations [3/6] • Le 2 principali componenti del proxy sono: • 1) Elemento di de-randomizzazione: • presenza di un parser FLEX modificato (legge un array di caratteri di input in arrivo dalla rete) • trattamento esplicito per gli errori sintattici (disconnessione del client ed • invio di un generico messaggio di sintax error) • 2) Protocollo di comunicazione: • MYSQL fornisce API per l’accesso al DB ma non fornisce librerie server- • side che accettano e disassemblano i pacchetti inviati • Utilizzo di una libreria di base per gestire query, errori e pacchetti di • disconnessione

  24. SQL Injection Attacks – SQL Randomizations [4/6] (animata) • La soluzione finale proposta per gestire le comunicazioni è la seguente: api mysql LATO CLIENT api mysql LATO CLIENT PROXY MYSQL DBMS CLIENT C S C S Libreria: gestisce query, errori e pacchetti di disconnessione • Proxy componente invisibile verso il client • proxy e DBMS sono sulla stessa macchina • (è necessario solamente specificare la porta relativa al proxy)

  25. SQL Injection Attacks – SQL Randomizations [5/6] • Vediamo un semplice esempio pratico di randomizzazione. Partiamo dalla seguente query: select gender, avg (age) from cs101.students where dept = %d group by gender • La randomizzazione è basata sull’append di una sequenza di interi random applicata alle keywords di ogni query. Nel nostro esempio: select123 gender, avg123 (age) from123 cs101.students where123 dept = %d group123 by123 gender

  26. SQL Injection Attacks – SQL Randomizations [6/6] • A questo punto se un utente maligno volesse formulare un tipico attacco mediante l’inserimento della stringa ’ or 1=1; --’ causerebbe la generazione della query: select gender, avg (age) from cs101.students where dept = ’ or 1=1; --’ group by gender • La randomizzazione della query comporta che ogni keyword del linguaggio SQL sia randomizzata. Ma la or, essendo una parola dell’input utente, non è soggetta a randomizzazione  la query viene considerata maligna! select123 gender, avg123 (age) from123 cs101.students where123 dept = ’ or 1=1; --’ group123 by123 gender

  27. Prove sperimentali • Sono state effettuate due tipologie di test: • un’applicazione CGI creata (ad hoc) dagli autori stessi: • nessuna validazione sull’input • possibilità di inserire codice SQL nella clausola “where” che si aspetta un account ID • senza SQLrand proxy: un attaccante facilmente ottiene informazini sugli account degli utenti • con SQLrand proxy: injected statement identificato ed emissione di un generico messaggio d’errore • identificare SQL injection attacks su applicazioni web pre-esistenti e molto diffuse: • phpBB v2.0.5 • php-Nuke attacchi neutralizzati con l’uso del proxy

  28. Performance evaluation • Scenario di test: • 3 insiemi di utenti concorrenti: 10 - 25 - 50 • esecuzione delle classi in modo round robin • in totale 100 prove: ciascuna con 5 differenti query concorrenti • lunghezza chiave: 32 bytes • lunghezza media queries: 639 bytes • la dimensione dei record delle tabelle ranged da 20 a poco piùdi 11.000 records • database, proxy e client running su separate macchine x86 con SO RedHat Linux, e tutte sulla stessa rete proxy overhead (in microsecondi) • Nel peggior dei casi, si ottiene un ritardo di 6.5 millisecondi per ciascuna query • sapendo che se intercorre un tempo che varia da pochi secondi a 10 secondi (a seconda dello scopo dell’applicazione) la risposta di una web application è considerata persa l’overhead introdotto dal proxy è insignificante • future work: sviluppo di developing tools per assistere i programmatori nell’utilizzo di SQLrand

  29. ISR: vantaggi - svantaggi • riportandoci al contesto più generale: Instruction-Set Randomization • Vantaggi: • possibile ri-randomizzazione periodica dei programmi in modo da minimizzare il rischio di attacchi persistenti. Ovvero: • nei sistemi operativi open source: quando il sistema viene ricompilato • nelle distribuzioni binarie: periodica re-randomization attraverso un automated script • in fase d’installazione • ISR offre trasparenza ad applicazioni, linguaggi e compilatori, nessuno dei quali deve essere modificato • Svantaggi: • l’utilizzo di cpu programmabili per il supporto di istruzioni randomizzate • feature non implementata dallla maggioranza dei processori in commercio • alternativamente: emulatore • inaccettabile overhead in tutte le applicazioni CPU intesive

  30. Estensioni & sviluppi futuri [1/4] • 4 filoni di ricerca contro i Buffer Overflow Attacks: • Safe Languages and Compilers: - introduzioni di linguaggi di programmazione • safe (Java, Modula3, ecc.) • - estensioni dei vecchi linguaggi per renderli • safe(es. C), senza snaturarne le proprietà • ▪ linguaggi ad alto livello e astratti • Java/Modula3 ▪nessuna gestione esplicita della memoria • ▪no al controllo dei dati a basso livello

  31. Estensioni & sviluppi futuri [2/4] • Come è possibile rendere un linguaggio d’origine “safe” ? • Vantaggi: • semplice utilizzo da parte del programmatore • non è necessario passare ad un nuovo linguaggio di programmazione Svantaggi: • protezione riferita solo ad alcune primitive specifiche Librerie sicure librerie condivise e pre-caricate per intercettare le chiamate di funzione delle librerie – trasparenti al programmatore; API librerie esplicitamente richiamabili da un programma. Forniscono delle primitive maggiormente sicure.

  32. Estensioni & sviluppi futuri [3/4] • 2)Compiler Tricks: utilizzo di patch per i più diffusi compilatori (es. gcc) • protezione verso accessi/allocazioni di memoria, gestione • corretta dei puntatori, controllo sulle dimensioni e rispetto • dei limiti degli array, ecc. • contro: mancanza di protezione verso alcuni tipi di code injection attack / introduzione di overhead • 3)Process Sandboxing:esecuzione dei processi in un ambiente protetto • filtraggio degli accessi alle system calls • effettuare dei checks a run-time del programma, monitorando i trasferimenti del controllo del flusso del programma (salti condizionati, salti incondizionati, ecc.)

  33. Estensioni & sviluppi futuri [4/4] • 4)Source Code Analysis:rilevazione di vulnerabilità nel codice (es. gets() in C) • tipicamente si sollevano dei warning a tempo di compilazione del programma • esistono 2 tipi di approcci: • approccio statico: tecniche di analisi statica per rilevare classi di attacchi e vulnerabilità conosciute • approccio dinamico: analisi a run-time per effettuare dei controlli sulle procedure/funzioni richiamate, grazie all’introduzione di una data structure che fornisca informazioni sulle strutture allocate nel programma

  34. Bibliografia • G. S. Kc, A. D. Keromytis, and V. Prevelakis. Countering Code-Injection Attacks With Instruction-Set Randomization. In Proceedings of the ACM Computer and Communications Security (CCS) Conference, pages 272–280, October 2003. • Luigi Auriemma. Buffer overflow: spiegazione tecnica ed esempio pratico. Aprile 2003. http://www.siforge.org/articles/2003/04/15-bofexp.html • G. Mazzei, A. Paolessi, S. Volpini. Buffer Overflow. In Corso di Sistemi Operativi, Facoltà di Ingegneria, Università degli studi di Siena, anno accademico 2001/2002. http://www.clusit.it/whitepapers/GASBof.pdf • T. Jim, G. Morrisett, D. Grossman, M. Hicks, J. Cheney, and Y. Wang. Cyclone: A safe dialect of C. In Proceedings of the USENIX Annual Technical Conference, pages 275–288, Monterey, California, June 2002. • T. C. Miller and T. de Raadt. strlcpy and strlcat: Consistent, Safe, String Copy and Concatentation. In Proceedings of the USENIX Technical Conference, Freenix Track, June 1999. • A. Baratloo, N. Singh, and T. Tsai. Transparent run-time defense against stack smashing attacks. In Proceedings of the USENIX Annual Technical Conference, June 2000. • D. Litchfield. Web Application Disassembly wth ODBC Error Messages. http://www.nextgenss.com/papers/webappdis.doc

More Related