Security WatchRiesaminiamo insieme le 10 leggi immutabili della sicurezza, Parte 1

Jesper M. Johansson

Nell'anno 2000, Scott Culp ha pubblicato un saggio dal titolo "Le 10 leggi immutabili della sicurezza". È uno dei migliori saggi sulla sicurezza che abbia mai letto. Le informazioni contenute nel saggio sono fondamentali ancora oggi per ogni attività relativa alla sicurezza dei dati e consiglio a tutti di leggerlo (e di stamparlo) nel caso non l'abbiate già fatto. E' disponibile su microsoft.com/technet/archive/community/columns/security/essays/10imlaws.mspx.

Il saggio ha suscitato reazioni contrastanti. Alcuni hanno commentato con sarcasmo che in questo modo Microsoft evitava di risolvere quelli che erano considerati gravi problemi. Altri hanno definito il saggio un'opera capitale in materia di sicurezza e, vista la sua eccezionale importanza, lo hanno riprodotto a piacimento. Tuttavia, le reazioni che ho più apprezzato sono state quelle di alcuni utenti che, ispirati dall'opera, hanno creato dei propri elenchi, come quello disponibile su edgeblog.net/2006/10-new-immutable-laws-of-it-security.

Negli otto anni successivi alla pubblicazione di tale saggio, molte cose sono cambiate nel campo della sicurezza. A tale riguardo è stato pubblicato moltissimo materiale. Siamo entrati nell'era della guerra informatica (che coinvolge criminalità organizzata, entità politiche ecc.). Nuove parole e concetti sono entrati a far parte del vocabolario comune, tra cui phishing, pharming, botnet, spyware e cross-site request forgery. Alcuni tra i rootkit più sofisticati mai creati vengono eseguiti in Windows. Alcune nuove versioni dei sistemi operativi tengono conto in larga misura della sicurezza mentre altri ignorano ancora del tutto il problema della sicurezza.

L'ingegneria sociale si è evoluta a tal punto da diventare una delle principali minacce. Le violazioni di dati, come quando un grande venditore al dettaglio ha divulgato 94 milioni di numeri di carte di credito, sono all'ordine del giorno (e gli utenti continuano ancora a fare acquisti in negozi di questo tipo). I governi di Stati Uniti e Regno Unito hanno diffuso le informazioni private di una percentuale considerevole di abitanti dei paesi occidentali (e gli utenti registrano ancora le proprie informazioni personali presso questi governi). E una quantità enorme di misure di sicurezza sono entrate a far parte della nostra vita quotidiana e delle procedure dei nostri aeroporti.

Penso sia giunto il momento di riesaminare queste leggi. Considerati tutti i cambiamenti a cui abbiamo assistito nella prima parte di questo secolo, possiamo ancora affermare che tali leggi sono intoccabili? Se lo sono, e se sono riuscite a sopravvivere agli ultimi 8 anni, possiamo affermare con una certa sicurezza che probabilmente sopravvivranno per altri 10 anni.

In questa serie, suddivisa in tre parti, eseguirò un'analisi critica di ognuna delle 10 leggi. Questo mese mi occuperò delle leggi dalla 1 alla 3. Nel prossimo numero, esaminerò le leggi dalla 4 alla 7 e, nel terzo, analizzerò le leggi dalla 8 alla 10, oltre a cercare di fornire ulteriori spunti di riflessione e commenti a mio avviso sensati alla luce di quanto è successo dall'anno in cui le leggi in questione sono state pubblicate, ovvero il 2000.

Legge 1: Se un utente malintenzionato riesce a convincerti ad eseguire il suo programma sul tuo computer, quello non è più il tuo computer.

Questa legge afferma in maniera efficace che qualsiasi software eseguito sul computer può controllare lo stesso. Quando le leggi immutabili hanno fatto la loro comparsa, i sistemi operativi della Microsoft erano Windows 98, Windows Me e Windows NT 4.0. Oggi abbiamo Windows Vista e Windows Server 2008.

