Una serie de ataques contra los registros de tres dominios de nivel superior permitió a los atacantes obtener certificados TLS fraudulentos para varios dominios de Google y otras grandes organizaciones. Google confirmó que los incidentes afectaron a las extensiones nacionales .gh, .sl y .as, correspondientes a Ghana, Sierra Leona y Samoa Americana, y anunció medidas para bloquear los certificados identificados en Chrome. La compañía advirtió de que podrían existir certificados no detectados y pidió a los propietarios de dominios que refuercen su vigilancia.
Las claves de los certificados TLS fraudulentos en 30 segundos
- Tres registros afectados: los atacantes comprometieron los dominios de nivel superior
.gh,.sly.as, lo que les permitió alterar la resolución de dominios seleccionados. - Certificados no autorizados: la manipulación del DNS facilitó superar las comprobaciones de control de dominio exigidas para emitir certificados HTTPS.
- Google intervino en Chrome: la compañía bloqueó los certificados fraudulentos identificados y colaboró con las autoridades de certificación para revocarlos.
- El alcance sigue sin estar claro: Google no ha publicado la lista completa de dominios afectados ni una cifra total de certificados emitidos.
- Los administradores deben actuar: la empresa recomienda vigilar los registros públicos de transparencia de certificados y restringir qué entidades pueden emitir certificados para sus dominios.
El incidente vuelve a poner de manifiesto una debilidad de la infraestructura de confianza de Internet: un certificado puede superar correctamente las comprobaciones habituales de emisión y, aun así, acabar en manos de un atacante si este consigue controlar temporalmente la infraestructura utilizada para demostrar la propiedad de un dominio.
Cómo consiguieron los atacantes obtener certificados válidos
Los certificados TLS (Transport Layer Security) permiten autenticar servidores y establecer conexiones cifradas entre clientes y servicios. Cuando un navegador visita una web mediante HTTPS, comprueba que el certificado presentado corresponde al dominio solicitado y que está firmado por una autoridad de certificación de confianza.
El problema aparece cuando un atacante consigue controlar el dominio o la infraestructura que se utiliza para verificar esa titularidad. Según Google, los responsables de estos ataques comprometieron los registros de .gh, .sl y .as, y modificaron registros DNS autoritativos y delegaciones de servidores de nombres para dominios seleccionados.
Con ese control temporal pudieron redirigir el tráfico hacia sistemas bajo su control y superar las comprobaciones automatizadas que utilizan las autoridades de certificación para verificar que quien solicita un certificado controla el dominio.
Google señaló que los certificados no autorizados afectaban a varios de sus dominios y a otros servicios de organizaciones importantes. No publicó una relación completa de las entidades afectadas ni precisó cuántos certificados llegaron a emitirse.
La compañía también aclaró que no había indicios de que se hubiera comprometido la infraestructura propia de las organizaciones afectadas ni de que las autoridades de certificación que emitieron los certificados hubieran incumplido los requisitos establecidos. El incidente se originó en el control de los registros de dominios de nivel superior, no en una intrusión confirmada en los sistemas de Google.
Un certificado fraudulento puede permitir que un atacante suplante criptográficamente un servicio cuando también consigue situarse en una posición desde la que interceptar o redirigir las conexiones. Por sí solo, disponer del certificado no garantiza que pueda leer cualquier comunicación cifrada: también necesita una vía para interponerse entre la víctima y el servicio legítimo.
Chrome bloquea los certificados identificados, pero no desaparece todo el riesgo
Google explicó que Chrome bloqueó los certificados no autorizados que identificó mediante CRLSets, un mecanismo que permite al navegador rechazar determinados certificados sin depender exclusivamente del proceso tradicional de revocación.
La empresa también trabajó con las autoridades de certificación implicadas para revocar los certificados correspondientes a dominios de Google. Estas medidas reducen la posibilidad de que los certificados detectados sigan utilizándose en ataques, pero no garantizan que se hayan localizado todos los emitidos durante los incidentes.
La revocación tradicional puede tardar en reflejarse en todos los clientes y sistemas. Por eso, los navegadores mantienen mecanismos adicionales para bloquear certificados concretos cuando detectan un riesgo. La protección tampoco es idéntica en todos los navegadores, aplicaciones y dispositivos, lo que complica la respuesta cuando un certificado fraudulento ha sido emitido por una entidad reconocida por el ecosistema.
Google indicó que los usuarios de Chrome no necesitan realizar ninguna acción específica para beneficiarse de los bloqueos que ha aplicado. Para los administradores de dominios, sin embargo, la recomendación es más exigente: la compañía advierte de que las medidas del navegador no deben considerarse una defensa suficiente.
La empresa reconoce que la complejidad de los secuestros de DNS impide garantizar que se hayan identificado todos los dominios afectados. También advierte de que los bloqueos de Chrome no protegen de forma fiable a quienes utilizan otros navegadores o clientes.
Por tanto, la situación no debe interpretarse como una vulneración confirmada de todas las organizaciones cuyos dominios aparecen en los registros de certificados. Lo que se ha confirmado es la emisión de certificados no autorizados para varios dominios, mientras que el alcance completo del incidente continúa sin conocerse públicamente.
Qué deberían revisar los administradores de sistemas
Google recomienda vigilar de forma continua los registros de Certificate Transparency (CT), un sistema público que permite consultar los certificados emitidos por autoridades de certificación. Los certificados de confianza utilizados por Chrome deben aparecer en estos registros, lo que permite detectar nuevas emisiones inesperadas con rapidez.
La vigilancia debe cubrir toda la cartera de dominios de una organización, incluidos los dominios regionales, los que apenas se utilizan y los que permanecen aparcados. Un dominio secundario puede convertirse en una vía de ataque si su registro o su configuración DNS no recibe la misma atención que la infraestructura principal.
Google también aconseja publicar registros CAA (Certification Authority Authorization), que permiten especificar qué autoridades de certificación están autorizadas para emitir certificados para un dominio. La empresa recomienda configuraciones restrictivas que incluyan vinculaciones con las cuentas ACME autorizadas, cuando corresponda.
Los registros CAA no impiden por sí solos la emisión fraudulenta durante un secuestro activo del DNS. Sin embargo, pueden ayudar a impedir nuevas emisiones cuando se recupera el control del dominio, especialmente si se restringen las cuentas autorizadas y los métodos de validación. Google advierte de que algunas autoridades pueden reutilizar comprobaciones de control de dominio almacenadas previamente, por lo que restaurar una política CAA restrictiva resulta especialmente importante tras un incidente.
Para los equipos de operaciones, estas medidas deberían acompañarse de una revisión de los accesos a las cuentas de registro, la configuración de DNS autoritativo y los procedimientos de recuperación. También conviene disponer de alertas ante cambios inesperados de delegaciones, direcciones IP y servidores de nombres.
El caso recuerda que HTTPS depende de varias capas de confianza: la seguridad del servidor, la resolución DNS, el control del dominio, las autoridades de certificación y los mecanismos de verificación del navegador. Proteger solo la aplicación web no basta si otra parte de esa cadena puede ser manipulada.
Preguntas frecuentes
¿Qué dominios de nivel superior fueron comprometidos?
Google identificó los registros .gh, correspondiente a Ghana; .sl, de Sierra Leona; y .as, de Samoa Americana.
¿Se comprometieron los servidores de Google?
Google afirmó que los incidentes no implicaron un compromiso de su propia infraestructura. Los atacantes manipularon registros de dominios y DNS para obtener certificados no autorizados.
¿Qué deben hacer los administradores de sistemas?
Google recomienda monitorizar los registros de Certificate Transparency, revisar toda la cartera de dominios y publicar registros CAA restrictivos para limitar las autoridades y cuentas autorizadas a emitir certificados.
¿Están protegidos todos los usuarios de Chrome?
Google bloqueó los certificados fraudulentos que identificó y señaló que los usuarios de Chrome no necesitan realizar ninguna acción. Sin embargo, la compañía no puede garantizar que se hayan detectado todos los certificados afectados ni que los bloqueos protejan de igual manera a otros navegadores.
vía: arstechnica.com
