Information Security for Geeks

JBoss Security: slides from OWASP

noreply@blogger.com (Roberto Scaccia) — Tue, 24 Jan 2012 22:48:00 PST

Here is the new OWASP slides on JBoss Security. JBoss is a well known Java Web Application Server used in professional environment. So read it if you have it!

The slides have been done by OWASP members who are very oriented to the Application Security. Well done guys!

Alice & Bob: il dato è sensibile perché ha freddo! Ovvero lo scanner ficcanaso

noreply@blogger.com (Roberto Scaccia) — Thu, 19 Jan 2012 22:21:00 PST

Bob: "Che comodità questa stampante/scanner dipartimentale, mi ricordo che due anni fa avevo sollevato un polverone incredibile sulle scannerizzazioni di questi aggeggi. Ti ricordi Alice?"

Alice: "Sì sì sempre il solito, ma adesso i file scansionati li cancelliamo! Una volta al mese un complesso script di cancellazione azzera il contenuto della directory! hihihihi (stavolta l'ho fregato)"

Bob: "(complesso script...bah!) Una volta al mese? E a che serve? Per liberare spazio immagino..."

Alice: "Beh sì, principalmente. Sai l'occupazione disco è un problema perché potrebbe generare fenomeni di tipo "Denial of Service" e quindi....bla bla...bla bla..."

Bob: "(gli hanno fatto fare il solito corso introduttivo sulla sicurezza informatica e adesso ha bisogno di dimostrare che ci ha capito qualche cosa...)"

Bob: "Alice, scusa se interrompo il tuo soliloquio, ma i documenti andrebbero cancellati almeno ogni notte. Non puoi escludere che qualcuno scansioni delle (proprie) informazioni sensibili!"

Alice: "Ma dai se scansiona la sua busta paga o l'indirizzo non è un grosso problema"

Bob: "(questa è tonta)"

Bob: "Forse non mi sono spiegato, "Dato sensibile" secondo la definizione del "Codice per la tutela della Privacy". Quindi: "...dati personali idonei a rivelare: l'origine razziale ed etnica, le convinzioni religiose, filosofiche o di altro genere, le opinioni politiche, l'adesione a partiti, sindacati, associazioni od organizzazioni a carattere religioso, filosofico, politico o sindacale, lo stato di salute e la vita sessuale"..."

Alice: "E quindi?"

Bob: "(niente, non ci arriva proprio, facciamo finta che abbia 5 anni...)"

Bob: "Mettiamo il caso che tu scansioni una ricetta medica o un qualche cosa legato al tuo stato di salute. Tale documento rimane in formato elettronico nella memoria della stampante/scanner dipartimentale. Tu dovresti cancellarlo, ma ti scordi. Abbastanza comune tra gli utenti no?

Ora, poiché questa memoria è accessibile ad un insieme di persone che non comprende solo te, altri potrebbero visualizzare tale documento e, in via ipotetica, iniziare pratiche discriminatorie nei tuoi confronti per le tue condizioni di salute. Discriminazione che potrebbe anche portare a fenomeni quali mobbing, licenziamento, o peggio, pratiche ricattatorie di vario tipo"

Alice: "?????!!!!????"

Alice: "Ma io sto bene di salute!"

Bob: "(non ci arrivi proprio eh!) Ok cancellate i documenti una volta al mese e buona fortuna!"

Alice: "(sempre il solito rompiscatole...)"

Bob: "La solita idiota"

P.S. (n.d.r.) il fatto che Alice sia di evidente sesso femminile non ha alcun legame con il suo ruolo in questi dialoghi (ruolo evidentemente non di spessore). Quindi non c'è alcun intento discriminatorio del sesso femminile.

Google: meglio saperlo!

noreply@blogger.com (Roberto Scaccia) — Wed, 18 Jan 2012 22:53:00 PST

Interessante piattaforma web di Google (Google Goodtoknow) per l'educazione degli utenti alla sicurezza e privacy. Come sempre informazione chiara, semplice e fruibile da (quasi) tutti. Il sito è ovviamente in inglese e anche i video.

Quattro le sezioni principali:

Sicuri on-line
I tuoi dati sul Web
I tuoi dati su Google
Gestisci i tuoi dati

In ognuna di esse è presente un video principale molto ben fatto (e corto!). Poi, nelle diverse sottosezioni, altri video e ulteriori informazioni. Interessante il sito http://www.dataliberation.org/home che permette di "liberare" i propri dati dai servizi Google. Intendiamoci: è fatto da Google stessa!

Ecco alcuni video:

Sicuri on-line

(guardate il video qui sopra ci sono anche indicazioni su come aumentare il livello di sicurezza con i servizi Google, non pensiate di sapere tutto!)

Cosa sono i Cookie

Privacy & Google

Contro la censura (SOPA)!

noreply@blogger.com (Roberto Scaccia) — Tue, 17 Jan 2012 23:12:00 PST

http://sopastrike.com/strike/

---- UPDATE ----

Sembra che la diffusa protesta mondiale stia facendo ritornare sui loro passi gli estensori della legge. Internet Power!

Qui una esauriente spiegazione del bravissimo Paolo Attivissimo del perché questa protesta ha avuto e ha un senso.

OpenSSL Multiple Vulnerabilities

noreply@blogger.com (Roberto Scaccia) — Mon, 09 Jan 2012 23:07:00 PST

Doveroso rimbalzare la notizia. Vista la pervasività di OpenSSL sui sistemi *nix, forse è il caso di fare un update no?

Hash Table, Collisioni e attacchi (D)DoS

noreply@blogger.com (Roberto Scaccia) — Tue, 03 Jan 2012 08:22:00 PST

Rischia di passare sotto silenzio questa vulnerabilità incredibilmente longeva e, almeno dalle prime valutazioni, assai pericolosa.

