Google denuncia secuestro de DNS: certificados TLS para google.com.gh, google.sl y google.as

Google informó el 6 de octubre que atacantes lograron emitir certificados HTTPS no autorizados para nombres de Google y YouTube después de comprometer registros DNS autoritativos de tres dominios de nivel superior con código de país: .gh (Ghana), .sl (Sierra Leone) y .as (American Samoa). Según los registros públicos de Certificate Transparency (CT), entre el 22 y el 27 de septiembre se añadieron al menos doce certificados para variantes de esos nombres (por ejemplo, google.com.gh, google.sl y google.as); Let's Encrypt emitió once y ZeroSSL emitió uno. Google aclara que sus propios sistemas internos no fueron vulnerados; la vía de ataque fue la manipulación de DNS en esos ccTLD.

En términos técnicos, lo que sucedió es un tipo clásico de secuestro de zona DNS: los atacantes cambiaron los registros autoritativos que indican qué servidores responden por un dominio. Las autoridades certificadoras (CAs) verifican el control sobre un nombre de dominio antes de emitir un certificado y una forma habitual de comprobación es exigir que quien solicita el certificado ponga un registro DNS específico o sirva un token en una URL del dominio. Al tomar control de la zona DNS autoritativa, los atacantes pudieron responder a esas pruebas y obtener así certificados válidos emitidos por CAs legítimas. Con un certificado válido en mano, un atacante capaz de interceptar tráfico (por ejemplo, en una red Wi‑Fi pública o mediante un enrutamiento malicioso) puede presentar el certificado y establecer conexiones cifradas aparentemente legítimas, lo que permitiría leer o manipular datos confidenciales.

Hechos verificados: Google bloqueó los certificados no autorizados en Chrome usando CRLSets —el mecanismo rápido de bloqueo de certificados de emergencia del navegador— y trabajó con las CAs para revocar los certificados, según su comunicado. Los registros de CT muestran las entradas y las revocaciones; búsquedas en servicios públicos como ctlogs.dev y herramientas de monitoreo como Cert Spotter confirmaron la presencia y posterior revocación de las huellas registradas. Google dijo además que detectó indicios de que otras organizaciones —marcas y servicios ampliamente usados— fueron afectadas por el mismo patrón, aunque no las identificó públicamente.

Lo que sigue incierto y no confirmado por Google incluye si alguno de esos certificados fue realmente usado en ataques activos contra usuarios para leer datos, la identidad de los atacantes, el método exacto por el cual se comprometieron los registros DNS de cada ccTLD y si las registradurías o registros de esos ccTLD han sido completamente remediados. Google también señaló que, debido a la complejidad de los secuestros DNS, no puede garantizar que su análisis haya detectado todos los dominios afectados.

El incidente expone varias vulnerabilidades en la cadena de confianza del ecosistema TLS/DNS. Primero, la emisión de certificados basada en pruebas de control de dominio (domain validation) depende de la integridad del sistema DNS: si la señal de control puede ser falsificada mediante un secuestro de zona, la CA puede legítimamente emitir un certificado a un atacante. Segundo, las CAs pueden reusar comprobaciones de control previas para acelerar emisiones posteriores; las reglas del Baseline Requirements (del CA/Browser Forum) fijan plazos para esa reutilización que se van a reducir en los próximos años, y algunos proveedores como Let's Encrypt ya han anunciado cambios en sus plazos de reuse. Estos detalles explican por qué un control de dominio temporal puede derivar en certificados válidos durante días.

Las consecuencias reales varían por rol: para usuarios finales, el riesgo principal es un ataque de hombre‑en‑medio que presente uno de esos certificados y descifre tráfico aparentemente cifrado. Para operadores de dominios y proveedores de servicios, la consecuencia es pérdida de control y posible suplantación de servicios; además, la necesidad de auditar rápidamente CT logs, revocar certificados y comprobar la integridad de las zonas DNS. Para las CAs, el suceso obliga a revisar procedimientos de validación y a acelerar políticas que reduzcan la ventana de reuso de comprobaciones de dominio.

Google y los CAs tomaron medidas concretas y visibles: bloqueo en Chrome mediante CRLSets y solicitudes de revocación a las CAs emisoras. Sin embargo, Google advirtió que las protecciones de Chrome no son suficientes para todos los navegadores y que los propietarios de dominios no deben confiar únicamente en el navegador para proteger a sus usuarios.

Recomendaciones prácticas y específicas (quién debe hacer qué): propietarios de dominios bajo cualquiera de esos ccTLD o con subdominios regionales deben immediately auditar registros de Certificate Transparency para todas las variantes de sus nombres —incluyendo dominios aparcados y regionales— usando servicios de monitorización de CT y revisar cualquier certificado no solicitado. Publique una CAA (Certification Authority Authorization) estricta que limite qué CAs pueden emitir certificados para su dominio y, cuando la CA lo permita, asóciela a su cuenta en esa CA para reducir riesgos. Reporte de inmediato cualquier emisión no autorizada a la CA emisora mediante un Certificate Problem Report; las CAs están obligadas a investigar y responder en plazos breves según las reglas del sector.

Adicionalmente, y aunque Google ya lo sugirió indirectamente, los administradores de DNS y responsables de registro deben comprobar credenciales y accesos a sus cuentas de registrador y a los servidores de nombres autoritativos: active autenticación multifactor en las cuentas de registrador, aplique locks de transferencia, revise cambios en los servidores de nombre y registre alertas de cambios de SOA/serial. Implemente o verifique DNSSEC en sus zonas cuando sea posible; DNSSEC no es una panacea ni siempre está disponible para todos los ccTLD, pero añade una capa que dificulta manipulaciones en ruta de la información de delegación. Finalmente, reduzca la ventana de confianza en validaciones de dominio donde su CA lo permita (p. ej., usar CAs que no reusen comprobaciones por largos periodos).

Para usuarios finales, la recomendación inmediata es mantener navegadores y sistemas actualizados: Chrome ya bloqueó los certificados afectados, pero otros navegadores pueden tardar más en recibir revocaciones y actualizaciones. Evite redes Wi‑Fi públicas no confiables y, si maneja información sensible, considere usar redes privadas o VPNs confiables mientras las investigaciones continúan.

Por último, este incidente subraya la importancia de la monitorización constante: Certificate Transparency es una herramienta pública que permite detectar emisiones inusuales, pero solo funciona si los propietarios la usan. Documentación y recursos sobre CT y vigilancia pública están disponibles en la página oficial de Certificate Transparency y en servicios de monitoreo como Cert Spotter; quienes administran dominios deben incorporarlos a sus procesos de seguridad. Más información técnica sobre CT y recursos para empezar pueden consultarse en certificate-transparency.org y en la documentación de Cert Spotter.