Dopo alcuni mesi (Moxie Marlinspike e Dan Kaminsky, Defcon e Blackhat) si riparla di una vulnerabilità alle implementazioni SSL (API crittografiche) che, di fatto, prestano il fianco ad un attacco di tipo man in the middle nonchè a tecniche di phishing.

Perchè se ne riparla dopo poco più di due mesi? E’ proprio di questi giorni la pubblicazione di un certificato (e chiave privata) attribuito a PayPal carpita proprio grazie alla vulnerabilità descritta da Moxie Marlinspike al BlackHat USA nel luglio di quest’anno (vedi video dell’intervento al defcon 17).

Frutto di tecniche di parsing datate e usate nelle librerie crittografiche dei client che implementano e usano lo strato SSL (per cui non solo browser web ma anche client di posta, instant messaging, client irc,VPN SSL, etc) e di tool appositi (sslsniff).

In particolare, questa vulnerabilità sfrutta la struttura del certificato X.509 del certificato e le informazioni in esso contenute usandole a proprio piacimento in quel procedimento di validazione a cascata della fiducia.

La catena di fiducia tra il sito interessato e la Certification Authority (CA) funziona come descritto sotto

Root CA -> Intermediate CA -> Intermediate CA -> .. -> Intermediate CA -> esempio.com

Cosa dovrebbe avvenire:

1. verifica che il nome del nodo foglia è lo stesso del sito a cui ci si sta collegando
2. verifica che il certificato è valido, non è scaduto, revocato, etc
3. Controllo della firma (signature)
4. Se tale firma della CA appartiene alla nostra lista di una Root CA trusted il processo di conclude positivamente altrimenti si ripetono nuovamente gli step dopo aver risalito la catena di un livello.

Questo è lo scenario incriminato:

Root CA -> Intermediate CA -> Intermediate CA -> .. ->Intermediate CA -> sitomalevolo.com -> esempio.com

Purtroppo, questo scenario, nelle condizioni di vulnerabilità indicate nel paper di Marlinspike al Blackhat di Las Vegas, sembra essere del tutto lecito: le firme sono validate, i certificati non sono scaduti/revocati, il procedimento indicato di verifica si conclude con una Root CA trusted “embedded” incorporata nel browser.

Questo significa però che abbiamo costruito un certificato VALIDO per esempio.com ma che in nessun modo rappresentiamo in quanto siamo legati a sitomalevolo.com

Affinchè questo funzioni, viene sfruttata la debolezza di una codifica del CN (Common Name) Subject del PKCS #10 in cui il campo (stringa) viene “chiuso” da un particolare valore null (\0).

Quando viene effettuato il controllo 1), in questo scenario vengono confrontate due stringhe di lunghezza potenzialmente diversa.

Tenendo conto che la stringa si conclude con il carattere \0, il parsing considera solamente i primi n caratteri fino al valore null (\0).

Quindi se in un certificato X509 è specificato di essere www.esempio.com\0sitomalevolo.com le verifiche vengono effettate sulla precedente stringa (fino al campo \0) e l’indirizzo a cui vogliamo collegarci (www.esempio.com).
A questo punto si hanno tutti gli elementi per effettuare un MITM che generi il certificato apposito e si interponga trasparentemente tra le parti (molte CA rilasciano dei certificati se il richiedente è l’owner specificato DOPO il valore null).

Per quanto riguarda Mozilla, i security advisor riportano di avere chiuso la falla a partire dalla versione di firefox 3.5 e 3.0.13 (vedi variante attacco su 3.0.11 vulnerabile), Thunderbird dalla 2.0.0.23, SeaMonkey dalla 1.1.18 e NSS dalla 3.12.3

Al momento sembra che le crypto API di windows siano vulnerabili.

Ci sono ripercussioni e impatti anche nel campo delle applicazioni mobile.

PayPal ha nel frattempo sospeso l’account di Moxie Marlinspike.

Raccomandazioni: massima attenzione sulle transazioni in https e scrivere manualmente il link sul browser (possibilmente firefox, aggiornato) e mai fidarsi di link specialmente contenute in messaggi di posta elettronica.

****************UPDATE*********************

Meglio tardi che mai http://www.microsoft.com/technet/security/bulletin/ms09-056.mspx