JBoss Security: slides from OWASP

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

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!

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:

1. Sicuri on-line
2. I tuoi dati sul Web
3. I tuoi dati su Google
4. 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)!

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

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

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!

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).