UNIVERSITÀ DI PERUGIA DIPARTIMENTO DI MATEMATICA E INFORMATICA Master di I° livello in Sistemi e Tecnologie per la sicurezza dell'Informazione e della Comunicazione Metodologie di Secure Programming Prof. Stefano Bistarelli C Consiglio Nazionale delle Ricerche Iit Istituto di Informatica e Telematica - Pisa Università “G. d’Annunzio” Dipartimento di Scienze, Pescara

Master di I° livello in Sistemi e Tecnologie per la sicurezza dell'Informazione e della Comunicazione S. Bistarelli - Metodologie di Secure Programming 2 Secure programming ~ defensive programming Design delle applicazioni inteso a garantirne il funzionamento a dispetto di un uso scorretto delle stesse. Idea simile alla progettazione di oggetti che ne garantiscono l’uso corretto  fornelli che lasciano passare gas solo se e’ accesa la fiamma  Prese e spine con versi obbligati Obbiettivo generico di migliorare il codice delle applicazioni:  Qualità (riducendo i bugs)  Rendendolo più comprensivile per la fase di audit (alpha-beta testing)  Renderlo corretto (fa ciò che deve) e completo (fa solo quello!)

Master di I° livello in Sistemi e Tecnologie per la sicurezza dell'Informazione e della Comunicazione S. Bistarelli - Metodologie di Secure Programming 3 Nothing is assumed! In programmazione difensiva nulla si assume.  TUTTI gli errori devono essere appositamente gestiti: non così  Ancor peggio se errore ma non genero eccezione   Se introduco piu’ di 256 caratteri come input? E perché mai uno dovrebbe inserire una stringa cosi’ lunga? Defensive programming  questo bug non deve esistere!  questo bug dimostra quello che vedremo essere il temibile buffer overflow exploitsbuffer overflowexploits

Master di I° livello in Sistemi e Tecnologie per la sicurezza dell'Informazione e della Comunicazione S. Bistarelli - Metodologie di Secure Programming 4 Tecniche di programmazione difensiva 1 Ridurre la complessità del codice  Minore possibilità di bugs (e di security problems)  … obfuscation technologies?  (forse la vedremo) Revisione del codice sorgente  Free software  Code audit esterno  Self code audit Fase di test Source code reuse  Attenzione!!!

Master di I° livello in Sistemi e Tecnologie per la sicurezza dell'Informazione e della Comunicazione S. Bistarelli - Metodologie di Secure Programming 5 Tecniche di programmazione difensiva 2 Input/ouput validation  Code injection!!!   Canonicalization  Tutto il codice è pericoloso  least privilege principle Mai sa o root Mai piu’ permessi dei necessari Tutti i dati sono importanti  E pericolosi (tainted variables!)

Master di I° livello in Sistemi e Tecnologie per la sicurezza dell'Informazione e della Comunicazione S. Bistarelli - Metodologie di Secure Programming 6 Il nostro corso … Prerequisiti  intuire la logica di un programma scritto in C, C#, ASP, PHP Non è richiesto saper programmare in C, C#, ASP, PHP  Conoscenza interfacce windows e conoscenza di base del sistema unix (linux) Corso difficile … Spero renderlo piu’ semplice possibile …

Master di I° livello in Sistemi e Tecnologie per la sicurezza dell'Informazione e della Comunicazione S. Bistarelli - Metodologie di Secure Programming 7 Code injection Un film … in inglese!!  TheCodeRoom TheCodeRoom E una discussione …

Master di I° livello in Sistemi e Tecnologie per la sicurezza dell'Informazione e della Comunicazione S. Bistarelli - Metodologie di Secure Programming 8 Errori del codice Un errore del codice può influire sulla sicurezza del software (in alcuni casi con conseguenze catastrofiche). Ad esempio nel giugno 1996 il satellite europeo Ariane 5 è esploso subito dopo il lancio a causa di un errore nel software; il programma tentò di inserire un numero di 64 bit in uno spazio di 16 bit, provocando un overflow.

Master di I° livello in Sistemi e Tecnologie per la sicurezza dell'Informazione e della Comunicazione S. Bistarelli - Metodologie di Secure Programming 9 Errori del codice: altri esempi Nel 1998 un bug negli switch Cisco provocò il blocco della rete frame relay Interspan di AT&T che collegava clienti. Nel 1999 il servizio di eBay fu sospeso per 22 ore a causa di errori nel software fornito da Sun Microsystems. Nel 1999 in uno degli script CGI di Hotmail fu scoperto un bug che permetteva di accedere agli account di posta elettronica di altri utenti. Nel 2004 la Microsoft rilascia il Service Pack 2 per Windows XP, dopo pochi giorni vengono scoperti 2 nuovi security bug, uno su Internet Explorer (ver. > 5) ed uno su Outlook Express.