Pericolosa, perché con delle semplici REQUEST POST si riesce a provocare un consumo di CPU del 100%, per un tempo che può arrivare anche a delle ore. Quindi DoS o peggio DDoS.

Pericolosa, perché non è relativa a questa o quella piattaforma, ma a come i diversi linguaggi implementano la funzione di hashing per la gestione delle strutture dati chiamate "Hash Table" (da non confondere con gli hash crittografici che, sebbene siano pur sempre degli hash, hanno altre finalità e caratteristiche).

Longeva, perché il primo lavoro su di essa fu presentato nel 2003 in una conferenza USENIX e solo oggi, dopo la presentazione al CCC (congresso del Chaos Computer Club), ci si è forse resi conto dell'impatto che può avere un attacco che sfrutta tale vulnerabilità.

La sostanza: inserire nelle hash table dei nuovi valori che generano collisioni con un degradamento "quadratico" del tempo di computazione.

Le hash table vengono utilizzate normalmente in tutti i linguaggi per realizzare i cosiddetti "array associativi", ovvero array che indicizzano i valori contenuti attraverso delle chiavi alfanumeriche:

arrayAssoc["pippo"] = "paperino";

print arrayAssoc["pippo"] ==> "paperino"

Il principio su cui si basano le hash table è semplice: calcolare una funzione H(x) (dove H sta per Hash e x è la chiave), la quale restituisce un intero che è l'indice dell'array sottostante:

H("pippo") = 3

