Sicurezza di Server WEB e firma di componenti Giorgio Dall'Agnola © - Gennaio 2000

Overview Analisi dei tipi di attacco Aspetti di security dei servizi web Protezione del server web Protezione del browser Sicurezza in Explorer e Netscape Firma elettronica dei componenti

Scenario di riferimento HTTP classico Browser WEB GET HTML page/document SERVER WEB Ricezione di pagine HTML HTTP evoluto Download di componenti software (Applet o controlli ActiveX) o instanziazione di componenti software sul server da pilotare mediante scripting Attivazione di un canale tra client web e applicazione server (Server web attivi e passivi) Browser WEB

Attacchi al browser WEB Punti d’attacco Attacchi al browser WEB SERVER WEB Browser WEB Attacchi al canale di comunicazione Attacchi al server WEB

Tipi di attacco SUL SERVER WEB SUL CANALE DI COMUNICAZIONE SHADOW SERVER DENIAL OF SERVICE UTILIZZO DELLA MACCHINA SERVER PER FAR PONTE SU ALTRI SISTEMI SUL CANALE DI COMUNICAZIONE CONNECTION HIJACKING ATTACCHI REPLAY SNIFFING DI RETE

Tipi di attacco SUL BROWSER WEB VIOLAZIONE PRIVACY (COOKIES) ESECUZIONE DI COMPONENTI ATTIVI FRAUDOLENTI: Macro VBA Script, Applet e Controlli ActiveX maliziosi Spy Component / Back Doors Trojan Horse Esecuzione mediante plug-in di codice malizioso (es. documenti PDF artefatti) ACCESSO A RISORSE DEL S.O. (HD, I/O, connessioni di rete o risorse condivise)

Autenticazione del server WEB La protezione delle pagine WEB si basa su un meccanismo debole se utilizzato da solo Si utilizzano delle ACL gestite dal server WEB e associate alle singole pagine Nel protocollo HTTP 1.0 si utilizza una BASE AUTHENTICATION dove l’utente dal browser manda tramite URL una stringa USERNAME:[PASSWD]CodeBase64/UUEncode facilmente intercettabile e manipolabile Username e password, codificate come sopra, sono mantenute in un semplice file di testo e manipolate con tools appositi (con interfaccia GUI o a caratteri) del server WEB

Autenticazione del server WEB E’ possibile attivare un’autenticazione basata sull’indirizzo o sul nome di dominio Si tratta di un metodo d’autenticazione insicuro Si devono utilizzare altre forme di autenticazione Autenticazione tramite gli account di sistema operativo (forma di autenticazione molto pericolosa in quanto espone ad attacchi l’intero sistema) Autenticazione tramite sistemi a sfida o password usa e getta (mediante moduli software che estendono le capacità d’autenticazione del server) Autenticazione mediante certificati a chiave pubblica (SSL e suoi derivati).

I COOKIES ESEMPIO www.omnitel.it FALSE /sito FALSE 935532272 username fugini .focalink.com TRUE / FALSE 1293796841 SB_ID 092278129800007154441241518571 .netscape.com TRUE / FALSE 978307388 NS_REG SHA1=%9B%E8%7B%DA%9Fy%F4%C4%0B%12%98C%86%B3229%5D%90%5F[-]UR%5FEMAIL=dallagno%40elet%2Epolimi%2Eit[-]UR%5FREG%5FID=17266063%3ASWDv1 .nscp-partners.com TRUE / FALSE 978307239 NS_REG SHA1=%b9K%bd%d4kp%ed%0b%b5TY%94z%94%2dX%0a%06%81%c9[-]UR%5FEMAIL=fugini%40elet%2Epolimi%2Eit[-]UR%5FREG%5FID=17266063%3ASWDv1

