Appunti completi corso Computer Security

Introduzione alla sicurezza dei sistemi

Si parte! Questo corso è particolare perché non studiamo qualcosa nello specifico, ma la sicurezza di interi sistemi. È parecchio interdisciplinare rispetto agli altri, devi sfruttare tutto ciò che hai imparato negli altri corsi… E l'ingegneria della sicurezza è particolare perché guardiamo non come costruire sistemi, ma come distruggerli… Inoltre qua è importante non solo il sistema informatico, ma anche l'utente. È lui che spacca le applicazioni e dobbiamo capire come loro possono minacciare la sicurezza di un sistema. Non parliamo solo di computer, anche (e spesso) di utenti. Fatti un giro su http://necst.it/

Argomenti del corso

Parleremo innanzitutto di cos'è la sicurezza, poi diremo qualcosa di base sulla crittografia, si parlerà di autenticazione, controllo dell'accesso e la parte più importante del corso: il software, la web security, la sicurezza delle reti e i malware. L'esame è scritto, ma ci sono fino a 3 punti bonus che voglio ovviamente avere. Se non li fai impari poco e io voglio imparare.

Sono due settimane in cui setteranno un ambiente online che possiamo usare per rompere alcuni software. In particolare la prima settimana sarà un software client-server, mentre nella seconda settimana rompiamo un software in esecuzione. SONO DIFFICILI, QUINDI DIVERTITI E SPENDERAI LE NOTTI. Useremo come linguaggi C, bash e Python che conosco tutti. Assai consigliato l'uso di Linux e il terminale. Servirà anche un po' di x86 che di base conosco e che comunque vedremo insieme.

Materiale di studio

Nel libro di FIR LEGGI il capitolo "Cronaca di una richiesta HTTP". Tra i libri il Gollman non ha la parte di software exploitation. Poi l'Anderson è gratuito in PDF ma non è un textbook: è interessante ma non è un libro per studiare come il primo. Esistono anche due libri opzionali che sembrano interessanti: ce n'è uno apposta sul software exploitation visto che noi lo vediamo in modo basilare. Il secondo è perfetto per spiegare come scrivere codice sicuro, per cui me lo prendo pure quello. Poi sulle slide ci saranno vari riferimenti ad alcuni paper utili per la tesi.

Capture the Flag e sicurezza

Il Capture the Flag nella cybersecurity è un gioco di hacking che consiste in cosa? Sono gli homework in versione difficile. Se li vuoi fare c'è un gruppo organizzato dagli studenti detto Hanoiati… toh.necst.it e si incontrano ogni settimana al Necst. Beh questi lavorano sabato e domenica quindi è perfetto per me.

Concetti fondamentali di sicurezza

Definizione di sicurezza

Ora iniziamo a dire che cos'è la sicurezza. Qui non parliamo solo dei sistemi informatici, ma in generale. Uno dice che hai un perimetro e ciò che sta dentro è sicuro, quello che sta fuori no. Un po' basilare ma è un punto di partenza (ha pure il nome di castle model…). La parola giusta è safe, che NON è sinonimo di secure, e purtroppo sono parole diverse che in italiano sono uguali… Safety significa che dici come un oggetto protegge l'interno dall'esterno, mentre security dice quanto l'oggetto è protetto dall'esterno.

Beh come immagine per descrivere la sicurezza ha usato un caveau… è sicuro? Sembra di sì, perché l'unico punto di entrata è protetto da un sistema robusto. Limita le persone ad entrarci. Perché? Perché richiede un sacco di tempo per essere violato. Ti immagini un tizio con la fiamma ossidrica se no non entri mai. Infatti le porte di metallo vendute hanno pure un numero che dice quanti minuti ci vogliono per romperla con la fiamma ossidrica. Ed è uno standard ISO, ci hanno pensato pure…

Poi guardi accanto a quell'affare e c'è un codice da inserire in cui capisci che le cifre sono quattro e sai pure quali. E sembra che sia un anno… poi lo hanno cambiato e hanno segnato i numeri con la penna… DEI GENI. Questa è una vulnerabilità. Pensiamo a quanto tempo ci vuole a tagliare due metri di ferro, e non ci accorgiamo che in un minuto scopri la password. Beh le foto sono vere ma quella tastiera NON apre la banca lol…. Ma la foto dopo è vera…. Porco cane, sta in un aeroporto americano...

Paradigma CIA