Master di I° livello in Sistemi e Tecnologie per la sicurezza dell'Informazione e della Comunicazione S. Bistarelli - Metodologie di Secure Programming 10 Errori del codice I difetti di implementazione sono molto più frequenti, e più seri, di quelli di progettazione. Un software sicuro deve essere in grado di funzionare anche in presenza di errori subdoli, appositamente introdotti da un aggressore intelligente e con la chiara intenzione di compromettere la sicurezza del sistema. Il metodo normalmente utilizzato per trovare gli errori casuali è il test della versione beta. Il tempo dedicato a questo test viene sempre più ristretto per esigenze commerciali. Ultimamente la tendenza è quella di far fare il beta testing agli utenti!

Master di I° livello in Sistemi e Tecnologie per la sicurezza dell'Informazione e della Comunicazione S. Bistarelli - Metodologie di Secure Programming 11 Attacchi basati sugli errori del codice La maggior parte dei problemi di sicurezza dei computer sono una conseguenza della presenza di errori nel software (si pensi ad esempio ai virus). Sfruttando questi bug è possibile, a volte, prendere il controllo del sistema (ad esempio in ambiente Unix eseguire comandi da root). I bug di sicurezza sono molto più difficili da scovare rispetto ai normali bug di funzionamento poichè i primi non si manifestano apertamente, vengono scoperti solo quando qualcuno trova il modo di sfruttarli. Questo è il motivo per cui ottenere un sistema sicuro è molto più difficile che ottenere un sistema privo di bug di funzionamento.

Master di I° livello in Sistemi e Tecnologie per la sicurezza dell'Informazione e della Comunicazione S. Bistarelli - Metodologie di Secure Programming 12 Attacchi basati sugli errori del codice I bug di sicurezza non sono rilevati normalmente attraverso la procedura di beta testing. Il test di sicurezza di un software richiede molto tempo e deve essere affidato ad un esperto che conosca bene l'argomento (anche se non è detto che ciò sia sufficiente...). Una volta scoperti, i problemi di sicurezza vengono sfruttati finchè qualcuno non trova il modo di risolverli (attraverso il rilascio di patch o service pack). Il lasso di tempo che intercorre tra la pubblicazione di un security bug ed il rilascio della patch è di vitale importanza per la sicurezza di un sistema.

Master di I° livello in Sistemi e Tecnologie per la sicurezza dell'Informazione e della Comunicazione S. Bistarelli - Metodologie di Secure Programming 13 Attacchi basati sugli errori del codice Ultimamente si è parlato molto di full disclosure ossia della libertà di diffondere liberamente qualsiasi informazione sulla sicurezza di un sistema informatico. Chi scopre un security bug ha il dovere di informare gli autori del sistema per dare loro il tempo di rilasciare le patch o ha il diritto di diffondere pubblicamente la notizia senza nessun avvertimento? Ultimamente la tendenza è quella di pubblicare la notizia del security bug senza troppe specifiche tecniche ed avvisare contemporaneamente l'autore del sistema incriminato. Una volta rilasciate le patch vengono divulgati i dettagli tecnici (ovviamente non tutti seguono queste indicazioni).

Master di I° livello in Sistemi e Tecnologie per la sicurezza dell'Informazione e della Comunicazione S. Bistarelli - Metodologie di Secure Programming 14 Canali di diffusione dei security bug Dove vengono diffuse le notizie sui security bug? Esistono diversi enti internazionali che si occupano di sicurezza informatica, il più famoso è il CERT Coordination Center che gestisce un archivio di tutti gli advisories sullo sicurezza nella sezione Altre organizzazioni sono il NIST Computer Security Division, che gestisce un database on-line di vulnerabilità, l'IACT Metabase, il FIRST un forum sui problemi legati alla sicurezza, etc. Esistono anche moltissime mailing-list, tra le più famose: bugtraq, full disclosure, sikurezza.org (italiana). In Italia esiste il CLUSIT, Associazione Italiana per la sicurezza informatica fondata dal Dipartimento di Informatica e Comunicazione dell'Università degli Studi di Milano.

Master di I° livello in Sistemi e Tecnologie per la sicurezza dell'Informazione e della Comunicazione S. Bistarelli - Metodologie di Secure Programming 15 Attacchi basati sugli errori del codice Occorre sottolineare che i bug del software (e quindi i problemi di sicurezza) sono inevitabili. Ogni qual volta un esperto sufficientemente dotato decide di analizzare un programma di protezione, finisce inevitabilmente per trovare qualche errore casuale in grado di compromettere la sicurezza del sistema. Più il software è complesso maggiore è il numero di problemi riscontrati. Ad esempio Windows XP contiene circa 40 milioni di linee di codice, Debian Gnu/Linux 2.2 circa 55 milioni (fonte:

Master di I° livello in Sistemi e Tecnologie per la sicurezza dell'Informazione e della Comunicazione S. Bistarelli - Metodologie di Secure Programming 16 Onnipresenza degli errori Secondo le stime di Carnegie Mellon University, sono presenti mediamente dai 5 ai 15 bug ogni mille righe di codice. Molti di questi sono piccoli errori e, poichè non influenzano le prestazioni, non vengono mai notati. Tuttavia, ognuno di questi bug potrebbe, in teoria, compromettere la sicurezza del sistema. Ad esempio su 55 milioni di linee di codice (Gnu/Linux) queste stime indicano la presenza di un numero di bug variabile da 275'000 a 825'000! L'unico modo per migliorare la sicurezza di un sistema è il continuo aggiornamento. Secondo alcune stime, il 99% di tutti gli attacchi sferrati attraverso Internet sarebbero stati evitati se gli amministratori avessero usato le versioni più aggiornate del software installato nei loro sistemi. (fonte: Bruce Schneier)

UNIVERSITÀ DI PERUGIA DIPARTIMENTO DI MATEMATICA E INFORMATICA Master di I° livello in Sistemi e Tecnologie per la sicurezza dell'Informazione e della Comunicazione Progetto OWASP le 10 vulnerabilità più critiche delle applicazioni Web

Master di I° livello in Sistemi e Tecnologie per la sicurezza dell'Informazione e della Comunicazione S. Bistarelli - Metodologie di Secure Programming 18 Web Application Web Application Security e OWASP Top 10 Il progetto OWASP Le dieci vulnerabiltà più comuni: OWASP Top10 Meccanismi di autenticazione non adeguati Crash del servizio: Buffer overflow Furto di credenziali di autenticazioni: Cross Site Scripting Manipolazione dei dati aziendali: SQL Injection Furto di identità: Errata gestione delle sessioni

Master di I° livello in Sistemi e Tecnologie per la sicurezza dell'Informazione e della Comunicazione S. Bistarelli - Metodologie di Secure Programming 19 Web Application Security // Trend  Sempre più aziende sono on-line  Sempre più utenti sono on-line: everyone, everywhere, everytime // Conseguenze New Business New security risk: confidential data, thief of identity // Quali problemi? Why good people write bad code -Graff e van Wyk in “Writing secure code” No sviluppo “sicuro” degli applicativi web Firewall and SSL non sono soluzioni di sicurezza completi Fonte:

Master di I° livello in Sistemi e Tecnologie per la sicurezza dell'Informazione e della Comunicazione S. Bistarelli - Metodologie di Secure Programming 20 Misure tradizionali e incidenti di sicurezza Gli Incidenti di sicurezza coinvolgono aziende che utilizzano:  Firewall: dal momento in cui sia consentito il protocollo HTTP in ingresso sul web server, un attaccante puo’ inserire qualsiasi informazione nelle richieste  IDS: sono facilmente bypassati a livello HTTP non bloccano un attacco ma lo segnalano solamente non possono fare nulla contro una richiesta cifrata non sono in grado di rilevare nuovi attacchi  VPN: realizzano reti virtuali tra ambienti eterogenei garantendo riservatezza e autenticazione tra i due peer.  AV: analizzano file ed per vedere se sono stati colpiti da nuovi virus; non sono rilevanti per quanto riguarda l’HTTP 75% incidenti avviene via HTTP Encryption transport layer (SSL) + FW non risolvono il problema di sviluppare un applicativo web “sicuro”

Master di I° livello in Sistemi e Tecnologie per la sicurezza dell'Informazione e della Comunicazione S. Bistarelli - Metodologie di Secure Programming 21 Concetti di WebAppSec  Canale e protocollo di comunicazione: HTTP layer 7 ISO/OSI, SSL layer 4-5  Server: Sviluppo applicativi web “sicuri” DataBase Accept from ANY to IP W.S. via HTTP/HTTPS Transport layer HTTP/HTTPS over TCP/IP Allow SQL Plugins: Perl C/C++ JSP, etc Database connection: ADO, ODBC, etc. SQL Database Apache IIS Netscape etc… Web server Richiesta HTTP request (cleartext or SSL) Risposta HTTP reply (HTML, Javascript, VBscript, etc) App. server

Master di I° livello in Sistemi e Tecnologie per la sicurezza dell'Informazione e della Comunicazione S. Bistarelli - Metodologie di Secure Programming 22 Principali progetti OWASP Linee guida:  Guida per la progettazione di applicativi web “sicuri”  OWASP Top Ten Vulnerability  Checklist per Web Application Vulnerability Assessment Tool per Pentester e code reviewer:  WebScarab  WebGoat

Master di I° livello in Sistemi e Tecnologie per la sicurezza dell'Informazione e della Comunicazione S. Bistarelli - Metodologie di Secure Programming 23 Top Ten vulnerability list OWASP mantiene una lista delle 10 vulnerabilità più critiche di un applicativo web. Aggiornate annualmente. Sempre più accettata come standard:  Federal Trade Commission (US Gov)  Oracle  Foundstone Inc. Stake  VISA, MasterCard, American Express Tradotta in italiano: A1. Unvalidated Input A2. Broken Access Control A3. Broken Authentication and Session Management A4. Cross Site Scripting (XSS) Flaws A5. Buffer Overflow A6. Injection Flaws A7. Improper Error Handling A8. Insecure Storage A9. Denial of Service A10. Insecure Configuration Management