El secuestro de los dominios .gh, .sl y .as permitió burlar el protocolo HTTPS

Los atacantes obtuvieron certificados HTTPS válidos para sitios de Google ajenos, sin comprometer a la propia empresa. El navegador podría haber aceptado un servidor falso como legítimo y no mostrar una advertencia. La causa fue un ataque contra la gestión de tres zonas de dominio.

Las zonas de dominio nacionales .gh, .sl y .as, correspondientes a Ghana, Sierra Leona y Samoa Americana, resultaron afectadas. Los atacantes intervinieron en la gestión de operadores externos de esas zonas y pudieron modificar los registros DNS. Algunos dominios podían apuntar a servidores de los delincuentes, aunque la dirección en la barra del navegador permaneciera igual. No fue necesario comprometer los sitios de Google.

Para emitir un certificado HTTPS, la autoridad de certificación verifica si el solicitante controla el dominio indicado. A menudo, para la validación basta con colocar un registro DNS especial. Al tomar el control de las zonas de dominio, los atacantes pudieron hacerse pasar por propietarios de las direcciones seleccionadas. La comprobación se completó con éxito y las autoridades de certificación emitieron documentos válidos en los que los navegadores suelen confiar.

Las copias de phishing habituales a menudo muestran una dirección diferente o advierten sobre el certificado. Aquí el peligro es más grave: si un visitante fuera redirigido a un servidor de los atacantes, un certificado TLS válido podría mantener la dirección habitual y la conexión protegida sin que el navegador mostrara una advertencia. El esquema crea condiciones para el robo de contraseñas y otros datos, aunque por ahora no hay confirmaciones de ataques reales contra visitantes.

En los registros públicos se encontraron al menos 12 certificados para siete direcciones de Google y YouTube, incluyendo google.com.gh, google.sl y google.as. Entre el 22 y el 27 de septiembre, once de los documentos fueron emitidos por Let's Encrypt y otro por ZeroSSL. Más tarde, los doce fueron revocados. No se conoce el número total de dominios afectados. Google no divulgó los nombres de otras organizaciones ni identificó a los responsables.

Google bloqueó los certificados detectados de sus servicios en Chrome mediante el mecanismo CRLSets y logró que las autoridades de certificación los revocaran. Luego los registros de transparencia de certificados señalaron certificados de otras marcas importantes y de servicios web populares. La empresa añadió los documentos sospechosos a la lista de bloqueo de Chrome y, cuando fue posible, avisó a los propietarios de los dominios. La propia infraestructura de Google no resultó afectada.

En el análisis del ataque Google indicó que los usuarios de Chrome no necesitan realizar ninguna acción. Sin embargo, los expertos no garantizan haber encontrado todas las direcciones afectadas. La protección de Chrome tampoco se aplica necesariamente a otros navegadores y aplicaciones. Se recomienda a los propietarios de sitios en las tres zonas afectadas que revisen el historial de emisión de certificados y busquen documentos desconocidos.

A los administradores se les aconseja limitar la emisión de certificados mediante registros CAA y vincular permisos a cuentas específicas. Durante la toma de control del DNS, este enfoque no ofrece protección completa, pero dificulta la emisión de certificados tras la recuperación del control de la zona. Algo parecido ya ocurrió en 2011: el ataque a DigiNotar permitió obtener certificados falsos para servicios de Google y de otras empresas.