Su Windows 98 e Windows Me, qualsiasi software eseguito aveva il controllo completo del computer. Windows NT 4.0 aveva un modello di sicurezza sottostante molto resistente agli attacchi ma, avviandolo come amministratore, il modello di isolamento veniva declassato al pari di quelli di Windows 98 e Windows Me. Era possibile avviare Windows NT 4.0 senza privilegi amministrativi ma il sistema non funzionava correttamente ed erano pochi coloro che sceglievano questa soluzione (probabilmente il numero di utenti si contava sulle dita di una mano).

Si supponga di aver avviato Windows NT 4.0 senza privilegi amministrativi. Possiamo affermare che la Legge 1 era valida quando è stata scritta? La risposta è sì. Innanzitutto, Windows NT 4.0 presentava numerose e significative lacune. Conteneva ad esempio autorizzazioni che avrebbero potuto essere più restrittive, in particolare quelle relative agli oggetti del kernel e del registro di sistema. Esistevano inoltre molti tipi di attacchi che non erano ancora stati scoperti ma che, a detta degli esperti, sarebbero affiorati presto. Ad esempio, nel 1999 gli utenti non si erano resi conto che eseguendo i processi come utenti privilegiati sul desktop interattivo potevano compromettere l'intero computer. Soltanto nel 2002, quando Chris Paget ha pubblicato il white paper sugli attacchi shatter "Sfruttare l'API Win32", questa rivelazione è diventata di dominio pubblico (seclists.org/bugtraq/2002/Aug/0102.html).

Microsoft aveva previsto gli attacchi shatter quando la Legge 1 è stata scritta? In realtà no. Microsoft ha riconosciuto solamente che: esistono pochi limiti di protezione effettivamente in grado di impedire ad un'applicazione in esecuzione su un computer di prendere il controllo dello stesso.

Windows Vista e Windows Server 2008 sono a due generazioni di distanza da Windows NT 4.0. Hanno forse smentito la Legge 1? Esistono altri sistemi operativi che lo fanno? Dipende. I sistemi operativi più recenti offrono certamente limiti di protezione più efficaci e già nel 2000 alcuni sistemi operativi sperimentali presentavano limiti di protezione invidiabili. Tuttavia, questi limiti sono ancora insufficienti. Ad esempio, Code-Access Security in Microsoft .NET Framework è un limite di protezione. È stato appositamente progettato in modo da impedire ai codici in esecuzione nella sandbox di danneggiare il sistema operativo sottostante.

Iframes di Internet Explorer è un altro limite di protezione. Ma Iframes non interessa l'accesso al sistema operativo, bensì solo l'accesso tra parti di contenuto all'interno di una pagina Web. La Modalità Protetta di Internet Explorer, illustrata nella Figura 1, è un limite di protezione a livello di sistema operativo. Il suo scopo è quello di impedire al codice eseguito all'interno di un browser di danneggiare il sistema operativo sottostante, senza intervento da parte dell'utente. Ne esistono altri, anche se in numero limitato, come gli account utente standard, che in teoria impediscono ad un account utente di danneggiare il sistema operativo sottostante o qualsiasi altro utente.