I COOKIES Sono semplici file di testo di piccole dimensioni che i server WEB generano e memorizzano in un preciso direttorio all’interno di ogni browser web Servono principalmente a memorizzare variabili di sessione, informazioni sull’utente, siti visitati Il loro utilizzo più frequente è quello di supporto all’immissione iterata di dati nei form di input (che andrebbero persi passando da una pagina all’altra) E’ possibile disabilitarli, ma le pagine che li utilizzano non funzionerebbero correttamente Esistono dei gestori di cookies che ne filtrano il contenuto rendendo disponibili ai server web solo alcune delle informazioni contenute

Protezione del server WEB Minimi privilegi ai processi attivati dal server Protezione del file system del server Confinamento dei singoli servizi Script attivati con minimo privilegio Autiding del server ad un fine livello di granularità SERVER WEB

Protezione del server WEB Minimi privilegi ai processi attivati dal processo principale del server WEB Il processo principale, che si pone in ascolto sulla porta 80, è purtroppo attivato dagli attuali S.O. con privilegi massimi (root in Unix, administrator in NT). Situazione a cui non si può porre rimedio. E’ il responsabile dell’attivazione dei processi figli inerenti i servizi offerti dal server WEB (es. collegamento con fonti di dati) Questi servizi devono essere attivati associandoli ad un utente virtuale a cui siano assegnati minimi privilegi --> si impedisce così a processi con possibili bug di aggredire l’intero sistema

Protezione del server WEB PROCESSO ASCOLTATORE PROCESSO ESECUTORE HTTP HTML UID = superuser (massimi privilegi) UID = user http (minimi privilegi) PORT < 1024 PORT > 1024

Protezione del server WEB Protezione del file system del server Agli utenti connessi al server web devono essere concessi privilegi minimi (read per le pagine html, execute per gli script o applicativi) Ai WEB administrator sono invece concessi anche i privilegi di modifica sulle pagine html e sui file di configurazione (write) E’ buona norma impedire agli utenti la visualizzazione e la navigazione delle cartelle contenenti pagine html, script e applicativi. Non conoscere la versione e le informazioni degli script presenti sul server, impedisce lo sfruttamento dei loro possibili BUG a scopo fraudolento

Protezione del server WEB Confinamento dei singoli servizi E’ consigliata l’adozione di un server da dedicare esclusivamente a server WEB, spostando ogni altro servizio o applicativo su altri elaboratori Nel caso ciò non sia possibile e servizi diversi utilizzino il medesimo file system, è buona prassi adottare una politica di security volta a gestire separatamente gli account di ciascun servizio limitandosi a fornire ai singoli utenti i soli privilegi strettamente necessari Per i server WEB è consigliabile tenere separati i direttori contenenti rispettivamente le pagine html e gli script (diritti di esecuzione limitati a questo direttorio)

Protezione del server WEB Script attivati con minimo privilegio Devono essere attivati con gli stretti privilegi necessari a compiere la loro funzione Auditing del server ad un fine livello di granularità Si devono attivare tutte le forme di auditing possibili e tenere sotto costante monitoraggio i vari file di LOG Si devono applicare al server tutti gli aggiornamenti e le patchs che si rendano necessari

Protezione del canale di comunicazione SERVER WEB Browser WEB Crittografia HTTP si protegge il flusso dati tra server WEB e browser mediante: l'instaurazione di un canale crittografico: utilizzo di SSL utilizzo di moduli crittografici ad hoc lato client e server facendo della crittografia a livello d’applicazione utilizzo di S-HTTP (oggi non particolarmente utilizzato) che estende l’HTML base con TAG specifici

SSL SSL (Secure Socket Layer): protocollo per la crittografia di canale (realizzato da Netscape) SSL 2.0 (autent. Server) SSL 3.0 (autent. Server + Client) garantisce autenticazione, integrità e confidenzialità Instaura un canale crittografico sicuro tra il layer di trasporto e quello applicativo Supporta i protocolli: http, nntp, smtp,ftp, telnet,... Nell’utilizzo di http sicuro si attiva sulla porta TCP/443 e gli è stata dedicata la URL https://…… Utilizza algoritmi a chiave pubblica per lo scambio delle chiavi di sessione (RSA, Diffie Hellman, Fortezza-KEA)

