mercoledì 4 gennaio 2017

mercoledì 22 febbraio 2012

Installare Ubuntu 11.10 su un portatile ASPIRE 5732Z

Ormai sono passati quasi 10 anni da quando ho iniziato a conoscere l'Open Source.

Ricordo che frequentavo un corso tecnico e facevo una grande fatica a capire che tra macchina e sistema operativo c'è l'essere umano, che è libero di scegliere cosa e se utilizzare un pacchetto piuttosto che un altro.

Ricordo che al mio primo Installation Party, portai un portatile, un Fujitsu, non ricordo più che modello fosse.

Il sistema operativo che installai era Ubuntu, non riusciva a riconoscere l'hardware (né scheda video né scheda di rete), praticamente vedevo lo schermo a pixel e al massimo potevo navigare solo se mi collegavo direttamente al modem.

... un disastro!!! Nella mia mente da newbie non riuscivo a venirne fuori, era stata plagiata dalla mentalità Microsoft (mouse, puntatore, installa, installa, ok)

Di tempo ne è passato, direi quasi un decennio e sia io che Ubuntu abbiamo fatto passi da giganti.

Per lavoro e studio, ho bisogno sia del sistema operativo Windows che di quello libero, ho scelto, ancora una volta Ubuntu.   Ho dovuto partizionare il disco fisso del portatile che uso abitualmente, un ACER ASPIRE 5732Z, all'inizio i dubbi erano altissimi, il primo fra tutti, quello di rovinare il Master Boot Record del sistema e l'impossibilità di utilizzare anche la partizione con il sistema Windows, con spreco di tempo nel ripristinare tutto.

