Metodologie di Secure Programming

1. Metodologie di Secure Programming Prof. Stefano Bistarelli CConsiglio Nazionale delle Ricerche IitIstituto di Informatica e Telematica - Pisa Università “G. d’Annunzio”Dipartimento di Scienze, Pescara

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!) 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 overflowexploits 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!!! 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!) 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 … S. Bistarelli - Metodologie di Secure Programming

7. Code injection • Un film … in inglese!!  • TheCodeRoom • E una discussione … 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. 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 6.600 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. 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! 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. 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. 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). 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 Centerwww.cert.org che gestisce un archivio di tutti gli advisories sullo sicurezza nella sezione http://www.cert.org/nav/index_red.html • Altre organizzazioni sono il NIST Computer Security Division,http://csrc.nist.gov/, che gestisce un database on-line di vulnerabilità, l'IACT Metabase, il FIRST un forum sui problemi legati alla sicurezza,http://www.first.org/, 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 http://www.clusit.it fondata dal Dipartimento di Informatica e Comunicazione dell'Università degli Studi di Milano. 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: http://www.dwheeler.com/sloc/). 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) S. Bistarelli - Metodologie di Secure Programming

17. Progetto OWASP le 10 vulnerabilità più critiche delle applicazioni Web

18. Web Application Security e OWASP Top 10 Il progetto OWASP http://www.owasp.org/ 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 S. Bistarelli - Metodologie di Secure Programming

19. Fonte: http://www.internetworldstats.com/stats.htm 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 Wykin “Writing secure code” • No sviluppo “sicuro” degli applicativi web • Firewall and SSL non sono soluzioni di sicurezza completi 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 e-mail per vedere se sono stati colpiti da nuovi virus; non sono rilevanti per quanto riguarda l’HTTP • 75% incidenti avviene via HTTP www.incidents.org • Encryption transport layer (SSL) + FW non risolvono il problema di sviluppare un applicativo web “sicuro” S. Bistarelli - Metodologie di Secure Programming

21. HTTP request (cleartext or SSL) Richiesta HTTP reply (HTML, Javascript, VBscript, etc) Concetti di WebAppSec Accept from ANY to IP W.S. via HTTP/HTTPS Allow SQL SQL Database Risposta DataBase Web server App. server Transport layer HTTP/HTTPS over TCP/IP • Database connection: • ADO, • ODBC, etc. • Apache • IIS • Netscape • etc… • Plugins: • Perl • C/C++ • JSP, etc • Canale e protocollo di comunicazione: HTTP layer 7 ISO/OSI, SSL layer 4-5 • Server: Sviluppo applicativi web “sicuri” 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 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: • http://www.owasp.org/local/italy.html • http://www.clusit.it/whitepapers.htm 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 S. Bistarelli - Metodologie di Secure Programming