Questo articolo è disponibile anche in versione podcast audio.

Il 19 ottobre scorso Microsoft ha annunciato che i dati riservati di alcuni suoi clienti e potenziali clienti sono stati resi pubblicamente accessibili via Internet a causa di un suo errore di configurazione. I dati includono dettagli delle strutture aziendali, le fatture, i listini prezzi, i dettagli dei progetti, i nomi e numeri di telefono dei dipendenti e il contenuto delle loro mail.

L’azienda minimizza e nota che l’errore è stato corretto poco dopo la sua segnalazione da parte della società di sicurezza informatica SOCRadar il 24 settembre scorso, ma alcuni esperti non sono altrettanto rassicuranti.

I dati sono stati infatti catalogati da siti come Grayhat Warfare e come avviene sempre in questi casi non c’è modo di sapere quanti malintenzionati hanno avuto il tempo di procurarsene una copia.

The Microsoft bucket has been publicly indexed for months, it's called olyympusv2 hosted on Azure blob storage - it was publicly readable. It's even in search engines.https://t.co/5iBIb2qvue pic.twitter.com/5zjC0IC4wh

— Kevin Beaumont (@GossiTheDog) October 20, 2022

Secondo l’avviso pubblicato da SOCRadar, il problema non riguarda soltanto Microsoft ma tocca anche Amazon e Google, che hanno malconfigurato vari server contenenti dati sensibili dei propri clienti aziendali.

SOCRadar ha raccolto le informazioni su queste violazioni di riservatezza in un’apposita pagina del proprio sito, che consente di sapere se un’azienda è coinvolta o meno digitandone il nome di dominio nella casella di ricerca, e ha dato alla vicenda il nome BlueBleed.

In totale sono circa 150.000 le aziende interessate, che appartengono a 123 paesi. Le mail rese troppo visibili sono circa un milione e gli utenti sono circa 800.000. Responsabilmente, SOCRadar non rivela i dati ma si limita a dire se sono presenti o meno negli archivi resi eccessivamente accessibili dai servizi cloud di Microsoft, Amazon e Google. Se la vostra azienda usa servizi cloud di questi tre grandi nomi è opportuno dedicare un minuto a un controllo per vedere se è fra quelle coinvolte.

Va ricordato che i dati ottenuti da fughe di questo genere vengono solitamente utilizzati dai criminali online per ricatti ed estorsioni o per carpire illecitamente la fiducia dei dipendenti di un’azienda presa di mira manifestando di conoscere informazioni aziendali riservate, ma vengono anche a volte semplicemente rivenduti al miglior offerente, per cui non è mai il caso di ignorare segnalazioni di cloud colabrodo come questa. 

---

2022/10/27 8:45. I bucket lasciati aperti non sono finiti:

I found another of the MSFT Bluebleed buckets, with the SQL databases. Contains databases Datastore, WMIDataStore, Olympusv2Backup and Datawarehouse_backup - has been kicking around for some time. pic.twitter.com/s35dN0C7Sg

— Kevin Beaumont (@GossiTheDog) October 26, 2022

 

Fonte aggiuntiva: Bleeping Computer, Graham Cluley.

Ultimo aggiornamento: 2021/06/11 1:50.

Martedì scorso (8 giugno) moltissimi siti Internet sono diventati inaccessibili per circa un’ora: siti governativi, Amazon, Reddit, Twitch, Hulu, PayPal, Vimeo e molte testate giornalistiche.

Alcuni giornali hanno parlato frettolosamente di attacco hacker, senza alcuna prova a sostegno, per poi correggere il tiro. La ragione reale, infatti, è stata molto, molto più banale.

 

Incredibilmente banale: il collasso è stato causato da una singola azienda, Fastly, che è andata a gambe all’aria. Già questo è imbarazzante, ma non è finita: Fastly è crollata per colpa di un singolo utente.

Sul serio: un utente di Fastly ha cambiato le proprie impostazioni, ed è venuta giù buona parte di Internet. Come è possibile?

Fastly è un fornitore statunitense di edge cloud o cloud perimetrale: un servizio che rende più veloce il caricamento dei siti, li protegge contro gli attacchi informatici e li aiuta quando ci sono picchi di traffico da parte di visitatori. È uno di una rosa piuttosto ristretta, che include nomi come Amazon Web Services e Cloudflare. Praticamente tutti i siti Internet si appoggiano a questi fornitori, per cui l’idea che Internet sia in grado di sopportare un attacco nucleare, come si diceva al suo debutto, è ormai un mito da seppellire.

Incidenti come questo, dovuti alla dipendenza da questi fornitori, sono piuttosto frequenti anche se relativamente brevi. Nel 2017 capitò ad Amazon Web Services, che per quattro ore mise fuori uso siti come Netflix e Spotify. Nel 2019 toccò a Cloudflare, che mandò in tilt Dropbox, Discord, Medium, Soundcloud e molti altri siti frequentatissimi. E proprio stasera (10 giugno) un “aumento della temperatura ambiente” di un datacenter Amazon a Francoforte ha causato grossi problemi di connettività, nei quali sono probabilmente incappato anch’io: il webinar su Zoom che stavo coordinando è andato a gambe all’aria in diretta, lasciando scollegate alcune centinaia di partecipanti senza alcuna possibilità di riconnettersi (Zoom usa AWS).

Dalla pagina di stato di Amazon: 

The root cause of this issue was a failure of a control system which disabled multiple air handlers in the affected Availability Zone. These air handlers move cool air to the servers and equipment, and when they were disabled, ambient temperatures began to rise. Servers and networking equipment in the affected Availability Zone began to power-off when unsafe temperatures were reached. Unfortunately, because this issue impacted several redundant network switches, a larger number of EC2 instances in this single Availability Zone lost network connectivity. While our operators would normally had been able to restore cooling before impact, a fire suppression system activated inside a section of the affected Availability Zone. When this system activates, the data center is evacuated and sealed, and a chemical is dispersed to remove oxygen from the air to extinguish any fire. In order to recover the impacted instances and network equipment, we needed to wait until the fire department was able to inspect the facility. After the fire department determined that there was no fire in the data center and it was safe to return, the building needed to be re-oxygenated before it was safe for engineers to enter the facility and restore the affected networking gear and servers. The fire suppression system that activated remains disabled. This system is designed to require smoke to activate and should not have discharged. This system will remain inactive until we are able to determine what triggered it improperly. In the meantime, alternate fire suppression measures are being used to protect the data center. Once cooling was restored and the servers and network equipment was re-powered, affected instances recovered quickly. A very small number of remaining instances and volumes that were adversely affected by the increased ambient temperatures and loss of power remain unresolved.

Il collasso di martedì scorso è stato causato involontariamente da uno dei clienti di Fastly, che ha appunto cambiato le proprie impostazioni, in maniera assolutamente legittima, e così facendo ha attivato un bug che era presente in un aggiornamento software che Fastly aveva diffuso ai propri clienti a metà maggio. Il bug ha fatto sì che l’85% della rete di Fastly desse errore.

Per fortuna i tecnici di Fastly hanno capito rapidamente la causa del problema e nel giro di una cinquantina di minuti scarsi sono riusciti a rimettere in funzione il 95% della propria rete. L’azienda si è scusata e ha spiegato in parte cosa è successo in questa cronologia degli eventi e in questo rapporto.

