Metodologie di Secure Programming

UNIVERSITÀ DI PERUGIADIPARTIMENTO DI MATEMATICA E INFORMATICAMaster 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 RicercheIit Istituto di Informatica e Telematica - Pisa

Università “G. d’Annunzio”Dipartimento di Scienze, Pescara

S. Bistarelli - Metodologie di Secure Programming

2

Master di I° livello in Sistemi e Tecnologie per la sicurezza dell'Informazione e della Comunicazione

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!)


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 exploits


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!!!


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!)


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 …


7


Code injection

Un film … in inglese!! TheCodeRoom

E una discussione …


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.


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.


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!


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.


12



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.


13



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).


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 www.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.


15



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/).


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 PERUGIADIPARTIMENTO DI MATEMATICA E INFORMATICAMaster 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


18


Web Application 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


19


Web Application SecurityWeb 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: http://www.internetworldstats.com/stats.htm


20


Misure tradizionali e incidenti di Misure tradizionali e incidenti di sicurezzasicurezza 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”


21


Concetti di WebAppSecConcetti 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

HTTPrequest(cleartext or SSL)

Risposta

HTTP reply(HTML, Javascript, VBscript, etc)

App. server


22


Principali progetti OWASPPrincipali 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


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 InputA2. Broken Access ControlA3. Broken Authentication and Session ManagementA4. Cross Site Scripting (XSS) FlawsA5. Buffer OverflowA6. Injection FlawsA7. Improper Error HandlingA8. Insecure StorageA9. Denial of Service A10. Insecure Configuration Management

Date post:	03-Jan-2016
Category:	Documents
Upload:	garrett-rivas
View:	41 times
Download:	4 times

Metodologie di Secure Programming

Documents