Alessandro Del Rosso

Un buco in SSL scuote la Rete

Una task force composta dagli esperti di sicurezza di numerose grandi aziende e organizzazioni sta lavorando alla risoluzione di una seria vulnerabilitÓ di sicurezza nel protocollo SSL, utilizzato per cifrare le transazioni online

Roma - Due ricercatori di sicurezza di PhoneFactor, una società che fornisce sistemi di autenticazione two-factor per i telefoni cellulari, hanno scoperto una seria vulnerabilità nei protocolli crittografici Secure Sockets Layer (SSL) e Transport Layer Security (TLS). Tale falla, secondo i suoi scopritori, potrebbe consentire ad un malintenzionato di iniettare informazioni a propria scelta all'interno di una connessione protetta.

I protocolli SSL 3.0 e TLS 1.0 sono alla base di altri noti protocolli di Internet come HTTPS e IMAP, e proteggono ogni giorno centinaia di milioni di transazioni online: acquisti con carta di credito, sessioni di home banking, accesso a database remoti e, in generale, ogni operazione su Internet che preveda lo scambio di dati sensibili tra client e server.

Scoperta lo scorso agosto da Marsh Ray e Steve Dispensa, e discussa in gran segreto lo scorso settembre con un consorzio costituito da grandi aziende e organizzazioni, la vulnerabilità avrebbe dovuto essere rivelata pubblicamente solo il prossimo anno: ciò per dare il tempo ai produttori di correggere le rispettive implementazioni di SSL/TLS. A sconvolgere questi piani è stato un ricercatore di sicurezza indipendente che, avendo incidentalmente scoperto la falla per proprio conto, lo scorso mercoledì ne ha rivelato l'esistenza su una mailing-list della Internet Engineering Task Force (IETF): una mossa che ha costretto Ray e Dispensa ad "uscire allo scoperto" e rivelare l'esistenza di una task force già impegnata nella risoluzione del problema.
Come spiegato dai due esperti di sicurezza in questo articolo, la vulnerabilità riguarda il meccanismo di autenticazione di SSL e può essere sfruttata da un aggressore per inserirsi all'interno di una comunicazione protetta - un attacco noto come man-in-the-middle - e inserire nel flusso delle informazioni cifrate dei comandi a sua scelta: ciò potrebbero renderlo in grado di alterare i dati trasmessi, iniettarvi del codice maligno e, ancor peggio, ottenere il certificato digitale del client, assumendone così l'identità. In altre parole, nella mani di un abile cracker la falla potrebbe essere utilizzata per manipolare ed eventualmente dirottare una comunicazione SSL/TLS.

"Dal momento che si tratta di una vulnerabilità del protocollo, e non semplicemente di un difetto di implementazione, l'impatto è di vasta portata", si legge nel succitato articolo di Ray e Dispensa. "Tutte le librerie SSL dovranno essere patchate, e le nuove copie dovranno essere distribuite insieme a molte applicazioni client e server. Una larga fetta di utenti sarà poi probabilmente costretta ad aggiornare ogni software che usa SSL".

Ma se la situazione appare molto seria, c'è chi sostiene che per gli utenti finali non c'è ragione di allarmarsi. Il noto hacker Moxie Marlinspike, che all'inizio dell'anno aveva dimostrato alcune gravi debolezze nel protocollo SSL, ha spiegato che il corrente bug riguarda una specifica forma di autenticazione SSL, chiamata client certificate authentication, raramente utilizzata nelle comuni transazioni online. "Per quanto ne so, la maggior parte delle persone che utilizzano SSL per collegarsi ad una webmail o al proprio conto bancario non sono interessati dal problema", ha dichiarato l'hacker, che ha poi aggiunto di non aver trovato questi attacchi "granché utili".

In un advisory, Ray e Dispensa smentiscono però Marlinspike sostenendo che la vulnerabilità da loro scoperta non è ristretta alla client certificate authentication. Nello stesso advisory i due esperti hanno anche pubblicato il link a un documento PDF dove analizzano la falla e i suoi possibili scenari d'impiego.