L’unica cosa rimasta inspiegata è l’identità del cliente di Fastly che ha fatto crollare mezza Internet. Non so voi, ma se l’avessi fatto io lo metterei nel curriculum.

Ultimo aggiornamento: 2021/04/10 22:40.

“RE è basato su altissimi standard di sicurezza, i nostri server sono tutti in Italia (Arezzo), tutte le connessioni sono effettuate tramite il protocollo HTTPS e crittografia SSL con certificato dei più importanti CA al mondo: Verisign Symantec e GeoTrust. Ma non basta, prima di essere inviati tutti i dati sono crittografati a priori e questa tecnologia, unica nel suo genere, raddoppia le garanzie di sicurezza rendendo RE sicuro come nessun altro.” Così scriveva Axioscloud.it, il sito che ospita il Registro Elettronico di molte scuole italiane (circa il 40%, secondo ANSA). Sito che ora è irraggiungibile.

Un attacco ransomware ha infatti buttato giù il sito “sicuro come nessun altro” e “basato su altissimi standard di sicurezza”. Questo è uno screenshot di com’era prima dell’attacco, come si può vedere su Archive.org.

 

Secondo Quotidiano Piemontese, il problema è iniziato sabato 3 aprile ed è poi peggiorato. Il quotidiano pubblica uno screenshot di Axios Italia che dice di stare “lavorando alacremente con l’obiettivo di rendere disponibili tutti i servizi web entro pochi giorni”.

Su Facebook, Axios Italia ha dichiarato inizialmente (3 aprile) che si trattava di un “improvviso malfunzionamento tecnico occorso durante la notte” che avrebbe “reso necessario un intervento di manutenzione straordinaria”. Lo stesso risulta dalla copia salvata su Archive.org il 5 aprile.

Oggi (5 aprile) l’azienda ha scritto, sempre su Facebook, che “a seguito delle approfondite verifiche tecniche messe in atto da Sabato mattina in parallelo con le attività di ripristino dei servizi, abbiamo avuto conferma che il disservizio creatosi è inequivocabilmente conseguenza di un attacco ransomware portato alla nostra infrastruttura. Dagli accertamenti effettuati, al momento, non ci risultano perdite e/o esfiltrazioni di dati. Stiamo lavorando per ripristinare l'infrastruttura nel più breve tempo possibile e contiamo di iniziare a rendere disponibili alcuni servizi a partire dalla giornata di mercoledì. Sarà nostra cura tenervi costantemente aggiornati.” 

Gli stessi messaggi sono presenti attualmente sul sito di Axios Italia. 

Fonti confidenziali mi segnalano una situazione piuttosto pesante. Non pubblico altri dettagli, per il momento, in attesa di conferme e riscontri: sarebbe utile che Axios facesse una dichiarazione pubblica sullo stato dei backup, su quale infrastruttura sia stata compromessa e su eventuali negoziati con gli autori dell’attacco. Comunque stiano le cose, temo che per il DPO di Axios il ritorno dalle ferie di Pasqua sarà piuttosto impegnativo.

2021/04/06 13:10. Secondo la mail inviata da Axios alle scuole, l’azienda è stata informata dell’attacco ransomware da parte del servizio di sicurezza di Aruba intorno alle due del mattino del 3 aprile e il disaster recovery avrebbe mitigato i danni. L’amministratore unico di Axios Italia, Stefano Rocchi, dice a Giornalettismo che è stato “deciso di non pagare alcun riscatto”.

 

2021/04/08 13:00. Al momento in cui scrivo questo aggiornamento il Registro Elettronico è ancora offline; redemo.axioscloud.it mi risponde con un timeout. Il sito di Axios Italia ospita ora un’informazione più dettagliata (screenshot qui sotto, cliccabile per leggerlo), che invita a consultare una comunicazione (PDF). Questa comunicazione dice, fra le altre cose, che “I dati personali gestiti non sono stati persi/distrutti e non vi è stata alcuna visione/estrapolazione indebita" e che “Le misure di sicurezza adottate, incluse le soluzioni di Disaster Recovery, nonostante un “attacco brutale con finalità estorsive” similare a quello ricevuto recentemente da multinazionali (esempio ACER), hanno consentito di preservare i dati gestiti nel rispetto della normativa privacy.”

 

Intanto la notizia è ormai riportata da molti siti e giornali (Cybersecurity360, Punto Informatico, Giornalettismo, per fare qualche esempio) e mi è arrivata una diffida dall’avvocato di Axios, alla quale ho risposto per quanto riguarda gli aspetti tecnici ricordando inoltre l’inevitabile Effetto Streisand.

 

2021/04/08 22:00. Come segnalato nei commenti, quella del 3 aprile 2021 non è la prima aggressione informatica che colpisce il Registro Elettronico di Axios Italia; il 9 aprile 2020 era stato bloccato da un attacco DDOS, riferiscono per esempio Repubblica e RAI.

2021/04/10 22:40. Axios ha dichiarato, sul proprio sito, quanto segue:

Gentili Clienti,
siamo lieti di comunicarVi che sono tornati online il Registro Elettronico, le funzionalità per le famiglie ed ulteriori servizi.
Stiamo inoltre continuando a monitorare la corretta funzionalità di tutti i sistemi ripristinati.
Vi ringraziamo ancora per la vicinanza e la pazienza dimostrata in questi giorni.

Continueremo a mantenerVi costantemente aggiornati sugli sviluppi.

10/04/2021 - Ore 18:05

Questo articolo vi arriva gratuitamente e senza pubblicità grazie alle donazioni dei lettori. Se vi è piaciuto, potete incoraggiarmi a scrivere ancora facendo una donazione anche voi, tramite Paypal (paypal.me/disinformatico), Bitcoin (3AN7DscEZN1x6CLR57e1fSA1LC3yQ387Pv) o altri metodi.

Questa foto (credit: @mothattacks) mostra il datacenter di Strasburgo della Ovh, colpito da un incendio il 10 marzo scorso. In questo datacenter venivano ospitati i dati di migliaia di clienti della società francese: era insomma la parte concreta di quello che in gergo viene definito cloud. Quel cloud è diventato letteralmente una disastrosa nuvola di fumo.

Trovate tutti i dettagli e i nomi di molti dei clienti colpiti in questo articolo di Wired.it, ma il dato più importante è che Ovh ha invitato gli utenti ad attivare i propri piani di disaster recovery. Questo di solito non è un buon segno, e significa che i dati custoditi presso il datacenter sono da considerare perduti.

Anche se la dinamica di questo incendio è ancora tutta da definire, il segnale di fumo è molto chiaro: depositare i propri dati nel cloud non implica automaticamente che il gestore del cloud ne abbia una copia di scorta per emergenze come queste (leggete attentamente il vostro contratto) ed è possibile che spetti al cliente fare questa copia di scorta altrove.

Per contro, implica che se i vostri processi di lavoro dipendono dalla disponibilità di quei dati depositati nel cloud, in caso di disastro che colpisce il cloud non potrete più lavorare. A meno che abbiate una copia di scorta locale o presso un cloud separato.

Casi come questo sono un’occasione importante per riflettere sulle proprie strategie di backup e sui propri piani di disaster recovery. Ne avete uno? Lo avete mai messo alla prova? Sareste in grado di lavorare senza accesso al cloud? È il momento giusto per farsi queste domande.

