Obamacare e il cybercrime

A volte sembra che il mondo del crimine informatico, sia legato solo alle tecnologie, alla vendita di armi, droga e pedopornogrfia nel deep web.

Tutta roba più o meno da film, che ogni tanto emerge nella stampa mainstream, magari facendo di tutta l’erba un fascio per accusare tecnologie molto importanti che non si comprendono (successe qualche mese fa quando Tor fu accusato di ogni male possibile).

Però il cybercrime, essendo un’emanazione digitale del crimine organizzato fisico (cioè quello che ti brucia il negozio se non gli paghi il pizzo), è sempre molto aggiornato e, soprattutto, legato al mondo reale.

Vediamo quindi di analizzare un esempio molto concreto, partendo da una delle riforme più importanti fatte negli Stati Uniti negli ultimi anni: Obamacare.

obamacare

Discutendo su LinkedIn, Luca di Abissi ha segnalato come nel deep web ci sia un gran movimento di mercato legato alla compravendita di identità con annesso profilo e informazioni mediche.

Questo è stato poi confermato da esperti nel settore del furto di identità come Robert Siciliano: Healthcare Data under Attack.

Siciliano, citando uno studio dell’Istituto Ponemon, spiega molto chiaramente la situazione

in the world of black market information, a medical record is considered more valuable than everything else

Il mercato delle identità digitali è sempre stato molto florido, in particolare con la facilità con cui è possibile recuperare informazioni in un web popolato di social network. Anzi comprare stock di profili reali, carte di credito o addirittura documenti, per chi frequenta dei market nemmeno tanto nascosti è un’attività facile e abbastanza economica.

Ora però l’asse si è spostato su qualcosa di più pregiato, ovvero le identità complete di una persona ma senza i dati finanziari, bensì quelli necessari a stipulare un’assicurazione medica.

La grande riforma di Obama, essendo fondamentalmente un filtro governativo a tante assicurazioni sanitarie private, ha aumentato a dismisura il valore di queste informazioni e quindi il loro mercato nero parallelo.

Questo accade per il solito fondamentale problema: la mancata protezione di dati personali da parte di chi li tratta.

Ma mentre una carta di credito si può bloccare con una telefonata, e se siamo assicurati riusciamo anche a ottenere un rimborso, con i dati sanitari la cosa cambia drasticamente. Anche perché i numeri di carte di credito nascono e muoiono in poco tempo, il profilo sanitario resta molto più a lungo.

Comprando un’identità sanitaria è possibile infatti presentarsi ad una struttura come se si fosse la persona derubata, e i dati saranno aggiornati su quel profilo.

Se quindi venisse fatto un trattamento ospedaliero particolare, o anche una banale analisi del sangue, i dati sarebbero riportati sul profilo della persona reale. Che ignara di tutto magari si presenterà dopo qualche mese in una struttura sanitaria, necessitando di cure, e potrebbe rischiare grosso qualora nessuno si accorgesse dei dati errati.

Anche potenzialmente la vita.

Questa storia quindi conferma il rischio che la nostra identità digitale, e quindi sempre più quella reale, siano facilmente trafugabili. È sempre più importante quindi porre estrema attenzione al trattamento di dati sensibili come quelli sanitari.

In USA la situazione è davvero a rischio, in Italia per fortuna il Codice Privacy prevede norme stringenti per questo tipo di dati. In ogni caso con la proliferazione di banche dati e dispositivi è fondamentale non perdere mai di vista i rischi che si corrono.

Questo esempio poi conferma anche la sovrapposizione tra crimine “vero” e cybercrime. Cosa che gli addetti ai lavori dicono da anni, ma che ora si sta manifestando sempre di più, minacciando elementi fondamentali della vita di ogni persona, come la salute.

Per Apple la vulnerabilità stavolta è vera, e grave

Qualche giorno fa avevo parlato di vulnerabilità vere e presunte. Vere sì, perché difatti era reale, presunte perché dipendenti da una vulnerabilità ancora più grave.

Questo era appunto un esempio per dire che nel campo della sicurezza informatica, purtroppo, si tende troppo spesso a guardare il dito e non la luna luminosa che c’è dietro.

Stavolta le cose non stanno così, anzi, la luna è molto ben vistosa e minacciosa.

Apple venerdì sera (notte in Italia), ha rilasciato un aggiornamento per iOS che risolveva alcuni problemi con SSL/TLS.

Citare il protocollo TLS in un aggiornamento di sicurezza fa (meglio: dovrebbe) tremare qualsiasi esperto, visto che è uno dei mattoni fondamentali della sicurezza della navigazione e dell’utilizzo dei servizi di internet. È quello che, per chi è poco esperto, fa chiudere il lucchetto del browser e ci conferma che il sito

È quello che stabilisce e garantisce il trust tra noi e il servizio che stiamo utilizzando, e in tempi come questi dove la fiducia in rete è ai minimi, è essenziale che i rischi su questo fronte siano i più bassi possibili.

Sempre collegandomi al post scorso, proprio la capacità di ragionare di un esperto di sicurezza dovrebbe farlo saltare sulla sedia quando si leggono vulnerabilità che permettono di attaccare il rapporto di fiducia tra utente e servizio.

Molti in effetti sono saltati, anche se ho letto su Twitter parecchie ingiurie verso Apple proprio per l’orario di pubblicazione di questa patch: venerdì pomeriggio. Immagino come saranno stati contenti i gestori di un parco dispositivi iOS aziendali, magari con migliaia di iPhone e iPad, che si ritrovano all’inizio del weekend con un deploy enorme e urgentissimo.

Come in ogni errore o vicenda di notevole gravità, si può sempre imparare qualcosa. In questo caso possiamo capire meglio due cose: quale è stato il problema e perché era urgente risolverlo.

Il problema è un “banale” errore nel codice. Questa forse è la cosa più disarmante, visto che si tratta, letteralmente, di due righe.

Lo spiega bene ImperialViolet, analizzando il codice pubblicato da Apple.
Il problema è questo

Apple sslKeyExchange.c

Il problema sono quelle due goto fail una dietro l’altra.

Semplificando molto, il bug sta nel fatto che il codice di verifica SSL/TLS può consentire lo stabilirsi di una connessione “sicura” (il lucchetto chiuso, per intenderci) anche se il server che stiamo contattando non da la prova di avere la chiave privata di quel certificato di cifratura.

Quando si stabilisce una connessione di questo tipo infatti dopo la prima richiesta ad esempio a https://www.lamiabancaonlain.it, il server manda al browser un certificato SSL e una chiave pubblica firmata. Il browser verifica il certificato sia emesso da una autorità riconosciuta, poi con la firma controlla se il server possiede effettivamente la chiave privata di quel certificato, per poter stabilire una connessione cifrata tra le due parti.

Con quei due goto fail, i dispositivi iOS saltano il secondo passaggio, è possibile quindi creare un sito fake, con il certificato corretto, ma con una firma sbagliata o addirittura senza alcuna firma, e il browser chiuderà comunque il lucchetto.

Imperia Violet ha anche messo a disposizione un sito di test per vedere se si è colpiti da questa vulnerabilità. Se si va qui infatti con un dispositivo vulnerabile il lucchetto si chiuderà.

Se invece ci andiamo con Firefox comparirà, correttamente, questo messaggio di errore

SSL ERROR

Ovviamente il bug è gravissimo, e bene ha fatto Apple a far uscire quanto prima un aggiornamento, che va installato il prima possibile. Tra l’altro pare che i Mac siano ancora vulnerabili a questo rischio.

Dicevo che la seconda lezione è che è urgente risolverlo quanto prima, anche di venerdì sera di quello che era un tranquillo fine settimana di febbraio.