A tranquillizzare gli utenti finali è tuttavia intervenuta anche VeriSign, che per bocca del suo vice presidente al marketing Tim Callan ha fatto sapere che il problema non rappresenta una grande minaccia per i navigatori del Web. "Sebbene la vulnerabilità possa essere sfruttata per aggiungere del codice maligno all'interno di un flusso dati SSL, questa non può essere in alcun modo utilizzata per decifrare la comunicazione e sottrarre dati sensibili", ha dichiarato Callan. "Ciò non toglie che per i grandi siti web e per un buon numero di corporation la vulnerabilità sia molto seria e urgente"

PhoneFactor ha fatto sapere che il gruppo di aziende e organizzazioni che sta affrontando l'emergenza - gruppo comprendente, fra gli altri, Microsoft, Intel, Nokia, IBM, Cisco, Open SSL, Apache, NSS, Red Hat e IETF - ha già raggiunto un accordo sui metodi da seguire per risolvere il problema e ha stilato delle linee guida per mitigare da subito i rischi derivanti dalla falla. IETF ha anche aperto un thread dove si sta discutendo la bozza di una correzione al protocollo TLS: nel momento in cui si scrive, però, il sito risulta irraggiungibile (si veda in tal caso la cache di Google).

Alessandro Del Rosso
Notizie collegate
70 Commenti alla Notizia Un buco in SSL scuote la Rete
Ordina
  • Allora dall'articolo si desume che tale vulnerabilita' permette di iniettare dei comandi all'interno del flusso dati della transazione. Ora non possono decriptare i dati non possono quindi modificare i dati che ho inviato... Il pericolo maggiore quindi e' per il server che potrebbe eseguire operazioni non volute? Oltretutto come fanno a rintracciare quello che ha iniettato il codice maligno? La cosa preoccupante e' che hanno insabbiato senz patchare robe da matti! Sono da arrestare!
  • No, aspetta. Leggendo l'articolo sembra che il "rogue MITM" usi un suo certificato per parlare con il client e il certificato del client per parlare con il "victim MS SSL server". Ciò non dovrebbe consentire di avere la possibilità di decifrare i messaggi provenienti da entrambe le direzioni?
    non+autenticato
  • - Scritto da: Spock
    > No, aspetta. Leggendo l'articolo sembra che il
    > "rogue MITM" usi un suo certificato per parlare
    > con il client e il certificato del client per
    > parlare con il "victim MS SSL server". Ciò non
    > dovrebbe consentire di avere la possibilità di
    > decifrare i messaggi provenienti da entrambe le
    > direzioni?

    No non decifra i dati che sono andatti al sever "vero" .. queli rimangono cifrati con una chiave (simmetrica) che il MTIM non è in grado di decifrare...   a meno che il MTIM non abbia lo stesso certificato e la stessa chiave privata (cioè la stessa coppia di chiavi asimmetriche)!
    Il che è poco plausibile ovviamente.
    Può solo immettere dati nella connessione...
    Il che è un problema o meglio può essere un problema... ma è un problema che nulla ha a che vedere con la capacità del MITM di leggere i dati.
    non+autenticato
  • Ma le chiavi simmetriche non vengono scambiate proprio in fase di handshake (e poi rigenerate riscambiate ad intervalli)?
    non+autenticato
  • Riassunto, da quello che ho capito, in parole povere:

    - Il client richiede una negoziazione TLS

    - Il MITM intercetta la richiesta iniziale del client, e la mette da parte.

    - Il MITM avvia una propria sessione cifrata col server

    - Il MITM esegue qualche richiesta maligna

    - Il MITM forza una rinegoziazione, ad esempio chiedendo una risorsa per cui il server chiederà una rinegoziazione del certificato client, o una rinegoziazione degli algoritmi di cifratura, o più semplicemente avviando una rinegoziazione del certificato client su sua iniziativa.

    - La rinegoziazione avviene cifrata con la chiave che il MITM e il server hanno deciso. Il MITM può fare da traduttore tra client e server, facendo credere al client che la nuova negoziazione che sta avvenendo sia frutto della sua prima richiesta.

    - Client e server avviano una nuova sessione, con una nuova chiave. Il MITM ora non farà altro che inoltrare tutto quello che gli arriva. Il client sarà convinto di stare parlando direttamente col server, il server sarà convinto di non aver mai cambiato interlocutore.


    Il problema sta nel fatto che nella nuova sessione, a livello di TLS, non è evidenziato in nessun modo che questa è frutto di una rinegoziazione di una sessione precedente, quindi il client non può rendersi conto che qualcuno "ci ha già messo le mani".

    Se il protocollo di livello più alto non prevede a sua volta un meccanismo di sessione (oppure gestisce la sua sessione in chiaro, come fa spesso HTTPS con i cookie), neanche il server potrà rendersi conto di star parlando con un client diverso.
    non+autenticato
  • per chi ha un po' di tempo:

    https://media.blackhat.com/bh-usa-09/video/MARLINS...

    non credo sia la stessa vulnerabilità ...
    non+autenticato
  • In primis non si tratta di una vulnerabilità dell'SSL ne tantomeno di una vulnerablità del protocollo correlato all'uso di certificati da parte di un GENERICO CLIENT ssl/tls in se.

    Si tratta invece di una vulnerabilità correlata al protocollo HTTPS e in particolare legata al comando HTTP TRACE (http 1.1).

    Come spiega qui.
    http://www.kb.cert.org/vuls/id/867593

    Riassumendo la vulnerabilità è sfruttabile in certe condizioni con certe vulnerabilità lato browser e server e comunque sempre legata a HTTPS (non a SSL/TLS in se.
    non+autenticato
  • rimane il fatto che in 1 anno non ne sono venuti a capo...
    Ed ora è di dominio pubblico..
    non+autenticato
  • - Scritto da: dfsfs
    > rimane il fatto che in 1 anno non ne sono venuti
    > a
    > capo...
    > Ed ora è di dominio pubblico..
    Ne sono venuti a capo...

    http://cvs.openssl.org/chngview?cn=18790
    non+autenticato
  • - Scritto da: ullala
    > - Scritto da: dfsfs
    > > rimane il fatto che in 1 anno non ne sono venuti
    > > a
    > > capo...
    > > Ed ora è di dominio pubblico..
    > Ne sono venuti a capo...
    >
    > http://cvs.openssl.org/chngview?cn=18790

    LOL, questo è un workaround, non un fix. La renegoziazione serve ed è parte della security del protocollo stesso. Se non effettui una renegoziazione periodica, aumentano le probabilità che un attacker raccolga campioni della sessione e riesca alla fine a decifrarla.

    La vulnerabilità è molto più complessa di come la credi, ed implica un cambiamento nel protocollo. Per questo sono mesi che tutti i maggiori vendor ne stanno discutendo - il cambiamento necessario è abbastanza semplice ma implica un aggiornamento radicale di tutti i client ed i server.


    Cordiali saluti
  • - Scritto da: markoer
    > - Scritto da: ullala
    > > - Scritto da: dfsfs
    > > > rimane il fatto che in 1 anno non ne sono
    > venuti
    > > > a
    > > > capo...
    > > > Ed ora è di dominio pubblico..
    > > Ne sono venuti a capo...
    > >
    > > http://cvs.openssl.org/chngview?cn=18790
    >
    > LOL, questo è un workaround, non un fix. La
    > renegoziazione serve ed è parte della security
    > del protocollo stesso. Se non effettui una
    > renegoziazione periodica, aumentano le
    > probabilità che un attacker raccolga campioni
    > della sessione e riesca alla fine a
    > decifrarla.
    >
    > La vulnerabilità è molto più complessa di come la
    > credi, ed implica un cambiamento nel protocollo.
    > Per questo sono mesi che tutti i maggiori vendor
    > ne stanno discutendo - il cambiamento necessario
    > è abbastanza semplice ma implica un aggiornamento
    > radicale di tutti i client ed i
    > server.
    >
    Secondo me se ne usciranno con la versione v4 e tutto il tempo che si stanno prendendo non è per una semplice patch, ma proprio per riscirvere il protocollo.
    Poi ci sarà l'aggiornamento dei servers e dei client con il nuovo protocollo. Sai le banche come saranno contente di avere i telefoni intesati delle massaie che non si collegano più ai loro conto correnti....
    >
    > Cordiali saluti
  • Da cosa deduci che l' advisory che citi abbia qualcosa a che fare con quello di cui si parla?
  • - Scritto da: unaltro
    > Da cosa deduci che l' advisory che citi abbia
    > qualcosa a che fare con quello di cui si
    > parla?

    In sostanza nulla...
    Ho semplicemente sbagliato a cliccare sull'elenco dei link degli advisory.. può succedere..
    Il che non toglie che la sostanza della questione resti...

    Ovvero il buco è legato al supporto di un tipo di negoziazione presente in HTTPS e che in generale le implementazioni che non implementano questa rinegoziazione o non la supportano NON abbiano questa vulnerabiltà!
    non+autenticato
  • Ma cosa stai scrivendo? Voglio pensare che volevi commentare un altro articolo.
    Leggiti i pdf qui: http://extendedsubset.com/?p=8
    E poi pentiti!
    non+autenticato
  • - Scritto da: Illo Illi
    > Ma cosa stai scrivendo? Voglio pensare che volevi
    > commentare un altro
    > articolo.
    > Leggiti i pdf qui: http://extendedsubset.com/?p=8
    > E poi pentiti!
    Quale è la parte di HTTPS che ti è sfuggita?
    non+autenticato
  • - Scritto da: ullala
    > - Scritto da: Illo Illi
    > > Ma cosa stai scrivendo? Voglio pensare che
    > > volevi
    > > commentare un altro
    > > articolo.
    > > Leggiti i pdf qui:
    > > http://extendedsubset.com/?p=8
    > > E poi pentiti!
    > Quale è la parte di HTTPS che ti è sfuggita?

    C'è scritto chiaramente che la vulnerabilità è in TLS e HTTP è solo una delle applicazioni di TLS. Quindi segui il consiglio e leggi Sorride


    Cordiali saluti
  • - Scritto da: markoer
    > - Scritto da: ullala
    > > - Scritto da: Illo Illi
    > > > Ma cosa stai scrivendo? Voglio pensare che
    > > > volevi
    > > > commentare un altro
    > > > articolo.
    > > > Leggiti i pdf qui:
    > > > http://extendedsubset.com/?p=8
    > > > E poi pentiti!
    > > Quale è la parte di HTTPS che ti è sfuggita?
    >
    > C'è scritto chiaramente che la vulnerabilità è in
    > TLS e HTTP è solo una delle applicazioni di TLS.
    > Quindi segui il consiglio e leggi
    > Sorride
    >
    >
    > Cordiali saluti

    1) Segui anche tu please e trova una applicazione (non https based) vulnerabile
    thanks!

    2) evita (per favore) nel futuro di fare come hai fatto più sotto di dire corbellerie come:
    "Sì. Non se usa IPSec, ma se usa un tunnel su HTTPS lo è."

    Anche perchè openvpn non è in grado di usare ipsec (lavora solo in TLS/SSL) e un tunnel TLS/SSL NO è (purtroppo per te e per fortuna nostra e anche tua) "un tunnel su HTTPS"...

    Che ti sia chiaro o meno HTTPS e TLS/SSL sono due (ripeto due) cose diverse....

    Per questo motivo praticamente nessuna applicazione TLS/SSL (escluse quelle HTTPS) che io conosca implementa la rinegoziazione con le modalità che consentono di sfruttare la vulnerabilità.
    non+autenticato
  • .. lo sapremmo solo dopo il bottoA bocca aperta
    non+autenticato
  • Leggermente OT, visto che non tratta di SSL, ma di un attacco a mio avviso ancora più infido.

    http://en.wikipedia.org/wiki/Man_in_the_Browser per le basi
    pippuz
    1258
CONTINUA A LEGGERE I COMMENTI
Successiva
(pagina 1/2 - 6 discussioni)