Certificados falsos, CRLSets y sospechas

Se han detectado más certificados fraudulentos que pretenden legitimar páginas falsas de Google (aunque podría hacerlo con cualquier dominio). Una entidad de confianza (para todos los Windows) ha firmado certificados falsos, lo que permite que se suplanten las páginas del buscador o que el tráfico cifrado en realidad sea visto por un tercero. Veamos algunas curiosidades.

Vuelve a ocurrir por quinta vez desde 2011, de forma muy similar. El 2 de julio, Google se percató de que se estaban usando certificados no válidos de Google, firmados por una autoridad de confianza preinstalada en Windows. En este caso, la organización gubernamental National Informatics Centre (NIC) de India, que maneja varias CA intermedias,  todas confiadas en última instancia por el “Indian Controller of Certifying Authorities (India CCA)”.

Al estar incluida en el repositorio de confianza raíz de Windows, la inmensa mayoría de programas confiarán en el certificado, además de por supuesto Internet Explorer y Chrome bajo Windows. Firefox, como sigue una política diferente de en quién confiar (que se ha mostrado más eficaz) no se ve afectado. Chrome, bajo otros sistemas operativos, tampoco.

Recordemos que para esto que suponga un “daño” para un usuario, se deben dar varias circunstancias:

• Que la víctima sea redirigida al sitio fraudulento donde se ha instalado el certificado falso. Esto puede hacerse por pharming, DNS, o cualquier otro método.
• Aunque así ocurriese, Google utiliza certificate-pinning para sus dominios de forma predeterminada. Así que si el atacante se limitó a emitir certificados de dominios de Google con la CA de la India, y la víctima visitaba estos sitios falsos con Chrome, el sistema se hubiese quejado.

Lo que no han dejado claro aún (habría que estudiar el certificado en detalle) es si estos certificados tienen alguna restricción de uso. Si solo han sido emitidos para validar servidores, o quizás también se pueda firmar código, etc.

Ejemplo de hipotético error de certificate pinning en Chrome sobre Eleven Paths

En cualquier caso, actualmente, ya no se corre tanto peligro. Los certificados están revocados y Microsoft ha emitido el parche correspondiente, que hace que los tres certificados intermedios (y por tanto cualquier “hijo” creado ilegítimamente) pasen al estado de “no confianza”. Incluso si han emitido certificados para otros dominios, y estos no están “pineados”, lo más probable es que el navegador se queje. Incluso así, por si fuera poco, Google ha emitido CRLSets actualizados para Chrome que actúan automáticamente sobre el navegador.

Algunos de los certificados revocados (falta el de 2014) mostrados en el keystore de Windows

¿Qué son los CRLSets?

CRLSets es un método “rápido” de revocación que utiliza Chrome, como ellos mismo dicen, para “situaciones de emergencia”. Son un conjunto de certificados que se aglutinan de información de otros CRLs, se descargan de un servidor, y son procesados por Chrome. Aunque el método es absolutamente transparente, la gestión de qué certificados van en la lista es totalmente opaca. No se sabe con qué certificados lo actualizan (a menos que se averigüe por otro lado). Para saber qué conjunto de CRLSets está descargando Chrome en este momento, lo más cómodo es usar este programa, creado en el lenguaje Go.

Descargando y volcando el contenido del crlset1718 de Chrome

Contenido del CRLSet

Al descargar el CRLSet más reciente, se observa un JSON con varios SPKI. Luego una lista de certificados padre, seguido de números de serie de certificados. Como un número de serie se puede repetir entre certificados diferentes, se organizan de esta manera puesto que un padre no debería emitir dos números de serie iguales. En algún punto de esta lista, se encuentran ya los certificados falsificados. El uso de CRLSets no es la mejor manera de proteger de forma global a los usuarios, pero sí es un método rápido con el que Google se permite reaccionar al margen de la industria de las CA.

¿Ataque o no?


¿Por qué siempre Google? Esto ya ha pasado. Es prácticamente la misma situación que ocurrió con  el gobierno francés en enero de 2014, Comodo y Diginotar en 2011 y TurkTrust en 2013. Curiosamente, en todos estos casos suelen ser dominios de Google (y en menor medida, Yahoo) los falsificados. Esto supone un riesgo para el atacante, porque llama mucho más la atención. ¿Se han creado certificados para otros dominios diferentes? No lo sabemos. Pero poder espiar las comunicaciones con Google es sin duda un botín más jugoso para atacantes que pretendan espiar que otros que intenten lucrarse… De ahí la siguiente duda.

Ha podido ocurrir que el Indian Controller of Certifying Authorities (India CCA) haya sido atacado, o que emitiera esos certificados conscientemente con el fin de espiar y, una vez “cazado” alegue que han sido atacados. Al tratarse de una institución nacional, podría ser usado para el espionaje civil, puesto que tendría la posibilidad de redirigir el tráfico a través de sus propios DNS. Pero como hemos mencionado, el hecho de que el certificate pinning activo de Chrome esté presente, hubiera delatado rápidamente el movimiento, lo que le resta efectividad. También puede ser que solo mencionen los certificados de Google porque esta es la empresa que suele detectar el fraude en sus certificados, y se ocupe de sus propios asuntos, pero existan otros dominios falsificados “ahí fuera”.