Il motivo lo abbiamo appena visto, un attacco al trust va risolto quanto prima perché è uno dei punti più critici dell’uso di internet.

Il problema però è anche che una volta che questo tipo di vulnerabilità sono note a tutti, cioè esce la patch, diventa esponenzialmente più rischiosa.

Mentre prima infatti era uno zero day noto a un numero ignote di persone, potenzialmente da nessuno al di fuori di Apple a tutta la comunità di cyber criminali mondiali.

La pubblicazione della patch però rende del tutto pubblica la vulnerabilità, anche a chi non era interessato a conoscerla (o a comprarla). Questo genera un aumento di rischio perché chi ha cattive intenzioni sa che

  1. c’è un buco sfruttabile (più o meno facilmente) su una marea di dispositivi
  2. gran parte di quei dispositivi sono ancora vulnerabili all’attacco

Praticamente la situazione ideale sia per gli hacker professionisti sia per gli script kiddie che si scaricheranno il tool o il modulo di Metasploit.

Tanto è vero che il giorno dopo il Patch Tuesday di Microsoft, quando appunto un gran numero di vulnerabilità viene pubblicato, c’è il giorno gergalmente chiamato Bloody Thursday dove vengono sfruttate selvaggiamente (in the wild) tutte le debolezze di tanti sistemi che sicuramente non avranno ancora installato la patch.

E questo è valido in particolare per le strutture aziendali, dove necessariamente le patch hanno un ciclo di approvazione e controllo.

Paradossalmente sono più deboli di un dispositivo personale come il mio, che ho aggiornato qualche minuto dopo l’uscita dell’aggiornamento.

Sempre mantenendo quindi la capacità di ragionare, vanno attivate comunque delle contromisure rapide, e installata la patch il prima possibile.

Soprattutto se, come in questo caso, il rischio sta alla base di tutto: il trust.

P.S. da oggi Glamis on Security cambia tema, aggiornando la grafica per più leggerezza e semplicità di lettura. Spero vi piaccia.

Gli hacktivist e la guerra in Siria

I venti di guerra soffiano e purtroppo continueranno a soffiare su scenari classici, e la Siria potrebbe essere presto uno di quelli.

Stavolta però, proprio perché parliamo della Siria, la guerra combattuta non sul fronte del confine o delle città, ma sulla linea rossa del web e di internet, il cyberwarfare, avrà probabilmente la sua prima uscita pubblica.

Da anni gli analisti di sicurezza (informatica e non) di tutto il mondo studiano il fenomeno dei gruppi di hacktivist che combattono e si combattono una guerra parallela, più “fredda” di quella ufficiale. Se non altro perché non ha, per ora e per quel che ne sappiamo, morti ammazzati.

Questi gruppi sono sempre stati attivi, e sono sempre stati più o meno esplicitamente supportati dai rispettivi governi. Ogni tanto c’è qualche notizia sui media mainstream, in particolare quando ci sono frecciatine più o meno pesanti da parte dei vari governi, come ad esempio questa degli Stati Uniti contro gli attacchi hacker cinesi.

La Siria, dicevamo, è diversa. Ma perché?

Perché la Siria dispone del primo vero, pubblico e pubblicamente supportato dal suo governo gruppo di hacker destinati al cyberwarfare: il Syrian Electronic Army.

Per capire quanto sia attivo questo gruppo, basta fare una ricerca sul sito di Graham Cluley (uno degli analisti di sicurezza informatica più attenti su questo tema, dopo aver lavorato per anni in Sophos)

clueleysyria

E questi sono gli attacchi delle ultime settimane.

Come si può notare il target prediletto del SEA sono i principali media statunitensi.

Addirittura qualche giorno fa sono arrivati, tramite un semplicissimo attacco di tipo spear phishing, quasi a modificare la homepage del New York Times.

Dallo screenshot pubblicato proprio dal SEA si vede come avevano già modificato il feed delle notizie, inserendo un sito arabo pro-governo siriano