Lunedì 14 dicembre, intorno alle 13, quasi tutti i servizi di Google sono andati in tilt per circa 50 minuti. È bastata un’ora scarsa di disservizio per creare un’ondata di panico planetario, dovuto al fatto che milioni di utenti non riuscivano più a mandare mail, scrivere o consultare i propri documenti custoditi online nel cloud, sfogliare l’agenda di Calendar, guardare video su YouTube, gestire i propri assistenti vocali, consultare mappe e fare lezioni a distanza con Meet.

I servizi sono tornati alla normalità dopo appunto una cinquantina di minuti, secondo il resoconto pubblicato da Google, che spiega che avevano smesso di funzionare tutti i suoi servizi che richiedevano un’autenticazione tramite account. In effetti il motore di ricerca ha continuato a funzionare, e YouTube era consultabile tramite navigazione in incognito, ma qualunque servizio che richiedesse login e password di Google era inaccessibile.

Nelle ore successive ci sono stati problemi con Gmail, per cui molti account di posta risultavano inaccessibili e chi cercava di mandare mail a quegli account riceveva una risposta automatica del tipo “questo account non esiste” (un bel “550-5.1.1 The email account that you tried to reach does not exist.") 

La causa scatenante, dice sempre Google, è stata “un problema con il nostro sistema automatizzato di gestione delle quote che ha ridotto la capacità del sistema centrale di gestione delle identità”.

Non è il primo blackout del genere: Downdetector ne ha catalogati parecchi quest’anno, anche se non così vasti, e Wikipedia nota che un’altra sospensione dei servizi primari di Google è avvenuta ad agosto 2020 e che anche l’11 novembre scorso si è verificato un blocco simile.

Ci sono un paio di lezioni da portare a casa a proposito di questo incidente.

La prima è sicuramente che siamo enormemente dipendenti da Google e che è meglio preparare un piano d’emergenza che consenta di continuare a operare almeno in forma ridotta se Google va in tilt. Il vostro impianto luci o di riscaldamento domotico è comandabile anche senza passare per Google? Dipendete dal vostro assistente vocale Google Home per qualche funzione importante (penso ai disabili o a chi ha mobilità ridotta per infortunio o malattia, per esempio)? La vostra azienda o scuola è paralizzata se i servizi di Google non funzionano? Procuratevi un Piano B.

I’m sitting here in the dark in my toddler’s room because the light is controlled by @Google Home. Rethinking... a lot right now.

— Joe Brown (@joemfbrown) December 14, 2020

It’s when google is down and you can’t heat your home that you realise how scarily reliant you are on google

👀 pic.twitter.com/9lsk0c6kRN

— Alex Dunsdon (@alexdunsdon) December 14, 2020

Senza arrivare a questi livelli estremi, vale la pena di cogliere l’occasione per chiedersi se è davvero una buona idea usare la login di Google per accedere a servizi di altri fornitori. Certo, è comodo, ma se Google si blocca diventa impossibile accedere non solo ai servizi di Google ma anche a tutti quelli di altri fornitori che dipendono dalla login di Google. Meglio avere account separati per ogni fornitore.

La seconda lezione è che conviene sapere dove reperire informazioni su questi blackout, in modo da capire rapidamente se il problema è nostro o esterno e agire di conseguenza (anche soltanto per mettersi il cuore in pace). Ho già citato Downdetector, disponibile anche su Twitter e Facebook e con sezioni separate per i singoli paesi, come Allestörungen.ch per la Svizzera o Downdetector.it per l’Italia), tenete presente la Dashboard dello stato di Google Workspace, presso

http://www.google.it/appsstatus#hl=it&v=status

La terza lezione è, come spiega bene Stefano Zanero, che fare congetture o ipotizzare attacchi informatici o complotti è una perdita di tempo:

Lo scrivo a beneficio di giornalisti e commentatori italiani: chi in Google conosce i motivi del disservizio, ovviamente non ne può parlare. Chi ne parla, non ne sa una mazza (e considerando la complessità della tecnologia in qualsiasi GAFAM, non può nemmeno tirare a indovinare).

— Stefano Zanero (@raistolo) December 14, 2020

 

Fonti aggiuntive: Gizmodo, BBC, ANSA, The Register.

Ultimo aggiornamento: 2019/09/03 18:00.

Il sito delle detrazioni fiscali ecobonus dell'ENEA permette a chiunque di vedere le pratiche altrui, come si può notare nello screenshot qui accanto, nel quale ho mascherato i nomi degli utenti.

Non è necessario conoscere alcuna login o password: è sufficiente un URL pubblico. Risultano inoltre esaminabili i dettagli delle singole pratiche e i rispettivi allegati, che ho scelto di non pubblicare qui nemmeno in versione mascherata.

Grazie a @i_am_sverx, che mi ha trovato le coordinate del responsabile della protezione dei dati (un po’ nascoste su ecobonus2019.enea.it/privacy.asp), l’ho potuto avvisare via mail. Ho messo in copia cnaipic@interno.it e comunicazioneweb@enea.it, fornendo loro l’URL pubblico in questione.

Il mio tweet sulla questione ha attirato l’interesse degli addetti del team digitale di Governo.it, che stanno esaminando la situazione. Su loro suggerimento, ho messo in copia anche il CERT della pubblica amministrazione italiana. Vediamo che succede.

2019/09/03 18:00

Ho ricevuto mail dalla responsabile relazioni esterne e comunicazione e dal responsabile della divisione ICT di Enea, che mi dicono che il problema è stato risolto. I primi controlli confermano. Ora restano solo le eventuali questioni legate al GDPR.


Questo articolo vi arriva gratuitamente e senza pubblicità grazie alle donazioni dei lettori. Se vi è piaciuto, potete incoraggiarmi a scrivere ancora facendo una donazione anche voi, tramite Paypal (paypal.me/disinformatico), Bitcoin (3AN7DscEZN1x6CLR57e1fSA1LC3yQ387Pv) o altri metodi.

Ultimo aggiornamento: 2019/08/27 12:00.

Le gioie dei dati nel cloud: la San Marino Tourservice S.p.A. ha messo centinaia di file contenenti dati dei clienti in un bucket Amazon leggibile da chiunque, con buona pace della sua privacy policy (che ho archiviato qui).

So che è già stata allertata tempo fa (non da me), ma non ha fatto nulla: i dati sono ancora lì, come lo erano a marzo scorso, alla mercé del primo che passa. Nomi, numeri di telefono, date di viaggio, infortuni e problemi di salute.

Un paio di esempi (in cui ho mascherato i principali dati), tanto per chiarire che non sto scherzando:


Visto che segnalare il problema direttamente e con discrezione agli interessati non sembra aver ottenuto alcun effetto, vediamo cosa succede con una segnalazione pubblica della figuraccia. Perché un cliente ha il diritto di sapere se i suoi dati personali verranno davvero tutelati dall’azienda alla quale si rivolge o se, come sembra, vige il chissenefrega più totale.

Ho inviato segnalazione anche al CNAIPIC.


15:50. Sono stato contattato dal responsabile informatico dell’azienda e gli ho spiegato i dettagli tecnici della questione, chiarendo che non ho trovato alcuna vulnerabilità ignota ma ho semplicemente usato uno degli appositi motori di ricerca che indicizzano i bucket world-readable. È comunque già un passo avanti. I dati sono tuttora leggibili e scaricabili da chiunque, anche in massa. Ricordo alle aziende che usano i bucket di Amazon che Amazon offre una guida alla messa in sicurezza e anche uno strumento di verifica delle impostazioni dei bucket.