array[H("pippo)] = array[3] = "paperino"

Tendenzialmente la funzione H presenta delle collisioni, ossia a chiavi diverse corrisponde lo stesso indice numerico ed in questo caso i valori sono organizzati in una lista collegata all'indice stesso. Nel caso di collisioni, la lista viene scorsa ad ogni inserimento.

E' questo il punto "debole" dell'algoritmo, perché l'inserimento di n elementi costa nel caso medio O(n), ovvero O(1) per ogni elemento inserito (tempo costante per ogni inserimento). Nel caso peggiore invece, diventa O(n^2), perché ogni elemento inserito ha la stessa chiave e quindi bisogna scansionare la linked-list del bucket corrispondente.

Quindi, per ritornare al dominio dei Web App Server, inviare dei POST che generano collisioni nelle hash table, implica in alcuni casi un tempo O(n^2), ovvero un carico della CPU fuori della norma.

Non c'è però da demonizzare le funzioni hash perché, se usate in un contesto chiuso, ovvero in un'applicazione client, questa "caratteristica" non crea grossi problemi ma solo inefficienze che possono essere anche accettate. Quando invece vengono utilizzate da codice Web che processa POST data, allora l'impatto dell'attacco è di una magnitudo superiore.

La vulnerabilità è assai pervasiva, perché di fatto quasi tutti i linguaggi hanno delle implementazioni non sicure di tale funzione: PHP, ASP.NET (e quindi C#, VB.NET, etc.), Java (Tomcat, JBoss, GlassFish), Ruby e Perl (ma sembra che questi abbiano già provveduto...), etc. O meglio, quasi tutti i Web Application Server basati su questi linguaggi!

Cosa fare?

Aspettare il rilascio della nuova versione del linguaggio di programmazione o dell'ambiente non è forse la cosa migliore nel breve periodo. Gli stessi autori dello speech al CCC suggeriscono di limitare il POST size e il numero dei parametri POST nei Web App Server come workaround.

Nel lungo periodo, non "scordarsi" di aggiornare i Web App Server. Ma questo vale un po' per tutto! :)

Ecco il video della presentazione al CCC:

Se non avete un'ora a disposizione, fate prima a guardarvi le slide in formato PDF scaricabili qui. Sono ben fatte e si capiscono!

Qualitapa.gov.it e Rainews24.rai.it hackerati: credenziali pubblicate. Controllate please!

noreply@blogger.com (Roberto Scaccia) — Fri, 30 Dec 2011 23:02:00 PST

I siti "qualitapa.gov.it" e "rainews24.rai.it" sono stati hackerati, e le credenziali di accesso ad essi pubblicate su pastebin.com!

Scorrendo la lista di credenziali, salta all'occhio che per la maggior parte di esse le password associate sono, molto probabilmente, quelle assegnate dalla piattaforma. Ma per alcune utenze invece la password è stata cambiata dagli stessi utenti.

Ottimo, se non fosse che spesso gli utenti riutilizzano le stesse password per accessi ad altri siti (tipo la posta elettronica...). Ovviamente in questi casi a rischio non c'è solo l'accesso alla piattaforma hackerata ma anche i diversi servizi acceduti dall'utente. Con un po' di prove e conoscendo email e password si possono guadagnare accessi sempre crescenti. E se poi si riesce ad avere accesso alla casella di posta elettronica...

Controllate quindi se siete nelle liste, o se ci sono persone che conoscete, ed avvisatele. E comunque anche se la password è quella di default, cambiatela!

Però una riflessione è d'obbligo: ancora con le password storate nei DB? Ma basta! Nel DB ci vanno solo gli Hash crittografici delle password e non le password (anche se cifrate).

Ci voleva il Natale! Podcast video Defcon 19

noreply@blogger.com (Roberto Scaccia) — Fri, 30 Dec 2011 00:17:00 PST

Ci voleva Babbo Natale per convincere quelli del Defcon 19 a rilasciare un bel podcast. Finalmente dico io! Almeno potremo farci gli affari loro e passare queste feste allenando la mente, oltre che lo stomaco. Lasciate il panettone e buttatevi quindi sul podcast.

Su iTunes è molto semplice aggiungere il podcast (https://www.defcon.org/podcast/defcon-19-video.rss) altrimenti usate quello che vi pare eh!

Buon (passato) Natale

Attenti a quel gioco sul market Android: è un malware

noreply@blogger.com (Roberto Scaccia) — Sat, 24 Dec 2011 22:48:00 PST

F-Secure segnala una pratica molto pericolosa: la pubblicazioni nei market di giochi che hanno un nome simile alla versione ufficiale e che invece sono dei malware. Un esempio per tutti è "Cut the Rope", che nella sua versione originale è a pagamento, mentre il malware ha come nome "Cut the Rope FREE" ed è appunto gratis. Stessa cosa per giochi come "Angry Birds Seasons FREE", etc.

Credo che il problema sussista principalmente nel market Android (vista la politica più restrittiva di Apple) ma bisogna sempre stare attenti, perché anche alla Mela potrebbe sfuggire qualche app maliziosa.

Un suggerimento utile è ovviamente quello di controllare il nome degli autori della app sia nella versione a pagamento che in quella free. Se coincidono allora non ci sono problemi (ma attenti a nomi leggermente diversi eh!).

Questa immagine è abbastanza esplicativa:

Come vedete compare il FREE che invoglia l'ignaro utente a scaricare il gioco-malware.

Quante cose si possono fare con una lattina!

noreply@blogger.com (Roberto Scaccia) — Sat, 24 Dec 2011 00:06:00 PST

Ci saranno un milione di video sul lockpicking, però è sempre sorprendente vedere come ci possono fregare! Per non dover sentir dire più "Accidenti non sapevo ci mettessero così poco".

Quindi sorprendetevi!

(link)

Cloud: un pericolo o un'opportunità? sfatiamo il mito...

noreply@blogger.com (Roberto Scaccia) — Mon, 21 Nov 2011 22:17:00 PST

"Cloud": credo non ci sia termine più abusato negli ultimi tempi. Ma poi cosa sarà mai questo benedetto Cloud?

Non è altro che la possibilità di avere i nostri documenti, applicazioni, backup, immagini, foto, etc. sempre disponibili in Internet. Dove? Non lo saprete ed ecco perché il termine "cloud" ovvero "nuvola".

Iniziamo con lo sfatare qualche mito: non c'è bisogno di aderire ai servizi Cloud di Amazon per essere nel Cloud! Se utilizzate un qualsiasi servizio di Google (mail, picasa, docs) o il vostro iPhone o Android, siete di fatto già nel Cloud! Per non parlare di Facebook: cosa c'è di più importante delle vostre abitudini, contatti, messaggi personali, geolocalizzazione?

E bisogna ammettere che questo "Cloud" è davvero molto comodo. Alcuni esempi:

il backup del vostro iPhone lo potete recuperare direttamente da iCloud nell'Apple Store, magari dopo un cambio del melafonino;
tenere il documento con le spese familiari su docs.google.com;
le app di Android e iPhone sempre disponibili (con i relativi dati)
l'impareggiabile DropBox!
i contatti, l'agenda e le mail disponibili sempre e ovunque
....

E questo è solo un piccolo esempio per l'utenza consumer.

Se consideriamo invece l'utenza "business" il Cloud è un'opportunità imperdibile. Non si ha più bisogno di comprare infrastruttura per attività spot, perché possiamo utilizzare l'infrastruttura del Cloud per storage o potenza di calcolo "on demand".

Le oscure sigle IAAS (Infrastructure as a service), PAAS (Platform as a Service) o SAAS (Software as a Service) sono unicamente la specificazione del livello del cloud: rispettivamente se utilizzate l'infrastruttura (storage o potenza di calcolo), la piattaforma (l'ambiente d sviluppo per es.), o il software (i backup iCloud, le App sempre disponibili, i documenti, la rubrica, etc.).

Ma la sostanza è sempre la stessa: servizi e dati in rete, non precisamente localizzati, sempre disponibili.

Ma c'è ovviamente il rovescio della medaglia: la sicurezza dei dati e la privacy. Mentre per l'aspetto sicurezza dovrete ovviamente affidarvi (e fidarvi) del provider che fornisce il servizio nel Cloud (Amazon, Google, etc.), che si spera abbia un buon livello di sicurezza, per gli aspetti legati alla privacy son dolori!

Eh sì, perché se da una parte è vero che la vostra privacy è legata in modo imprescindibile alla sicurezza del Cloud, dall'altra è anche vero che a fronte di un qualsiasi incidente di privacy gli aspetti legali saranno un vero incubo. Quale legislazione bisogna considerare? Dove sono i miei dati? Quali sono le procedure per richiedere i tracciati di uso?

Tutti aspetti contrattuali, e quindi legali, che richiedono una conoscenza approfondita del fenomeno, dei legali preparati (e lo sono in pochi) e dei periti anch'essi preparati nel contesto specifico. Da non sottovalutare anche l'aspetto economico: probabilmente dovrete instaurare rapporti con altri paesi e venire a capo della matassa che si srotola dal nostro bel paese fino a...dove?

Insomma, come detto, un vero incubo!

Però è anche vero che se non siete per esempio una grossa azienda con segreti industriali o un PA, ma bensì dei semplici utenti che già usano gmail, perché preoccuparsi? Siete già nel Cloud e tutti i vostri dati sono già nell'accogliente grembo di mamma Google (e probabilmente dell'NSA).

Ricordate sempre che sulla bilancia ci sono usabilità e sicurezza. Volete maggiore sicurezza? Perderete qualche comodità. Volete maggiore comodità? Dovrete rinunciare a un po' di sicurezza.

C'est la vie! Nel Cloud.

Qualche video:

(questo è un po' "pettinato" ma rende l'idea sui vantaggi)

(questo invece è da vedere assolutamente: analisi molto lucida di pregi e difetti del Cloud)

E' nato! Duqu figlio di Stuxnet

noreply@blogger.com (Roberto Scaccia) — Sat, 22 Oct 2011 23:23:00 PDT

Gira da un po' la notizia e quindi è meglio rilanciarla che stare zitti.

Pare che Duqu sia figlio di Stuxnet (sembra Febbre da Cavallo). Ma non ha le finalità distruttive del "padre". Del resto le nuove generazioni sono miti in tutto.

Pare che il suo unico scopo sia quello di farsi gli affari nostri, probabilmente per un successivo e più distruttivo attacco. Per una descrizione sommaria il sito di F-Secure, altrimenti il PDF "monumentale" di Symantec (fatto molto bene).

Da tenere d'occhio!

Sicurezza Fisica? Google (e Batman) insegna!

noreply@blogger.com (Roberto Scaccia) — Tue, 18 Oct 2011 23:13:00 PDT

Dovete fare un capitolato d'appalto per la sicurezza fisica della vostra azienda o dell'ente in cui lavorate? Guardate prima questo video :-)

C'è praticamente tutto, anche i soldi (una montagna) che Google ha. Altrimenti chiamate Batman e vedete se vi fa dei prezzi vantaggiosi.

Da notare il processo di distruzione dei dischi rigidi, il riconoscimento biometrico a più livelli e la costante presenza di "umani" (perché qualcuno pensa che i controlli di sicurezza fisica elminino il fattore umano....poveretto).

Mi viene da ridere pensando a certe soluzioni nostrane con strane porte "bus-like", operatori distratti e riconoscimenti facciali alquanto discutibili...ma questa è un'altra storia!

Defcon 19: disponibile il DVD...gratis!

noreply@blogger.com (Roberto Scaccia) — Tue, 18 Oct 2011 22:25:00 PDT

Scaricate il DVD dell'ultimo Defcon con le slide degli interventi e qualche altra cosa: https://www.defcon.org/index.html#dc19dvd

Vederli su Internet avrà anche il suo fascino ma se ce li avete belli e pronti è meglio no? ;-)

