Secuestros de DNS en tres ccTLDs derivaron en certificados falsos de Google

El 6 de octubre, Google reveló que los atacantes habían comprometido los registros de tres dominios de nivel superior de código de país (ccTLD) para obtener certificados HTTPS no autorizados para varios de sus dominios. Las extensiones afectadas fueron .gh (Ghana), .sl (Sierra Leona) y .as (Samoa Americana). Aunque los sistemas internos de Google permanecieron seguros, la brecha permitió a los actores de amenazas suplantar servicios de Google mediante conexiones cifradas, lo que representaba un riesgo significativo para la privacidad de los datos de los usuarios.

Qué ocurrió

Los atacantes obtuvieron el control sobre los registros DNS autoritativos de los dominios bajo estos tres ccTLD. Al modificar estos registros, demostraron el control del dominio ante las Autoridades de Certificación (CA), que es el método estándar para validar la propiedad antes de emitir un certificado TLS. Este proceso les permitió solicitar y recibir certificados válidos para nombres como google.com.gh, google.sl y youtube.as. Google declaró que no tenía motivos para creer que las CA actuaron indebidamente, ya que siguieron procedimientos de validación estándar basados en los datos DNS manipulados.

Los registros de Transparencia de Certificados (CT), que sirven como registro público de todos los certificados emitidos, revelaron al menos 12 certificados no autorizados emitidos entre el 22 y el 27 de septiembre. Let’s Encrypt emitió 11 de estos certificados, mientras que ZeroSSL emitió uno. Los ataques ocurrieron en oleadas, con los dominios .gh como objetivo el 22 de septiembre, .sl el 25 de septiembre y .as el 27 de septiembre. Google trabajó con las respectivas CA para revocar estos certificados y utilizó la función CRLSets de Chrome para bloquearlos dentro de su navegador. Sin embargo, los usuarios de otros navegadores permanecieron vulnerables hasta que las revocaciones se propagaron globalmente.

Detalles clave

• Registros afectados: La compromisión involucró los ccTLD de Ghana (.gh), Sierra Leona (.sl) y Samoa Americana (.as).
• Cantidad de certificados: Se emitieron al menos 12 certificados no autorizados para siete nombres de dominio distintos de Google y YouTube.
• Autoridades emisoras: Let’s Encrypt emitió 11 certificados y ZeroSSL emitió uno; todos fueron validados por dominio.
• Cronología: Los certificados fueron registrados entre el 22 y el 27 de septiembre, con revocaciones ocurridas entre el 26 de septiembre y el 1 de octubre.
• Método de detección: Los certificados no autorizados fueron identificados a través de registros CT públicos utilizando servicios como ctlogs.dev y Cert Spotter.
• Impacto más amplio: Google indicó que otras marcas globales y servicios en línea también fueron objetivos, aunque no se divulgaron nombres específicos.

Contexto

Para entender este incidente, es útil saber cómo se emiten los certificados TLS. Las CA dependen de la Validación de Dominio (DV) para confirmar que el solicitante controla el dominio. Esto suele hacerse verificando un registro específico en la configuración DNS del dominio. Si un atacante compromete el registro DNS, puede insertar estos registros de validación, engañando a la CA para que emita un certificado. Una vez emitido, este certificado permite al atacante crear una clonación cifrada convincente del sitio legítimo, habilitando ataques de intermediario (man-in-the-middle) donde los datos de los usuarios pueden ser interceptados.

Los registros de Transparencia de Certificados (CT) se introdujeron para mitigar tales riesgos haciendo públicas todas las emisiones de certificados. Esto permite a los propietarios de dominios e investigadores de seguridad monitorear certificados no autorizados. Además, los registros CAA (Certification Authority Authorization) permiten a los propietarios de dominios especificar qué CA están permitidas para emitir certificados para sus dominios. Si bien los registros CAA pueden prevenir la emisión no autorizada desde CA no listadas, son ineficaces si el atacante tiene control total sobre el DNS y puede eliminar o alterar el propio registro CAA.

Por qué importa

Para los equipos que alojan software por cuenta propia o gestionan sus propios dominios, este incidente subraya la fragilidad de la confianza en el ecosistema DNS. Incluso si su infraestructura interna es segura, una compromisión a nivel de registro puede llevar a la emisión de certificados no autorizados para sus dominios. Esto significa que confiar únicamente en la presencia de un candado HTTPS válido ya no es suficiente para garantizar la autenticidad del sitio. Los autoalojadores deben monitorear activamente las emisiones de certificados inesperadas para detectar posibles secuestros tempranamente.

Además, el tiempo de respuesta para la revocación varió significativamente, con algunos certificados permaneciendo válidos durante casi una semana después de la detección. Durante esta ventana, los usuarios que visitaban los sitios suplantados podrían haber tenido sus datos expuestos. Para los gerentes de TI, esto destaca la importancia de tener sistemas de monitoreo independientes que no dependan de los proveedores de navegadores para proteger a los usuarios. La detección proactiva mediante el monitoreo de registros CT puede reducir la ventana de exposición y permitir informes y revocaciones más rápidos.

Qué puede hacer

• Monitoree los registros CT: Configure alertas automatizadas para cualquier nuevo certificado emitido para sus dominios utilizando servicios de monitoreo de registros CT. Esto incluye dominios aparcados y variaciones regionales de ccTLD.
• Implemente registros CAA: Publique registros CAA estrictos en su DNS para restringir qué CA pueden emitir certificados para sus dominios. Asegúrese de que estos registros estén vinculados a su cuenta específica de CA cuando sea posible.
• Revise la seguridad del DNS: Audite la configuración de seguridad de su registrador de dominios y proveedor de DNS. Habilite la autenticación multifactor y revise los registros de acceso para cualquier actividad inusual.
• Reporte certificados no autorizados: Si detecta un certificado no autorizado, presente un Informe de Problema de Certificado ante la CA emisora inmediatamente. Están obligados a investigar y responder dentro de las 24 horas.
• Verifique dominios regionales: Si opera en o tiene dominios bajo .gh, .sl o .as, revise específicamente para detectar anomalías.