Figura 1 Internet Explorer 7 utilizza un limite di protezione chiamato Modalità Protetta (Fare clic sull'immagine per ingrandirla)

È molto importante capire cosa si intende con il termine "limite di protezione". Non rappresenta un muro invalicabile che garantisce un isolamento illimitato e totale. Il vero significato del termine è che una società produttrice di software, Microsoft ad esempio, è tenuta a correggere ogni violazione di tale limite tramite una patch di sicurezza. Il software presenterà sempre bug e verranno portate alla luce senza dubbio nuove violazioni, così la società produttrice di software dovrà continuare a correggerle. Con il passare del tempo, tali società dovranno continuare a migliorare i propri software per impedire a queste vulnerabilità di manifestarsi. Tale affermazione sembrerebbe confermare che la Legge 1 è ancora valida.

Tuttavia, vi è ancora un punto, ben più importante, che occorre prendere in considerazione. In precedenza, avrai certamente notato l'espressione "senza intervento da parte dell'utente". La Legge 1 non tratta esattamente i difetti e le vulnerabilità del software. Riguarda in realtà le vulnerabilità degli utenti! Il verbo chiave è "convincerti". Se un utente malintenzionato riesce a convincerti ad eseguire il suo programma, probabilmente lo fa in un contesto che strutturalmente conferisce al programma privilegi elevati.

Anche se non si possiedono privilegi da amministratore ciò potrebbe non fare differenza. Anche in qualità di utente standard, si può avere accesso a numerose informazioni interessanti: documenti bancari, lettere d'amore, fotografie, video e informazioni aziendali riservate. Per un malintenzionato, tutte queste informazioni sono potenzialmente interessanti e tutto questo materiale può essere visionato senza disporre di privilegi elevati. In termini di dati memorizzati sul computer, l'esecuzione di un malware permette ad un utente malintenzionato di avere accesso a tutte le tue azioni. Pertanto, se sei solito definire il "tuo computer" come "l'insieme dei dati presenti sul tuo computer," puoi ignorare tutte le discussioni relative ai privilegi e concludere semplicemente che la Legge 1 è ancora valida.

Senza voler essere eccessivamente pignoli riguardo alla definizione di "tuo computer", sembra proprio che la Legge 1 sia riuscita a resistere al trascorrere del tempo. Il punto chiave della Legge 1 è affermare che tu, in qualità di operatore di un computer, devi assumerti la responsabilità del software in esecuzione su quel determinato computer. Se installi un driver dannoso o un codec video maligno, sei stato tu ad aver consegnato quel computer nelle mani di un criminale!

Sebbene le società produttrici di software siano in grado di fare molto per evitare danni accidentali ed è proprio per questo che vengono prodotti i limiti di protezione, l'esecuzione intenzionale di un software dannoso ha in genere la meglio su tutte le misure di sicurezza adottate. Ed ecco perché formare gli utenti è un punto chiave, oltre a garantire che essi non siano in grado di eseguire attività amministrative. Pertanto, possiamo affermare con certezza che la Legge 1 è tuttora valida, sebbene sia necessario apportare una piccola modifica alla definizione di "tuo computer".

Legge 2: Se un utente malintenzionato è in grado di modificare il sistema operativo del tuo computer, quello non è più il tuo computer.

In apparenza, questa legge sembra essere piuttosto chiara. E' ovvio che se un utente malintenzionato è in grado di modificare il sistema operativo del tuo computer, non puoi più fare affidamento sullo stesso. Tuttavia, il concetto di sistema operativo è cambiato con il mutare delle esigenze informatiche. Diversi anni fa, ho scritto una definizione del termine sistema operativo per The Blackwell Encyclopedia of Management (managementencyclopedia com). In tale definizione si parlava un sistema operativo che gestiva l'accesso alle periferiche di input ed output, all'hardware, eccetera. Finora non ho ancora ricevuto una copia dell'enciclopedia ed il mio contributo originale sarà andato sicuramente perso. Tuttavia, sono certo di non aver mai affermato che un sistema operativo contiene un solitario, un sistema di input tablet e transcoder video.

Poiché l'informatica diventa sempre più complessa, i sistemi operativi si sono evoluti al fine di supportare un numero crescente di funzioni. A complicare ulteriormente le cose, gli OEM contengono spesso numerosi software aggiuntivi che possono essere utili o del tutto dannosi. Alcuni di questi software aggiuntivi moltiplicano le funzionalità già previste nel sistema operativo principale.

Ad esempio, un'installazione predefinita di Windows Server 2008 Enterprise Edition ha una traccia del disco di oltre 5 gigabyte. Windows Vista Ultimate Edition contiene più di 58.000 file ed occupa oltre 10 gigabyte. E non vi sono soltanto file che vanno a comporre il sistema operativo. Mi riferisco, ad esempio, a migliaia di impostazioni di configurazione, oltre a daemon e servizi.

Tutto questo fa parte del sistema operativo. Si tratta di un termine collettivo che contiene tutti i file, le impostazioni di configurazione e i servizi, così come la totalità degli oggetti di runtime, tra cui semafori, named pipes, endpoint RPC, creati dagli stessi file e dalle impostazioni di configurazione. Persino gli elementi più astratti come l'ora del sistema ed alcuni tipi di dati, come i contenuti dei log degli eventi, fanno parte del sistema operativo.

Considerata la crescita e l'evoluzione dei sistemi operativi, è giusto affermare che modificando anche uno solo dei file si rende meno affidabile il computer? La prima risposta, quella spontanea, è no. Ad esempio, Windows Vista è dotato di edlin.exe, il vecchio editor di riga di MS-DOS. Non ne sono certo, ma scommetterei un caffè che, da quando tale sistema operativo è in commercio, edlin.exe è stato avviato solo un paio di volte su tutti gli esemplari venduti. Sono stato io a farlo entrambe le volte, quando circa tre minuti fa stavo cercando di ricordare la sintassi. Se qualcuno modifica edlin.exe o un altro file che non viene mai utilizzato, significa che quel computer non è più il tuo computer?

Edlin.exe è senza dubbio parte del sistema operativo, ma se nessuno esegue il file, come può una semplice modifica compromettere il computer? E' chiaro, la risposta è che non può farlo. Modificare una parte del sistema operativo che non è mai stata utilizzata non compromette affatto un computer. E sono tante le sezioni del sistema operativo che non vengono mai utilizzate.

Nonostante quanto affermato finora, la seconda risposta è sì. Non si può considerare soltanto l'esecuzione di un file finalizzata a verificare se la modifica compromette o meno il computer. La questione è molto più sottile. Prova a dare un'occhiata all'elenco di controllo di accesso (ACL) per edlin.exe, illustrato nella Figura 2.

Figura 2 L'ACL per edlin.exe è molto restrittivo (Fare clic sull'immagine per ingrandirla)