nytsea

Ma, come in tutti gli scenari di guerra classici, chi è attaccato non sta fermo a subire le conseguenze. Reagisce.

Mentre però in uno scenario classico sono gli stati a farsi la guerra, nel mondo degli hacktivist non c’è una distinzione chiara delle parti, anzi spesso la confusione di chi-si-allea-con-chi è tale che gruppi di hacktivist di una nazione possono agire in contrasto al loro stesso governo.

Proprio in questi giorni, sulla pagina Facebook del movimento LulzSec, è partita una pesante campagna di reclutamento di persone esperte in vari settori, proprio per agire in vista di un possibile attacco alla Siria.

LulzSec era (ma sarebbe meglio dire è) un gruppo di hacker e hacktivist molto famoso nell’ambiente, noto in particolare per l’Operazione Antisec, proprio in contrasto alle misure antiterrorismo del governo USA, che puniscono severamente anche le attività di hacking.

Alleati e partner di Anonymous in diverse operazioni, furono poi duramente colpiti quando uno dei loro capi si rivelò essere un informatore dell’FBI, e questo portò all’arresto di diversi altri esponenti di punta del gruppo.

Queste azioni comunque hanno solo rallentato l’attività del gruppo, che come detto in questi giorni di preparativi di una guerra in Siria sta raccogliendo le forze

lulz

lulzjihad

Il punto più interessante è che il target sono sì i siti jihadisti e in ogni caso il governo Siriano. Ma l’operazione nasce principalmente per aiutare chi si trova in Siria

lulztor

Ma non in ogni caso a supportare un possibile attacco USA.
Vista la palese ostilità del gruppo verso Washington.

In conclusione la situazione, come già detto, è molto confusa, ma probabilmente questi sono gli scenari con cui ci dovremo confrontare sempre di più nei prossimi anni.

Specialmente perché gli hacktivist tendono sempre ad agire in base ad una specifica ideologia, e quindi sono potenzialmente molto più pericolosi, meno prevedibili e più spregiudicati di un potenziale gruppo hacker militare o governativo.

Molto spesso infatti proprio i governi sfruttano questi gruppi per fare vere e proprie operazioni underground, ben al di la di qualsiasi legge nazionale ed internazionale.

Del resto come ha scritto Topiary, uno dei leader di LulzSec arrestati dopo il “tradimento” di Sabu, nel suo ultimo tweet

Come attivare l’autenticazione a due fattori su LinkedIn e Twitter

Avevo già parlato sia del perché sia molto importante utilizzare un sistema di autenticazione a due fattori per i servizi web, in particolare i social network, sia del fatto che i recenti attacchi a Twitter e LinkedIn potevano essere evitati (o per lo meno mitigati) proprio attivando questa funzionalità. Che su quei due social network però mancava.

Dopo qualche mese dagli attacchi, per fortuna sia Twitter che LinkedIn hanno reso disponibile ai propri utenti un sistema di verifica dei login.

Praticamente usano lo stesso metodo: registrate un numero di cellulare e loro vi inviano un SMS con un codice da usare dopo aver inserito username e password.

Vediamo meglio come abilitare questa funzionalità.

Twitter

Prima di tutto un consiglio: se avete già associato al vostro account Twitter un numero di cellulare rimuovetelo prima di attivare questo servizio. Sembra ci sia un bug, quindi si fa molto prima a togliere tutto e ricominciare da capo.

Abilitare il tutto è molto semplice, basta cliccare sull’ingranaggio in alto a destra, andare su Impostazioni, e selezionare l’opzione Richiedi un codice di verifica all’accesso

Twitter richiedi codice di accesso

Dovrete quindi inserire un numero di telefono cellulare, verificarlo inviando un SMS a Twitter, e successivamente potrete abilitare l’invio del codice

Twitter registra cellulare

