Los atacantes comprometieron los registros de .gh, .sl y .as y obtuvieron al menos 12 certificados HTTPS para dominios de Google y YouTube.
El incidente no supone un ataque directo contra los servidores de Google, pero sí revela una peligrosa vulnerabilidad en una pieza esencial de la seguridad de Internet: el sistema que relaciona DNS, dominios y certificados HTTPS.
Durante varios días de septiembre, los atacantes lograron controlar temporalmente registros correspondientes a los dominios .gh, .sl y .as, asociados respectivamente con Ghana, Sierra Leona y Samoa Americana. Después utilizaron ese control para conseguir certificados digitales aparentemente legítimos para nombres vinculados a Google y YouTube.
El problema fue detectado y los certificados terminaron revocados. Chrome también bloqueó los certificados afectados. Sin embargo, Google reconoce que no puede garantizar que todos los dominios comprometidos hayan sido identificados.
El ataque no entró en Google, pero puso en riesgo la confianza de Internet
La primera precisión es importante: los sistemas internos de Google no fueron vulnerados.
El ataque se produjo en una capa diferente. Los delincuentes consiguieron comprometer tres registros de dominios de nivel superior con código de país —conocidos como ccTLD— y modificar registros DNS autoritativos.
Eso les permitió superar las comprobaciones necesarias para solicitar certificados HTTPS.
En otras palabras, los atacantes no tuvieron que romper directamente la seguridad de Google. Consiguieron controlar temporalmente la infraestructura que permitía demostrar ante una autoridad certificadora que determinados dominios estaban bajo su control.
Ese matiz explica la gravedad del caso.
Un certificado HTTPS válido permite que un navegador considere legítima una conexión cifrada. Si un atacante consigue uno para un dominio determinado, puede potencialmente presentarse ante el usuario como el propietario legítimo de ese dominio.
En determinadas circunstancias, esto podría facilitar ataques de intermediario y la interceptación de información privada.
Google, no obstante, no ha dicho que los certificados fueran utilizados efectivamente para hacerse pasar por sus páginas ni que datos de usuarios fueran robados. Esa diferencia es fundamental: la existencia de los certificados demuestra una brecha en el proceso de validación, pero no demuestra por sí sola que hubiera víctimas finales.
Al menos 12 certificados fueron emitidos para Google y YouTube
Los registros públicos de Certificate Transparency, que permiten consultar los certificados digitales emitidos por las autoridades certificadoras, ofrecen una imagen mucho más concreta del incidente.
The Hacker News localizó 12 certificados asociados con siete dominios de Google y YouTube.
Las emisiones se produjeron en tres oleadas:
- 22 de septiembre: dominios bajo
.gh. - 25 de septiembre: dominios bajo
.sl. - 27 de septiembre: dominios bajo
.as.
Entre los nombres afectados aparecen variantes como google.com.gh, google.sl, google.as, youtube.com.gh y youtube.sl.
La mayoría de los certificados fueron emitidos por Let’s Encrypt, que expidió 11 de los 12 encontrados. El certificado restante fue emitido por ZeroSSL.
La propia Let’s Encrypt confirmó posteriormente que durante los secuestros se habían emitido certificados para dominios de Google y YouTube y que habían sido revocados.
El dato resulta especialmente llamativo porque los registros históricos consultados por The Hacker News muestran que, antes del incidente, otros certificados para varios de esos dominios procedían habitualmente de Google Trust Services, la propia autoridad certificadora de Google.
¿Cómo consiguieron los certificados?
El mecanismo utilizado se basa en una debilidad bastante conocida cuando se combina con un secuestro DNS.
Cuando una empresa solicita un certificado para un dominio, la autoridad certificadora debe comprobar que el solicitante tiene control sobre ese dominio.
Una de las formas de hacerlo consiste en modificar determinados registros DNS.
El problema es evidente: si un atacante consigue controlar temporalmente esos registros DNS, puede superar la comprobación de control del dominio.
Eso es precisamente lo que Google considera que ocurrió.
Los atacantes modificaron los registros DNS autoritativos de los dominios afectados durante los secuestros. De esta manera pudieron superar el proceso de validación necesario para conseguir certificados.
Google ha indicado que no tiene motivos para pensar que las autoridades certificadoras actuaran incorrectamente.
El problema estaba en que, desde el punto de vista de la infraestructura de validación, el atacante había conseguido aparentar que tenía el control legítimo del dominio.
Los certificados estuvieron activos durante días
Los certificados no permanecieron todos el mismo tiempo en circulación.
Los registros examinados muestran que los primeros certificados de .gh fueron registrados el 22 de septiembre y revocados el 26 de septiembre.
Los correspondientes a .sl aparecieron el 25 de septiembre y varios fueron revocados el 1 de octubre.
Los certificados de .as aparecieron el 27 de septiembre y también fueron revocados el 1 de octubre.
El intervalo más corto entre la aparición de un certificado en los registros y su revocación fue de aproximadamente un día y medio.
El más largo se acercó a una semana.
Google afirma que tuvo conocimiento de los secuestros durante la semana anterior a su comunicación pública del 6 de octubre y que actuó inmediatamente después de detectarlos.
Chrome bloqueó los certificados
Google utilizó CRLSets, el sistema de Chrome destinado a bloquear rápidamente certificados considerados peligrosos, para impedir que los certificados identificados pudieran seguir siendo aceptados por el navegador.
Además, Google colaboró con las autoridades certificadoras responsables para conseguir su revocación.
Para los usuarios de Chrome, Google asegura que no es necesario realizar ninguna acción específica.
Pero la compañía introduce una advertencia importante: no todos los usuarios de Internet utilizan Chrome.
El bloqueo incorporado al navegador no constituye una protección universal para quienes utilizan Firefox, Safari, navegadores basados en otros motores o determinadas aplicaciones.
Por eso, el problema no termina simplemente porque Chrome haya bloqueado los certificados.
Google admite que puede haber más dominios afectados
Este es probablemente uno de los aspectos más inquietantes del incidente.
Los investigadores solo comprobaron una selección de nombres pertenecientes a Google y YouTube. Por tanto, los 12 certificados identificados no tienen por qué representar el número total de certificados emitidos durante los secuestros.
Google asegura que los datos de Certificate Transparency también apuntaron a otras organizaciones y servicios ampliamente utilizados, incluidas marcas internacionales conocidas.
La compañía no ha identificado públicamente a esas organizaciones.
Google también ha advertido de que los secuestros DNS son complejos y que no puede garantizar que su análisis haya identificado todos los dominios afectados.
Eso obliga a mantener cierta cautela.
El incidente confirmado es grave, pero todavía no existe información pública suficiente para afirmar que todos los dominios afectados hayan sido localizados o que los certificados fraudulentos hayan sido utilizados contra usuarios.
¿Se robaron datos de usuarios?
Por ahora, no está demostrado.
Google no ha afirmado que los certificados fueran utilizados para hacerse pasar por las páginas legítimas ni que permitieran leer información privada de usuarios.
La diferencia entre capacidad y explotación real resulta fundamental.
El certificado proporciona al atacante una herramienta potencialmente peligrosa. Pero para convertir esa capacidad en un ataque efectivo tendría que producirse una cadena adicional de circunstancias.
Por tanto, no es correcto afirmar que los piratas informáticos hayan robado cuentas de Google o contraseñas mediante este incidente sin pruebas adicionales.
Lo que sí está acreditado es que certificados no autorizados fueron emitidos para nombres de Google y YouTube y que posteriormente fueron revocados.
Los tres dominios comprometidos
Los sufijos afectados corresponden a:
- .gh: Ghana.
- .sl: Sierra Leona.
- .as: Samoa Americana.
Los tres son dominios territoriales de nivel superior.
El hecho de que el ataque se produjera de forma escalonada resulta especialmente significativo: primero .gh, después .sl y finalmente .as.
Los registros públicos muestran certificados emitidos el 22, 25 y 27 de septiembre, respectivamente.
La secuencia apunta a una operación coordinada, aunque Google no ha atribuido públicamente el ataque a ningún grupo concreto ni ha explicado cómo se consiguió comprometer cada registro.
El peligro de un certificado HTTPS falso
Para el usuario medio, el candado del navegador suele representar una señal sencilla: conexión segura.
Pero HTTPS no significa automáticamente que una página sea legítima en todos los sentidos.
El certificado garantiza determinadas propiedades criptográficas de la conexión y permite al navegador verificar que el certificado corresponde al dominio solicitado.
Por eso, si un atacante consigue un certificado válido para un dominio que no controla realmente, puede producirse una situación especialmente peligrosa.
El incidente demuestra que la seguridad de HTTPS depende también de la seguridad de la infraestructura DNS y del proceso de emisión de certificados.
No basta con proteger los servidores de una empresa si un tercero puede manipular el mecanismo mediante el que se acredita quién controla un dominio.
Google recomienda vigilar los certificados
Google ha planteado varias medidas para los propietarios de dominios.
La primera es vigilar los registros de Certificate Transparency.
Estos registros permiten detectar cuándo una autoridad certificadora ha emitido un certificado para un dominio. Una organización puede establecer mecanismos de alerta para descubrir rápidamente certificados que no haya solicitado.
La segunda recomendación es utilizar registros CAA (Certification Authority Authorization) estrictos.
Un registro CAA permite especificar qué autoridades certificadoras están autorizadas a emitir certificados para un determinado dominio.
La tercera medida consiste en informar inmediatamente a la autoridad certificadora cuando aparezca un certificado que el propietario del dominio no haya solicitado.
Las reglas del sector permiten presentar informes sobre certificados problemáticos y obligan a las autoridades certificadoras a investigar determinadas denuncias.
Pero el CAA tampoco es una solución mágica
Hay un matiz técnico importante.
Un registro CAA no puede impedir necesariamente la emisión de un certificado mientras el atacante mantiene el control del DNS.
Si el delincuente ha conseguido modificar los registros DNS, también podría tener capacidad para eliminar o alterar el registro CAA.
La utilidad del CAA aparece especialmente cuando el propietario recupera el control de su infraestructura.
Existe además otro problema: las autoridades certificadoras pueden reutilizar durante un determinado periodo una comprobación anterior de control del dominio.
Según las reglas actuales, ese periodo puede llegar hasta 200 días, aunque el calendario aprobado por el CA/Browser Forum contempla reducirlo a 100 días en marzo de 2027 y a 10 días en marzo de 2029.
Let’s Encrypt utiliza actualmente periodos mucho más cortos y ha anunciado planes para reducir todavía más el tiempo de reutilización de las validaciones.
Un ataque que vuelve a poner el foco en el DNS
El caso deja una conclusión incómoda para todo el ecosistema de Internet.
La seguridad digital no depende únicamente de los grandes gigantes tecnológicos.
También depende de una enorme cadena de registros de dominios, operadores DNS, autoridades certificadoras, navegadores y sistemas de transparencia.
Un fallo en cualquiera de esas capas puede afectar a servicios utilizados por millones de personas.
Y lo ocurrido con .gh, .sl y .as demuestra que incluso una empresa como Google puede verse obligada a reaccionar ante un problema situado fuera de sus propios servidores.
La amenaza no es solo Google
Aunque los nombres de Google y YouTube hayan sido los más llamativos, el problema potencial es mucho mayor.
Google asegura que sus análisis encontraron indicios de que otras organizaciones también pudieron verse afectadas.
Todavía no se ha publicado una lista completa de esas entidades.
Por ello, el verdadero alcance del incidente puede tardar en conocerse.
Los registros de Certificate Transparency se convierten en este escenario en una herramienta esencial para investigadores y administradores de sistemas, porque permiten reconstruir qué certificados se emitieron y cuándo.
La transparencia, en este caso, puede ser precisamente lo que permita descubrir una intrusión que de otro modo podría permanecer oculta.
¿Qué sabemos y qué sigue sin respuesta?
A día de hoy, los hechos conocidos pueden resumirse así:
- Tres ccTLD fueron comprometidos:
.gh,.sly.as. - Se emitieron al menos 12 certificados no autorizados para nombres relacionados con Google y YouTube.
- Los certificados afectaban a siete dominios.
- Let’s Encrypt emitió 11 y ZeroSSL uno.
- Todos los certificados identificados fueron posteriormente revocados.
- Chrome bloqueó los certificados mediante CRLSets.
- Google afirma que sus propios sistemas no fueron vulnerados.
- No está demostrado que los certificados fueran utilizados para robar información de usuarios.
- Google no ha identificado públicamente a los atacantes.
- Tampoco ha explicado públicamente cómo fueron comprometidos los tres registros.
- La compañía reconoce que podrían existir otros dominios afectados.
La última incógnita es precisamente la más importante: ¿cuántos dominios fueron realmente comprometidos y qué hicieron los atacantes con los certificados obtenidos?
Mientras esas preguntas permanezcan abiertas, sería prematuro dar por cerrado el incidente.
Una advertencia para toda la infraestructura de Internet
El secuestro de los dominios .gh, .sl y .as no demuestra que HTTPS haya dejado de ser seguro. Tampoco demuestra que Google haya sido hackeado.
Demuestra algo más concreto y, precisamente por eso, más relevante: la confianza que sostiene Internet depende de una cadena mucho más amplia que los servidores de las grandes compañías.
Un atacante que consigue alterar el DNS puede intentar convertirse en el propietario aparente de un dominio. Si además obtiene un certificado reconocido por los navegadores, la frontera entre una conexión legítima y una conexión controlada por un tercero puede volverse peligrosamente difícil de distinguir.
El caso de Google sirve como advertencia para empresas, administraciones públicas y particulares que gestionan dominios.
Vigilar los certificados, proteger el DNS y reaccionar inmediatamente ante cambios no autorizados ya no es una cuestión exclusiva de los grandes departamentos de ciberseguridad: es una parte esencial de la seguridad de cualquier organización conectada a Internet.
Toqueteo
Toqueteo
Toqueteo