SSL Utilizza algoritmi simmetrici per instaurare il canale crittografico (RC2, RC4, DES, 3DES, IDEA) Utilizza chiavi simmetriche da 128 bit (Stati Uniti e Canada) o da 40 bit (altri paesi) e chiavi pubbliche da 512, 1024, 2048, 4096 bit La versione 2.0 utilizza certificati X.509 v1, mentre la 3.0 certificati X.509 v3 Negoziazione dei protocolli crittografici e del tipo di chiave

https://www.securesite… (1) (4) Attivazione sicurezza SSL https://www.securesite… (1) SERVER WEB (2) Server Certificate Browser WEB Client Certificate (3) (4) Attivazione sicurezza Canale SSL HTTP Giorgio Dall'Agnola © - Gennaio 2000

Certificato a chiave pubblica Che cos’è? Una struttura dati per legare in modo sicuro una chiave pubblica ad alcuni attributi Caratteristiche: tipicamente lega chiave a persona firmato in modo elettronico dall’emettitore: l’autorità di certificazione (CA) con scadenza temporale revocabile sia dall’utente che dall’emettitore

Esempio di certificato Campi: Esempio: version 1 serial number 1430 signature algorithm RSA with MD5, 1024 issuer C=IT, O=PoliMi validity 1/1/2000 - 31/12/2000 subject C=IT, O=PoliMi CN=MariagraziaFugini subjectpubickeyinfo RSA, 1024, xxxx…xxx digital signature yy…..yyy

Infrastruttura pubblica per la certificazione di chiavi Non c’è ancora una vera PKI (Public Key Infrastructure) Lotta accanita tra vari standard X.509v1 (ISO) X.509v3 (ISO + IETF) PKCS (RSA, in parte compatibile con X.509v3)

Funzionamento di una PKI Come verificare che un certificato a chiave pubblica (firmato da Ca1) sia autentico? ….occorre il certificato della chiave di CA1 (che sarà firmato da CA1) … e così via … fino a raggiungere la CA di root occorre un’infrastruttura (gerarchia?) di certificazione e distribuzione

Revoca dei certificati Un certificato può essere revocato prima della sua scadenza naturale dal soggetto dall’emettitore un certificato revocato viene inserito in una CRL (Certification Revocation List) quando si riceve un messaggio si deve verificare che il certificato non sia incluso nella CRL dell’emettitore le CRL sono mantenute dagli emettitori dei certificati

Dove si utilizzano le chiavi pubbliche e i certificati? Scambio di messaggi di E-mail (PEM, PGP, S/MIME) Applicazioni proprietarie (per controllo remoto, per realizzare moduli di sicurezza) Per apparecchiature hardware (router, HW di rete) Per applicazioni di e-commerce Per realizzare siti WEB sicuri

COM Object Active X Nome commerciale di un insieme di tecnologie e servizi per lo sviluppo di applicazioni basate su componenti riutilizzabili Fondata sul modello COM (Component Object Model) di Microsoft e sue estensioni (DCOM) Permette lo sviluppo di componenti client, server e di middleware in un’ottica di programmazione in ambiente distribuito Oggetti ActiveX: applicazioni (*.exe) servizi sw a caricamento dinamico (*.dll) componenti sw (*.ocx e prima *.vbx) applicazioni documento (internamente a IE *.exe, *.dll)

Remote object on any server Object running on client COM & DCOM Server Client COM Remote object on any server Object running on client

COM & DCOM Inprocess Local Remote COM run time Client Component LPC COM run time Security provider RPC Component Client Inprocess Remote Protocol stack DCOM network- protocol

Controlli ActiveX Sono oggetti COM utilizzati come: componenti run-time ( forniscono classi di oggetti e funzioni) interfaccia GUI (da utilizzare in applicativi e web) Per il programmatore sono oggetti con: eventi proprietà metodi Possono richiamare API di sistema Si utilizzano per realizzare pagine WEB attive (scaricati tramite browser) Utilizzati da altri componenti o pilotati da script (VB Script e Jscript) Fuzionano con IE 3.X e 4.X e Netscape munito di appositi Plug-in