Tutto abbastanza semplice.
Come già disponibile prima, inoltre, potrete selezionare quali avvisi ricevere sul vostro cellulare via SMS o se abilitare la funzionalità di SMS-twitting.

LinkedIn

Anche su LinkedIn la procedura è simile.

Riporto qui la versione inglese del sito, uso quella perché la versione in Italiano ancora non ha recepito gli ultimi cambiamenti grafici.

Basta cliccare sul proprio account in alto a destra, andare su Privacy and Settings –>Account –>Manage security settings e arrivare a questa schermata

linkedin-security-settings

Oltre a poter abilitare l’SSL (e fatelo immediatamente, anzi installate HTTPS Everywhere) potrete attivare la funzionalità di invio del codice di verifica.

Va quindi registrato un numero di cellulare, ed è fatta.

Linkedin registra cellulare

E ora?

E ora basta!

Da questo momento ogni volta che vi loggherete in questi due servizi con username e password vi verrà inviato un codice via SMS

codici sms

Ovviamente questo sistema non è esente né da rischi né da scomodità.

La scomodità principale è quella di avere copertura telefonica per ricevere, almeno in tempi brevissimi, l’SMS. E a volte, soprattutto all’estero, questo è un problema.

La speranza è quella che sia Twitter che LinkedIn seguano quanto fatto da Google e Facebook, utilizzando un generatore di codici all’interno magari delle loro app per smartphone.

In ogni caso è un primo passo, semplice ma molto importante, per essere un po’ più sicuri in rete su questi due servizi molto usati.

Bye!

La roba Microsoft é la più bucata! Ehm… quasi

Leggevo con colpevole ritardo il report degli NSS labs sull’andamento delle vulnerabilità (qui il PDF).

Molto interessante è questa tabella (cliccate per ingrandire) che riporta i vendor maggiormente colpiti da CVE, facilmente exploitabili nello scorso anno.

Top Vulnerabilities

Top 10 vendors with highly critical, easy to exploit vulnerabilities – Fonte NSS Labs

La prima cosa che salta subito agli occhi è che, come riportato dal titolo, il software Microsoft è solo decima in classifica. E per giunta è colpita solo dall’1% di tutti i CVE emessi nel 2012.

Sfatiamo subito un mito quindi, un luogo comune un po’ datato ma ancora in voga. Purtroppo anche tra i professionisti e gli addetti ai lavori.

La seconda cosa che risulta guardando l’analisi di NSS è che i sistemi operativi non sono i più colpiti. I primi posti della classifica sono infatti coperti da software ordinario, middleware o plug-in di altri programmi.

Queste due cose messe insieme (il mito di Windows colabrodo e il fatto che siano più facilmente vulnerabili browser e plug-in) provocano un effetto devastante nella gestione ordinaria della sicurezza delle nostre postazioni di lavoro. Sia a casa che, soprattutto, in azienda.

Addirittura devastante come effetto? Eh sì.

Sì perché le informazioni e i dati sono un innesco fondamentale per definire le policy e le azioni legate alla sicurezza informatica, sia essa aziendale o personale.

Partire quindi da pregiudizi, o ancora peggio da informazioni totalmente sbagliate causa delle politiche di sicurezza altrettanto sbagliate, e questo a sua volta apre dei buchi nella nostra (già fin troppo fragile) linea di difesa.

Abbattere il pregiudizio guardando quella tabella non solo è essenziale per rimettere le cose in carreggiata, ma soprattutto per focalizzare la nostra attenzione sui posti dove veramente abbiamo un problema.

Fin troppo spesso infatti le politiche di aggiornamento dei vari asset aziendali spingono su patch di Windows, agent antimalware, agent personal firewall e chissà quale altra amenità.

Poi però abbiamo postazioni di lavoro e, peggio, server su cui gira Firefox 3.6.
Oppure utilizziamo ancora applicazioni che richiedono obbligatoriamente di usare una bella Java versione 5.0.