Steve Jobs è morto: viva il Re

noreply@blogger.com (Roberto Scaccia) — Wed, 05 Oct 2011 21:58:00 PDT

Si può pensar bene o male di lui, dei suoi prodotti, della sua vita, delle sue scelte, ma resta il fatto che è stato un visionario che ha contribuito in modo decisivo al futuro tecnologico di tutti noi.

"Stay hungry. Stay foolish"

Ciao Steve e grazie.

Quando l'usabilità si coniuga con la sicurezza

noreply@blogger.com (Roberto Scaccia) — Mon, 19 Sep 2011 09:29:00 PDT

Capita di rado di assistere ad un evento così. Per chi come me ha la fissazione della sicurezza poi ha quasi del miracoloso.

Se un software o un sistema è sicuro di solito non ce ne accorgiamo. E se è insicuro ce ne accorgiamo solo quando il danno è fatto e non c'è più niente da fare!

Partiamo dagli albori: confidenzialità, integrità e disponibilità. L'ho presa troppo alla larga? Forse. Però c'è un sottile file rosso. Seguiamolo.

Sulla confidenzialità ce ne sarebbe da dire, ma una cosa è certa: non c'è aspetto più inusabile degli strumenti che mirano a mantenere la confidenzialità delle informazioni. Cifrari, chiavi, passphrase, hash e quant'altro sono lontani anni luce dall'uomo della strada. E se poi non ci ricordiamo la chiave? I dati sono persi? Insomma la confidenzialità è roba da esperti o poco ci manca.

Integrità e Disponibilità invece sono più vicine all'utente comune di quanto ci si possa aspettare. Non trovate più quel file che avete salvato, o lo trovate ma è corrotto? Bene nel primo caso avete un esempio lampante di "disponibilità", nel secondo di "integrità".

Ok, cerco di stringere: un esempio disponibilità e integrità che è alla portata dell'utente comune (che qualche spocchioso informatico chiama utOnto) è il backup & restore. Ora quello che vorrei fare è dimostrare al lettore che si può raggiungere un elevato livello di integrità e di disponibilità anche sul suo computer casalingo.

Cosa c'è di più tragico che reinizializzare (o reinstallare) il proprio computer? Dobbiamo formattare il disco, reinstallare il sistema operativo, le diverse applicazioni, rifare tutte le configurazioni, recuperare i dati, etc. Per poi scoprire che le cronologie sono definitivamente perse e, solo dopo un ragionevole tempo, che anche qualche cosa di importante non è stato salvato.

E alla fine non possiamo che rassegnarci, SOB!

Bene, ieri ho finalmente avuto la dimostrazione che è possibile evitare tutti questi problemi. Ho infatti deciso di reinstallare da capo il mio MacBook Pro. Pur avendo già installato Lion avevo notato una certa "scattosità" della grafica, forse attribuibile ai miei diversi esperimenti.

Dopo un anno e mezzo ci può stare una reinstallazione del tutto (di solito sono restio, ma se la regola d'oro è "per prima cosa, riavvia", quella d'argento è "formatta e poi riprova").

Ovviamente da bravo security man, non contento del backup di TimeMachine che per un anno e mezzo mi ha tranquillizzato (senza considerare Mozy...), ho fatto il backup dei dati importanti su due diversi dischi rigidi: gli stessi dati duplicati più il backup di TimeMachine. Poi ho creato ben due chiavi USB con il Lion sopra (non si sa mai, magari una è corrotta...) ed ho iniziato.