Utilizzo nei browser Java Applet HTML Document JavaScript™ Non-HTML Document VBScript ActiveX Control Giorgio Dall'Agnola © - Gennaio 2000

Security in IExplorer I controlli activeX non hanno un modello di sicurezza intrinseco (Java), ma vengono presi “a scatola chiusa” Solo le credenziali che questi portano con sé (certificati e firma elettronica) vengono valutate per decidere se accettare o no il componente L’utente può definire le proprie politiche di sicurezza (scegliere quali componenti attivare e scaricare a diversi livelli di granularità) E’ sempre l’utente l’ultimo arbitro della propria security

Authenticode (TM) Codice wrappato in un file *.CAB e firmato elettronicamente Politiche diverse per controlli ActiveX e Applet Java Utilizzo di certificati secondo lo standard di certificazione X.509 Identificazione dell’autore Validazione dell’integrità del codice Accountability del software scaricato

Zone di sicurezza Suddivisione dello spazio degli indirizzi in 4 zone di sicurezza Area Internet Area Intranet Area siti attendibili Area siti con restrizioni A ciascuna zona si associa un livello di sicurezza cui corrisponde un profilo di security Sono 3 i livelli di sicurezza con policy predefinite Un livello è personalizzabile dall’utente

Livelli di sicurezza Per il livello di sicurezza definito dall’utente è possibile definire una propria policy di security (IE 4.X) Su ogni componente (sia controllo activeX che applet Java) è possibile associare con appositi tool un livello di security predefinito (High, Medium, Low) Solo sulle applet Java è possibile associare un profilo di security personalizzato includendo richieste d’accesso esplicite (I/O, accesso a funzioni di S.O, r/w HD, etc.)

Livelli di sicurezza sul browser

Livelli di sicurezza sul componente firmato

Procedura seguita per decidere se accettare un controllo ActiveX Si identifica la zona di sicurezza a cui appartiene il server da dove il componente è scaricato (in base all’indirizzo IP) Si utilizza il livello di security definito per tale zona Nel caso dei 3 livelli predefiniti (High, Medium, Low) il comportamento è quello dettagliato in tabella:

Procedura seguita per decidere se accettare un controllo ActiveX Nel caso del livello di sicurezza personalizzato, l’utente stabilisce la propria politica di security indipendentemente dal livello di security associato al componente Per ogni tipo di componente da scaricare si può impostare il browser ad agire secondo tre diverse modalità: ATTIVA: si accetta il componente senza nessun messaggio di warning all’utente; DISATTIVA: si rifiuta il componente (che perciò non verrà eseguito) senza alcun messaggio di warning all’utente; RICHIEDI: all’utente è mostrato un messaggio di warning con la richiesta di decidere se accettare o no il componente.

Procedura seguita per decidere se accettare un’applet Java Si opera analogamente ai controlli ActiveX per i livelli di security High, Medium e Low. Se si usa un profilo di security personalizzato, il profilo di security impiegato nella firma dell’applet è confrontato con quello impostato nel browser. In base al confronto, il browser decide automaticamente senza l’intervento dell’utente quali permessi concedere e quali negare. All’utente compare comunque allo scaricamento anche un messaggio di warning con elencati i privilegi richiesti dall’applet.

Repository dei certificati di IExplorer I certificati di autori ritenuti attendibili sono inseriti in un repository I certificati per la firma del software sono rilasciati da apposite autorità di certificazione Giorgio Dall'Agnola © - Gennaio 2000

I contro di ActiveX Non si è assicurati sui bugs e sul codice malizioso contenuto nei controlli scaricati - Nessuna verifica del codice I controlli possono chiamare API di sistema - Grande rischio Possono contenere cavalli di troia o possono instaurare back-door Problema di IE: assegnazione dei siti alle zone di security in base al loro indirizzo (address spoofing)

I contro di ActiveX Incapsulamento del codice (controlli black-box) non si può testare la bontà del controllo Possibilità per controlli ostili di interferire con applicazioni server (COM/DCOM) quali gestori di transazioni o business critical Si è costretti a firmare il software per utilizzarlo in IE