Ma non potevo rinunciare ad installare Ubuntu. Così ho scaricato da Windows il pacchetto dal sito di Ubuntu, (ci vuole un po' di tempo). Senza masterizzare l'ISO, lancio l'eseguibile scaricato (wubi.exe).
Viene scompattato e si avvia una procedura guidata (tipica di Microsoft) che porta al partizionamento del sistema per l'installazione, dopo il riavvio, di Ubuntu, e la creazione anche di un nome utente e di una password.

Il sistema chiede il riavvio che può essere immediato o manuale. Al riavvio, con grande mio sconforto, osservo solo uno schermo nero, senza la possibilità di effettuare nessuna modifica.

Il pensiero che Ubuntu non riconoscesse qualche hardware mi è saltato subito in mente, ma mi sbagliavo... effettuando ricerche nella rete ho letto che si trattava solo di un problema di illuminazione del monitor, premendo contemporaneamente i tasti funzione per l'illuminazione, lo schermo si illumina di  un bel celeste.

Si tratta di Grub, permette di provare o installare Ubuntu. È possibile cambiare le opzioni di boot... premere F6 per scegliere la lingua, dopo averla scelta premere Esc e scrivere in fondo alla riga di boot le lettere acpi_osi=Linux - premere Invio e lanciare l'installatore. Lo schermo diventerà nero, per schiarirlo utilizzare i tasti di illuminazione.

Sin dalla prova, il sistema è funzionante, riconosce la rete, la scheda video, gli hard disk esterni.

Per aggirare il problema dell'illuminazione iniziale, modificare
  il file /etc/rc.local aggiungendo prima della riga exit 0 la riga setpci-s 00:02.0 F4.B=00 e modificare il file /etc/default/grub alla linea GRUB_CMDLINE_LINUX_DEFAULT  in quiet splash acpi_osi=Linux

Il link da cui mi sono documentato è questo, è fornita da UNKNOWN47 segue una procedura più complessa, nel mio caso non è stato necessario seguirla, ma è stata molto utile.

martedì 27 settembre 2011

Sicurezza informatica e politica

È di qualche giorno fa la notizia che la Fondazione Magna Carta insieme alla Microsoft e a Glocus hanno promosso un convegno dal titolo  "Tutela del consumatore e sviluppo delle nuove tecnologie, i nuovi strumenti per una maggiore consapevolezza della Privacy on line" presso la Sala della Mercede della Camera dei Deputati.

Tra i relatori sono presenti esperti tecnici, nonché esponenti rappresentativi delle aziende che hanno promosso il convegno, ma anche esponenti politici.

Dal rapporto è emerso che ormai gli utenti della rete sono consapevoli del rischio sicurezza che corrono nel momento che utilizzano un computer in rete.

Gli utenti sanno che la loro privacy non è al sicuro, e dati sensibili, come numeri di carte di credito e di conto corrente sono facilmente reperibili attraverso l'uso di worm e trojan che sniffano la rete, catturano i dati e li inviano ad hacker che sfruttano la rete per i propri fini personali.

Per difendersi dalle minacce gli strumenti più usati vanno dall'aggiornamento degli antivirus e da politiche 'controllate' dei firewall, all'utilizzo di password complesse.

Fin qui, come esperta di sicurezza informatica, mi sembra che i dati raccolti rispondano a quella che è la realtà italiana sulla prevenzione della sicurezza informatica.

Ma si tratta sempre di un rapporto non obiettivo, soprattutto se penso che l'azienda software che l'ha promosso è la Microsoft. È opinione diffusa e generalizzata che i sistemi Microsoft sono quelli più soggetti a minacce informatiche, minacce che sfruttano debolezze interne del suo codice, e debolezze esterne prodotte nelle installazioni di default dei software.

Mi sembra strano che nelle interviste sia stato chiesto agli utenti di valutare la fiducia della tutela e della privacy riposta negli enti o Istituzioni Politiche, soprattutto per quando riguarda i dati che transitano nella rete, visto che ad eccezione del flag per il consenso alla gestione dei propri dati che si appone quando si compila un forum, non vedo altri interventi pro sicurezza dei dati online.
Infine non posso non sottolineare il fatto che, ancora una volta, non sia stata garantita una 'par condicio'. Gli strumenti più diffusi e più importanti per combattere le minacce e garantire la sicurezza dei dati nella rete sono Open Source per quale motivo il sondaggio è stato chiesto alla Microsoft?

Il discorso è sempre lo stesso, gli affari vanno a pari passo con le conoscenze politiche e molto spesso quello che viene offerto non è proprio quello utile per chi viene amministrato.

venerdì 23 settembre 2011

BIC: Browser Integrity Check

Il problema della sicurezza informatica è all'ordine del giorno, in continuazione nascono nuove minacce. Tante sono le misure di sicurezza adottate, antivirus, NIDS (Network Intrusion Detection Sistem), analisi del traffico, risultano inutili se non viene garantita l'integrità del sistema. Integrità che passa attraverso l'integrità del browser, attraverso il quale client e server si pongono in comunicazione.

Appare evidente quanto sia importante garantire l'integrità del sistema non solo a livello del client ma anche a livello del server.


Dal punto di vista del client, il browser che vuole essere un Trusted Browser Secure Strategy deve fornire un metodo usato nelle operazioni di sicurezza, per verificare la sua integrità.

Il modulo è scritto in JavaScript per garantire l'indipendenza dalle piattaforme e dai browser.

Quando un web browser si connette ad un web server in un'architettura fidata (TBSA), chiama il metodo tbsa.browserIntegrityCheck(serverCallbackURL); che invoca la funzionalità presente nel server, appunto la serverCallbackURL. Il browser esegue il controllo di integrità del browser attivando una xmlHTTPrequest, tramite la funzionalità serverCallBackURL. Con questa procedura si invia la firma digitale del client al web server.
                    +-----------------------------------------------+
                    |           Browser-Integrity Check             |
                    |                   HTTP/POST                   |
                    +-----------------------------------------------+
                    |POST <some_serverCallback_url> HTTP/1.0        |
                    |From: <user_specification>                     |
                    |User-Agent: <browser-specfied agent>           |
                    |Content-Type: application/x-www-form-urlencoded|
                    |Content-Length: 32                             |
                    |                                               |
                    |browserName=<some_browser_name>&               |
                    |digitalSignature=<browser_digital_signature>   |
                    +-----------------------------------------------+

Fonte http://tools.ietf.org/html/draft-caldwell-tbsa-00

Quando il tbsa.browserIntegrityCheck() invia la sua firma digitale al serverCallbackURL, il modulo nel web server valuta la firma digitale per determinare se il browser è fidato.
Il controllo di integrità del browser lato server invia un TOKEN che solo il browser che ha inviato la richiesta può interpretare, è inviato in risposta alla richiesta xmlHTTPrequest; il browser abile a processare o interpretare il token, si aspetta di rispondere con lo stesso codice con cui era stato invocato il metodo precedente tbsa.browserIntegrityCheck().

Il TOKEN ricevuto dopo la terminazione del tbsa.browserIntegrityCheck() deve essere verificato nuovamente con il server. Per far questo, il codice usato per far avviare il controllo di integrità del browser deve inviare il TOKEN al suo componente lato server per la validazione lato server. Quest'ultimo potrà rispondere con un valore booleano o disconnettere la sessione.

Ecco il processo di controllo dell'integrità del browser:
 
               +-------------------------------------------------------------+
               |                TBSA Browser-Integrity Check                 |
               |                     Client-side Example                     |
               +-------------------------------------------------------------+
               |                                                             |
               |<script type="text/javascript">                              |
               |      if(tbsa){                                              |
               |           var bicToken=tbsa.browserIntegrityCheck(          |
               |                          "http://foo.com/tbsa-bic.php"      |
               |                        );                                   |
               |                                                             |
               |           if(myApp.tbsaBicXverify(bicToken))){              |
               |                                                             |
               |            /* Browser-Integrity Check token is verified */  |
               |                                                             |
               |           } else {                                          |
               |                                                             |
               |              /*Browser Integrity Check failed!*/            |
               |                                                             |
               |           }                                                 |
               |      }else{                                                 |
               |                                                             |
               |              /*Browser is not TBSA-compliant*/              |
               |                                                             |
               |      }                                                      |
               |  </script>                                                  |
               +-------------------------------------------------------------+ 