21:10. Mi è arrivata una mail dal responsabile informatico dell’azienda, che ha confermato la mia segnalazione e ha detto che verranno prese misure opportune (che non descrivo qui) e ringraziato con la promessa di aggiornarmi sulle modifiche e con la cortese richiesta di verificare il loro operato. Tutto è bene quel che finisce bene? Beh, resta la questione delle conseguenze GDPR di questa esposizione di dati privati. Ma questa è un’altra storia.


2019/08/22 7:35. Sono stato contattato di nuovo dall’azienda, che mi ha chiesto di verificare che a seguito di un intervento tecnico ora i dati non sono più accessibili a chiunque. I miei controlli a campione confermano che è così.

2019/08/27 12:00. Ho sostituito gli screenshot iniziali (che avevo mascherato quasi completamente) con delle versioni completamente mascherate.


Questo articolo vi arriva gratuitamente e senza pubblicità grazie alle donazioni dei lettori. Se vi è piaciuto, potete incoraggiarmi a scrivere ancora facendo una donazione anche voi, tramite Paypal (paypal.me/disinformatico), Bitcoin (3AN7DscEZN1x6CLR57e1fSA1LC3yQ387Pv) o altri metodi.

Ultimo aggiornamento: 2019/08/06 23:40.

Datadrifter di Spyglass Security è un nuovo motore di ricerca che trova i bucket di Google Cloud lasciati aperti. Se fate sign-in con un account Google, scegliete Explore e poi Images, troverete davvero di tutto. Attenzione: molte immagini e molti video sono assolutamente non adatti ad ambienti con minori o luoghi di lavoro. Questa è la schermata più safe for work che sono riuscito a catturare (e anche così ho dovuto mascherarne una parte).

Notate in basso a destra l’immagine di quello che sembra essere un impianto di lettura automatica di indirizzi postali, con buona pace di GDPR, leggi sulla privacy, sicurezza informatica e compagnia bella.



Datadrifter offre anche una funzione di ricerca, in versione semplice o avanzata. La versione a pagamento (da 20 dollari/mese in su) permette di approfondire la ricerca, ma non ho ancora provato: devo ancora sciacquarmi gli occhi per le cose che ho visto.

Nella ricerca semplice è sufficiente immettere il nome di un bucket trovato per esempio nella sezione Explore per ottenere un elenco di file come questo, che riguarda il lettore di indirizzi postali:



Sono tentato di abbonarmi per vedere cosa trova. Qualcuno di voi lo conosceva già e lo ha già provato?

Secondariamente: ma quanto bisogna essere incompetenti per lasciare un bucket Google Cloud leggibile dal mondo intero?

2019/08/06 23:40

La versione a pagamento permette di vedere molto di più: scansando a fatica l’ondata di immagini pornografiche, emergono decine di immagini di documenti personali, alcuni dei quali anche italiani, e di screenshot di transazioni di acquisto, con nomi, cognomi, date e importi. Ho trovato il nome di almeno una delle aziende che sta mettendo online questi documenti.

Un clic destro sull’immagine seguito da Copy Image Location permette di risalire al bucket e verificare che l’immagine è realmente accessibile a chiunque, come in questo caso volutamente innocuo (la foto di un cane). Gli URL sembrano essere tutti del tipo https://www.googleapis.com/download/storage/v1/b/[nome del bucket]/o/[path][nomefile][parametri].

Fra i nomi dei bucket ho notato welo, cluster-media, simplestorage, phil-videos, piratebay-pics (decisamente NSFW), appstore-assets, nextpro, mastodon, imwork, alarabiya-assets, vidooly, symphonyimages, fcc-photos, chinatimes, store-production e altri ancora.

Nello screenshot qui sotto ho coperto io i dati sensibili, che negli originali sono perfettamente leggibili:



Ora sarebbe interessante trovare il modo di sapere a quali aziende appartengono questi bucket colabrodo e contattarle per sapere se la visibilità è consapevole e intenzionale o se è un errore gravissimo da correggere.

Questo articolo è il testo del mio podcast settimanale La Rete in tre minuti su @RadioInblu, in onda ogni martedì alle 9:03 e alle 17:03. Questa puntata può essere ascoltata qui.


Domanda a bruciapelo: dove sono le vostre foto di famiglia? Ne avete una copia di scorta, o fate quello che fanno quasi tutti, ossia avete quelle vecchie ammassate in una scatola da qualche parte in casa e quelle recenti nello smartphone? Non per menare gramo, ma avete già pensato cosa fareste se vi si guastasse lo smartphone o lo perdeste? Riuscireste a recuperare tutti i vostri ricordi digitali? Pensateci un momento.

Ormai è diventato normale affidarsi al cloud, ossia all’archiviazione dei propri dati presso un fornitore di servizi, sia per lavoro sia nella sfera privata. Gli smartphone archiviano quasi sempre automaticamente una copia dei dati presso i cloud di Google, se avete un telefonino Android, o di Apple, se avete uno smartphone di questa marca. Ma è importante ricordarsi una regola fondamentale: il cloud è il computer di qualcun altro. E quel qualcun altro non sempre ha a cuore i vostri ricordi più cari quanto li avete voi.

Lo hanno scoperto di recente, con amarezza, gli utenti di MySpace. Per chi non se lo ricorda, MySpace, nato nel 2003, era diventato il social network più popolare nella seconda metà degli anni duemila. Nel 2006 era addirittura più visitato di Google. Aveva centinaia di milioni di utenti e tantissime funzioni all’epoca innovative, come il caricamento di canzoni, e permetteva di elencare ben otto amici speciali nel proprio profilo. Nel 2009 fu travolto, come tanti altri, da Facebook.

Ma MySpace esiste ancora, anche se è quasi dimenticato, e milioni di persone vi hanno depositato i propri dati per anni. Foto, pensieri, ricordi, musica. Sembravano al sicuro, nel cloud. Finché un bel giorno, quei “computer di qualcun altro” hanno avuto un problema. Pochi giorni fa MySpace ha annunciato che a causa di un aggiornamento tecnico non riuscito ha perso irrimediabilmente tutte le foto, i video e i file audio caricati dagli utenti fino al 2015. Dodici anni di dati. Si stima che solo le canzoni perdute siano circa cinquanta milioni.

MySpace ha chiesto scusa per il disagio, come si dice sempre in questi casi, e ha consigliato agli utenti di ricorrere alle copie di scorta personali per recuperare i propri dati. La cosa suona parecchio ironica, visto che a quanto pare MySpace non aveva pensato di approntare una copia di scorta dei dati dei clienti prima di imbarcarsi nell’aggiornamento poi fallito.

La vicenda ha messo in luce uno dei limiti del cloud: certo, è meglio di niente, e ci sono fornitori di servizi cloud estremamente professionali e affidabili, ma alla fine se depositiamo i nostri dati nel computer di qualcun altro quei dati dipendono dalla competenza e dalle decisioni di quel qualcun altro.

Il consiglio degli esperti è quindi di usare il cloud come deposito facilmente accessibile, ma di avere comunque una copia personale, locale, dei propri dati. Spesso è sufficiente un buon disco rigido, scollegato da Internet, al sicuro da aggiornamenti tecnici mal riusciti e da eventuali virus e attacchi informatici. Magari protetto da una password e depositato a casa di un amico fidato. Pensateci.


2019/03/26 20:20. Cracked.com segnala che questa non è la prima purga drastica dei contenuti di Myspace: una perdita analoga di dati era già avvenuta nel 2013.