Firma del codice Si aggiungono al codice Java una serie di istruzioni per accedere alle Java Capabilities API di Netscape Le Java Capabilities API permettono di definire: chi è abilitato a svolgere una data azione (identificato dalla firma elettronica apposta in seguito) - CLASS PRINCIPAL con che privilegi - CLASS PRIVILEGE su quali risorse del sistema - CLASS TARGET Si wrappa poi il codice in un file *.JAR e poi lo si firma con degli appositi tool (bisogna possedere: una chiave privata e la rispettiva chiave pubblica con il certificato della CA che l’ha validata) l’applet (possono essere più d’una) è ora pronta per essere scaricata

Java Java: il linguaggio di programmazione di Sun portabilità grazie alla codifica bytecode e VM per ogni piattaforma linguaggio object -oriented puro adatto all’implementazione di applicazioni di internetworking sviluppo di Applicazioni o Applet (applicazioni che si scaricano da un server tramite la rete e si eseguono in locale) JDK 1.1: è il core implementato nei browser oggi implementato in Netscape 4.04 (Symantec) e IExplorer 4.01 (implementazione proprietaria secondo le specifiche SUN) dalla versione 1.1.5 del JDK è stato inglobato il JIT Symantec introduzione dei JavaBeans e API per la sicurezza (controllo degli accessi e crittografia) JDK 1.2 appena rilasciato

Modello di sicurezza Java Applicazioni Java: nessuna restrizione Applet Java: adottano il modello chiamato SANDBOX che prevede: controllo del bytecode Java (Bytecode verifier) contenuto nei file *.class controllo delle classi Java caricate in memoria (Class Loader) controllo della correttezza dei metodi secondo un set di regole (Security Manager) Un’applet deve passare i 3 check (tutti) per essere eseguita dal browser

<APPLET CODE=DBApplet.class … /APPLET> Sandbox Internet 1 <APPLET CODE=DBApplet.class … /APPLET> Page.html Server WEB Class Loader 3 Bytecode Verifier 2 DBApplet.class Name space 4 JVM Java Virtual Machine Security Manager 5 6

Bytecode verifier Verifica il bytecode alla ricerca di comportamenti illeciti Viene controllato il formato di ogni porzione di codice Utilizzo di un dimostratore di teoremi che: controlla gli oggetti istanziati verifica l’incremento dei puntatori verifica restrizioni d’accesso Il bytecode ha una semantica più ricca di Java: la si può sfruttare per operazioni non ammesse dal linguaggio (minaccia)

Class Loader Determina se, in run-time, può essere aggiunta una classe all’ambiente Java Le classi sono caricate in zone di memoria separate (name space) Le classi fondamentali del CORE Java stanno in name space a cui sono assegnati i massimi privilegi (classi protette da corruzioni esterne) Tutte le classi inserite nella variabile d’ambiente CLASSPATH acquisiscono massimi privilegi (non sono controllate)

Security Manager Controlla i metodi prima che siano eseguiti basandosi su: la classe di provenienza un SET di regole predefinite Controlla: conflitti nell’assegnazione dello spazio dei nomi chiamate ai processi del SO l’accesso alle classi operazioni di lettura/scrittura su HD operazioni di I/O su socket Se una condizione viene violata è sollevata una Security Exception Ogni browser implementa una propria versione

Evoluzione del modello di sicurezza Java Sandbox del JDK 1.02: modello valido (controllo e validazione codice) ma rigido A partire dal JDK 1.1 allentamento delle restrizioni imposte dalla Sandbox per Applet con firma digitale JDK futuri: ancora più flessibilità per Applet e Applicazioni in base a firma digitale, provenienza, tipo di azione svolta dal codice

Evoluzione del modello di sicurezza Java Opzionale: l’utente può scegliere da browser quali restrizioni della Sandbox allentare se l’applet è firmata Selezionabile: modello per assegnare privilegi ad applicazioni e applet in modo più flessibile

JDK 1.2 Security Overview