skip to main | skip to sidebar
24 commenti

Password patetiche nei siti di Polizia e Giustizia italiani: sberleffo alle leggi sulla privacy

L'articolo è stato aggiornato dopo la pubblicazione iniziale. Ultimo aggiornamento: 2015/07/28 20:35.

È stata rivendicata via Twitter alcuni giorni fa una violazione di vari siti collegati alla Polizia e alla Giustizia italiana (immagine qui accanto), accompagnata dalla pubblicazione di database contenenti dati sensibili provenienti dai siti violati: nomi, indirizzi e numeri di telefono di persone delle forze dell'ordine o legate al settore.

Lasciamo stare le ragioni dell'intrusione: già è imbarazzante che abbia avuto successo, ma la vera vergogna è quello che ha messo in luce, ossia la gestione pateticamente inetta della sicurezza.

Come segnala Luigi Rosa su Siamogeek,

Le password sono tutte in chiaro oppure codificate in MD5 senza salt. In un paio di database nel campo password c’è l’hash MD5, uno spazio e poi la password in chiaro tra parentesi. In più di un esempio la tabella degli amministratori ha le password in chiaro e quella degli utenti ha le password in MD5. Molte password in MD5 sono uguali al nome dell’utente oppure banali (ovvero se vengono trascritte in un motore di ricerca appare la pagina con l’equivalente in chiaro).

E le password usate sono da mettersi le mani nei capelli:

numeri nel formato ggmmaaaa, nomi di città, nomi di persone e parole come passamontagna, meccaemedina, 69cazzo69, Password, 123, polizia, Soloio.

Sì, c'è persino l'immancabile uso di password come password. Luigi segnala anche che ci sono chiari segni di “tentativi di hackeraggio pregresso”. Complimenti.

Mi associo alle sante parole di Luigi:

Le leggi sulla tutela dei dati personali (dette anche “leggi sulla privacy”) dovrebbero, appunto, servire a tutelare i dati personali da questo tipo di intrusioni, non ad obbligare i cittadini e le aziende private a firmare e conservare tonnellate di carta inutile.

Tutti i dettagli sono nell'articolo completo su Siamogeek.


Correzione: avevo scritto inizialmente che la rivendicazione era stata pubblicata oggi, ma in realtà era stata pubblicata alcuni giorni fa e solo oggi l'ho ricevuta tramite un retweet. Ho corretto il testo.
Invia un commento
I commenti non appaiono subito, devono essere tutti approvati da un moderatore. Lo so, è scomodo, ma è necessario per tenere lontani scocciatori, spammer, troll e stupidi: siate civili e verrete pubblicati qualunque sia la vostra opinione; gli incivili di qualsiasi orientamento non verranno pubblicati, se non per mostrare il loro squallore.
Inviando un commento date il vostro consenso alla sua pubblicazione, qui o altrove.
Maggiori informazioni riguardanti regole e utilizzo dei commenti sono reperibili nella sezione apposita.
NOTA BENE. L'area sottostante per l'invio dei commenti non è contenuta in questa pagina ma è un iframe, cioè una finestra su una pagina di Blogger esterna a questo blog. Ciò significa che dovete assicurarvi che non venga bloccata da estensioni del vostro browser (tipo quelle che eliminano le pubblicità) e/o da altri programmi di protezione antimalware (tipo Kaspersky). Inoltre è necessario che sia permesso accettare i cookie da terze parti (informativa sulla privacy a riguardo).
Commenti
Commenti (24)
E in azienda che vogliono usare una password uguale per i vari servizi?
Io facendo il finto tonto ne ho già create ad hoc, ignorandoli. Nulla di astruso, ma nemmeno così ovvio...
Le password sono tutte in chiaro oppure codificate in MD5 senza salt.

E' inammissibile che si debba obbligare i sysadmin a salare le password perché è un vile attacco alla loro salute. Infatti, l'ipertensione arteriosa può essere molto pericolosa.

Ma per fortuna lo stato italiano queste cose le sa e, difatti, non glielo ha fatto fare.
A questo punto vado a lavorare io nella sicurezza dei loro DB. Ancora a usare MD5 che vergogna.
E io che in azienda "costringo" gli utenti a cambiare la password e ad averla "complessa" e non ripetibile perchè gestiscono "dati personali" (cioè anagrafiche clienti, in cui l'unico dato personale è il numero di telefono, trattandosi di AZIENDE presenti sulle pagine gialle e con partita iva)??? E ho dovuto installare un agent per memorizzare gli accessi nei server da parte dell'utente Administrator (gli accessi: non cosa viene effettuato, solo ed esclusivamente gli accessi....), pena la non approvazione del bilancio?
Tonnellate di carta inutile al solo scopo di scaricare la responsabilità su altri: utente, io ti tutelo, visto?
Quella considerazione su "obbligare i cittadini e le aziende private a firmare e conservare tonnellate di carta inutile" è proprio ciò che mi fa esitare a cambiare il mio gestore telefonico. Come distinguere fra tutti quei fogli, fra quelli che DEVO firmare e quelli che POSSO firmare?
Grazie, "garante", per tutte le complicazioni che ci stai dando, senza dimenticare la tassa sui cookies (che lui chiama legge sui cookies).
Scusate l'ignoranza mia, cos'è la tassa sui cookies? Questa m'era sfuggita fra tutte le altre...Grazie
Qui usiamo un framework scritto da me e per la specifica parte di codifica della pass viene usato un altro algoritmo di hashing e oltre al salt l'operazione di codifica viene iterata tot volte. Questa scelta, pur essendo di semplice implementazione, non solo aumenta notevolmente le risorse necessarie per un attacco brute force, ma non usando un sistema standard hai prima il problema - non banale - di riuscire a identificare COME è stata crittografata la password.

Ovviamente il codice è proprietario. Se volete cercare di convincermi che sarebbe più sicuro avere tutto aperto e sbandierare ai quattro venti quale algoritmo viene utilizzato, quante volte viene iterato il processo e come viene usato il salt in queste iterazioni, beh, provateci pure. Ogni tanto fa bene leggere anche qualche stronzata (*)

*: la dico in modo un po' violento ma... i teorici che dicono a prescindere "è meglio l'open" mi hanno un po' rotto. E' meglio codice mantenuto e testato bene, e la storia dimostra che la qualità del codice dei progetti open è strettamente correlata alla quantità e alle capacità dei programmatori che ci lavorano. Sul kernel di Linux ad es. ci lavorano programmatori professionisti occupati full time e pagati, e i risultati si vedono; basta spostarsi appena più in là su un componente comunque fondamentale per la sicurezza della Rete come OpenSSL perché saltino fuori falle assurde... poi vai a vedere, e ci lavoravano in tre gatti, di cui solo uno con una certa costanza. Se OpenSSL fosse stato closed, ma curato e testato da un team di alto livello, certe cose non sarebbero successe (non risolve tutti i problemi, però fare le cose bene generalmente porta a risultati migliori che far le cose in modo arrangiato). Sento già i "grazie tante", beh, allora concorderete che non è una questione di open / closed ma di chi / come viene sviluppata la cosa.

Anche perché la storiella che se è open chiunque può vedere e correggere è molto romantica, fa molta presa, uno slogan azzeccato... l'importante è non portare numeri reali. Voglio vedere quanti programmatori entrano in un progetto precostituito perché trovano il bug e si mettono a correggerlo in prima persona (chi ha questa fantasia non si rende minimamente conto di come funziona il bug fixing... modifichi il codice e se poi crei altri bug? Se poi alteri le funzionalità? Chi sei tu per metterci mano? Su, fatemi il favore...), invece di segnalarlo che - guarda caso - viene fatto tanto quanto per il software open e il software closed. Ed è da lì che viene fuori lo slogan "chiunque può correggerlo", fatto apposta per promuovere faziosamente l'open; per cui l'open è meglio anche se scritto a culo, e non succede niente a dire a chi cerca di attaccarti i tuoi segreti... Certo, ripeto, magari in un kernel che viene mantenute da teste e risorse tali per cui i bug vengono individuati e corretti in tempi ridotti si; su altri pacchetti no. E allora non è che l'open è intrinsecamente più sicuro, a parità di qualità e capacità di sviluppo è vero il contrario. Prendiamo l'esempio di OpenSSL, individuato un buffer overflow capire come sfruttarlo fosse stato closed era alla portata di pochi, con il codice disponibile diventa alla portata di tanti... Ma tanto è una religione ed è inutile cercare di mostrarvi le incoerenze o le omissioni della vostra fede.
E le Poste, che per il sito Banco Posta Impresa On Line usano una versione di Websphere fuori supporto dal 2013 con sistemi di cifratura dichiarati non sicuri?
@FX : cerco di rispondere alle tue giuste critiche in maniera costruttiva. Diciamo che e' piu' corretto dire che SAREBBE meglio l' open se la gente si prendesse la briga di controllare il codice ma sappiamo benissimo che per il 99% degli utilizzatori del software open source la migliore qualita' dello stesso (e lo dico da utilizzatore io stesso) e' che e' gratuito per la maggior parte. Sul perche' dico "la maggior parte" penso che tu sappia (altrimenti ti esorto ad informarti in merito) la distinzione su cui batte il buon vecchio Stallman tra Open Source e Free Software. Pero' potrebbe essere una buona cosa rendere open i dettagli dell' algoritmo, a mio parere, perche' cosi' si "certifica" la bonta' teorica del metodo. Pensa ad RSA nelle cui basi teoriche ancora nessuno ha trovato errori o metodi per forzarlo rapidamente
Se posso mettere i miei due cents sul tavolo dell'Open, sto seriamente pensando di abbandonare Thunderbird dopo anni di onorato servizio. Per tre volte su due PC diversi ho perso tutti i messaggi. Recuperati quasi tutti un po' a fatica (non sono uno smanettone ma se mi ci metto d'impegno e seguendo i suggerimenti della rete, qualcosa riescono a fare) ma rimane il dubbio di poterli perdere ancora. Cosa che con Outlook era utopia.

Se con le mail ci lavori, bene che ci sia l'alternativa "gratis", ma per essere corretti, forse il closed source è più affidabile.
@Fx stai facendo una pericolosa confusione tra algoritmi open e codice open.

Ci possono essere algoritmi open assolutamente sicuri implementati su software open assolutamente insicuro. Un esempio per tutti: Heartbleed.

Il pericolo della sicurezza fai da te e' che non hai DI SICURO un'entita' terza che verifica il tuo algoritmo e/o non hai la verifica teorica matematica che la composizione della funzioni f(x) che parte dalla password in chiaro e arriva alla password codificata serva effettivamente a migliorare la sicurezza.

Poi siamo tutti daccordo che anche ROT13(MD5) sia meglio di MD5 da solo (prova: cerca su google 5f4dcc3b5aa765d61d8327deb882cf99 e cerca 5s4qpp3o5nn765q61q8327qro882ps99) ma se qualcuno ti ruba il database _e_ il sorgente (come e' successo ad Hacking Team), ce l'hai nel sottocoda. (e' un esempio banale)

Se ti sei un tifoso di "security by obscurity", va bene, devi solo sperare che il tuo codice non vada in giro...
Stupidocane, senza offesa, la tua esperienza personale non vale come argomentazione, perché altrimenti varrebbero anche quelle del tipo "l'omeopatia con me ha funzionato".
Comunque potrei citarti vari casi di intere caselle mail perse con Exchange (proprietario) o sorgenti perduti per sempre con SourceSafe (proprietario pure lui).
@Stupidocane da ~15 anni uso IMAP con backup server side e ho "un po'" di Thunderbird su vari computer (Win e Linux) che referenziano quegli account IMAP; ovviamente ci accedo via webmail e via mobile (K9). Mai persa mail per bachi di mail client.

Se tieni la mail in locale, la corruzione del DB locale delle mail e' un fatto che puo' succedere, indipendentemente dal software (ti dico io quanti PST danneggiati ho visto e riparato...)

A questo aggiungi che Outlook 2007 e 2010 avevano una decente gestione dell'IMAP, con 2013 hanno tolto la possibilita' di salvare la Sent Mail sull'acct IMAP (la salva per forza nei local folder).
@Fx: il tuo contributo è in parte condivisibile, vivo giornalmente sulla mia pelle la scelta (una dozzina di anni fa) della mia azienda di adottare in massa e acriticamente software 'open'. Per mia esperienza il vero problema del software 'open' è che non esiste un rapporto contrattuale tra chi sviluppa software e chi lo utilizza (con in mezzo in genere una società che - a pagamento - lo customizza e lo mantiene), quindi chi sviluppa ha solo un dovere morale (e non legale) di scrivere buon codice, di correggere i bachi in un tempo ragionevole, di implementare funzionalità promesse e necessarie. La conseguenza è che un software non scritto bene in partenza oppure che non raggiunge la massa critica di utilizzatori e sviluppatori si rivela un bagno di sangue su chi lo ha adottato, magari con piani di investimento pluriennali.
A margine di questo comunque ritengo, soprattutto quando c'è di mezzo la sicurezza, che per tutto il software, anche quello commerciale, debba essere disponibile il sorgente, almeno al committente (che in certi casi deve essere anche libero di modificarli, ma questo va risolto contrattualmente). IMHO
Rigongia: sono d'accordo, il punto è finirla una volta per tutte di considerare una cosa "buona" solo perché open o "cattiva" solo perché closed. Ci sono schifezze inimmaginabili che sono open e ci sono software di altissima qualità (il che non significa "perfetti" o "privi di bug", dico sempre "se è software ha bug" - corollario: "anche se è hardware") che sono closed. Io preferisco entrare nel merito che ragionare per stereotipi.

Nel caso specifico degli algoritmi di crittografia è cosa buona che siano open. Detto questo per mio personale parere il COME li usi è cosa buona invece rimanga segreto.

Stupidocane: spezzo una lancia a favore di Thunderbird, o meglio, ultimamente ho avuto a che fare con Outlook 2013 e ho proposto di passare proprio a Thunderbird perché ha una serie di problemi (in particolare con IMAP) che non si spiegano - ovvero che non c'erano nelle versioni precedenti. Diciamo che è un po' come per gli OS: dove vai vai, vantaggi e svantaggi. Purtroppo, come dicevo prima, la soluzione perfetta non esiste mai. Per fare un paragone è come se si dovesse scegliere tra una berlina o un SUV, ci sono vantaggi e svantaggi AHAH
Una cosa sulla "legge sulla privacy"... non tutela i dati dalle intrusioni illecite, ma disciplina l'uso di questi. Ovvero ti permette di richiedere e ottenere la rimozione dei tuoi dati dagli archivi e di permettere o vietarne alcuni usi. Ok, foglia di fico perché tanto tutte le aziende ti dicono che se non dai il consenso non possono far niente, quindi...

E' comunque assurdo che sia così facile rubare dati.
Stupidocane: io sto seriamente pensando di passare tutta la gestione della mia mail su Gmail. Si, chissenefrega se è nel cloud, tanto l'85% della posta è spam. :D
Luigi: se la sicurezza dipende da dato + codice, capisco benissimo che se vanno in giro entrambi cambia niente, però devono andare in giro entrambi, e non è banale. Un esempio pratico: una comune SQL injection... estrai gli hash, punto. Il codice non lo vedi manco con il binocolo. Voglio dire: non sto dicendo che la security through obscurity sia la panacea di tutti i mali, però è ora di finirla di pensarla come un peggiorativo. Alcune volte può fornire un eccesso di confidenza e nessuno lo nega, ma se gestita senza superficialità offre un vantaggio non irrilevante. Il punto è far le cose per bene, e lo ripeto ancora, poi open o closed è una questione che può contribuire in bene o in male a seconda del caso specifico. Smettiamola di ragionare per stereotipi "open = bene", l'esempio di Hearthbleed l'hai fatto anche tu ed è clamoroso.

Nell'ultimo post, che è stato approvato dopo che è stato approvato il tuo, dicevo per l'appunto quello che dici tu: certi algoritmi alla base è un bene siano open, il COME lo uso beh, anche no (anche perché se rendessi open il sw che citavo prima tanto non se lo guarderebbe nessuno e potrei aver commesso i peggiori errori che non avrei alcun plus).

Explobot: il codice sorgente al committente imho è da fornire sia per una ragione di sicurezza ma soprattutto per non lasciarlo a piedi se decide di andarsene. Tant'è che per nostra politica facciamo proprio questo (previa firma di una clausola NDA e di un'altra in cui si impegna a non divulgare il codice né di usarlo per altri progetti oltre a quello/i già in essere). Quando offri una piattaforma proprietaria credo sia una questione di correttezza adottare questo tipo di politica.

In ogni caso la scelta di impiegare una piattaforma proprietaria, nel nostro caso, non ha dietro ragioni di sicurezza: l'obiettivo è quello di offrire un prodotto facilmente customizzabile in ogni sua parte. Lo puoi fare anche con i prodotti open ma quando superano una certa complessità subentra un problema di inefficienza. E come dici tu, non hai supporto / assistenza ufficiale. Il successo di Red Hat è dato proprio da quello: un supporto ufficiale a un prodotto open. Il problema è che più vai nel piccolo più è raro trovare del supporto ufficiale, al punto che spesso ti imbatti in pacchetti che addirittura non sono nemmeno più mantenuti...
@Fx: il codice sorgente al committente solo in un mondo perfetto, e purtroppo non è quello in cui viviamo :-( Ho lavorato da entrambe le parti della barricata e ti garantisco che anche in grosse aziende (per pigrizia, per incompetenza, pensando male, per altro ? Boh!) non c'è la cultura di pretendere il codice e di stabilire contrattualmente di poterlo modificare (sembra una sottigliezza, ma non lo è), neanche quando si tratta di patch a codice open source, che spesso è una clausola della licenza del software di partenza (ho visto cose che voi umani neanche potreste immaginarvi ...). Come ho sentito dire, il mercato dell'informatica è un mercato 'asimmetrico', chi vende sa cosa vende, chi compra non molto.
Explobot: seguo perfettamente quello che dici :) La nostra scelta di fornire il codice è proprio perché oggi di clienti attenti alla tematica ci sono... perché si sono già scottati in passato.

Capita a fagiolo:

http://arstechnica.com/security/2015/07/major-flaw-could-let-lone-wolf-hacker-bring-down-huge-swath-of-internet/

A me onestamente spaventa che software come OpenSSL e BIND siano così diffusi, vedendone i problemi che hanno dietro. Non che il closed sia la soluzione, ma come chi fa software closed può eccedere in confidenza per la security through obscurity, a me sembra che ci sia un eccesso di confidenza sul software open giusto perché è open.
@Fx: siamo in sintonia :-), però c'è gente dove lavoro che malgrado i disastri davanti agli occhi di tutti, si ostina a difendere il suo orticello per cecità ideologica, per convenienza, per ottusità, per pigrizia, per orgoglio e questo costa tempo, risorse, opportunità e in ultima analisi denaro (doppiamente grave perché siamo un ente pubblico). Ma tranquilli se questo prodotto è stato un disastro c'è n'è già pronto un altro che promette faville: "avanti un altro purché sia 'gratis' !". per la gioia dei fornitori. Mi sembra di essere su una nave il cui timone è in mano a dei folli (neanche fossero il capitano Achab). Ormai sono pragmatico e rassegnato, indosso il giubbotto di salvataggio in attesa del naufragio. Chiamami Ismaele! ;-)
@Fx
Beh, uno dei motivi per usare codice open è che sicuramente non nasconde backdoor. Cosa che invece succede nel codice proprietario. Guarda per esempio lo scandalo della libreria RSA BSAFE, che conteneva una backdoor nel generatore di numeri pseudocasuali. La NSA pagò 10 milioni di dollari (da rivelazioni Snowden) per corrompere i programmatori a piazzare la backdoor. Basterebbe molto meno a convincere un qualsiasi admin a mettere una backdoor nel suo codice "oscuro". A proposito, i tuoi utenti si fidano che non hai piazzato backdoor nel tuo codice?
Explobot: siamo in sintonia perché entrambi siamo sul fronte e conosciamo le questioni per esperienza diretta :)

Heavymachinegun: i miei post erano un accorato invito a lasciar perdere stereotipi, superficialità e frasi ad effetto. Il problema che tu poni ricade in questa categoria. Un cliente che si rivolge a noi SI FIDA, perché sa che possiamo entrare nel suo gestionale, sa che possiamo entrare nel suo database, sa che possiamo entrare nella sua email, in alcuni casi possiamo accedere ai file, e così via. Ci deve essere sempre qualcuno che ha un accesso di questo tipo se vuoi che le cose funzionino. Perfino alla cassaforte di Fort Knox ci sarà qualcuno che farà manutenzione, o no? Poi noi operiamo nella massima trasparenza: se ci chiedessero il codice sorgente (come ho già scritto), magari a certe condizioni, ma glielo daremmo, se ci chiedessero quando e perché accediamo ai loro dati terremmo un registro; la realtà è che esistono i rapporti di fiducia e tante volte funzionano molto meglio degli altri... nello specifico non firmando impegni precisi di non divulgazione nei confronti dei nostri clienti adottiamo politiche interne che sono più restrittive di quanto potrebbe essere altrimenti, dato che il cliente nel 99% dei casi non ha la panoramica completa.

Anche perché la realtà dei fatti è che se volessimo svolgere attività malevola, una backdoor è l'ultima delle cose che andrei a pensare, ci sono talmente tanti sistemi che è del tutto riduttivo questionare sul "i tuoi utenti si fidano che non hai piazzato backdoor"... Basta vedere che fine ha fatto Hacking Team: se vuoi fregare qualcuno prima o poi ci riesci, a prescindere dalle backdoor.

Tra l'altro, tu ti fidi che l'elettricista che è venuto a casa tua non ha piazzato microspie? No, giusto per dire =)
@Fx
Beh, la fiducia è una cosa soggettiva.

Comunque ci tengo a precisare che "closed source" non è sinonimo di "security by obscurity", anche se spesso vengono confusi. Il principio di Kerckhoff dice che si deve progettare il sistema COME SE l'avversario avesse in mano il codice. Non dice nulla sul distribuire o meno il codice. Quindi tu NON hai fatto security by obscurity, perché anche se il tuo codice cadesse in mani maliziose, il sistema sarebbe ugualmente sicuro. Chi ti dice che hai seguito la security by obscurity non ha capito bene la definizione.
Qui lo spiega bene:
https://en.wikipedia.org/wiki/Kerckhoffs%27s_principle#cite_note-Bellovin-7

Poi è ovvio che l'open source ha l'effetto di assicurare gli utenti che il principio di Kerckhoff è stato rispettato, e che non ci sono backdoor. Ma se gli utenti si fidano ugualmente, non c'è problema.