Fonte http://tools.ietf.org/html/draft-caldwell-tbsa-00

La gran parte del TBSA è implementata lato client. Comunque, per realizzare i benefici del TBSA, alcuni elementi lato server sono necessari. La libreria TBSA deve essere indipendente da piattaforme, ed essere utilizzata dai principali linguaggi di programmazione lato server (PHP, JAVA, Python). Per implementare il controllo di integrità del browser lato server si richiede che le librerie TBSA hanno due componenti:  tbsa.bicValidate() e tbsa.bicXvalidate().

tbsa.bicValidate() è il modulo è usato dalla chiamata serverCallBackURL usato lato client per ottenere il BIC TOKEN. Questo metodo deve disporre di un certificato digitale X.509 e capace di validare lo stesso. Questo significa che tbsa.bicValidate potrebbe usare un progetto esistente come openSSL per validare il certificato o applicare qualche strategia proprietaria. Il metodo tbsa.bicValidate()  deve essere capace di generare un BIC TOKEN random per il ritorno dell'entità chiamata. Un metodo semplice per ottenere una stringa random è utilizzare un hash SHA512. Comunque, questo TOKEN deve essere verificato attraverso tbsa.bicXvalidate(). I TOKEN possono essere conservati lato server per un certo periodo di tempo ed è possibile anche utilizzare TOKEN eterni.

tbsa.bicXvalidate() è la controparte di tbsa.bicValidate(). Si tratta di un metodo che permette di ricevere un TOKEN dal client e confrontarlo con i TOKEN registrati da tbsa.bicValidate().Inoltre, per minimizzare il piano di attacco dei TOKEN registrati, tbsa.bicXvalidate() deve rimuovere qualsiasi TOKEN che ha validato, questo permette di conservare le risorse lato server, ma evita che un browser possa indovinare un valido TOKEN e invalidare il framework TBSA.


Fonte http://tools.ietf.org/html/draft-caldwell-tbsa-00

venerdì 16 settembre 2011

Enterprise security management (ESM): la legge non è chiara



La normativa sulla protezione dei dati personali è presente da più di dieci anni e ancora non è chiaro, ne tanto meno è stato messo in pratica, come garantire la privacy sia all'interno che all'esterno dell'organizzazione.