Si fa un gran parlare di protezione dei dati digitali, GDPR (regolamento generale sulla protezione dei dati) e relative sanzioni, per cui sembra ragionevole pensare che le aziende siano ben attente nel gestire i dati dei clienti. Il GDPR, in particolare, prevede sanzioni talmente pesanti in caso di fuga di dati sensibili che parrebbe ovvio e inevitabile investire in misure di sicurezza.

È di ieri la notizia della fuga di dati del database di Rousseu, la piattaforma del Movimento 5 Stelle, già protagonista di una precedente fuga: trovate i dettagli su DavidPuente.it e in questo articolo di Martina Pennisi sul Corriere della Sera online. Ma non è certo un caso isolato.

In queste settimane ho seguito un tipo molto specifico di fughe di dati: quelle tramite i bucket di Amazon. I bucket sono degli spazi a noleggio per la custodia dei dati. In pratica, un’azienda, invece di investire in un proprio server nel quale depositare i propri dati, può affittare spazio sui server di Amazon e mettere lì i dati. Amazon garantisce spazio e traffico a volontà: basta pagare.

Il grosso vantaggio è la flessibilità: una piccola azienda può espandersi in fretta senza dover aspettare di comperare dei propri server aggiuntivi, affittando invece spazio su Amazon. Due clic e lo spazio raddoppia, triplica, si decuplica. Quando non serve più si abbandona.

Il problema è che se il bucket non viene configurato correttamente, i dati sono accessibili a chiunque, perché hanno un link pubblico. E non è difficile scovarli. Questo è un esempio di un bucket lasciato aperto, riguardante un’azienda russa:




Basta cliccare su uno qualsiasi dei link e compaiono scansioni di passaporti come questa (ho mascherato io i dati in tutte le immagini seguenti):




In un altro bucket ci sono dati sanitari italiani:




Altrove ci sono backup di database, tessere sanitarie, password, tabelle di contabilità, documenti di tribunali:


Estratti conto di una banca messicana:



La cosa curiosa è che alcuni bucket sono già stati visitati da qualcuno che ha lasciato un cortese avviso:

Hello,
This is a friendly warning that your Amazon AWS S3 bucket settings are wrong.
Anyone can write to this bucket.
Please fix this before a bad guy finds it.

Insomma, il problema è piuttosto diffuso e largamente ignorato.

Magari vi state chiedendo quali tipi di reato si possano compiere realisticamente con una scansione di un documento d’identità. Non voglio regalare spunti criminogeni a nessuno, per cui mi limito a un solo esempio già divulgato: ricordate la truffa “Questa è la tua password, sappiamo che hai visitato siti porno, ti abbiamo registrato, ora paga altrimenti diffonderemo il video”? Ne avevo parlato a luglio scorso.

Immaginate quanto diventa più credibile questa truffa se il suo messaggio dichiara di provenire dalla polizia e include i vostri dati anagrafici, il vostro numero di telefono e il numero di un vostro documento e vi intima di pagare una multa per evitare conseguenze più gravi.

Cosa si fa quando ci si imbatte in casi come questi? La soluzione più diretta sembrerebbe essere quella di contattare le aziende responsabili, ma ve lo sconsiglio: quando lo faccio io, pur qualificandomi come giornalista e informatico, la maggior parte delle volte non vengo creduto.