A questo punto per dire che un sistema è sicuro ci servono delle assunzioni. Quali assunzioni sono fatte per i sistemi informatici? Ci si basa sul PARADIGMA CIA: CONFIDENZIALITÀ, INTEGRITÀ, DISPONIBILITÀ (availability).

La confidenzialità significa che in un sistema informatico i dati sono acceduti dalle sole persone autorizzate. È quello che si pensa per prima cosa quando parli di sicurezza. L'integrità indica che solo le persone autorizzate possono modificare i dati, e lo fanno solo nei modi autorizzati. Se vai in una banca a prendere 100 euro, ti aspetti che il conto bancario scenda di 100 euro e non 2000. La modifica dei dati deve avvenire in modo autorizzato, ed è più complicato della confidenzialità. Quest'ultima è una decisione binaria, l'integrità no… Questi due obiettivi però limitano la disponibilità. Se prendi il PC e lo butti nell'oceano stai sicuro che nessun altro accede ai dati. Però grazie al cazzo non lo puoi più usare. Quindi la disponibilità va contro confidenzialità e integrità. C'è di mezzo un trade-off ed esistendo ha anche senso che ci siano gli ingegneri.

Vulnerability ed exploit

Un altro concetto da introdurre è la differenza tra vulnerability ed exploit. Ma sai come funziona una chiave di una porta? Più o meno… c'è una bella foto e lo capisci. Funziona da secoli, MA… qual è l'assunzione che facciamo per dire che la chiave è sicura? Beh se c'è un solo pin nel cilindro, basta usare uno strumentino per alzarlo al giusto livello. Ma siccome i pin sono tanti, non possiamo alzarli tutti in contemporanea. Se lo facessimo in contemporanea, abbiamo costruito una chiave… Questa è l'assunzione.

Ci serve un qualcosa che alza tutti i pin allo stesso tempo e al livello giusto. Non è propriamente vero. C'è una vulnerabilità chiamata attrito. Nel mondo ideale se alzi un pin e poi lo lasci, quello cade. Però se il lock non è nella giusta posizione, ma spostato lateralmente, non cade e rimane in alto. E questo è il principio del grimaldello: applicare una tensione laterale al pin così rimane sopra. Una volta alzati tutti i pin il lock è aperto. Pure questo si conosce da secoli come le chiavi :D come si risolve questo problema? La vulnerabilità è l'attrito, l'uso del grimaldello è l'exploit.

Avrei potuto spiegarti come usare il grimaldello senza dire perché funziona… Sarebbe complicato e pure inutile. Quindi puoi usare gli exploit degli altri senza sapere cosa fanno. O al contrario puoi vedere che c'è una vulnerabilità e non sapere come sfruttarla: in quel caso non potresti dimostrare che la vulnerabilità c'è, e soprattutto non potresti fixarla. Nella computer security è quasi impossibile usare un exploit senza conoscere la vulnerabilità, perché usiamo il codice che lo dice. Nel mondo fisico le due cose possono essere separate.

Abbiamo visto che la vulnerabilità è l'attrito: come lo ripariamo? Lo scopo è ridurre il più possibile l'attrito, quindi produrre pin di un certo materiale, buttarci olio ovunque… o dare al lock una forma che rende impossibile la vulnerabilità. Il problema è che in qualche modo ci serve una chiave se no come apriamo la porta? La soluzione è rivedere da capo il design del lock. Ed esistono, ma sono più costosi. Cosa significa? Che li usiamo laddove il livello di sicurezza richiesto è più alto. Significa che i lock avanzati sono invulnerabili? No sicuramente. Ma siccome costano tanto, usiamo i lock con la vulnerabilità perché non proteggiamo qualcosa di sacro. Se più sicurezza è richiesta, usiamo i lock avanzati.

Sistemi sicuri

Importante: tutti i sistemi contengono vulnerabilità. Le vulnerabilità a volte sono errori, ma spesso sono intrinseche. Per dire, un computer senza energia prima o poi si spegne e non lo puoi usare. Non esiste un sistema senza vulnerabilità. Se ti basi su quella per dire se un sistema è sicuro, allora nessun sistema è sicuro. Come definiamo la sicurezza? Non la definiamo come sicurezza assoluta, perché nessuno la ha. Per dire, noi siamo vulnerabili biologicamente: prima o poi moriamo. Però cerchiamo di proteggerci lo stesso. Non possiamo essere invulnerabili, però cerchiamo di essere il più protetti possibile. Un sistema quindi è sicuro se "lo è abbastanza". Chiedere "il sistema è sicuro" è una domanda senza senso. E per dire se lo è abbastanza serve un'altra definizione: abbastanza PER COSA. Cosa vogliamo fare col sistema? Cosa non vogliamo che succeda? Quindi diciamo sicuro "abbastanza" e diciamo abbastanza per cosa. Lo stesso sistema può essere sicuro in un contesto e non esserlo in un altro.