Inizializzo il disco rigido da 750 GB (con una sovrascrittura di zeri che rende l'operazione non proprio breve) e l'installazione di Lion comincia. Dopo poco, al termine, mi chiede se ho un disco TimeMachine. Lo connetto e lui "tomo tomo, cacchio cacchio" comincia a cercare sul disco quali sono i dati archiviati nei backup precedenti. Ci mette un po' ma l'Hub USB e i 2 TB del disco rigido non aiutano. Alla fine seleziono tutto e, augurandomi che tutto vada bene ("tanto che mi importa alla fine ho i backup fatti a "mano"!") inizio il ripristino.

Lo lascio una notte a lavorare e la mattina seguente, come il giorno di Natale, trovo sotto l'albero un Mac completamente identico alla precedente installazione, ma estremamente più performante.

Che dire? Mi sono meravigliato di come un sistema di backup e soprattutto di restore possa essere così usabile. Capita spesso di fare dei backup o dei restore parziali, ma fare un restore di un intero disco rigido con dati che si avvicinano ai 300 GB diventa impresa più lunga e complessa (non confondiamo il restore con la copia del dell'intera partizione; nel caso della copia, avrei ripristinato il sistema tale e quale con annessi tutti i problemi).

TimeMachine e Mac OSX Lion hanno reso questo restore "epocale" una passeggiata, lunga e paziente, ma per nulla accidentata. A prova di utOnto insomma. E questo significa per me coniugare usabilità e sicurezza. Del resto cosa c'è di più importante dei propri dati?

P.S. qualcuno penserà che sono un invasato di Mac o altre fesserie del genere. Se lo pensate e non avete mai provato quello che ho descritto nel post allora vi consiglio di essere un po' più cauti, nell'altro caso invece sarete sicuramente d'accordo con me.

Anche tu sei un hacker!

noreply@blogger.com (Roberto Scaccia) — Wed, 31 Aug 2011 13:52:00 PDT

Probabilmente alla fine di questo video esclamerete:

"Accidenti, sono un hacker e non lo sapevo!"

Alcune verità assolute nel video:

Hacking è passione: quanti fanno lavori che odiano?
Hacking è uscire dagli schemi: pensiero laterale, grande dote!
Hacking è stimoli intellettuali: fondamentali per sopravvivere.
Hacker sono anche Donne e Bambini: dopo wargames qualcuno si è convinto per i bambini ma per le donne...
Gli Hacker sono cattivi? No, solo mal rappresentati dai Media

Php 5.3.7 e Apache web server: vulnerabilità col botto!

noreply@blogger.com (Roberto Scaccia) — Wed, 24 Aug 2011 23:30:00 PDT

E' da un po' di tempo che non faccio segnalazioni del genere. Ci sono molti siti a cui sarete affezionati e che sono sicuramente più tempestivi del sottoscritto. Ma quando esce qualche cosa di clamoroso, lo spirito di servizio di questo blog esce fuori :-)

- Cominciamo da PHP: la nuova versione 5.3.7 implementa la crypt() in modo singolare, perché alcune volte il risultato della cifratura è il solo SALT! Incredibile vero? Evitate quindi di fare l'upgrade a tale versione fino a che non sia uscita una patch per questa grave vulnerabilità.

Description:

If crypt() is executed with MD5 salts, the return value conists of the salt only.

DES and BLOWFISH salts work as expected."

- E proseguiamo con Apache web server: da quello che leggo la vulnerabilità era stata segnalata già dal 2007 ma fino ad oggi (o dovrei dire ieri) non esisteva un PoC in giro. Adesso c'è: una specie di HTTP request della morte, con cui buttare giù un server web (apache) in poco tempo. Gli amministratori di sistema farebbero bene a prestarvi attenzione. In questi tempi i DoS e i DDoS sono tornati di moda grazie ad Anonymous e vari, e allora...

Alice & Bob: password wallet

noreply@blogger.com (Roberto Scaccia) — Mon, 22 Aug 2011 10:03:00 PDT

Bob: "...e quindi io alla fine per gestire le password utilizzo un "Password Wallet" "

Alice: "Cosa?"

Bob: "Password Wallet: applicazione che memorizza le password, opportunamente protetta mediante cifratura ed unica password di accesso."

Alice: "Ma nooo, io le password me le ricordo a memoria!"

Bob: "(tranquilla lei!)"

20 anni di Password!

noreply@blogger.com (Roberto Scaccia) — Thu, 11 Aug 2011 09:31:00 PDT

"dopo 20 anni di sforzi, abbiamo e con successo insegnato a tutti ad usare password che sono difficili da ricordare ma facili da indovinare per un computer"

Insomma un successo! :-)

Google: video e istruzioni per l'autenticazione forte

noreply@blogger.com (Roberto Scaccia) — Thu, 04 Aug 2011 23:48:00 PDT

Vi ho rotto fino allo sfinimento. Ma se usate i servizi di Google non potete derogare sull'autenticazione forte. Username e password non bastano più. Serve un'autenticazione forte a due fattori. Seria. E Google sa come si fa:

Se avete un cellulare, e lo avete di sicuro, l'autenticazione forte con Google non è un problema. E poi essere richiamati da un servizio vocale (quando magari l'SMS non arriva) con una voce in perfetto italiano (ma computerizzata) è una gran soddisfazione.

Fatelo!

Le migliori password della nostra vita

noreply@blogger.com (Roberto Scaccia) — Sun, 24 Jul 2011 23:27:00 PDT

State leggendo questo post, e vi state chiedendo se andare avanti: "l'ennesimo post sulle migliori password, su che struttura debbano avere per raggiungere un livello di sicurezza adeguato. Non se ne può più!".

Già m'immagino!

Non l'avrei di certo scritto, se non avessi alcune considerazioni da fare sui meccanismi di autenticazione forte e sulle care vecchie password.