La cosa più efficace è segnalare dettagliatamente il tutto alle autorità apposite: per esempio, in Svizzera ci sono l’apposita pagina dell’Ufficio Federale di Polizia e quella di MELANI (la Centrale d'annuncio e d'analisi per la sicurezza dell'informazione); in Italia ci si rivolge al CNAIPIC (Centro Nazionale Anticrimine Informatico per la Protezione delle Infrastrutture Critiche). Che è quello che ho fatto io per questi casi. Speriamo in bene.

Credit: Victor Gevers.

Avete presente quando si dice che la parola “cloud” andrebbe sostituita mentalmente con “il computer di qualcun altro”? Da oggi bisognerebbe forse usare un’altra frase: “il computer di qualcun altro, aperto a tutti e pure scrivibile da chiunque, sul quale qualcuno lascia messaggi per avvisarti del disastro imminente”.

È quello che stanno scoprendo amaramente le tante aziende e organizzazioni governative che usano i servizi cloud di Amazon, i cosiddetti Amazon Web Services, per mettervi i propri dati. È un sistema potente e flessibile, ma bisogna saperlo usare. A quanto pare molti responsabili informatici non hanno studiato come si usa, perché hanno impostato questi servizi, denominati in gergo bucket (secchio), in modo che possano essere letti da chiunque. E in alcuni casi anche scritti dal primo che passa.

Non è colpa di Amazon, ma dei suoi clienti incompetenti. Clienti con nomi come Uber, Dow Jones, FedEx e persino il Pentagono, che hanno lasciato bene in vista i propri dati in questo modo, come raccontano WeLiveSecurity e la BBC. Secondo i dati della società di sicurezza francese HTTPCS, 1 bucket su 50 non è protetto contro la scrittura.

Mi è stato segnalato, per esempio, un noto canale satellitare europeo che ha la guida TV su Amazon Web Services scrivibile da chiunque. Far comparire qualcos’altro al posto delle immagini di Peppa Pig sarebbe un gioco da ragazzi.

****.s3.amazonaws.com/admin/server/php/files/peppa3.jpg

Gli hacker buoni hanno fatto il possibile, lasciando messaggi di avvertimento nei bucket vulnerabili, ma in molti casi sono rimasti inascoltati. Alcuni esperti di sicurezza hanno contattato le organizzazioni maldestre per avvisarle, ma non sempre sono stati capiti e in alcuni casi rischiano anche ritorsioni legali (che è come rischiare una denuncia perché hai guardato in casa di qualcuno attraverso la finestra, hai visto che c’era un incendio e hai avvisato il proprietario).

Altri hanno preferito creare siti Web come Buckhacker (attualmente offline), che è una sorta di Google per i bucket aperti, in modo da portare il problema all’attenzione dei media.

Il guaio di queste vulnerabilità è che i dati messi a disposizione di chiunque sono spesso i nostri e sono un bersaglio ghiotto e facile per qualunque criminale. Immaginate qualcuno che cancella tutti i dati di un’azienda o di un’agenzia governativa, oppure li blocca con una password che verrà fornita solo in cambio di un riscatto. Se la vostra organizzazione usa gli Amazon Web Services, date un’occhiata alle impostazioni. Amazon ha allestito uno strumento apposito che facilita questo controllo.


Fonte aggiuntiva: Bitdefender.

Ha fatto subito il giro del mondo il racconto della disavventura capitata a James Pinkstone, di Atlanta, negli Stati Uniti: Apple Music, il servizio di streaming musicale a pagamento di Apple, ha cancellato ben 122 gigabyte di musica dal suo Mac. Compresi i brani che lui stesso aveva composto. E lo ha fatto, dice, senza dare alcun preavviso e senza chiedere il consenso. Non solo: quando ha contattato l’assistenza Apple gli è stato detto che Apple Music stava funzionando correttamente e che questa cancellazione era un comportamento previsto.

Se siete uno dei circa undici milioni di utenti paganti di Apple Music, la storia del signor Pinkstone è da brivido; in generale, è un monito per chiunque affidi i propri dati al cloud. Che, va ricordato, è un termine di marketing per non dire “il computer di qualcun altro”.

Apple Music, infatti, inizialmente legge tutti i brani audio presenti nel computer dell’abbonato, li confronta con quelli che Apple ha in archivio e poi cancella dal computer quelli che gli risultano presenti in archivio. Quando l’abbonato vuole ascoltare un brano su uno qualunque dei propri dispositivi, Apple glielo manda in streaming. Questo fa risparmiare spazio su disco e consente di avere la musica a disposizione ovunque.

Il problema, racconta il signor Pinkstone, è che il software di confronto e riconoscimento dei brani è impreciso e sbaglia a identificare i brani, per esempio confondendo una versione di una canzone con un’altra, e quindi capita che sostituisca un’edizione rara con quella generica più comune, una cover con un originale, una versione dal vivo con quella registrata in studio. L’edizione rara, magari trovata con fatica, viene cancellata dal computer dell’abbonato.

Peggio ancora, quando Apple Music incontra un brano che non riconosce, lo preleva dal computer dell’abbonato, lo copia sui propri server e poi lo cancella dal computer dell’utente. E lo fa anche con i brani composti dall’utente, come nel caso del signor Pinkstone. Questo significa che Apple controlla l’accesso dell’autore alla sua musica, e dato che Apple Music è un servizio a pagamento, l’utente deve pagare per avere accesso alle proprie composizioni o alla musica che aveva già pagato acquistandola per esempio su CD.

James Pinkstone è riuscito a recuperare tutta la propria musica attingendo a un backup, ma chi non ha una copia di scorta della propria collezione musicale rischia di trovarsi a dipendere da Apple e doverle pagare un abbonamento. Peggio ancora, chi elimina il proprio account Apple Music dopo i primi tre mesi di prova gratuiti rischia di aver perso tutto.

C'è chi fa notare che in realtà Apple Music avvisa prima di cancellare, ma lo fa in modo poco chiaro ed è facile sbagliarsi: forse è quello che è successo al signor Pinkstone e ad altri utenti in passato. Comunque sia, la vicenda evidenzia bene il rischio molto concreto dell’attuale tendenza ad affidarsi a servizi cloud senza conservare una propria copia locale dei dati: si diventa dipendenti dall’accesso a Internet e soprattutto dagli umori del fornitore del cloud per l’accesso ai propri dati e per la loro integrità. E se il cloud sbaglia o l’abbonamento scade, i dati sono persi o silenziosamente alterati per sempre.

Credit: Wikipedia/Gage Skidmore

Ricordate l’enorme collezione di foto intime rubate alle celebrità americane nel 2014? Sono stati resi pubblici alcuni verbali delle indagini condotte dall’FBI per risalire ai colpevoli e ci sono dei paralleli interessanti con le notizie recenti di un’analoga collezione circolante in Rete di foto esplicite di minorenni del Canton Ticino che sta suscitando molte discussioni.

I verbali dell’FBI descrivono il modo in cui una delle vittime, identificata soltanto come J.L. (presumibilmente Jennifer Lawrence), si è fatta delle foto intime con il proprio iPhone, non le ha mai condivise pubblicamente, mandandole soltanto al proprio partner e cancellandole subito dopo averle inviate.

Detta così, si direbbe che la vittima abbia preso tutte le precauzioni normalmente sufficienti; ma dai verbali emerge che la vittima ha ricevuto una mail di phishing, che simulava un messaggio dell’assistenza clienti di Apple con il mittente appleprivacysecurity@icloud.com:

Your Apple ID was used to login into iCloud from an unrecognized device on Wednesday, August 20th, 2014. Operating System: iOS 5.4. Location: Moscow, Russia (IP=95.108.142.138). If this wasn't you, for your protection we recommend you change your password immediately. In order to make sure it is you changing the password, we have given you a one time passcode, 0184737, to use when resetting your password at http://applesecurity.serveuser.com/. We apologize for the inconvenience and any concerns about your privacy. Apple Privacy Protection.

La vittima ha dichiarato di averlo ritenuto autentico, anche se non ricorda se ha seguito le sue istruzioni. Se lo ha fatto, ha regalato la propria password di iCloud al ladro di foto, che a quel punto poteva scaricare via Internet, senza che la vittima lo sapesse, tutte le copie delle fotografie della vittima salvate automaticamente su iCloud.

Sul caso ticinese c'è stretto riserbo da parte degli inquirenti, per cui per ora non è da escludere che alcune delle foto di minorenni non siano state condivise in pubblico volontariamente ma siano state rubate via Internet con una tecnica come quella che ha descritto l’FBI, peraltro assolutamente standard nel settore. Una perizia tecnica sugli smartphone delle persone coinvolte potrebbe togliere questo dubbio importante, visto che per molti genitori (e probabilmente anche per l’opinione pubblica) c’è una grande differenza di responsabilità fra fare un autoscatto intimo tenendolo per sé o per il partner e condividerlo intenzionalmente con chiunque su un social network. Prima di giudicare, insomma, è meglio chiarire come le foto in questione sono diventate pubblicamente accessibil.

Cosa altrettanto importante, episodi come questo dimostrano che rubare le foto dagli smartphone è più facile di quel che si pensa comunemente, perché non è necessario l’accesso fisico al telefonino e quindi le normali precauzioni di buon senso non bastano. L’unica soluzione sicura per garantire che un selfie intimo non finisca in giro è, molto drasticamente, non farne, per nessun motivo. Quello che non c’è non si può rubare.

Conservare le proprie password in un'unica applicazione che le gestisca e le ricordi per noi sembra una buona idea, ed è sicuramente meno pericoloso che usare la stessa password dappertutto come fanno in tanti, ma ha dei limiti. Lo hanno scoperto gli utenti di LastPass, un servizio di custodia password basato su tecnologia cloud, che è stato violato pochi giorni fa.

LastPass ha annunciato infatti che sono stati trafugati indirizzi di mail, promemoria di password, codici di autenticazione e altri dati degli utenti, ma gli archivi cifrati dei clienti non sembrano essere stati aperti.

Non c'è da farsi prendere dal panico se si usa LastPass, ma c'è un possibile rischio se la propria master password è debole (è costituita da una sola parola o da una sequenza di caratteri usata altrove come password); comunque è opportuno cambiarla e cambiare anche le password presso gli altri siti gestiti tramite LastPass.

Il problema principale, in questo momento, è che il sito di LastPass è sovraccarico di richieste di accesso proprio per aggiornare questi dati. In attesa di riuscirci, vale la pena di porsi una domanda: è davvero una buona idea dipendere dai computer di qualcun altro per la propria sicurezza? Ben vengano le applicazioni di gestione delle password, ma è meglio usarne una che consenta la gestione locale, magari su una penna USB chiusa dentro un cassetto e comunque protetta dalla master password.


Fonti aggiuntive: ZDNet.

A settembre scorso erano finite in Rete moltissime foto intime di celebrità soprattutto statunitensi, sottratte dai loro smartphone. Per gli internauti è ormai storia passata, ma per l'FBI è invece un'indagine ancora in corso, che ha portato ai primi risultati. Il colpevole principale sarebbe un certo Emilio Herrera, titolare dell'indirizzo IP di Chicago dal quale sono stati effettuati ben 3263 tentativi di accesso a 572 account iCloud differenti nel corso di vari mesi.

La segnalazione del comportamento anomalo è giunta agli inquirenti dalla Apple, logicamente insospettita dal fatto che uno stesso indirizzo IP potesse avere così tanti account.

L'intruso scaricava il contenuto dell'account iCloud della vittima usando uno strumento software facilmente acquistabile in Rete e altrettanto facilmente usabile. È forse questo l'aspetto più interessante della vicenda: l'intrusione non è frutto di chissà quali competenze da superinformatici. Un intruso digitale intelligente non sarebbe stato così ingenuo da accedere a tutti quegli account da uno stesso indirizzo IP, men che meno dal proprio.

Un altro trucco molto diffuso e molto efficace rimane il classico phishing: l'invio alla vittima di una mail che simula di provenire dall'assistenza tecnica del cloud e convince la vittima a visitare un sito che imita quello del cloud ma è in realtà gestito dal ladro e chiede di immettere nome utente e password, che così finiscono in mano al criminale.

La prevenzione resta sempre il rimedio più efficace: se non ci sono foto intime da rubare, non c'è intrusione che tenga. E se proprio si sente il bisogno di farsi selfie potenzialmente imbarazzanti, è meglio usare un dispositivo non connesso a Internet, come per esempio una normale fotocamera.

Questo articolo vi arriva grazie alla gentile donazione di “giovanni.se*” ed è stato aggiornato dopo la pubblicazione iniziale.

Non pensavo che mi sarebbe capitato di citare Kim Kardashian in questo blog, ma sono in circolazione in Rete da un paio di giorni le sue foto private piuttosto esplicite, insieme a quelle ancora più esplicite di altre celebrità (Kaley Cuoco, Jennifer Lawrence e molte altre), e ne stanno parlando un po' tutti: The Hacker News, Naked Security, Time (anche qui), Gawker, Huffington Post, Corriere del Ticino, BBC. Per cui vale la pena di analizzare gli aspetti di sicurezza informatica di questa faccenda e smontare un paio di miti e ipotesi.

Primo, non è affatto vero, come hanno scritto alcune fonti giornalistiche, che le foto sono state prontamente rimosse da Internet: sono ancora reperibili molto facilmente (non fornisco dettagli per ovvie ragioni legali), e ogni volta che viene disattivata una fonte ne spuntano altre. È importante non alimentare false sicurezze e non dare credito all'idea che una foto che è finita su Internet possa essere magicamente rimossa con totale certezza.

Secondo, non c'è per ora nessuna indicazione tecnica che la nuova ondata di foto sia il risultato di una nuova falla in iCloud o in altri servizi analoghi. Chi ha analizzato i dati EXIF delle foto circolanti non ha trovato immagini con date (di scatto originale o di manipolazione con software di ritocco/archiviazione) successive a quelle delle foto già in circolazione dall'inizio di settembre.

Terzo, nel caso della Kardashian non sembra esserci di mezzo iCloud, dato che lei ha dichiarato di non avere un account iCloud e le sue foto provengono in origine da un cellulare BlackBerry, come nel dettaglio qui accanto, tratto da uno degli autoscatti sottratti, che risalgono a quanto pare ad alcuni anni fa.

Quarto, vale anche stavolta la precauzione già data: attivate l'autenticazione a due fattori; se non volete che le vostre foto intime finiscano nel cloud, disattivate i servizi cloud e comunque toglietele dal telefonino. Meglio ancora, fatele con una fotocamera che non si connette a Internet e custoditele offline.

Questo articolo vi arriva grazie alla gentile donazione di “remot*” e “swiftgt*” ed è stato aggiornato dopo la pubblicazione iniziale.

Poche ore fa sul famigerato canale /b/ di 4chan è stata pubblicata una serie molto consistente di fotografie e video personali di circa un centinaio di cantanti e attrici e dei loro partner: Jennifer Lawrence, Kaley Cuoco, Avril Lavigne, Kate Upton, Ariana Grande, Lea Michele, Kirsten Dunst e molte altre.

Alcuni scatti sono estremamente intimi e sono stati autenticati dalle rispettive vittime del furto di massa, che è stato segnalato da Huffington Post, Gawker, Mashable, Business Insider, E!Online, BBC e in numerosi altri siti di notizie.

Si tratterebbe di un assaggio, studiato per invogliare gli utenti a mandare soldi (tramite bitcoin) all'autore del furto affinché pubblichi il resto del maltolto, evitando i rischi di una trattativa con siti di gossip o peggio.

Lasciando da parte il contenuto delle foto e passando agli aspetti tecnici (analizzati bene da @SwiftOnSecurity su Twitter e da Graham Cluley sul Guardian), molti dei siti che stanno pubblicando la notizia ipotizzano che il furto sia avvenuto a causa di una falla di iCloud di Apple, che metterebbe a repentaglio la privacy di chiunque usi un iPhone e i servizi online di Apple per custodire le proprie foto.

In effetti, l'entità massiccia del furto, perpetrato ai danni di più persone e contenente immagini risalenti a date differenti, anche recentissime (secondo le acconciature e i dati EXIF), e in alcuni casi addirittura cancellate (TMZ.com), e il fatto che si tratta in quasi tutti i casi di selfie o di foto chiaramente fatte con un telefonino, rendono molto plausibile la strada della sottrazione tramite accesso indebito alla copia conservata nel cloud senza adeguate precauzioni. Proprio oggi Apple ha corretto una falla che permetteva di accedere agli account iCloud tramite un banale bruteforcing, ma può darsi che sia semplicemente una coincidenza.

L'intrusione così ampia si potrebbe anche spiegare semplicemente con il fatto che il criminale ha avuto accesso alla rubrica telefonica di una vittima iniziale e vi ha trovato i numeri delle altre.

Tuttavia l'idea che il problema riguardi soltanto il cloud di Apple parrebbe smentita dal fatto che i telefonini visibili nelle foto non sono tutti iPhone (lo è quello mostrato qui sopra in mano a Jennifer Lawrence, ma altre foto mostrano cellulari di altre marche), anche se chi usa telefonini non-Apple potrebbe trovarsi comunque con il dispositivo collegato ad iCloud.

L'altra ipotesi plausibile è che il furto sia stato realizzato da una persona che lavora all'interno dei servizi cloud dei produttori dei telefonini o delle reti cellulari utilzzate dalle celebrità coinvolte.

Va notato, infine, che non si tratta soltanto del fatto che delle celebrità rivelano qualche centimetro di pelle in più e lo fanno magari prima del trucco e di Photoshop: nelle foto ci sono anche le coordinate GPS, con il conseguente rischio di stalking. Non tutti coloro che lavoro nel mondo dello spettacolo hanno i soldi per pagarsi guardie del corpo e servizi di vigilanza.

Non è la prima volta che avviene una predazione del genere: nel 2012 era successo a Scarlett Johansson, Mila Kunis e altre celebrità. L'autore del furto era stato identificato e condannato a dieci anni di carcere. Anche in questo caso, sottolineo che un adulto ha il diritto di farsi le foto intime che meglio preferisce e che questa è comunque una violazione della privacy anche nel caso di celebrità, la cui unica colpa è fidarsi delle promesse di riservatezza dei fornitori dei servizi che usano.

Per chi non ha tempo o voglia di studiare gli aspetti di sicurezza dei servizi cloud e dei telefonini (per esempio l'autenticazione a due fattori e la disattivazione dei dati GPS) resta valida la raccomandazione di sempre: se fate foto che non volete far circolare, non fatele mai usando un dispositivo collegato o collegabile a Internet e non affidatele ai servizi cloud. Meglio ancora, non fatevi foto intime, se non volete spendere tempo a imparare come proteggerle.

Tenete presente che anche se voi fate del vostro meglio, una fuga d'immagini compromettenti può avvenire lo stesso, a causa di una carenza di sicurezza del fornitore dei servizi cloud. Questi servizi non hanno a cuore la vostra privacy; hanno a cuore il profitto. Se a voi succedono guai perché loro non hanno protetto bene le vostre foto, ai loro dirigenti non frega nulla: sono assicurati e comunque di solito le clausole del servizio li esonerano da ogni risarcimento. Per cui se devono scegliere fra sicurezza e profitto, tipicamente sceglieranno il profitto.

Per chi invece si scatena nella caccia alle foto e ai video in questione, ricordo che tipicamente in questi casi i criminali informatici preparano subito copie fasulle contenenti malware o generano siti contenenti le parole chiave legate alla foto, e poi aspettano che i polli arrivino e scarichino, installando il malware o guadagnando dalle pubblicità visualizzate.

E per chi gongola spinto dal voyeurismo e dice che tanto sono celebrità e se la sono cercata, ricordo solo una cosa: questo potrebbe succedere anche a voi. Anche a vostra figlia.


Aggiornamento 1 (14:00): Secondo le discussioni in corso su 4chan, la serie di immagini sarebbe stata pubblicata inizialmente su Anonib (sito ad alto rischio di immagini scioccanti, come del resto 4chan) e farebbe parte di una collezione già circolante (almeno in parte) da tempo fra i cultori di questo genere di contenuti. Inoltre alcune analisi dei dettagli anatomici delle persone ritratte indicano che alcune delle foto sono false (manipolate) o attribuite alle persone sbagliate. Infine, alcuni membri di 4chan ritengono di aver individuato il colpevole della pubblicazione (che non è necessariamente il colpevole del furto), ma 4chan spesso pubblica storie come questa per assistere con compiacimento alla persecuzione di una persona che in realtà non c'entra nulla. Meglio attendere dati concreti prima di lanciarsi in una caccia alle streghe.

Aggiornamento 2 (20:30): Gawker sembra confermare che 4chan non è l'origine delle immagini, che invece sarebbe AnonIB, e che molte delle immagini circolavano già da qualche tempo.

Aggiornamento 3 (23:10): Ars Technica ha postato un articolo molto categorico nel mettere in relazione le immagini trafugate e la falla Apple, ma non spiega le ragioni di tanta certezza. Inoltre sottolinea che se un fornitore di servizi cloud ha una falla di sicurezza, l'utente può anche essere supremamente diligente e prudente, ma si mette nelle mani di quel fornitore. Che ha pochissimo incentivo a garantire la privacy dei suoi clienti.

Aggiornamento 4 (2014/09/02, 14:15): l'esame dei dati EXIF delle immagini circolanti indica, almeno in alcuni casi, date recentissime (metà agosto scorso) e l'uso di Photoshop Express e Windows Viewer; le immagini sarebbero state quindi manipolate prima di essere diffuse. C'è anche almeno uno UUID. Inoltre la natura caotica e frammentata della diffusione sembra indicare che si tratti non di un'unico furto di massa, ma della pubblicazione di una o più collezioni ottenute da fonti differenti: non ci sarebbe, insomma, una mente unica. È interessante notare, infine, che se è stata sfruttata una falla di iCloud o una tecnica di social engineering chi l'ha usata avrebbe potuto tranquillamente azzerare i dispositivi delle vittime, ma a quanto pare si è limitato a copiarne le foto.  A tutt'oggi non c'è nessuna conferma oggettiva di un eventuale nesso fra la falla di Find my iPhone e questi furti d'immagini.

Questo articolo vi arriva grazie alla gentile donazione di “c.bocc*” ed è stato aggiornato dopo la pubblicazione iniziale.

Disco pieno. Su un MacBook Air, che ha un disco a stato solido da 128 GB, può capitare. Quello che non mi aspettavo è l'origine del riempimento: la cache di Dropbox, che aveva assunto la ragguardevole dimensione di 40 gigabyte. In una cartella nascosta, oltretutto, per cui non avrei mai scoperto la causa dell'intasamento se non avessi usato Disk Inventory (utility gratuita sostenuta dalle donazioni).

Una cache gigantesca del genere mi è capitata probabilmente perché ho un Dropbox da 100 gigabyte, che però non sono tutti occupati e non sono neanche tutti condivisi sull'Air, quindi magari a voi non capiterà mai. Ma vi segnalo comunque l'episodio, caso mai dovesse capitarvi o semplicemente se volete dare un'occhiata alle dimensioni della vostra cache Dropbox su un Mac: andate nel Finder e (con il menu Go) scegliete di andare alla cartella ~/Dropbox/.dropbox.cache. Visualizzatela, cancellatene il contenuto e sarete a posto, come descritto nell'help di Dropbox (solo in inglese).

Stamattina ho dedicato la prima puntata del Disinformatico radiofonico dopo la mini-pausa estiva all'“hackeraggio epico” subìto da Mat Honan, giornalista di Wired, ai primi del mese. Se ne è parlato tanto in Rete, ma io ho la fortuna di occuparmene a distanza di due settimane e di poter quindi fare un sunto di come è realmente andata la vicenda, senza le false piste dei primi giorni.

Nella violazione degli account di Honan ci sono lezioni per tutti e un potente promemoria del fatto che il cloud e la cancellazione a distanza sono armi a doppio taglio. Il giornalista si è trovato con il computer, il tablet e lo smartphone completamente azzerati e ha perso un anno di dati e foto personali. E questo è solo l'inizio.

Se vi interessa, trovate il mio racconto della disavventura di Mat Honan sul sito della Rete Tre della RSI sotto forma di serie di articoli e come podcast.

Megaupload e Filesonic dimostrano che il cloud puro non è sicuro

La chiusura di Megaupload e la mutazione senza preavviso di Filesonic non sono soltanto tappe della lotta alla pirateria audiovisiva. Hanno implicazioni molto più significative: dimostrano che l'idea di depositare i propri dati nel cloud è insicura.

Come hanno segnalato molti utenti, fra coloro che utilizzavano questi cyberlocker c'erano anche clienti che non commettevano alcuna violazione del diritto d'autore: vi avevano caricato dei dati di cui erano legittimi titolari. Erano clienti legali che oltretutto pagavano per un servizio. Ma la scure della chiusura (calata dall'FBI o autoimposta) ha colpito anche loro, causando la perdita dei loro dati se non ne avevano una copia altrove.

Kevin Mitnick, come al solito, ha riassunto bene le implicazioni della vicenda sulla strombazzatissima idea del cloud: “Il caso Megaupload ha appena dimostrato che i VOSTRI dati NON SONO AL SICURO nel cloud. Il Governo può semplicemente sequestrare i vostri dati :-( mentre interviene su un'altra azienda”.

Queste sono le conseguenze inattese della difesa fanatica di un diritto d'autore obsoleto: ci vanno di mezzo anche gli utenti onesti. La validità delle accuse degli inquirenti statunitensi nei confronti di Megaupload è, in questo senso, del tutto irrilevante. Chi usa il cloud puro rischia comunque di vedersi sparire tutto senza preavviso; chi usa soluzioni ibride, con copia locale, corre un rischio minore, ma deve tenere presente che in qualunque momento la copia remota può svanire.