Wednesday, September 14, 2011

The attack intent on Google proves one of the weaknesses of Public Key Infrastructure: Certificate Authorities

On August 29th, Google made public onits official blog that they detected a “Man in the Middle” (MITM) attack intent that could had been used to intercept information between all their web services (Gmail, Gdocs, search, etc) and some Iran ISPs.
The blog post also states that the attackers used a Digital Certificate (issued to *.google.com) from a Dutch Certificate Authority (or CA) called DigiNotar, which according to Google, it is not used by them. This is a proof of concept of one of the weaknesses in Public Key Infrastructure (or PKI).

This incident forced Google and Microsoft to remove DigiNotar as a Trusted CA by updating their operating systems and Internet browsers.

What are Digital Certificates, Certificate Authorities and Public Key Infrastructure?

A Digital Certificate is a documented issued by a third party (called Certificate Authority) that authenticates a person or entity and it is used to create secure (or encrypted) connections with the use of SSL (or Secure Socket Layer) protocol through Internet. A Digital Certificate contains information like: name, permitted use, issuer, issued to, encryption algorithms, serial numbers, expiration dates, dates issued, etc.

We can compare a Digital Certificate with a passport, which is a document with international validity used to identify its holder.

Certificate Authorities are Organizations whose mainfunction is to issue or revoke Digital Certificates. Before issuing them, they must perform a due diligence in order to validate the persons or entities that request them (known as requestors) and then issue them by applying their digital signature on their certificate.

Going back to our passport example, they must be issued by a government agency. In order to obtain or renew one, each requestor must provide proof of their identity by showing a national identity card or similar document. Once the government validates the identity, they issue the passport with their signature and corresponding formats.

Public Key Infrastructure is an authentication framework that involves a set of programs, data formats, procedures, communication protocols, security policies and public encryption mechanisms that working together allow disperse persons or entities to communicate in a predictable and secure manner.

In order for persons or entities to participate in a PKI, they must possess a Digital Certificate issued by a “Trusted CA”. A trusted CA is one that is considered as such by an operating system, Internet browser or user. Normally, operating systems are configured by default with a list of trusted CA. This is what allows persons or entities that possess Digital Certificates issued by different CAs, and that have never met, authenticate and communicate in a secure manner.

Going back to our passport example, it will be considered internationally valid if it was issued by an official and authorized entity. This means that different immigration services will check for a specific passport who is the authorized entity to issue it and will validate our document and identity by trusting that entity.

How was the attack intent on Google performed?

Google did not give out details on the attack itself, but with the Digital Certificate issued by a trusted CA to *.google.com and information found on the case, we can establish the following attack vector:

  1. The attacker, by executing a DNS poisoning attack, modified the DNS cache entries of some ISPs from Iran. This allowed them to redirect all traffic to Google services to another server. Remember that a DNS resolves domain names into IP addresses, and each time it does this, it stores the resolutions in a cache for faster access. The DNS poisoning attack modifies the resolutions in the cache by injecting data that did not originate from authoritative (or original) DNS sources. 
  2. Then, the attacker configured a Proxy server with which he can receive, modify (or sniff) and redirect traffic to others servers. Here is where our trusted Digital Certificate comes into play: When the users connect to the Proxy server (redirected thanks to the DNS poisoning), it authenticates to them by using the Digital Certificate obtained. Since it was issued to *.google.com and it was a trusted Certificate, browsers and operating systems will treat the proxy server as a legitimate Google site (their browser will show gmail.google.com and hence match the issued certificate).
  3. Finally, the attacker will redirect traffic to the legitimate Google site. All traffic returning from Google to the user will go through the same Proxy Server, allowing the attacker to sniff it and thus obtaining passwords, reading mails, documents and search strings. 
There is information that indicates that steps 1 and 2 were executed, but this was never confirmed by Google. Moreover, the attack was detected and stopped by Google’s Internet browser (Chrome), which detected that the Digital Certificate was a fraud; hence, step 2 of the attack must have taken place.

The immediate action taken by Google and Microsoft was to remove DigiNotar as a trusted CA from their operating systems and browsers. This implies that all web sites that use certificates issued by this CA to authenticate or encrypt data, will receive an error from Internet browsers stating that the certificate in use was issued by a non-trusted CA.

