El 6 de octubre, Google reveló que atacantes habían comprometido tres dominios de nivel superior de código de país (ccTLD) y obtenido certificados HTTPS no autorizados para varios dominios de Google. Este incidente plantea serias preocupaciones sobre la seguridad en línea, ya que afecta no solo a la integridad de los servicios de Google, sino también a la confianza que los usuarios depositan en la infraestructura de Internet en general.
Los dominios en cuestión son aquellos que terminan en .gh (Ghana), .sl (Sierra Leona) y .as (Samoa Americana). Aunque los sistemas de Google no fueron vulnerados directamente, la obtención de un certificado HTTPS a través de métodos fraudulentos permite a un atacante hacerse pasar por un sitio legítimo. Esto significa que, a través de una conexión cifrada, un atacante podría interceptar y leer datos privados enviados por usuarios desprevenidos que crean estar interactuando con el sitio auténtico.
En respuesta a esta amenaza, Google empleó su mecanismo CRLSets, diseñado para bloquear rápidamente certificados no autorizados en situaciones de emergencia. Además, la compañía colaboró con las autoridades certificadoras (CAs) que emitieron los certificados comprometidos para revocarlos. Este proceso no solo protege a los usuarios de Chrome, sino que también busca salvaguardar a quienes utilizan otros navegadores y aplicaciones.
Los registros de Transparencia de Certificados (CT) revelan que al menos 12 certificados fueron emitidos entre el 22 y el 27 de septiembre para nombres relacionados con Google y YouTube bajo los tres ccTLD mencionados. Estos incluyen dominios como google.com.gh, google.sl y google.as. Un certificado HTTPS es emitido por una autoridad certificadora una vez que el solicitante demuestra el control sobre el dominio, generalmente a través de la adición de un registro a la DNS del dominio. En este caso, los atacantes lograron modificar los registros DNS autoritativos durante el secuestro, lo que llevó a Google a concluir que las autoridades certificadoras no cometieron ningún error.
El medio especializado The Hacker News encontró los certificados comprometidos el 7 de octubre mediante dos servicios de búsqueda de CT, ctlogs.dev y Cert Spotter. De los 12 certificados, 11 fueron emitidos por Let's Encrypt y uno por ZeroSSL. Los certificados aparecieron en los registros en tres días distintos, uno por ccTLD: .gh el 22 de septiembre, .sl el 25 de septiembre y .as el 27 de septiembre.
Todos los certificados son de validación de dominio, lo que significa que fueron emitidos tras verificar que el solicitante controla efectivamente el dominio. En los registros revisados, que datan de al menos el 10 de septiembre, cada uno de los certificados para google.com.gh, google.sl y google.as provenía de Google Trust Services, la propia autoridad certificadora de Google. Matthew McPherrin, un miembro del equipo de Let's Encrypt, confirmó en el foro de la comunidad de la CA que los certificados para Google y YouTube fueron emitidos y posteriormente revocados.
A pesar de que solo se buscó un conjunto limitado de nombres de Google y YouTube, Google advirtió que los datos de CT también indicaron que otras organizaciones podrían haber sido afectadas por los mismos ataques, aunque no se revelaron sus nombres. Los registros de Cert Spotter mostraron el 7 de octubre que todos los 12 certificados habían sido revocados. Los dos certificados para .gh y el de ZeroSSL fueron revocados el 26 de septiembre, mientras que los otros nueve fueron revocados el 1 de octubre.
La brecha más corta entre la primera entrada de registro de un certificado y su revocación fue de aproximadamente un día y medio, mientras que la más larga fue de casi una semana. El primer certificado para .as fue registrado el 27 de septiembre, aproximadamente un día después de la revocación de los certificados para .gh.
Google indicó que se enteró de los secuestros la semana anterior a su comunicado del 6 de octubre y actuó de inmediato, aunque no proporcionó fechas específicas sobre los secuestros ni sobre sus propias acciones. Además, Google también bloqueó en Chrome los certificados que encontró para otras organizaciones y se puso en contacto con aquellas con las que pudo hacerlo.
Para los usuarios de Chrome, no es necesario realizar ninguna acción, según Google. Sin embargo, los propietarios de dominios no deben confiar exclusivamente en el navegador para proteger a sus usuarios. Dado que los secuestros de DNS son complejos, el equipo de Chrome Secure Web y Networking advirtió que no pueden garantizar que su análisis haya identificado todos los dominios afectados.
El comunicado de Google no menciona si alguno de los certificados fue utilizado para suplantar un sitio de Google o para leer datos de los usuarios. Tampoco se identificó a los atacantes ni se detalló cómo fueron comprometidos los ccTLD, ni si se ha asegurado su integridad.
Google proporcionó a los propietarios de dominios dos pasos recomendados. Las reglas que siguen las CAs permiten una tercera acción. En primer lugar, se aconseja monitorear los registros de CT para cada dominio en posesión, incluidos los dominios aparcados y los nombres de ccTLD regionales. Los servicios de monitoreo de CT envían alertas cuando se emite un certificado para un dominio. Quienes operen un dominio bajo .gh, .sl o .as deben revisar las entradas recientes de registro para certificados que no hayan solicitado.
En segundo lugar, se recomienda publicar un registro CAA estricto. Un registro CAA es un registro DNS que especifica las CAs autorizadas a emitir certificados para un dominio, y una CA debe verificarlo antes de emitir dicho certificado. Google sugiere vincular este registro a la propia cuenta del propietario en la CA, aunque esto solo funciona si la CA admite esa opción.
Por último, se debe informar a la CA que emitió un certificado no solicitado. Según los Requisitos Básicos que siguen las CAs, cualquier persona puede presentar un Informe de Problema de Certificado, y la CA debe investigar y reportar sus hallazgos iniciales en un plazo de 24 horas.
Es importante señalar que un registro CAA no puede detener la emisión de un certificado mientras se lleva a cabo un secuestro de DNS. Un atacante que tenga la capacidad de eliminar el registro o insertar uno falso todavía podría obtener un certificado, según el estándar CAA. Sin embargo, el registro se vuelve relevante una vez que el propietario recupera el control del DNS. Las CAs pueden reutilizar una verificación de dominio completada para certificados posteriores, por lo que un atacante que pasó la verificación durante un secuestro podría solicitar más certificados después de que este termine. Un registro CAA estricto impide esta práctica.
Los Requisitos Básicos permiten que una CA reutilice una verificación de dominio por hasta 200 días, con un límite que se reducirá a 100 días en marzo de 2027 y a 10 días en marzo de 2029, de acuerdo con un cronograma aprobado por el CA/Browser Forum en abril de 2025. Let's Encrypt, que emitió 11 de los 12 certificados, anunció en diciembre de 2025 que reutiliza una verificación de dominio por 30 días y planea reducir ese período a 7 horas para 2028.
El 7 de octubre, cada uno de los siete dominios afectados contaba con un registro CAA estricto. Google Public DNS devolvió un registro que solo nombraba a pki.goog, el dominio de Google Trust Services, para todos ellos. Cada certificado puede ser consultado en un servicio de búsqueda de CT mediante su huella digital SHA-256, cuyos números coinciden con las filas de la tabla que se proporcionó en la investigación inicial.