Prendiamo l'autenticazione a due fattori con token. Come spero già sappiate (ma non siete certo obbligati) si dice "a due fattori" perché il primo fattore è una cosa che si conosce (es. le credenziali), mentre il secondo è una cosa che si possiede fisicamente (per es un token OTP). In quest'ultimo caso però, dobbiamo avere fisicamente l'oggetto con noi, ed è questo il problema.
Un token (qualsiasi cosa esso sia) è una cosa troppo vincolante, poiché possiamo dimenticarcelo a casa e allora che fare? Di fatto, non potremmo accedere al servizio che richiede tale autenticazione!
Google e molti altri propongono un'autenticazione a due fattori più "furba", che utilizza magari il cellulare come token (con SMS o telefonate con codici), oppure propongono l'immissione del PIN del Token solo per alcune operazioni (di solito le banche on-line).

Non parliamo poi di autenticazioni a 3 fattori: "una cosa che tu sai"+"una cosa che tu hai"+"una cosa che tu sei"! L'iride, le impronte, il volto, l'orecchio e avanti con l'immaginazione per identificare un'altra parte del corpo che sia unica nelle sue caratteristiche. Di fatto però ci sono problemi di calibrazione degli strumenti di riconoscimento di tali parametri biometrici per non avere eccessivi falsi positivi o falsi negativi. Senza considerare poi che, dovendo tali sistemi verificare i parametri biometrici con quelli già memorizzati, tale autenticazione pone dei problemi di privacy per gli archivi di tali dati, che devono essere opportunamente gestiti secondo il codice di tutela della privacy.

Insomma, non solo mi devo portare dietro una smartcard, un token, il telefonino! Ma devo anche stare attento alla barba, oppure se ho la congiuntivite o le mani sudate. Un delirio insomma.

La cara vecchia password, per quanto vetusta, gode ancora di caratteristiche invidiabili: la delega, e l'usabilità.

Nel primo caso, possiamo in qualsiasi momento delegare qualcun altro ad accedere per nostro conto al servizio che ci interessa semplicemente comunicandogli la password (con ogni mezzo). Ovviamente stiamo rilassando la sicurezza generale e la stiamo affidando al nostro delegato. Quante volte lo facciamo nella vita reale? Basterà poi cambiare la password.

Nel secondo caso invece, cosa c'è di più usabile di una cosa da tenere a mente? Ci vuole solo un po' di esercizio in fondo.

Ma non è tutto ora quello che luccica: le password soffrono di un problema ben conosciuto che si chiama "Social Engineering" (SE). Qual'è il modo migliore per catturare una password? MTM? Brute Force? Attacchi del dizionario?

No.

Ce ne sono tanti di modi: osservare la nostra vittima mentre inserisce la password; fare qualche prova con il nome della moglie, del padre, della madre e relative date di nascita; provare con le domande di sicurezza (anzi direi di insicurezza); fingersi la vittima e chiamare l'helpdesk della sua compagnia telefonica; guardare quel foglietto con su scritta la password troppo complessa...TROPPO COMPLESSA!