Conclusion 

PKI is still a good authentication framework to Exchange information between unknown entities, but like all things, it has its weaknesses:

  • Like it was demonstrated in this incident, the Dutch CA issued a certificate without doing a due diligence on the identity of the requestor, thus putting in danger the confidentiality of the information of group of Google users. 
  • More than one CA can issue a Digital Certificate to the same person or entity. In this case, Google works with Verisign and not DigiNotar. 
  • If the private key with which the CA digitally signed the certificate is compromised, all certificates issued must be revoked. 
What to do to avoid these incidents?
  • CAs must perform a due diligence on the identity of the requestor.
  • There should be a register, like the one used with domain names (registrars), that would allow a CA to detect if a requestor is already using or possess a Digital Certificate. By having this, fraudulent certificate issuing (like what happened to Google) could be avoided. 
  • PKI should incorporate a new figure in its framework that incorporates the previous register. This register should be an independent entity that validates identities with authorized CAs. 
  • Finally, browsers and operating systems should incorporate an additional control to use the new register suggested. A good example of this is Chrome, which uses this sort of controls only for their google.com domain. 

Monday, September 12, 2011

El intento de ataque a Google demuestra un punto débil en la Infraestructura de Clave Pública: Las Autoridades de Certificación

El 29 de Agosto, Google publicó en su blog oficial que detectó un intento de ataque del tipo hombre en el medio (Man-in-the-middle ó MITM) que podría haber permitido la intercepción de datos de todos los servicios de Google (Gmail, Docs, buscador, etc.) a varios usuarios ubicados en Iran.

El mismo comenta que los atacantes utilizaron un Certificado Digital (a nombre del dominio *.google.com) emitido por una Autoridad de Certificación llamada DigiNotar, que no es utilizada por Google, exponiendo así una de las debilidades de la Infraestructura de Clave Pública .

El incidente provocó que tanto Google cómo Microsoft remueva a DigiNotar cómo un CA de confianza mediante la actualización inmediata de sus navegadores y sistemas operativos.


¿Qué es un Certificado Digital, una Autoridad de Certificación y una Infraestructura de Clave Pública?

El Certificado Digital (ó Certificado SSL) es un documento emitido por un tercero (llamado Autoridad de Certificación) que autentifica a una persona ó entidad y es utilizado para realizar conexiones seguras / cifradas en Internet por medio del protocolo SSL (ó Secure Socket Layer). Un Certificado Digital contiene datos como ser: nombre, dirección, usos permitidos, quién lo emitió, datos de cifrado, número de serie, fecha de expiración, fecha de emisión, etc.

Para clarificar la definición, podemos usar el Pasaporte como analogía: El pasaporte es un documento con validez internacional que identifica a su titular.

La
Autoridad de Certificación (Certificate Authority ó CA) son organizaciones cuya principal función es emitir ó revocar Certificados Digitales. Antes de emitirlos, deben validar la identidad de las personas ó entidades que solicitan el mismo y luego emitirlo mediante la aplicación de su firma digital.

Volviendo a nuestra analogía con el pasaporte, en el caso de Argentina, los mismos son emitidos por el Ministerio del Interior ó Policía Federal Argentina. Para renovarlo u obtenerlo, cada persona debe probar su identidad mediante su DNI. Una vez validada la Identidad, se emite el pasaporte con los sellos y formatos correspondientes.

La Infraestructura de Clave Pública (Public Key Infrastructure ó PKI) es un marco de autentificación que consiste en un conjunto de programas, formatos de datos, procedimientos, protocolos de comunicación, políticas de seguridad y mecanismos de cifrado público que en conjunto permiten a personas ó entidades dispersas comunicarse de manera segura y predecible.

Las personas ó entidades que quieran participar en un PKI necesitan poseer un Certificado Digital emitido por un CA de confianza. Un CA de confianza es aquel CA considerado por un sistema operativo (y/o navegadores de Internet ó usuario) como tal. Normalmente, los sistemas operativos ya poseen un listado de CAs de confianza por defecto. Esto es lo que permite que personas ó entidades, con Certificados Digitales emitidos por diferentes CAs y que nunca se han conocido, autentificarse y comunicarse de forma segura.

