La presentazione è in caricamento. Aspetta per favore

La presentazione è in caricamento. Aspetta per favore

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

Presentazioni simili


Presentazione sul tema: "1 SQLrand: Preventing SQL Injection Attacks Stephen W. Boyd & Angelos D. Keromytis Columbia University Elia Gaglio 809477 & Mirco Tonin 804425 Seminario."— Transcript della presentazione:

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

2 2 Code injection attacks SQL injection attack è unistanza 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 linsieme 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 code injection attacks sql injection attacks

3 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 allistruzione 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 lattaccante deve conoscere larchitettura del sistema target

4 4 1. void leggistringa(void){ 2. char buff[8]; 3. gets(buff); 4. } int main(void){ 7. leggistringa(); 8. return(0); 9. } programma C: riempimento dello stack 0x indirizzi alti push ebp call ………… assembler: EIP: EBP buff[0]: buff[1]: buff[2]: buff[3]: buff[4]: buff[5]: buff[6]: buff[7]: bytes 1 byte... stringa in input: aaaabbbb 0x x aaaa: bbbb: buffer overflow Alluscita della funzione, avremo che EIP=0x EBP=0x Buffer Overflow (2/3) (animata)

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

6 6 Contromisura: ISR allinterno 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 dattacco differiscono tra loro, tutte hanno un denominatore comune: lattaccante 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 dellattaccante circa lambiente / linguaggio interpretato di programmazione del sistema target code injection attacks sql injection attacks unix shell commands Perl code injection contromisura: un approccio generale di prevenzione verso qualsiasi code injection attack: Instruction-Set Randomization

7 7 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 applicazione del metodo ISR al linguaggio SQL nostro articolo

8 8 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 lattaccante non conosce il linguaggio usato e di conseguenza non puo speak alla macchina (non conosce la key di randomizzazione) due alternativi approcci nelluso 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: 2 32 trasposizione randomizzata (basata sulla chiave) dei bit: (la chiave di decodifica sarà linversa) attacco brute force: 32! ( 32! >> 2 32 ) => sicurezza maggiore ENCODED INSTRUCTION STREAM CPU ENCODING KEY xor decoded instruction stream in ogni caso, una chiave di 32 bits è sufficiente per una protezione verso attacchi di code injection

9 9 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) DkeyP disco efP DkeyP ram SO PCB: registers: CPU tale executable file contiene allinterno dellheader, lappropriata chiave di decodifica (DkeyP) del processo caricato in memoria nel frattempo, il sistema operativo estrae la chiave di decodifica dallheader delleseguibile 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 unistruzione privilegiata GAVL che permette un accesso in sola scrittura nel speciale registro di CPU. P GAVL

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

11 11 Performance ftpsendmailfibonacci bochs39.0s28 s5.73s (93s) linux29.2s 1.35s0.322s ftp & sendmail (processi I/O intensive): una perdita contenuta nelle performance fibonacci (CPU intensive application): tremendo slowdown (inaccettabile) risultati sperimentali: tempo di esecuzione (in secondi) per identici file binari su Bochs e una macchina Linux (sulla quale è stato fatto girare bochs)

12 12 ISR su altri linguaggi (1/2) Le idee e i concetti, introdotti al fine di ottenere unesecuzione sicura delle istruzioni macchina, sono state estese per garantire la sicurezza desecuzione 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 $list{$k} }; } output: programma P, dove ad ogni costrutto perl in P è stata appesa la chiave (tag) foreach $k (sort keys %$tre){ $v = $tre ->{$k}; die ``duplicate key $k\n if defined $list $list{$k} }; } la chiave (tag) viene fornita via a command line argument è necessario una modifica dellanalizzatore lessicale dellinterprete Perl, affinchè possa riconoscere le keywords seguite dal corretto tag

13 13 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) linterprete bash dovrà essere modificato al fine di riconoscere le nuove keywords (commad+tag) #!/bin/sh if [ x$1 == x; then echo Must provide directory name. exit fi /bin/ls –l $1 exit ISR su altri linguaggi (2/2)

