Può capitare a chiunque di scovare un difetto in un software: quelli dei sistemi operativi sono leggendari ma ci sono anche i difetti nei software con cui sono realizzate le infrastrutture del web : e anche di questi, soprattutto negli ultimi tempi , si fa un gran parlare. Così capita che, nelle stesse ore, a Punto Informatico giungano tre segnalazioni di altrettanti problemi a siti piuttosto noti. In tutti e tre i casi si tratta di vulnerabilità di media entità, ma abbastanza serie da essere prese subito in considerazione. E in tutti e tre i casi si trattava di vulnerabilità XSS che, dopo la segnalazione di Punto Informatico , sono state eliminate in poche ore.
Si trattava del portale Rosso Alice di Telecom Italia, del sito della Camera dei Deputati e di una sezione della rete di contatto col pubblico del Comune di Milano . Tre nomi noti, quindi, che se fossero stati presi di mira da malintenzionati avrebbero potuto diventare uno strumento molto pericoloso : chi non si fiderebbe di una richiesta giunta dal sito di una istituzione?
Un problema non da poco, ma che non viene sottovalutato: in questo settore non si improvvisa nulla, spiega a Punto Informatico il direttore Servizi Informativi del Comune di Milano, l’ing. Alessandro Musumeci : “Per le nostre politiche di sicurezza ci atteniamo al Piano Generale di sviluppo per il quinquennio 2006-11, approvato dal Consiglio Comunale”. In passato, racconta, il sito del comune meneghino aveva già incontrato qualche difficoltà: “Ma la soluzione non è diminuire le risorse messe a disposizione, piuttosto bisogna lavorare per rendere i servizi più sicuri”.
Un problema non da poco, per una rete che solo all’interno delle strutture comunali conta oltre 10mila computer collegati e che gestisce un traffico sul web che può arrivare a 500mila pagine visitate ogni giorno , attraverso gli oltre 50 servizi a disposizione del cittadino. “Stiamo rivisitando la parte infrastrutturale – spiega il direttore – eliminando quella struttura a macchia di leopardo che metteva in comunicazione tra loro le molteplici isole di cui era composta la rete”.
Un’architettura che si esponeva più facilmente ad attacchi esterni anche a causa di una comunicazione insufficiente: “Capitava spesso che alcune porzioni del network fossero attaccate o isolate, e passasse molto tempo prima che qualcuno se ne accorgesse”. Ora invece una nuova rete in fibra ottica, in via di ultimazione, tiene sotto controllo costante tutte le risorse.
“La sicurezza non è una problematica tecnica – spiega Musumeci – bensì organizzativa: non la si può affrontare semplicemente installando l’ultimo antivirus, ma gestendo un cocktail di procedure da implementare e da tenere costantemente aggiornate e sotto controllo”. Per questo il Comune ha anche approntato un numero verde di riferimento, attraverso il quale transitano le eventuali segnalazioni di problemi tecnici: gli operatori che rispondono collaborano con i sistemisti e gli admin ad individuare e risolvere le falle, nel più breve tempo possibile .
E per il futuro ? “Stiamo già lavorando ad una nuova versione del sito, che risponda meglio alle esigenze della città in previsione dell’Expo del 2015”: i programmatori sono già al lavoro per aggiornare alcune webapp seguendo i dettami ITIL , e “in tutti i nuovi contratti stipulati queste procedure sono alla base di tutti i servizi di autenticazione”. Ma cosa succede dall’altra parte della barricata? Cosa fanno e come operano i bug hunter , coloro che passano le loro loro giornate (o più spesso le nottate) a fare pelo e contropelo ai siti in giro per il web? Punto Informatico lo ha chiesto a Matteo Flora , celebre esperto di sicurezza e bug hunter nel tempo libero.
Punto Informatico : Come si scoprono le vulnerabilità di un sito web?
Matteo Flora: Le falle si “scoprono” spesso e volentieri grazie all’esperienza, che fa subito emergere come lampanti eventuali errori trasportati dal mezzo di comunicazione. Dopo un po’ di tempo passato a ricercare questo tipo di vulnerabilità, l’osservare come vengono maneggiate ed inoltrate le richieste molte volte è tutto quello che serve per ipotizzare la presenza di talune problematiche.
PI: Questione di mestiere, di pratica?
MF: Non è certo magia né tantomeno mistero: solo metodo, spirito di osservazione e spesso impegno pregresso. “It’s not Rocket Science”, anche se devo ammettere che da taluni soggetti, spesso anche italiani, ho visto emergere strategie di exploiting degne dell’ammirazione di chi osserva un’artista all’opera.
PI: Quali sono le principali vulnerabilità in circolazione?
MF: Nell’ambito della WebApplication Security tra le vulnerabilità più diffuse abbiamo il Cross Site Scripting (esecuzione di codice javascript non autorizzato all’interno di pagine web), varie ed eventuali declinazioni di SQL Injection (possibilità di sovvertire la comunicazione con la base dati al fine di sottrarre o alterare le informazioni ivi contenute) e RFI, Remote File Inclusion (la possibilità in “includere” tramite falle codice malevole lato server in applicativi).
PI: E quali di queste si portano dietro maggiori rischi per il navigatore?
MF: Alcune di queste vulnerabilità, che di per sé potrebbero essere poco o nulla pericolose, possono con perizia e maestria essere declinate ad esempio in CSRF, Cross Site Request Forgery (il meccanismo mediante il quale un utente malevolo “penetra” in un sito protetto da password utilizzando le credenziali di un utente già loggato), che ovviamente rendono altamente pericolose anche vulnerabilità che sembrerebbero “banali”.
PI: Cosa occorre fare quando si scopre una falla?
MF: Personalmente dopo decine e decine di questi episodi ho deciso di pubblicare una precisa policy scritta , adattando al panorama normativo italiano la famosa dislcosure policy di RFP (RainForrest Puppy).
PI: In cosa consiste?
MF: Il contenuto è breve e preciso: la vulnerabilità viene comunicata al vendor (proprietario del sito, del prodotto o ditta ed ente responsabili) e ci si attende una conferma della ricezione entro 5 giorni. Se la risposta non arriva si ritenta e si attendono altri 5 giorni.
PI: Se non arriva alcuna risposta?
MF: Se ancora una volta la risposta non arriva in nessuna forma, si pubblica la vulnerabilità dopo essersi sincerati di avere un contatto (quando possibile) con responsabili di sicurezza, admin, abuse, responsabili stampa o call center.
PI: E se invece gli interessati rispondono?
MF: Se invece si viene contattati allora si spiega in modo estremamente preciso tutta la problematica e si decide mutualmente come procedere. Non è necessario risolvere immediatamente la vulnerabilità, basta dare una scadenza compatibile con il buon senso.
PI: La storia finisce qui?
MF: Trascorsa la scadenza ed una volta che la vulnerabilità è stata sanata si procede in coppia o singolarmente a comunicare la vulnerabilità ritrovata: questo per un duplice motivo.
PI: Quale?
MF: Innanzitutto per permettere agli utenti che non avessero fatto un upgrade alla nuova versione di sapere che è necessario un upgrade viste le problematiche incontrate, ed in secondo luogo per permettere ad altri ricercatori indipendenti di controllare se la problematica si riflette anche su altri prodotti simili o simili realtà. Succede infatti spessissimo che una vulnerabilità su un prodotto o servizio sia riproponibile in ambiti simili o derivati.
PI: Ma chi sono i bug hunter, perché fanno quello che fanno?
MF: Se lo chiedono in molti… Alcuni ci vedono come esaltati in cerca di fama e gloria imperitura, altri come schizofrenici maniaci di protagonismo (che per diamine ci può stare, ma dopo un po’ è discretamente tedioso). Alcuni ci vedono come prezzolati cacciatori di teste o come ricattatori di società, ma anche qui non ci siamo: nessuno di noi, se serio, accetta soldi dalle società trovate vulnerabili per “tacere” su questa o quella falla.
PI: E allora perché?
MF: Almeno nel mio caso, e di quegli italiani e non che ho avuto modo di conoscere e stimare (e ce ne sono tantissimi!), siamo fermamente convinti che le società non stiano minimamente interessandosi della sicurezza come primo approccio, della sicurezza come tutela degli utenti in primis e della collettività in generale.
PI: Una questione sociale ed etica?
MF: Lo facciamo perché ci piacerebbe che i nostri dati fossero conservati gelosamente e con la massima attenzione: vedere società che non lo fanno magari per un errore o una svista fa scattare il desiderio di miglioramento. Si segnalano, le vulnerabilità, e si diffondono al grande pubblico solamente quando (spessissimo, ahimé) anche a distanza di mesi dalla segnalazione permangono online e non vengono sanate.
a cura di Luca Annunziata
Ti potrebbe interessare
6 feb 2008