L'ACL per edlin.exe è molto restrittivo. Soltanto il servizio TrustedInstaller ha il diritto di modificare il file eseguibile. Questa affermazione è molto importante: significa che, quando un utente malintenzionato modifica il file in questione sul tuo computer, provoca un effetto indiretto. La modifica di edlin.exe implica quindi che quello non è più il tuo computer. Il fatto rilevante in questo caso è che un utente malintenzionato sia in grado di modificare edlin.exe. Se l'utente malintenzionato riesce a modificare il file, può modificare qualsiasi tipo di file, il che significa che non potrai più fare affidamento su quel computer.

Il sistema operativo si protegge da solo. I servizi sono protetti contro le modifiche non autorizzate. Le impostazioni di configurazione sono protette contro le modifiche non autorizzate. I file su disco sono protetti contro le modifiche non autorizzate. Persino i semafori e gli endpoint RPC utilizzati dal sistema operativo sono protetti contro le modifiche non autorizzate. Se un utente malintenzionato può modificare uno qualsiasi di questi file, significa che è in grado di modificarli tutti, e probabilmente lo ha già fatto.

Questo è ciò che conta. Nelle leggi immutabili, non è l'azione ad indicare che il tuo computer è stato compromesso. Il punto fondamentale è che qualcuno sia in grado di compiere quell'azione. Ciò non va trascurato. In ogni aspetto della sicurezza, occorre sempre tener presente che la capacità è di gran lunga più importante dell'azione stessa.

Se un computer naviga su Internet senza patch di sicurezza per mesi, possiamo ancora definirlo un computer sicuro? No. Il computer è da considerarsi compromesso. Non si può più fare affidamento su un sistema che potrebbe essere stato violato. (Ho affermato esattamente lo stesso cinque anni fa nel mio articolo "Aiuto!" Sono stato attaccato. Che fare ora? disponibile su technet.microsoft.com/library/cc512587.) Se ti stai confrontando con un avversario esperto, è possibile che un sistema compromesso non mostri alcuna traccia di compromissione. Il sistema potrebbe sembrare perfettamente normale.

Senza dubbio, la Legge 2 è ancora valida. Se un utente malintenzionato è in grado di modificare qualsiasi oggetto protetto sul tuo computer, quello non è più il tuo computer. Va tenuto presente che ciò che conta non è modificare concretamente i file, quanto piuttosto essere in grado di farlo.

Legge 3: Se un utente malintenzionato ha accesso fisico illimitato al tuo computer, quello non è più il tuo computer.

