Approvata la bozza di modifica per il protocollo SSL

Con l’intento di eliminare una lacuna di sicurezza recentemente messa a nudo nel protocollo SSL/TLS, è stata da poco pubblicata una bozza di aggiornamento. IETF (Internet Engineering Task Force), ente di standardizzazione caratterizzato da una struttura “aperta” formata da specialisti, tecnici e ricercatori, sembra abbia già approvato l’intervento di modifica. La nuova versione del protocollo propone una rivisitazione della modalità con cui vengono rinegoziate sessioni SSL crittografate cosicché non possa essere più possibile, per un aggressore, l’iniezione di payload potenzialmente dannosi.

A novembre alcuni esperti nel campo della sicurezza informatica avevano lanciato l’allarme circa la scoperta di alcune vulnerabilità nel protocollo SSL/TLS. TLS ed il predecessore SSL sono protocolli crittografici che hanno come obiettivo quello di garantire una comunicazione sicura tra client e server puntando anche sull’integrità dei dati.

Stando a quanto dichiarato, le vulnerabilità messe a nudo potrebbero essere sfruttate da parte di aggressori per aggiungere delle informazioni arbitrarie durante connessioni “sicure”. Il fulcro del problema risiederebbe in una lacuna “di design” del protocollo TLS allorquando vengano rinegoziati i parametri di una connessione TLS già esistente. Tale evento si verifica, ad esempio, quando un sistema client tenti di accedere ad un’area sicura su un server web che implichi la richiesta di certificati lato client.

L’attacco viene sommariamente descritto nei termini che seguono. L’aggressore si inserisce nella connessione tra client e server e stabilisce una connessione HTTPS con il server. Egli comincia con il porre la connessione verso il sistema client in uno stato incompleto. Viene poi inviata al server una richiesta HTTPS per l’accesso ad un’area sicura: il server rinegozia una nuova connessione e trasmette al client la richiesta del certificato. L’aggressore inoltra tutti i successivi pacchetti scambiati tra client e server senza apportare alcuna modifica. Come passo finale, la richiesta HTTP formulata dal malintenzionato viene eseguita nella forma in cui è giunta dal sistema client.

Secondo Marsh Ray, l’esperto che ha documentato la scoperta, le défaillances sarebbero state verificate sia su server Apache httpd che su Microsoft IIS, con un’ampia varietà di applicazioni web. Ray aggiunge di avere dimostrato anche casi in cui non sono coinvolti certificati lato client. Il filo conduttore degli attacchi è comunque uno solo: l’aggressore può essere capace di effettuare una transazione HTTP di propria scelta, autenticata da un utente vittima dell’attacco “man-in-the-middle”.

A distanza di pochi giorni, uno studente turco – Anil Kurmus – ha sfruttato con successo il cosiddetto “SSL renegotiation bug” per “sottrarre” le credenziali di accesso alla piattaforma social network e microblogging “Twitter”.

Le reazioni dopo l’individuazione della falla di sicurezza nel protocollo SSL sono state, comunque, abbastanza fredde. Molti ricercatori osservarono scettici che sebbene un aggressore possa essere in grado di iniettare un ristretto quantitativo di dati all’interno di una sessione SSL autenticata, egli non può leggere le informazioni cifrate che fluiscono tra le due parti.

Kurmus riuscì a far leva sul bug per “rubare” nomi utente e password scambiati tra client e server di Twitter nonostante tali dati fossero crittografati. L’attacco sembra avere avuto successo iniettando del codice che richiedeva alle API di Twitter di riprodurre il contenuto della richiesta web sotto forma di messaggio dopo l’operazione di decifratura dei dati.

“E’ possibile che altre persone abbiano già sfruttato il problema senza poi rendere pubblici i risultati della loro scoperta”, ha commentato Kurmus. “Per questo ritengo importante che la problematica non sia sottovalutata”.
Twitter applicò prontamente una “patch” per difendersi da simili tipologie di attacco.

Molti ricercatori di sicurezza hanno comunque voluto sottolineare come l’attacco di Kurmus possa essere andato in porto solo perché le API di Twitter gli abbiano permesso, in quel frangente, di esporre il contenuto del flusso dati, in forma non crittografata, come semplice “post”. Non è però da escludere che varianti dell’attacco possano funzionare su altri servizi. “Qualunque sito che permette agli utenti di pubblicare messaggi, inviare e-mail o qualunque altro genere di informazioni può potenzialmente essere oggetto di aggressioni”, ha dichiarato Ivan Ristic, esperto in materia di sicurezza informatica che lavora per l’azienda londinese “SSL Labs”.