Cronaca di una richiesta HTTP

Risposta riassuntiva alla cronaca di una richiesta HTTP:

• Prima connessione: il PC conosce solo il proprio MAC e non ha nemmeno il proprio IP, quindi invia una richiesta DHCP.
• Il router risponde al messaggio DHCP dando l'IP del PC, l'IP del gateway e l'IP del DNS.
• Ora il PC che ha l'URL del sito deve fare una richiesta DNS, ma non conosce il MAC del gateway.
• Invia per questo una richiesta ARP a cui il gateway risponderà col suo indirizzo MAC.
• A questo punto il PC può fare la richiesta DNS al server apposito che risponderà con l'IP del sito da raggiungere.
• Il PC fa lo handshake con il sito, inviando il SYN e ricevendo il SYNACK.
• Infine il PC fa finalmente la richiesta HTTP e il sito risponderà con la pagina web.

Vulnerabilità non ovvia

C'è un bellissimo esempio di una vulnerabilità non proprio ovvia. Se leggi il codice e fai dei test potrebbe funzionare tutto, ma in realtà siccome assegni un int ad uno short potresti raggiungere una linea di codice che apparentemente non dovresti raggiungere. È una vulnerabilità aritmetica. Quel codice non fa niente di speciale, però significa che nella realtà potresti fare qualcosa che non andrebbe fatto.

Homework

HOMEWORK FOR NEXT TIME: can you find a different exploit for the same vulnerability?

Assets e minacce

Definizione di assets e threats

Dobbiamo definire altri due termini: ASSETS e THREATS. Vedi un bellissimo Hammer contro strati antiproiettile riempito di cannoni con dei militari intorno a proteggerlo, che figata. Chi è la persona più "protected" e chi è "safe" tra me e il tizio dentro l'Hammer? Quello dentro l'Hammer è più protected, ma io che sto in Italia sono safe. In pratica dipende dall'esistenza di una minaccia. È come fare una domanda del tipo perché gli aerei sono protetti e i treni no. È una domanda del cazzo perché è come dire che io non sono protetto e quei militari sì, peccato che io sto in Italia e quelli in Afghanistan.

Per prima cosa bisogna definire il THREAT, esiste una minaccia? Dicevamo ieri se un sistema è sicuro "abbastanza" e quell'abbastanza è collegato alla minaccia. Sembrano concetti ovvi ma non lo sono, perché la gente comune (ignorante e grillina) pensa che i militari se la spassano perché sono protetti e che noi siamo dei poveracci vittime della ka$ta. La sicurezza va contestualizzata, come tutte le cose: bisogna identificare quali sono le minacce e quanto la sicurezza deve essere "abbastanza".

Per valutare la sicurezza di un computer non devi guardare solo gli algoritmi usati, ma per prima cosa quanto è importante quel computer? Per esempio se stai nelle montagne del Colorado mica ti serve l'Hammer… Al massimo ti servono l'acqua perché fa un caldo boia, un telefono se stai via tanto tempo e visto che sei negli USA un fucile per i coyote. Non è un posto pericoloso, è tranquillo di per sé. Peccato che sotto quella montagna c'è un bunker nucleare, quindi se dovesse esserci una guerra nucleare quella montagna diventerebbe il posto più importante del Colorado…

Threats ed agenti delle minacce

Il THREAT lo abbiamo definito: è la minaccia, e si compone in due pezzi. La minaccia in sé e gli agenti della minaccia (chi può eseguirla). L'altro elemento che non abbiamo esplicitato è l'ASSET, cioè quello che proteggiamo e il suo valore. Nella sicurezza informatica gli asset saranno gli aspetti informatici: l'hardware a disposizione, il software, ma quello che proteggiamo davvero sono i dati. Poi ora c'è l'internet of things, ovvero i computer controllano oggetti fisici, quindi la protezione dei computer non è solo per i dati ma anche per oggetti che eseguono azioni (immagina le automobili…).