Nel 2000 questa legge non venne compresa subito. Molti utenti non si rendevano conto di cosa sia possibile ottenere avendo accesso fisico ad un sistema. Del resto, persino alcune agenzie governative che avrebbero dovuto capirlo meglio di altri, sono rimaste completamente all'oscuro di questo problema. Allora le linee guida sulla sicurezza consigliavano di abilitare lo spegnimento senza che l'opzione di accesso fosse disabilitata. Il tasto Spegni nella schermata di accesso era pertanto grigio. La teoria alla base di questa convinzione era che, per spegnere il computer, l'utente doveva prima effettuare l'accesso, creando in tal modo un registro che permetteva di verificare chi avesse spento il sistema.

Si tratta di un caso esemplare di ragionamento insensato. Per aver accesso al tasto Spegni dalla schermata di accesso, occorre prima di tutto sedersi davanti ad un computer. E se sei seduto al computer e hai davvero intenzione di spegnere il computer, puoi sempre utilizzare il pulsante rotondo sulla parte anteriore del case, o meglio ancora, scollegare il cavo di alimentazione. Il sistema si spegne. E della persona che ha compiuto questa azione non rimane alcuna traccia.

Windows 2000 è dotato di un'impostazione di sicurezza chiamata Consenti il disinserimento senza l'accesso, opzione tuttora disponibile in Windows Vista, come illustrato nella Figura 3. Il principio era lo stesso. Al fine di disinserire un computer portatile dal proprio alloggiamento di espansione è necessario accedere in primo luogo al sistema.

Figura 3 Perché non rubare sia il computer che l'alloggiamento di espansione? (Fare clic sull'immagine per ingrandirla)

La protezione effettiva fornita da questa impostazione è alquanto dubbia. In teoria, se chiunque può arrivare al computer e disinserirlo, allora qualcuno potrebbe rubarlo facilmente. Non che io voglia rubare un computer portatile, ma se volessi farlo, questa misura preventiva di certo non mi dissuaderebbe. Probabilmente, prenderei sia il computer portatile che l'alloggiamento di espansione. Caspita, ruberei anche il cavo di rete e di alimentazione. Si tratta solo di apportare una piccola modifica alla sicurezza!

L'accesso fisico al computer è diventato un argomento d'attualità quando Petter Nordahl-Hagen ha creato Offline NT Password & Registry Editor. La sua creazione era semplicemente un disco di avvio di Linux con un driver del file di sistema NTFS sperimentale che permetteva l'accesso di lettura e scrittura ad un volume NTFS. Il software sul disco di boot montava il Registro di sistema sul computer locale e inseriva una nuova password per l'account amministratore nel SAM (gestione delle risorse software). Occorrevano soltanto l'accesso fisico al sistema ed un paio di minuti.

Era proprio per contrastare simili tool che venne scritta la Legge 3. Infatti il tool di Nordahl-Hagen veniva utilizzato in molte dimostrazioni. Sfortunatamente, la maggior parte degli utenti non ha mai capito il senso di questo problema. Ho utilizzato personalmente il tool in alcune dimostrazioni, poi ho smesso di farlo perché ero stufo di sentirmi ripetere "Come facciamo a garantire che nessuno dei nostri utenti conosca tool come questo?" oppure "Cosa sta facendo Microsoft per risolvere questo problema?" Gran parte dell'industria IT, un fatto allarmante, non voleva accettare o comprendere che l'accesso fisico è il più pericoloso di tutti.

In tale contesto, la Legge 3 è una norma davvero importante. Tuttavia, i critici l'hanno attaccata senza pietà. Veniva derisa come un tentativo di Microsoft di evitare di risolvere i problemi potenzialmente imputabili, anche nei casi più remoti, all'accesso fisico. In diversi casi la legge 3 è stata utilizzata per respingere relazioni sulla vulnerabilità, compresa quella su Offline NT Password & Registry Editor. Bloccare gli utenti malintenzionati che hanno accesso fisico al sistema è possibile in un solo modo: accertandosi che non possano avere accesso a nulla.

È questo il punto debole della Legge 3, apparsa finora inattaccabile. Da quando le leggi sono state pubblicate, le tecnologie di crittografia dei dischi sono diventate sempre più affidabili. Con una crittografia totale del disco rigido, o più correttamente, una crittografia dell'intero volume, un volume completo (quello che negli altri sistemi operativi è chiamato partizione) può essere codificato. Dunque se l'intero volume di avvio (in altre parole, il volume con il sistema operativo) viene codificato, la domanda che dobbiamo farci è questa: la Legge 3 è ancora valida?