O, peggio ancora visto che sono i primi della lista, non abbiamo nessuna procedura che controlli l’aggiornamento costante di Flash o di Acrobat Reader. E il secondo è il posto dove passano tutti i PDF che arrivano, e i PDF sono un veicolo fondamentale per diffondere malware e altra robaccia.

L’analisi di questo tipo di rapporti, il leggere attentamente i numeri e i confronti, è e deve essere attività essenziale per chiunque si appresti a definire le proprie politiche di sicurezza. Siano quelle di una realtà con quattro PC o quelle di un’azienda con decine di migliaia di postazioni.

Purtroppo anche i professionisti più navigati cadono spesso in errori di questo tipo. Anzi, spezzo una lancia, in fondo se lo meritano, ci cadono proprio perché applicano ancora modelli non aggiornati alla realtà attuale, che prevede ulteriori fattori (come la facilità di esecuzione di un attacco) e contesti diversi (ad esempio l’uso o l’esposizione di rete di un certo asset o servizio).

I prodotti Microsoft, e Windows in particolare, hanno sì’ comunque un elevato grado di vulnerabilità e sono pesantemente attaccati. Guardiamo la tabella (cliccate per ingrandire) di confronto sulle vulnerabilità comprate dai programmi ZDI e VCP negli ultimi 10 anni.

Top 10 vendors

Top 10 vendors for which ZDI & VCP purchased vulnerabilities since 2001 – Fonte NSS Labs

Microsoft fa sicuramente la parte del leone in questo caso, ma questo dato mostra due cose principalmente:

  • la “facilità” di attacco dei suoi prodotti
  • l’elevato interesse che ricercatori e hacker hanno nei suoi riguardi (infatti la seconda è Apple).

Ma come usare questo dato allora? Non significa però necessariamente che tutte quelle vulnerabilità siano di elevata criticità, né che siano, come detto nella prima tabella, facilmente utilizzabili per bucare qualcosa.

Quindi è vero che i grandi numeri restano “onori” di alcuni vendor in particolare, ma guardare solo i numeri non serve.

Va sempre considerato il contesto, altrimenti richiamo di focalizzarci solo su un prodotto che ha sì un gran numero di vulnerabilità, ma magari di basso livello o molto difficili da sfruttare. Oppure ci sforziamo molto per proteggere sistemi già protetti da altre cose (come ad esempio i sistemi di protezione perimetrale, o il prodotto antimalware), mentre poi lasciamo utilizzare agli utenti degli altri software di uso quotidiano, mai aggiornati e con plug-in obsoleti e pericolosi.

E in più, in questo scenario già di per se inquietante, quegli stessi software sono estremamente facili da bucare. Basta andare su qualche forum e trovare dei programmi già pronti.

Ecco, la chiave di lettura di utilissimi report come quello di NSS deve essere appunto quella di prendere i numeri con grande spirito critico, mettere in dubbio costantemente le proprie certezze, e cercare di capire dove sta realmente il problema.

E potrebbe non essere il primo della lista, visto che, come diceva Indiana Jones

“X” never, ever marks the spot. 🙂

Bye!

P.S. Molto interessante è il fatto, notato anche dagli analisti degli NSS Labs che nella prima tabella compare anche Advantech, un produttore di sistemi industriali SCADA.

L’attenzione su questi sistemi è in crescita costante secondo NSS Labs infatti

ICS/SCADA vulnerability disclosures increased more than 600% since 2010 and almost doubled from 72 in 2011 to 124 in 2012.

Questo anche perché, come dicono loro stessi, sono emerse nel 2012 nuove tecniche e strumenti per permettere ai ricercatori di sicurezza (sia buoni che cattivi) di scovare meglio falle nei sistemi industriali.

Resta comunque un fronte aperto e pericolosamente in crescita, non solo per lo Stuxnet di cui ha tanto parlato la stampa generalista.