Il documento sulla privacy risulta in molti punti generico e a volte non completo, lascia molto spazio alla libera interpretazione. È per questo che il titolare/amministratore dell'organizzazione deve adoperarsi per gestire la sicurezza e la privacy sia relativamente ai soggetti interni che a quelli esterni.
Deve, in altre parole, individuare in maniera distinta il 'titolare del rapporto', il 'responsabile del trattamento e l''incaricato del trattamento'.

Questa è una scelta complessa, considerando le diverse figure professionali presenti in un'azienda, quali l'amministratore di sistema, l'operatore di sistema, l'utente.

All'inizio della stesura del documento, il garante non aveva assolutamente previsto queste figure professionali forse anche per effetto del carattere ancora giovane della gestione dei processi e delle organizzazioni gestite tramite reti digitali. elle successive integrazioni del documento si sono specificati i ruoli e le funzionalità svolte dalle figure interessate dal settore informativo fino ad arrivare nell'ultimo Decreto Legislativo del 2003 (n. 196) in cui viene tralasciata la specifica dei termini per ritornare all'originaria tripartizione dei soggetti responsabili dei dati.

La realtà, invece, è ben diversa e richiede una particolare attenzione. La gestione organizzativa dei
processi aziendali non può prescindere dalla formazione e dal flusso di informazioni che deve
essere garantito ad ogni livello del management.

Per questo motivo il Garante per la privacy ha emanato un documento che ne disciplina in maniera chiara le figure dell'amministratore di sistema e delle figure correlate, il documento si chiama Misure e accorgimenti prescritti ai titolari dei trattamenti effettuati con strumenti elettronici relativamente alle attribuzioni delle funzioni di amministratore di sistema, ed è stato emanato a fine novembre 2008. Il documento si prefigge, in primo luogo, di richiamare l'attenzione sui rischi e le criticità delle funzioni svolte dai sistemisti, nonché dagli operatori dei sistemi informatici.

Si individuano ruoli, identificando l'Amministratore di sistema come una figura professionale finalizzata alla gestione e alla manutenzione di un sistema di elaborazione; le cui attività sono dirette al salvataggio dei dati (backup/recovery), l'organizzazione dei flussi di rete, l'organizzazione della circolazione delle informazioni all'interno della rete, la manutenzione dell'hardware e dei supporti di memorizzazione, come hard disk esterni; ma anche le responsabilità in modo da evitare il rischio che si abusi delle funzionalità conferite, essendo in grado di accedere direttamente e agevolmente ai dati gestiti nei sistemi informatici.

Le norme che regolarizzano gli abusi sono relativamente al sistema informatico telematico (art. 615-ter), alla frode informatica (art. 640-ter), al danneggiamento di informazioni, dati e programmi informatici (art. 635-bis e -ter) e al danneggiamento di sistemi informatici telematici (art. 635-quater e -quinquies).

venerdì 2 settembre 2011

Man-in-the-browser

Non a caso il primo post di Security Strategy parla dell'attacco Man-in-the-Browser,  oggi con la diffusione della rete e il proliferare di blog, contenuti multimediali, transazioni e comunicazioni, i web browser, con i quali i contenuti sono prodotti, fruiti e forniti, risultano essere le applicazioni più interessati dagli attacchi informatici.

L' attacco MitB non fa differenze tra browser, si verifica indipendentemente se si tratta di Chrome, Explorer o Firefox, per citare solo i più diffusi. Si diffonde in maniera semplice e solo per scelta, inconsapevole, dell'utente. L'utente scarica in locale, nel client, un programma che l'utente considera utile, in realtà è un trojan horse, un programma che eseguito raccoglie informazioni riservate o apre porte di sistema all'accesso non controllato dall'esterno.

Non si tratta, quindi, di un vero e proprio virus, perché il Trojan non ha capacità di replicarsi, ma solo di fare da testa di ponte ad attacchi ancora più distruttivi.