La risposta è, senza dubbio, forse. In primo luogo, occorre memorizzare da qualche parte le chiavi di decrittografia. Il posto più semplice dove memorizzare le chiavi, nonché l'opzione predefinita di BitLocker, è un chip Trusted Platforms Module nel computer. In tal modo, il computer non è protetto all'avvio. Una volta che il computer è acceso, un utente malintenzionato, pieno di risorse e ben finanziato, che dispone del controllo fisico permanente sul computer può attaccarlo in innumerevoli modi. Dato che il computer può essere connesso ad una rete arbitraria, esistono diverse modalità correlate alla rete per attaccare il sistema.

Un utente malintenzionato, ad esempio, potrebbe leggere o scrivere una memoria mediante una periferica di accesso diretto alla memoria (DMA), come un'unità di memoria flash USB. Una volta che il computer è acceso e che l'utente malintenzionato ha accesso fisico allo stesso, i giochi sono fatti.

Se le chiavi non sono memorizzate sul computer, il successo dell'attacco dipende dalla possibilità dell'utente malintenzionato di riuscire ad ottenere o indovinare le chiavi. Se per avviare il computer viene utilizzato un codice PIN, è probabile che l'utente malintenzionato indovini il codice in maniera relativamente facile. Se le chiavi sono memorizzate o sono derivate da una periferica hardware separata, ad esempio un'unità di memoria flash USB o una chiave con una password monouso, l'utente malintenzionato deve accedere a tali periferiche separate. Certo, esistono diversi modi per ottenere tali chiavi o per rendere la vita difficile alla persona che ha accesso alle stesse ma, nonostante tutto, lo sforzo richiesto è probabilmente maggiore.

E' anche possibile interpretare la Legge 3 in un modo leggermente differente: "Se l'utente malintenzionato ha accesso fisico al tuo computer, è probabile che il computer sia stato rubato ed è pertanto improbabile che riuscirai a riaverlo". Da questo punto di vista, il computer non è più tuo. E sempre da questo punto di vista, l'utente malintenzionato potrebbe anche non avere interesse ad impossessarsi dei dati sul computer. Tuttavia, non è questa la riflessione alla base della Legge 3. Essa intendeva sottolineare che un utente malintenzionato può accedere ai dati sul tuo computer e non solo al computer stesso.

Considerando tutto ciò, possiamo affermare che la Legge 3 è ancora valida. Senza dubbio alcune delle tecnologie odierne hanno fatto grandi progressi per impedire ad utenti malintenzionati di avere accesso fisico ad un computer, limitando in tal modo il numero di utenti in grado di avere accesso ai dati di un computer in cui sono presenti misure di sicurezza. Detto questo, sono le capacità di un utente malintenzionato a stabilire fino a che punto egli si potrà spingere e le nuove tecnologie tengono conto di molte problematiche messe in evidenza dalle 10 leggi immutabili. Ma l'accesso fisico offre ancora la possibilità, anche se più complicata, di entrare in un sistema.

Fino ad oggi le leggi immutabili della sicurezza si sono dimostrate molto adattabili, sia rispetto ai progressi tecnologici che al passare del tempo. Delle prime 3 leggi, la terza è la più instabile, sebbene in alcuni casi sia ancora valida. Si tratta, tuttavia, della legge che presenta le attenuazioni più solide e più facilmente disponibili. Nei prossimi due numeri di TechNet Magazine riprenderò questo argomento per stabilire se le Leggi dalla 4 alla 10 sono ancora valide.

Jesper M. Johansson, è un Software Architect e si occupa della sicurezza dei software. Collabora inoltre con la rivista TechNet Magazine in qualità di redattore. Ha conseguito un dottorato in gestione dei sistemi informatici, vanta un'esperienza più che ventennale sul tema della sicurezza; è inoltre Microsoft Most Valuable Professional (MVP) per la protezione delle aziende. Il suo ultimo libro è Windows Server 2008 Security Resource Kit.