14 14 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 15 Esempi di SQL Injection Attacks [1/5] CONTESTO: pagina di login ad un servizio web, realizzata mediante unapplicazione CGI (si richiedono username e password) Nel momento in cui lutente inserisce i dati viene generata la query: 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 =. $uid. and password = password(. $pwd. ); select * from mysql.user where username = or 1=1; -- and password = password(_any_text_);

16 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 lutente inserisse un username fasullo aaa verrebbe invocata la URL: Lapice 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 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: 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 Il procedimento prosegue fino a quando tutti i nomi delle colonne sono scoperti… tblUsers password username

18 18 Esempi di SQL Injection Attacks [4/5] (animata) 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: 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 username password lastloggedin nvarchar

19 19 Esempi di SQL Injection Attacks [5/5] (animata) Dopo aver a disposizione la struttura della tabella sarà possibile da parte dellattaccante inserire un nuovo account fasullo nel DB: insert into tblusers(username,password,lastloggedin,status) values ('jsmith','secret','Oct :52PM','foo')-- tblUsers username password lastloggedin status nvarchar date jsmith secret Oct :52PM foo

20 20 SQL Injection Attacks – alcune soluzioni Come si possono fronteggiare gli SQL Injection Attacks? Accorgimenti per aumentare la sicurezza dellapplicazione (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 sullesatta 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 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 linterprete SQL del DB (in analogia allapproccio 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 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 dallinterprete SQL del DB Il proxy lavora esclusivamente a livello sintattico, effettuando anche il filtraggio dei messaggi di errore provenienti dal DB

23 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 laccesso 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 24 SQL Injection Attacks – SQL Randomizations [4/6] (animata) CLIENT PROXY MYSQL DBMS 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) La soluzione finale proposta per gestire le comunicazioni è la seguente: api mysql LATO CLIENT C C S S

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

26 26 SQL Injection Attacks – SQL Randomizations [6/6] A questo punto se un utente maligno volesse formulare un tipico attacco mediante linserimento 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 dellinput 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 27 Prove sperimentali Sono state effettuate due tipologie di test: 1. unapplicazione CGI creata (ad hoc) dagli autori stessi: nessuna validazione sullinput 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 derrore 2. identificare SQL injection attacks su applicazioni web pre-esistenti e molto diffuse: phpBB v2.0.5 php-Nuke attacchi neutralizzati con luso del proxy

28 28 Performance evaluation Scenario di test: 3 insiemi di utenti concorrenti: 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 records database, proxy e client running su separate macchine x86 con SO RedHat Linux, e tutte sulla stessa rete UsersMinMaxMeanStd 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 dellapplicazione) la risposta di una web application è considerata persa loverhead introdotto dal proxy è insignificante future work: sviluppo di developing tools per assistere i programmatori nellutilizzo di SQLrand

29 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 dinstallazione ISR offre trasparenza ad applicazioni, linguaggi e compilatori, nessuno dei quali deve essere modificato Svantaggi: lutilizzo 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 30 Estensioni & sviluppi futuri [1/4] 4 filoni di ricerca contro i Buffer Overflow Attacks: 1)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 31 Estensioni & sviluppi futuri [2/4] Come è possibile rendere un linguaggio dorigine safe ? 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. Vantaggi: semplice utilizzo da parte del programmatore non è necessario passare ad un nuovo linguaggio di programmazione Svantaggi: protezione riferita solo ad alcune primitive specifiche

32 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 Sanboxing: 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 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 allintroduzione di una data structure che fornisca informazioni sulle strutture allocate nel programma

34 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 Luigi Auriemma. Buffer overflow: spiegazione tecnica ed esempio pratico. Aprile G. Mazzei, A. Paolessi, S. Volpini. Buffer Overflow. In Corso di Sistemi Operativi, Facoltà di Ingegneria, Università degli studi di Siena, anno accademico 2001/ 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 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 A. Baratloo, N. Singh, and T. Tsai. Transparent run-time defense against stack smashing attacks. In Proceedings of the USENIX Annual Technical Conference, June D. Litchfield. Web Application Disassembly wth ODBC Error Messages.


Scaricare ppt "1 SQLrand: Preventing SQL Injection Attacks Stephen W. Boyd & Angelos D. Keromytis Columbia University Elia Gaglio 809477 & Mirco Tonin 804425 Seminario."

Presentazioni simili


Annunci Google