93299 Letture

Sicurezza: minacce, difese e consigli tecnici

Il browser è il nuovo sistema operativo

Con il termine “Web 2.0”, probabilmente un pò troppo inflazionato, si usa indicare l'evoluzione del Word Wide Web (WWW) evidenziatasi nel corso degli ultimi anni: il web è oggi sempre più “dinamico” e favorisce in modo molto spiccato l'interazione con gli utenti. Sono esempi di “Web 2.0” la diffusione di vere e proprie applicazioni che “funzionano online” e che assolvono ai compiti più disparati. Si pensi ai social network come Facebook oppure a Myspace o Youtube ma anche ai tanti servizi che permettono di condividere file ed informazioni attraverso la rete. Si rammentino le decine di funzionalità che Google mette a disposizione (Gmail e “Documenti e fogli di lavoro” in primis) e che sono fruibili ricorrendo unicamente al browser, una volta collegati alla rete Internet e senza avviare alcuna applicazione in ambito locale.
Proprio Google, con il lancio di Chrome, ha introdotto il concetto di un browser che evolve sempre più verso una sorta di sistema operativo integrandosi strettamente con le varie applicazioni web. Grazie alla tecnologia Gears, le “web application” possono essere anche utilizzate, sempre servendosi del browser, in modalità offline svincolandosi dalla connessione Internet. Ecco quindi che un'e-mail od un documento possono essere preparati o modificati offline e “sincronizzati” con le copie conservate online non appena la connessione torna ad essere disponibile.
E' ovvio come una simile evoluzione del browser in un'entità più complessa porti con sé inevitabili problematiche di sicurezza.

