Trovata una falla di sicurezza nel sistema di autenticazione delle email in Google

Di - 15 November 2012 - in

Google, come molte altre aziende, fa uso di DKIM, DomainKeys Identified Email, nelle email che invia. Si tratta di un semplice sistema per l’autenticazione delle email, ovvero per capire se l’email ricevuta venga effettivamente da dove dice di venire.

Nello specifico, DKIM serve ad autenticare il dominio di provenienza dell’emal (insomma, il destinatario può assicurarsi che l’email @google.com provenga effettivamente da Google, ma non può assicurarsi che provenga esattamente dal dipendente Google che ha quell’indirizzo), e si differenzia in questo dalle firme digitali vere e proprie, che identificano la singola persona.

Il funzionamento è molto semplice. Negli header della lettera, ovvero la parte della lettera che contiene informazioni sulla lettera stessa, e che non è tipicamente mostrata al destinatario, viene aggiunta una riga contenente una stringa di caratteri detta firma. Tale firma viene generata dal server del mittente (ad esempio, appunto, google.com) a partire dal nome di dominio del server e dal testo dell’email. Il programma di posta del destinatario, vedendo questa riga, scarica dal server del mittente una chiave per verificare tale firma, e controlla che sia corretta. Se non lo è, avvisa l’utente.

In questo modo l’utente che riceve la posta con un programma che supporti DKIM (lo fanno molti programmi o loro estensioni) può accertarsi:

  • Che la lettera venga dall’azienda o dal sito a cui il mittente appartiene
  • Che la lettera non sia in ogni caso spam o phishing
  • Che la lettera non sia stata modificata dai server per i quali è passata (la firma si basa anche sul contenuto della mail, se il contenuto è modificato la firma fallisce)

Questo sistema viene ormai utilizzato da tutte le principali aziende che lavorano in Internet ed hanno necessità di comunicare con i loro utenti.

Recentemente, è stata trovata una falla nel modo in cui lo utilizza Google (e non solo), in maniera abbastanza interessante da rendere il fatto davvero degno di nota.

Un matematico statunitense, Zachary Harris (nella foto), si è visto recapitare una e-mail da un sedicente reclutatore di personale in Google, che lo invitava a farsi sentire per un posto da programmatore Linux. Ora Harris, che mai si era occupato di programmazione, si è insospettito credendola una email di phishing, ed è andato a controllare la firma.

Sorprendentemente, la firma sembrava corretta. Approfondendo il controllo, però, Harris si è accorto che la chiave utilizzata per decifrare la firma (e quindi anche quella utilizzata per crearla) erano particolarmente corte: mezzo kilobit, quando la lunghezza minima raccomandata è di un kilobit.

Non spiego qui i fondamenti della crittografia, che peraltro chi è interessato a un articolo di questo tipo conoscerà anche piuttosto bene, ma i sistemi crittografici di questo genere si basano sull’utilizzo di due numeri primi molto grandi, dai quali si calcolano le chiavi pubblica (quella usata per verificare la firma) e privata (quella utilizzata per generare la firma).

L’idea è che piú un numero, che è la chiave pubblica (una sua parte, in realtà, ma non sottilizziamo) è grande, e piú la fattorizzazione necessaria a trovare la chiave privata diventa un’operazione lunga, al punto da essere non attuabile o perché banalmente piú lunga di una vita umana, o perché, una volta completata, l’informazione ottenuta sarà obsoleta (perché è cambiata la chiave o perché i dati non servono piú).

Con l’evoluzione rapida dei computer, e con i sistemi di cloud computing, i tempi di fattorizzazione si accorciano sempre di piú, richiedendo chiavi sempre piú lunghe. Da matematico quale è, Harris si è subito reso conto che con un po’ di cloud computing ottenere la chiave privata da una chiave pubblica da mezzo kilobit è una cosa abbastanza facile e veloce da fare, permettendo cosí a chiunque di mandare email perfettamente verificabili a nome di Google, cosa probabilmente fatta dal mittente della strana email ricevuta.

Considerando molto strano che Google avesse una simile falla di sicurezza, Harris ha creduto che la cosa fosse intenzionale per testare le sue capacità di matematico e, dopo aver trovato la chiave privata ha mandato una email a Larry Page, a nome di Sergey Brin, contenente l’url del suo sito.

Pur non ricevendo alcuna risposta da Google, Harris si è ritrovato un picco di visite al suo sito web, e due giorni dopo Google ha iniziato ad utilizzare chiavi a 2 kilobit, il doppio del minimo raccomandato, per le sue comunicazioni. Insomma, la vulnerabilità era vera.

Con una rapida analisi, Harris ha scoperto lo stesso problema dovuto a chiavi corte (768, 512 o addirittura 384 bit) per PayPal, Yahoo, Amazon, eBay, Apple, Dell, LinkedIn, Twitter, SBCGlobal, US Bank, HP, Match.com e HSBC. Insomma, fingere di essere qualcuno appartenente a queste aziende richiedeva solo qualche capacità matematica (roba da studente dei primi anni di matematica o informatica), qualche giorno di tempo e un po’ di cloud computing.

Le varie aziende avvertite da Harris hanno cambiato la chiave (operazione semplice, ma non troppo: è necessario ricordarsi di rimuovere anche la vecchia chiave, che se resta disponibile sui DNS associata al dominio, resta anche utilizzabile), finché Harris, dopo aver contattato il CERT (un centro studi sulla sicurezza informatica) non ha deciso di rendere pubblico il problema invitando tutti a utilizzare chiavi in grado di resistere ad attacchi fatti con macchine o sistemi recenti.

Ottimo lavoro da parte di Harris, che dimostra come anche le migliori tecnologie di garanzia della sicurezza, se non utilizzate bene, possono rivelarsi rassicuranti trappole.

 

Via | Wired

Leave a Reply

Lorenzo Breda Articolo scritto da

Studente di Informatica a Roma, si occupa di programmazione web sopratutto lato server, e di accessibilità del web. Utilizza e ama Debian GNU/Linux, e si interessa di fisica, fumetto, trekking e fotografia (gli ultimi due possibilmente abbinati). Collabora con Googlab da aprile 2012.

Contatta l'autore

Previous post:

Next post: