Google: secuestros de ccTLD dieron certificados HTTPS falsos

Unos atacantes que se hicieron con el control de tres dominios de nivel superior geográficos aprovecharon esa posición para obtener certificados HTTPS de varios dominios de Google, así como de dominios de otras grandes organizaciones. Google dio a conocer los incidentes el martes.

Las terminaciones afectadas son .gh (Ghana), .sl (Sierra Leona) y .as (Samoa Americana). Los dominios de nivel superior geográficos, o ccTLD, son los sufijos de internet de dos letras asignados a países y territorios. Su gestión diaria suele correr a cargo de empresas externas y no de un organismo público. Según Google, los atacantes comprometieron a esos operadores externos. Eso les dio poder sobre todos los dominios registrados bajo las tres terminaciones, y a continuación modificaron los registros DNS autoritativos.

Los registros DNS autoritativos son la respuesta oficial a la pregunta de dónde se encuentra un dominio en internet. Quien los controla puede redirigir el tráfico y, en muchos casos, convencer a una autoridad de certificación de que el dominio es suyo.

Google asegura que sus propios sistemas no fueron vulnerados

Google insistió en que los atacantes nunca llegaron a entrar en su infraestructura.

"Estos incidentes no implicaron un compromiso de los sistemas de Google", señaló la compañía.

También exculpó a las organizaciones que emitieron los certificados. "Dada la naturaleza de los ataques, no tenemos motivos para creer que las autoridades de certificación (CA) que emitieron los certificados afectados hicieran nada mal", añadió Google.

Esta es la parte incómoda del incidente. Las autoridades de certificación (CA) emiten certificados tras comprobar que el solicitante controla el dominio, un proceso conocido como validación de control de dominio (DCV). Si un atacante controla el DNS, esas comprobaciones pueden superarse aunque la solicitud sea fraudulenta. Las CA siguieron el procedimiento, y el procedimiento dio la respuesta equivocada.

Google tuvo conocimiento de los secuestros la semana pasada. No explicó cómo se comprometió a los operadores de los registros, quién estaba detrás de los ataques ni cuándo empezó la actividad.

Cómo bloqueó Chrome los certificados

En el caso de los certificados que afectaban a sus propios servicios, Google envió bloqueos a Chrome mediante CRLSets. Se trata de una lista de certificados revocados que el navegador descarga discretamente en segundo plano. Permite a Google cortar el paso a certificados maliciosos sin tener que esperar a una nueva versión completa del navegador.

Google también colaboró con las CA emisoras para revocar formalmente los certificados. Ese paso es importante para quien no usa Chrome, ya que la revocación por parte de la CA llega también a otros navegadores y clientes.

A continuación, la compañía recurrió a los registros de Certificate Transparency (CT). Son registros públicos, a los que solo se pueden añadir entradas, de los certificados emitidos, concebidos para que los propietarios de dominios y los investigadores puedan detectar certificados que no han solicitado. Los datos de CT apuntaban a otras organizaciones que Google cree que fueron víctimas de la misma campaña, entre ellas varias grandes marcas internacionales y servicios en línea populares. Google no las identificó. También bloqueó esos certificados en Chrome y se puso en contacto con las organizaciones afectadas siempre que pudo.

"Los usuarios de Chrome no necesitan hacer nada para estar protegidos", escribió Google. Como ocurre con las actualizaciones de seguridad del navegador habituales, mantener Chrome al día garantiza contar con las últimas protecciones.

Los límites de la respuesta

Google se cuidó de no exagerar el alcance de la solución. Advirtió de que bloquear certificados en el navegador no debería ser la única línea de defensa. Dado lo complejos que son los secuestros de DNS, explicó la compañía, "no podemos garantizar que nuestro análisis haya identificado todos los dominios afectados".

También recordó que las intervenciones de Chrome no protegen de forma fiable a quienes usan otros navegadores.

De cara al futuro, Google afirmó que seguirá trabajando con el resto de la comunidad para limitar los daños que pueden causar los compromisos de DNS y de enrutamiento.

"Para proteger a nuestros usuarios, nos comprometemos con mejoras a largo plazo del ecosistema HTTPS, como reducir la validez de los certificados y la reutilización de la DCV, a través del Chrome Root Program y del nuevo Chrome Quantum-resistant Root Program", concluyó la compañía.

El contexto general

Este incidente pone de manifiesto hasta qué punto la seguridad de la web descansa sobre el DNS. El candado de la barra de direcciones demuestra que se emitió un certificado para un dominio. No demuestra que lo pidiera quien debía. Cuando se compromete la capa del registro que está por encima de un dominio, incluso organizaciones bien gestionadas como Google pueden acabar con certificados aparentemente válidos emitidos a su nombre sin que se haya producido ninguna intrusión en sus propias redes.

Para los defensores, la lección práctica es vigilar los registros de CT en busca de certificados que cubran sus dominios. Así es como Google encontró a las demás víctimas, y cualquier organización puede hacer lo mismo. Las empresas que dependen de ccTLD menos vigilados para sus webs regionales o sus enlaces cortos deberían plantearse si el operador que hay detrás de ese sufijo merece la misma confianza que su propia infraestructura.

La alusión de Google a certificados de vida más corta y a una menor reutilización de la DCV indica que considera que las validaciones de larga duración son una forma de prolongar el impacto de secuestros como estos. El nuevo programa de raíces resistentes a la computación cuántica encaja además en un movimiento más amplio hacia la criptografía poscuántica, que también se ha visto en las firmas poscuánticas de OpenSSH.

Habrá que estar atentos a si los operadores de los registros explican cómo se produjo la intrusión, a si las demás marcas afectadas dan la cara y a si otros fabricantes de navegadores siguen los pasos de Chrome con sus propios bloqueos.