L'attacco MitB rientra nella tipologia degli attacchi che sfruttano le comunicazioni client-server, in particolar modo le sessioni che si instaurano per l'invio e la ricezione di contenuti. Le sessioni sono memorizzate sui server insieme al loro identificativo, lo scopo è quello di individuare univocamente le comunicazioni intercorse con ciascun utente. Lo scopo del Trojan è quello di catturare e modificare le chiamate che il browser fa alle librerie e ai meccanismi di sicurezza.

L'identificativo di sessione è anche sfruttato nell'Hijacking attack, intercettare la comunicazione tra client e server e 'rubare' l'identità dell'utente legittimo.

Come tutti gli attacchi informatici, l'obiettivo principale dell'attacco MitB è quello di porre in essere frodi finanziarie, intercettando operazioni bancarie effettuate on line da  utenti, che non sanno minimamente di avere nel proprio computer un programma che comunica a qualcuno nella rete le proprie generalità, il numero di carta di credito, le password e via dicendo...

L'attacco è posto in essere in due fasi. Nella prima  viene installato un Trojan sul computer della vittima, alla quale rimane invisibile, camuffato da software di aggiornamento, quando in realtà cattura o modifica le transazioni prima che siano inviati alle librerie di sicurezza invocate dal browser e presenti nel sistema.

A questo punto, nella seconda fase, vengono inviate all'intruso le informazioni necessarie per impersonificare il computer vittima.

All'utente, d'altro canto,  viene ritornata la pagina con i valori attesi, in modo da non destare nessun sospetto.

La vittima difficilmente può scoprire questo attacco, visto che tutti i mezzi messi a disposizione per garantire la sicurezza, come ad esempio le librerie Sicure Socket Layer, sono attivi e funzionanti.

Visto che l'autenticazione tradizionale non funziona, il sistema per evitare questo attacco è quello di  utilizzare browser fidati riconosciuti come tali dal web server utilizzato per la transazione.

Nel draft Trusted Browser Security Architecture (TBSA) si propone di bloccare tutti gli add-on e le estensioni del browser, ma questa soluzione, a detta degli stessi autori, non è una valida soluzione al problema. Se si pensa ai plug-in come Flash Player, Adobe Reader, Java, QuickTime, indispensabili per accedere ai contenuti  nella rete, bloccarli significherebbe non visualizzare la maggior parte delle informazioni presenti nella rete.

Una proposta fatta da alcuni ricercatori dell'Università della California, Barth, Porter Felt, Saxena e Boodman, è quella di proteggere i browser dalle vulnerabilità che possono affliggere le estensioni, curando le estensioni attraverso alcuni punti importanti:
  • restringere i loro privilegi rispetto al browser;
  • isolarle e/o separarle;
  • migliorare la loro sicurezza.
La soluzione prevede l'utilizzo di un API (Application Programming Interface) per il browser, utilizzabile dai linguaggi di programmazione client-server, come JavaScript e che permette ad un'applicazione Trusted Browser Secure Architecture (TBSA) di identificare e negoziare il livello di sicurezza richiesto nell'interscambio di messaggi tra client e server prima di iniziare la comunicazione. Naturalmente questo è possibile solo dopo aver fatto un controllo di integrità sia del web browser, che del web server.

 Altra soluzione implementate dai sistemi finanziari per garantire l'associazione unica tra account bancario e cliente è quello della verifica della transazione e dell'autenticazione attraverso un canale diverso da quello del web, in genere ad accesso al sistema on-line o a transazione avvenuta con carta di credito, viene inviato un sms al telefono cellulare comunicato dal cliente per avvertirlo che è avvenuto un accesso al sistema con le sue credenziali e/o che la transazione è avvenuta con successo, questo sistema è conosciuto come Out-of-Band (OOB) Authentication and Transaction Verification.
 Tuttavia anche questo sistema non può essere adottato in sicurezza, poiché non rileva la presenza o meno di un trojan che sta infettando il browser mentre si compiono operazioni riservate.

Riferimenti:
http://www.acros.si/papers/session_fixation.pdf
Wikipedia
OWASP
Trusted Browser Security Architecture (TBSA)  
Out-of-Band (OOB) Authentication and Transaction Verification