Gli aggressori concentrati nello sviluppare codici malware in grado di insediarsi sui sistemi client, sfruttano, per raggiungere il loro intento, delle vulnerabilità del browser oppure cercano di aggiungere del codice nocivo in pagine web ben conosciute (attacchi XSS e SQL Injection).
Oltre ad aggiornare tempestivamente il browser non appena il produttore rilascia patch ed aggiornamenti (l'utilizzo delle versioni più vecchie dei vari browser dovrebbe essere impedito e vietato), è possibile seguire alcune linee guida per evitare di incappare in qualche minaccia durante la navigazione sul web.
Per impostazione predefinita, ad installazione ultimata, il browser è impostato in modo che sia in grado di gestire e utilizzare correttamente un vasto numero di tecnologie per il web (ActiveX, Java, JavaScript, VBScript,...). Il nostro consiglio è quello di disattivare l'esecuzione di ActiveX e Java in Internet Explorer e di Java negli altri browser.
ActiveX è una tecnologia Microsoft per lo sviluppo di componenti riutilizzabili in diverse applicazioni. Vengono ampiamente sfruttati in Internet per dotare il client (browser web) di funzionalità atte a rendere possibile la visualizzazione di contenuti particolari, l'utilizzo di caratteristiche evolute non incluse in Internet Explorer, una maggiore interoperatività tra client e server. Buoni passi in avanti sono stati compiuti con il rilascio di Internet Explorer 7 che provvede a bloccare, in modo predefinito, molti ActiveX richiedendo all'utente un'autorizzazione esplicita per consentirne l'esecuzione. Microsoft stessa, nel corso di diversi "patch day" mensili, è stata costretta a rilasciare un aggiornamento per scongiurare eventuali attacchi rivolti nei confronti di componenti ActiveX sviluppati da terze parti. Gli aggiornamenti di solito impostano esclusivamente dei "kill bit", meccanismo di protezione che consente di impedire il caricamento di un controllo ActiveX da parte del motore di rendering HTML di Internet Explorer.

Java invece è un linguaggio di programmazione orientato agli oggetti, derivato dal C++ e messo a punto sotto la guida di Sun Microsystems con un lavoro che iniziò già nel 1991. I programmi Java che possono essere eseguiti da browser web si chiamano “applet” e sono inseribili nelle pagine Internet utilizzando apposite tag. Per fruire di un'applet Java è sufficiente che sul sistema in uso sia installato il "Java Runtime Environment" (JRE). Molti utenti, tuttavia, pur avendo installato Java sul proprio personal computer (talvolta viene fornito insieme con alcune applicazioni; ad esempio OpenOffice.org), non provvedono ad aggiornarlo tempestivamente e a rimuovere le versioni più datate del pacchetto. Navigare sul web avendo le applet Java abilitate ed utilizzando una vecchia versione del linguaggio è assolutamente sconsigliato: come qualsiasi altra software house, anche Sun rilascia periodicamente degli aggiornamenti di sicurezza per Java in modo tale da correggere tutte le falle di sicurezza via a via scoperte. Alcune di esse, com'è facile accorgersi operando qualche breve ricerca nell'archivio di Secunia, sono considerate particolarmente gravi e possono portare all'esecuzione di codice nocivo nel caso in cui l'utente visiti un sito web maligno, allestito con l'apposito scopo di creare danni, sottrarre informazioni sensibili, rubare credenziali di accesso, installare altri programmi dannosi.
Come regola generale, quindi, è bene controllare che sul sistema in uso sia presente solo la versione più aggiornata di Java JRE e, nel caso siano ancora installate release precedenti, è bene provvedere a disinstallarle manualmente dal Pannello di controllo di Windows. Nel caso in cui il normale processo di disinstallazione delle precedenti versioni di Java, da Pannello di controllo, non dovesse andare a buon fine, suggeriamo di ricorrere all'utilità Microsoft Windows Installer Cleanup. Si tratta di uno strumento che provvede ad eliminare dal registro di sistema tutti i riferimenti non validi a procedure d'installazione di Java. Il software, gratuito, è scaricabile attraverso questo link.
Prima di procedere, è comunque bene accertarsi che nessuna applicazione desktop richieda una versione di Java specifica. Non è infrequente, infatti, imbattersi in software gestionali che, per poter funzionare correttamente, necessitano (lo dichiarano esplicitamente) di una ben precisa versione di Java. Ciò, di regola, non dovrebbe comunque accadere nel caso di un'applicazione Java ben scritta.


Per verificare se il browser web è in grado di eseguire applet Java, è sufficiente collegarsi con la pagina ufficiale di test elaborata da Sun (ved. questa pagina). Immediatamente sotto il paragrafo "Test your JVM", dovrebbero comparire tutti i dettagli relativi alla JRE installata insieme con un'immagine animata. Qualora ciò non dovesse accadere, è possibile che la JRE non risulti installata sul personal computer oppure che l'esecuzione delle applet Java venga in qualche modo bloccata (da browser oppure attraverso le funzionalità messe a disposizione dai più moderni software "personal firewall" che integrano funzionalità di filtro dei contenuti inseriti nelle pagine Internet).


Gli utenti che sono costretti ad utilizzare vecchie versioni di JRE per consentire l'esecuzione di applicazioni piuttosto datate (cosa piuttosto comune con alcuni software di tipo fiscale, installati, ad esempio, presso gli studi commercialisti), dovrebbero provvedere a disabilitare l'esecuzione delle applet Java dal browser in uso (Internet Explorer, Firefox, ...). Nel caso di Firefox, è sufficiente disattivare la casella Attiva Java presente nella sezione Contenuti (menù Strumenti, Opzioni del browser). Analoga casella è disponibile, in Internet Explorer, accedendo al menù Strumenti, Opzioni Internet quindi cliccando sulla scheda Avanzate, nella sezione Java (Sun).
Attraverso la finestra di configurazione di Java (Pannello di controllo di Windows, icona Java, scheda Avanzate, Java predefinito per browser), è poi possibile disattivare il caricamento del plug-in da parte dei vari browser.


Attacchi XSS e SQL Injection: quando ad essere bersagliata è l'applicazione web

Parliamo di attacchi cross site scripting, una tipologia di aggressione che è oggi utilizzata da molti malintenzionati per rubare credenziali d'accesso ai vari servizi online, compresi quelli per la gestione di conti correnti bancari e carte di credito. Le vulnerabilità cross site scripting, spesso identificate con l'acronimo XSS, possono affliggere molti siti web, compresi quelli gestiti da aziende di gran fama. Ed, anzi, sono proprio i siti web di realtà ormai consolidate e più conosciute dagli utenti ad essere maggiormente prese di mira per questo genere di attacchi.

Ogniqualvolta facciamo clic su un collegamento ipertestuale, presente in una pagina web, il nostro browser (client) invia una richiesta al server web, attraverso il protocollo HTTP. I metodi di richiesta di una pagina web possono essere diversi sebbene i principali, ai quale i tecnici si riferiscono prevalentemente, siano GET e POST. In HTML, nel momento in cui si vogliano trasmettere delle informazioni al server, ad esempio i dati inseriti in un comune modulo online ("form"), si utilizza solitamente il metodo POST: i dati vengono codificati dal browser sotto forma di un URL. Nel caso di GET, invece, il contenuto delle variabili trasmesse ad una pagina web, verrà visualizzato direttamente nella barra degli indirizzi del browser.
In tutte le pagine web dinamiche, il cui contenuto, cioè, viene generato dal server al momento della richiesta proveniente dal sistema client collegato e che quindi, di volta in volta, può differire, si analizzano le richieste GET e POST per visualizzare il materiale richiesto dall'utente (client). In particolare, i dati ricevuti attraverso richieste GET e POST viene solitamente impiegato, previa analisi ed eventuali rielaborazione, per effettuare interrogazioni su una base dati.


Coloro che intentano attacchi di tipo cross site scripting sfruttano delle vulnerabilità presenti nelle pagine web dinamiche per modificare il codice della pagina web successivamente proposta al visitatore oppure per effettuare reindirizzamenti verso altri siti web, diversi da quello realmente richiesto. Vulnerabilità di questo tipo derivano da una imperfetta gestione del contenuto delle variabili utilizzate dalla pagina dinamica. In queste circostanze, un aggressore può "inettare" del codice JavaScript "maligno" all'interno di una pagina web.
Precisiamo subito che gli attacchi cross site scripting non agiscono assolutamente "lato server". In altre parole, non è il server che ospita la pagina dinamica ad essere violato.

Supponiamo che un aggressore individui una pagina web dinamica che può essere oggetto di attacco. L'aggressore nota come tale pagina sembri elaborare numerosi parametri. Se, modificando il contenuto dei vari parametri elencati nella barra degli indirizzi del browser, la pagina web paia riutilizzarne uno o più di essi ripubblicandone il contenuto nella pagina generata dinamicamente, è possibile tentare un attacco cross site scripting. L'aggressore, allora, proverà ad inserire, in calce al contenuto di un parametro visualizzato nella barra degli indirizzi (i più "papabili" sono solitamente i valori che appaiono essere di tipo stringa), del codice JavaScript.
Qualora il programmatore della pagina dinamica non abbia opportunamente provveduto a scrivere una funzione che "depuri" i parametri in ingresso degli elementi potenzialmente nocivi (i.e. tag HTML, apici, simboli utilizzati dal linguaggio di programmazione,...) e provveda a riscrivere il contenuto del "parametro vulnerabile" sulla pagina successivamente proposta all'utente, può succedere che il codice maligno venga "iniettato" nel corpo della pagina.
Ovviamente, l'aggressore - una volta scoperta la vulnerabilità - dovrà indurre gli utenti del sito che ospita le pagine vulnerabili ad attacchi XSS, a cliccare su un link contenente lo script nocivo.


Si pensi di aver a che fare con una pagina web dinamica (php) così richiamata: http://www.nomedominio.xx/paginavulnerabile.php?p1=ciao&p2=123&p3=abc
L'aggressore scopre che il contenuto del parametro "p1" viene riscritto sulla pagina generata senza alcun controllo preventivo. Egli, allora, provvede a richiamare la pagina dinamica posponendo al contenuto ciao del parametro "p1" il codice javascript "maligno", ad esempio nella forma <script>...codice javascript nocivo...</script>.
Il codice JavaScript può anche contenere riferimenti a file .js dannosi memorizzati su siti web remoti, completamente diversi da quello visitato dall'utente.

Poiché il codice JavaScript dannoso, in forza della vulnerabilità legata alla non corretta gestione del contenuto del parametro in ingresso, viene eseguito all'interno dello stesso contesto del sito web visitato, se l'aggressore riuscirà ad indurre un utente a visitare il link da lui prodotto, potrà - per esempio - rubare credenziali di accesso o leggere e trasmettere altrove il contenuto dei cookie legati al sito web oggetto dell'attacco XSS.

Supponiamo di avere aperto più finestre (o schede) con il medesimo browser. L'eventuale sito "maligno" visualizzato nella prima finestra o scheda non può essere in grado di accedere ai dati visualizzati in un'altra delle finestre del browser aperte. E ciò grazie ad una particolare policy introdotta nei browser web che impedisce questi scenari.
L'attacco cross site scripting tenta, in qualche modo, di aggirare questo aspetto tecnico: allorquando l'aggressore dovesse riuscire ad "inettare" codice JavaScript "maligno" all'interno di una pagina web, tale codice verrebbe regolarmente eseguito poiché il browser lo considera come proveniente dal medesimo contesto (la stessa finestra o scheda del browser).


Servizi famosissimi come MySpace, YouTube e PayPal sono stati, nel corso del tempo, vittime di attacchi XSS. Emblematico l'incidente accaduto qualche tempo fa ad una banca italiana: gli aggressori, dopo aver individuato una pagina affetta da vulnerabilità XSS, hanno iniziato ad inviare una pesante campagna di spam, nell'intento di "intercettare" clienti della banca in questione. Nell'e-mail "phishing" veniva inserito un link contenente anche un JavaScript "maligno". La pagina oggetto della vulerabilità XSS utilizzava un certificato SSL: gli aggressori, grazie all'URL modificato trasmesso via e-mail, sono stati in grado di "iniettare" un IFRAME all'interno della pagina di login dell'istituto di credito. L'incauto utente che avesse provveduto a cliccare sul link ricevuto via e-mail avrebbe ritenuto di essere sul sito della banca. Inserendo i propri dati di autenticazione, questi sarebbero però stati trasmessi su un server "maligno" sito a Taiwan e ciò in forza della presenza dell'IFRAME maligno aggiunto via JavaScript.

Come sottolineò già a suo tempo il team di Kaspersky, è bene non fidarsi troppo delle connessioni ritenute sicure (https:). Anche in questi casi, se la pagina web è vulnerabile ad attacchi XSS il suo contenuto può essere infatti modificato.

Gli attacchi XSS sono insomma una "manna dal cielo" per coloro che si macchiano di truffe online ("phishing"). L'utente, infatti, spesso non sospetta dell'"agguato" rassicurandosi nell'osservare che subito dopo il riferimento al protocollo utilizzato (http:// od https://) sia indicato il nome a dominio di un sito web conosciuto e legittimo.

Per difendersi da attacchi XSS è sempre bene diffidare di link trasmessi attraverso la posta elettronica o via "instant messaging", soprattutto se arrivano da mittenti sconosciuti oppure non fidati.

  1. Avatar
    Salvos404
    12/04/2009 21.46.16
    Ho scaricato e installato correttamente l'aggiornamento kb967715 per windows xp(x86),ho anche controllato che sia stato installato,fin qui tutto ok;ma quando apro la finestra Criterio gruppo e faccio doppio clic sulla voce Modelli amministrativi (sezione Configurazione computer),la voce "sistema" non compare e di conseguenza non posso andare avanti.
    Esiste una soluzione?
    P.S.complimenti per l'articolo e soprattutto per il tool Secunia UTILISSIMO E LEGGERISSIMO!
  2. Avatar
    Gigiweb
    19/03/2009 00.32.27
    Senza parole ( e senza più fiato :D ) .........davvero complimenti per questo grande e completo articolo!!
  3. Avatar
    Leolas
    06/03/2009 20.18.27
    wow, complimenti per l'articolo, michele :wink:

    direi che di completi come questi se ne vedono davvero pochi in giro :)
Sicurezza: minacce, difese e consigli tecnici - IlSoftware.it - pag. 5