Volviendo a la analogía con el pasaporte, el mismo se considerará valido a nivel internacional siempre y cuando sea emitido por una entidad oficial autorizada. Para los servicios inmigratorios del exterior, los organismos autorizados a expedir Pasaportes para Argentina son la Policía Federal Argentina y el Ministerio del Interior. Dicho de otra forma, ellos confían únicamente en éstos organismos para que avalen nuestra identidad.

¿Cómo fue el intento de ataque a Google?

Google no dio datos detallados sobre el ataque, pero con el Certificado Digital emitido por un CA de confianza a nombre de *.google.com y la información sobre el caso, podemos establecer el siguiente vector de ataque:

  1. El atacante, modificó los registros del cache de un servidor de Nombres de Dominio (DNS) mediante un ataque de envenenamiento de DNS (DNS Poisoning), logrando redireccionar el tráfico dirigido a google.com a otro servidor. Recordemos que un DNS es consultado en forma transparente por el sistema operativo cada vez que ingresamos una dirección web (como ser www.google.com) y permite transformar esa dirección en una IP. Cada vez que sucede esto, la asociación dirección web a IP se guarda en el cache del servidor DNS. El ataque en cuestión cambia la IP de esa asociación por otra. 
  2. El atacante configuró un servidor como Proxy por el cual puede recibir, modificar y redireccionar tráfico a otro servidor. Aquí es donde el Certificado Digital obtenido toma un rol fundamental, dado que el servidor Proxy se va a autentificar con el usuario final como www.google.com y al ser emitido por un CA de confianza, el navegador del usuario final lo mostrará como un sitio web válido. 
  3. Finalmente, el atacante redirecciona el tráfico al verdadero sitio de Google. Todo el tráfico que vuelve al usuario lo hace por el mismo servidor Proxy, permitiéndole al atacante capturar todo el tráfico entre usuarios y los servicios de Google, como ser contraseñas, correos (Gmail), documentos (Gdocs), y busquedas. 

Existen reportes que indican que los pasos 1 y 2 fueron ejecutados, pero esto no fue confirmado por Google. Adicionalmente, el ataque fue detectado y detenido dado que el navegador de Google detectó que el Certificado Digital era fraudulento, y para eso, los usuarios deberían haber completado el paso 2 del ataque.

La acción inmediata de Google y Microsoft fue remover al CA DigiNotar de la lista de CAs de confianza en el sistema operativo. Esto implica que todos los sitios web que utilicen Certificados Digitales emitidos por este CA para cifrar la conexión ó autentificarse, aparecerán en los navegadores de Internet con advertencias mencionando que el certificado fue emitido por un CA no de confianza.


Conclusión

La Infraestructura de Clave Pública sigue siendo un buen marco de autentificación para intercambiar información de forma segura entre partes desconocidas, pero como todo, tiene sus puntos débiles:

  • Como quedó demostrado en este caso, el CA Holandés emitió un certificado sin validar de forma exhaustiva la Identidad del solicitante, poniendo en peligro la confidencialidad de la información de los usuarios de Google. 
  • Más de un CA puede emitir un Certificado Digital a una misma persona. Google trabaja con el CA Verisign y no con DigiNotar. 
  • Si la Clave Privada con la cual el CA firmó Digitalmente el Certificado se ve comprometida, todos los Certificados emitidos deben ser revocados. 

¿Qué hacer para evitar estos incidentes?

  • Los CA deben validar de forma exhaustiva la identidad de las personas ó entidades solicitando un Certificado Digital. 
  • Debería existir un registro, al igual que existe con los nombres de dominio, que permita identificar si una persona ó entidad ya posee un Certificado Digital. De esta forma, se evitaría la emisión fraudulenta de certificados como sucedió con Google. 
  • El PKI debería introducir una nueva figura intermedia, que permita incorporar el punto anterior en su marco de autentificación. Esta nueva figura debería ser un ente independiente que valide Identidades con CA autorizados. 
  • Finalmente, los navegadores y sistemas operativos deben incorporar un control adicional utilizar la nueva figura intermedia sugerida en el punto anterior. A modo de ejemplo, el navegador de Google (Chrome) ya incorporó para el dominio google.com un sistema que solo permite la utilización de Certificados Digitales emitidos por los CA que ellos utilizan. Esto debería ser implementado a nivel mundial.