Naturalmente ci sono anche i danni di reputazione per un'azienda, che sono pure peggiori dei danni economici. Quest'ultimo è un rischio più grande da tenere in conto rispetto ai danni economici. Fa parte dell'analisi del rischio. C'era per esempio un sito di incontri fatto apposta per tradire i propri partner… Qualcuno è riuscito a prelevare tutti i dati e ha ricattato l'azienda, la quale non ha accettato e questo tizio ha pubblicato tutti i dati.

È successo un po' come nel film The Client List ma in modo più realistico: gente che si è lasciata, politici che hanno fatto una figuraccia mondiale, pure gente che si è suicidata… Si è trattato di un sito con fatturato piccolo, ma quando tutti i dati sono diventati pubblici è stata la fine del mondo. Dal punto di vista del rischio quel sito non andava proprio creato fin dall'inizio perché il danno di reputazione sarebbe stato ben più grosso dei riscontri economici.

Conclusioni su sicurezza e minacce

Bisogna quindi pensare nei sistemi informatici che da proteggere sono i tre elementi CIA. Loro sono l'asset e devi chiederti: cosa succede se questi asset vengono rubati? Non ci sono solo i danni economici. Fa parte dell'analisi del rischio.

Per esistere un threat deve esistere anche il threat agent. Il rischio può esserci teoricamente e c'è sempre, ma se non c'è l'agente non esiste la minaccia in sé. Per questo in Giappone prendono il posto posando il portafoglio o il telefono e non si preoccupano che qualcuno glielo rubi perché lì non succede MAI. Qui al Poli invece ti rubano il computer pure sotto il naso. Pazzesco… Però è così: al Poli di Como andavo tranquillamente in bagno lasciando la roba incustodita perché sapevo che nessuno ruba, anche se fisicamente è possibile che accada. Qui a Milano invece nessuno lo fa perché la minaccia esiste.

Terminologia: hacker e attacker

Ora per non far infuriare il prof ricorda che chi attacca è un ATTACKER. Lo HACKER in italiano è… smanettone? Se il termine hacker in italiano lo puoi sostituire col significato smanettone allora è usato bene. Quindi attacker per il criminale, hacker per lo smanettone. Se vuoi indicare un hacker che fa danni usa BLACK HAT HACKER, la versione informatica dei western film :D

Calcolo empirico del rischio

Interessante il calcolo empirico del rischio: asset * vulnerabilità * minacce dove le prime due variabili sono controllate, l'ultima no. Nella sicurezza bisogna bilanciare la riduzione delle vulnerabilità / contenimento dei danni con il costo. È una combinazione di elementi, e le minacce possono essere create da te stesso… O meglio la compagnia crea una minaccia per se stessa ma noi ingegneri della sicurezza non controlliamo questa variabile, però dobbiamo tenerne conto. Per esempio quando il McDonald è arrivato in Europa per la prima volta il suo slogan era proprio l'essere americano, perché faceva figo.

Peccato che in giro per il mondo (come oggi) un po' di gente odia gli americani (chissà perché), e quindi si protesta facendo tre possibili cose: bruciare la bandiera americana per strada, lanciare pietre al consolato, oppure bruciare un McDonald :D ed è così che chi gestiva la sicurezza delle infrastrutture del McDonald doveva tenere in conto la possibilità che qualcuno faceva bruciare il negozio in segno di protesta. Anche per questo hanno cambiato il marketing togliendo i riferimenti americani, anzi mo fanno pure il Parmigiano Burger col parmigiano fatto a Parma (in Ohio però).

Trade-off nella sicurezza

Come ingegneri consideriamo le vulnerabilità, gli asset e come proteggerli, anche in caso di problemi. Per esempio se qualcuno può distruggere un database, usiamo una buona strategia di backup. Tuttavia ogni scelta di sicurezza ha un costo, per questo serve un trade-off. Il costo può essere diretto: del management, delle operazioni, degli elementi fisici (hardware e software), delle persone che devono gestire gli strumenti. Sono costi diretti, più facili da prevedere e quantificare. Ma ci sono anche quelli indiretti difficili da prevedere, come l'usabilità.

Per esempio bloccare il telefono ti protegge i dati, ma diminuisce l'usabilità: ogni volta devi scrivere il pin ed è una scocciatura. Bloccare lo smartphone è diventato infatti più frequente a seguito dell'introduzione di metodi veloci come l'impronta digitale, che rende tutto più veloce. O problemi dovuti alle performance (HTTPS è più pesante di HTTP). Oppure problemi di privacy: alcuni sistemi magari costano poco come soldi, ma hanno grande impatto di privacy.