Per questo le password non dovrebbero mai essere troppo complesse. Perché il rischio è che vengano scritte da qualche parte e allora attachi di Social Engineering potrebbero diventare una triste (per l'utente) realtà.

Come determinare la robustezza di una password

Innanzitutto la "robustezza" che possiamo calcolare è quella rispetto ad attacchi di tipo brute force. Quindi enumerazioni di tutte le possibili password. Poi con alcuni accorgimenti si può partire dai criteri di robustezza per il brute force e ovviare anche al problema degli attacchi di tipo SE. Per capire quanto è robusta una password ci sono due vie: quella semplice e quella complessa.

La considerazione semplice da fare è che se scegliamo un password lunga N caratteri in cui ogni carattere è scelto da un alfabeto di Z simboli, allora la robustezza è pari a tutte le combinazioni possibili che si è costretti a fare per indovinarla: Z^N. Che espresso in bit è pari a Log2(Z^N) = N*log2(Z).

Ovvero un attacco di tipo brute force deve enumerare tutte le stringhe binarie fino a Log2(Z^N).

Per la via complessa, che introduce il concetto di entropia binaria, vi rimando alla fine di questo post.

Come costruire una password

Vediamo un elenco di raccomandazioni su come costruire delle password robuste:

fissate una lunghezza ragionevole: non eccessivamente lunga per le password casuali, abbastanza lunga per quelle non casuali e basate su parole appartenenti a domini "esotici". Se ricordate quanto detto prima, in fondo la robustezza è pari a Z^N, quindi se aumentate di solo un carattere la password, moltiplicate Z^N per N!
password casuali generate con PRNG o RNG (Pseudorandom Number Generator o Random Number Generator): se hanno un alfabeto di simboli abbastanza ampio e una lunghezza ragionevole sono inattaccabili con metodi quali forza bruta, attacchi del dizionario ed altro; ma purtroppo sono difficilmente memorizzabili ed il rischio di trovarle memorizzate da qualche parte è molto alto. Quindi soggette ad attacchi di tipo SE.
password non casuali: (tra cui le passphrase) sono composte da parole di senso compiuto che possono creare delle frasi e quindi di facile memorizzazione. Alcune considerazioni che riguardano queste password però sono doverose:

se sostituite ad alcune lettere (non a tutte!) i numeri o le maiuscole, questo aumenta la forza della password solo per attacchi a forza bruta, perché invece attacchi del dizionario sono possibili con strategie adeguate (ogni volta che trovi una lettera, prova a sostituire con il numero equivalente se esiste, etc.)
potete separare le parole con degli spazi che aumentano la memorizzabilità (sempre che il sistema accetti degli spazi)
fissate un numero esatto di numeri o maiuscole da inserire: eviterà l'inserimento di password con tutti numeri, o tutte lettere maiuscole
evitate di mettere tutti i numeri all'inizio o alla fine della password
scegliete un dominio delle parole insolito: se è meno conosciuto e meno probabile che vi sia un dizionario già pronto
i segni di interpunzione servono solo per ampliare l'alfabeto ma sono terribilmente complicati da ricordare. Se fossi in voi li userei solo in casi eccezionali e in posizioni ben identificate
non prendete una frase di un libro perché con un po' di SE e Google basta inserire l'incipit ed avete subito il resto; potete però cambiare la frase con qualche trucco che solo voi sapete
evitate delle password imbarazzanti o che rivelano vostre informazioni riservate: se la password rimane nascosta non è un problema, ma nel caso dobbiate rivelarla a qualcuno per motivi di urgenza, vi trovereste in imbarazzo
non vi complicate la vita: relazionate la forma della password al rischio di compromissione della stessa; non avete bisogno di una password eccessivamente robusta per l'iscrizione con falso nome sul forum di giochi on-line!
cambio della password: cambiatela, ma non così spesso, alla fine rischiereste di usare le 3-4 password che usate di solito!
usate un password wallet elettronico: scegliete una master password abbastanza robusta ed un programma open source di cui sia possibile ispezionare il codice

Approfondimento "entropico"

Proverò ad essere estremamente discorsivo, ma qualche concetto di Teoria dell'Informazione è inevitabile (e anche interessante no?).

Scegliamo una password di lunghezza N, in cui ogni carattere è scelto da un alfabeto A, dove |A| = Z è la cardinalità di A (gli elementi che ci sono in A).

Sia PWD = C1 C2 C3....Cn. L'entropia binaria della password (ovvero, con molte semplificazioni, la sua robustezza) è quindi la seguente:

[1] H(password) = H(C1,C2,..,Cn) = H(C1)+H(C2)+H(C3)+...+H(Cn)

(l'ultima uguaglianza vale perché le probabilità con cui compaiono i caratteri nella password sono indipendenti)

Dove H(Ci) è l'entropia del carattere i-esimo nella password, che è a sua volta l'entropia del singolo carattere Ci nell'alfabeto di appartenenza A. Quindi:

[2] H(Ci) = Somm 1..Z P(Ci)*I(ci) = Somm 1..Z P(Ci)*log2(1/P(Ci)) = Somm 1..Z P(Ci)*-log2(Pci) = - Somm 1..Z P(Ci)*log2(Pci)

H(Ci) quindi costituisce il numero "medio" di bit necessari per rappresentare un qualsiasi carattere dell'alfabeto A scelto.

I(Ci) = log2(1/P(Ci)) = -log2(P(Ci)) è invece il contenuto informativo del carattere Ci, ovvero il numero di bit necessari per rappresentare la probabilità di accadimento dello stesso Ci: più è alta la probabilità, più basso è il contenuto informativo collegato al fatto che quell'evento si è verificato.

Se la distribuzione di probabilità dei caratteri nell'alfabeto è equiprobabile (ovvero P(Ci) = 1/|A| = 1/Z per ogni i, perché ogni carattere ha la stessa probabilità di comparire) e indipendente (P(Ci) non dipende da P(Cj) per i diverso da j) allora:

[3] H(Ci) = -Somm 1..Z 1/Z*log2(1/Z) = Somm 1..Z 1/Z*log2(Z) = (1/Z+1/Z...+1/Z)*log2(Z) = log2(Z)

Quindi H(Ci) = log2(Z), ossia l'entropia binaria media di un carattere dell'alfabeto è pari al logaritmo in base 2 della cardinalità dell'alfabeto.

Abbiamo fatto un giro molto lungo ma alla fine siamo arrivati ad una conclusione intuitiva: per rappresentare |A| = Z caratteri diversi servono esattamente log2(Z) bit. Ovvero dobbiamo enumerare tutte le stringhe binarie lunghe log2(Z) bit. E' quello che si fa nel brute force, no?

Per cui ritornando a (1):

[4] H(password) = log2(Z) + log2(Z) +...+log2(Z) = N*log2(Z)

ovvero per rappresentare una password di N caratteri scelti tra Z, servono esattamente N moltiplicato il numero dei bit necessario per ogni carattere. Questa misura indica di fatto la robustezza della password perché, banalmente, per portare un attacco a forza bruta basterebbe "contare" tutte le stringhe da N*log2(Z) bit (ovvero log2(Z^N). Più è alta quest'ultima, più la password è robusta. E guarda caso il risultato è lo stesso che con il calcolo delle combinazioni!

Dopo la teoria (i matematici inorridirebbero per questa mia affermazione), passiamo ad un esempio pratico:

Sia dato l'alfabeto A={0,1,2,3,4,5,6,7} dove |A|=Z=8, allora la probabilità P(Ci) = log2(Z) = log2(8) = 3. Sono quindi mediamente necessari 3 bit per rappresentare qualsiasi numero da 0 a 7.
Se la nostra password è lunga N = 8 caratteri, allora serviranno esattamente N*log2(Z) = 8*log2(8) = 8*3=24 bit per rappresentarla. Nel caso peggiore, dovremo enumerare tutte le stringhe da 24 bit.

Semplice no?

Hacking time: cracckare chiavi WPA? facile con Fastweb e Alice

noreply@blogger.com (Roberto Scaccia) — Sun, 10 Jul 2011 22:19:00 PDT

Sinceramente non mi sono mai dedicato al cracking delle chiavi WPA. Troppa fatica. Ma ultimamente ci sono dei programmini estremamente interessanti e astuti. Perché agire con la forza bruta quando si può raggiungere lo stesso risultato con l'astuzia?

Se vi dicessi che sia Fastweb che Alice danno in giro i loro router WiFi con una password precalcolata in base al MAC Address, e che tale Mac Address è nel caso di Fastweb ben visibile nel SSID, ci credereste?

E' invece è proprio così.

Ovviamente qualche buon tempone ha pensato bene di fare reverse engineering. Una volta capito l'algoritmo, TUTTI i router che usano questa astuta tecnica (praticamente la più becera Security Through Obscurity) sono facilmente crackabili.

Se leggerete con attenzione l'articolo linkato, capirete che gli errori dei progettisti sono stati diversi. Non solo il fatto di derivare la chiave condivisa da un dato ben visibile sulla rete come il SSID, ma anche quello di scegliere un algoritmo particolarmente banale, in cui:

l'alfabeto delle chiavi è assai ridotto: numeri e lettere dalla "a" alla "f" (vi ricorda qualche cosa?); se vedo una stringa esadecimale, mi viene il dubbio che sia un MD5 e magari del MAC address (ed in parte purtroppo è vero!)
la lunghezza delle chiavi è 10 per poter utilizzare la stessa chiave anche con WEP: così anche un attacco a forza bruta è fattibile (in virtù dell'alfabeto ridotto)
il codice non è offuscato: serve a poco però aiuta!
Solo per chi ha Fastweb: l'accesso alla rete permette di sapere vita morte e miracoli del possessore; basta andare sulla homepage Fastweb
altre...

Insomma le hanno fatte davvero tutte! Mi meraviglio che non abbiano "inventato" un nuovo algoritmo di cifratura! Magari uno XOR con una chiave segreta.

Se avete una Mac, cercate lo script rof.rb in rete. Eseguitelo (tranquilli vi guida passo passo) e se siete fortunati, ma manco tanto, avrete la vostra chiave WPA!

Non c'è quasi soddisfazione così :)

Ovviamente tutto ciò è illegale e se dovete fare delle prove, fatele sui vostri sistemi.

Ah, se siete dei fortunati possessori di router WiFi Alice e Fastweb: CAMBIATE LA CHIAVE!

Anonymous: manuale di sopravvivenza

noreply@blogger.com (Roberto Scaccia) — Tue, 05 Jul 2011 22:41:00 PDT

Anonymous si dà all'editoria ed esce con un manuale di istruzioni per il perfetto dissidente digitale.

Dalla connessione alla rete TOR, a quella ai server IRC tramite tunnelling, fino al cambio dei DNS e alle macchine virtuali.

Insomma tutto quello che un aspirante hacktivista digitale dovrebbe fare per essere sicuro di non essere scoperto.

Però, a guardar bene le istruzioni, queste possono essere viste anche come un buon vademecum per mantenere l'anonimità in rete, senza per forza essere degli attivisti (malevoli) digitali ed effettuare azioni lesive quali attacchi di tipo DDoS.

Comunque interessante da leggere :-)

Security Conference: solo vaporware?

noreply@blogger.com (Roberto Scaccia) — Fri, 01 Jul 2011 08:37:00 PDT

Non ce la faccio più! Questo è stato l'ennesimo convegno di sicurezza "fuffologico". Ma possibile che ultimamente tutti i convegni siano così scadenti? Almeno una volta ti volevano vendere il solito scatolotto, adesso nemmeno più quello! Qualità degli oratori scadente, qualità del contenuto degli interventi scadente, organizzazione scadente, etc.

L'ultima che ho sentito è la "Teoria del Cigno Nero". Metafora dell'evento raro impredicibile e catastrofico. Che per sua natura non è prevedibile. Roba da Wikipedia, copia-incolla e lavoro per i Debunker (vero Paolo?). Capisco che abbia il suo fascino e colpisca la platea (ma solo un certo tipo eh...), ma suvvia questi colpi da teatro dell'orrore lasciamoli ad altri contesti no?

E che dire della solita statistica con il numero di malware per paese? A che serve? A spaventare e quindi a vendere servizi? Alla fine anche quelli digiuni di sicurezza, dopo 5 anni, le hanno capite queste cose o no? Ah giusto, se parlassero con i loro tecnici invece che pascolare in giro per rinfreschi (ed essere stipendiati per farlo) forse saprebbero qualche cosa di più.

Poi cominci a guardare la platea di uditori e chi ti trovi? Generali, AD, "capoccioni" vari che manco sanno accendere un PC, figuriamoci capire cosa sia un DDoS, o chi siano gli "Anonymous", o peggio capire che c'è una differenza tra hacker e cracker. Forse lo capirebbero con un esempio banale?

"se il tuo bambino comincia a smontare e rimontare le cose, è un hacker!"
"se il tuo bambino comincia a smontare le mattonelle del bagno per nascondere la cocaina, allora è un cracker".

Ci vuole molto?

Insomma non se ne può più. La scelta è quindi oramai tra convegni organizzati dalle Università e in generale da enti di ricerca (ma spesso le conferenze sono a pagamento) e convegni nell'ambito dell'hacking (e qui già va meglio, ma gli hacker si sa per loro natura sono schivi). I primi godono certamente di alcuni approfondimenti derivati dalla ricerca. Dateci una rete Bayesiana ogni tanto, un grafo, una sommatoria vi prego!!! Ovviamente alcune parti potranno essere un po' troppo accademiche per alcuni, ma almeno saranno interessanti!

I secondi invece sono da sempre interventi molto "smanettosi" in cui si fanno vedere "cose" (oddio mi viene in mente però l'ennesimo speech sulla SQL injection), ma poi saranno compresi da un uditorio di burocrati interessati solo al break mangereccio?

Per concludere: per cortesia, tutti gli pseudo-esperti di sicurezza (e se hai una responsabilità in tal senso sei pregato di studiare prima) se ne restino a casa o almeno non tengano speech pretendendo di vendere al mondo la solita aria-fritta!

Alla fin fine "security means hacking"!