Google informó que atacantes comprometieron tres registros de ccTLD —.gh (Ghana), .sl (Sierra Leone) y .as (Samoa Americana)— y usaron ese acceso para modificar registros DNS autoritativos y conseguir certificados HTTPS no autorizados que cubrían varios dominios de Google y de otras organizaciones.
Qué sucedió y cuál fue el alcance conocido
Según el equipo de seguridad de Chrome, las intrusiones permitieron a los atacantes alterar los registros DNS autoritativos bajo esas zonas de nivel superior, lo que facilitó demostrar control sobre nombres de dominio durante procesos de emisión de certificados. Google aclara que no hubo indicios de compromiso de sus sistemas internos y que no tiene razones para creer que las autoridades de certificación (CA) actuaran de forma indebida.
Chrome reaccionó rápidamente bloqueando los certificados afectados mediante CRLSets, la herramienta que el navegador usa para invalidar certificados de emergencia. Además, Google trabajó con las CAs que emitieron las credenciales para revocarlas y minimizar el riesgo para clientes de otros navegadores.
Por qué un ataque al DNS puede comprometer la confianza HTTPS
La emisión de certificados TLS/HTTPS incluye pasos de validación que demuestran control sobre un dominio (domain-control validation). Si un atacante logra manipular los registros DNS autoritativos, puede redirigir validaciones o responder a retos de CA y así obtener certificados válidos para dominios que no controla realmente. Eso convierte una falla en la infraestructura DNS en una vía para socavar la confianza HTTPS sin tener que vulnerar el servidor de la web objetivo.
Organizaciones afectadas y limitaciones de la mitigación
La investigación de Google, apoyada en entradas de Certificate Transparency (CT), reveló que además de dominios de Google algunas marcas y servicios globales resultaron afectados, aunque la compañía no publicó la lista ni el número exacto de certificados obtenidos. Google ha contactado a organizaciones afectadas cuando ha podido.
Google advierte, no obstante, que las medidas desplegadas en Chrome no protegen de forma fiable a usuarios de otros navegadores y que la detección puede no haber identificado todos los dominios comprometidos. Por ello, el bloqueo en el lado del navegador no debe considerarse una solución completa.
Recomendaciones prácticas para administradores y propietarios de dominios
- Revisar registros de Certificate Transparency (CT) para todo el portafolio de dominios, incluyendo dominios regionales y aparcados, y buscar emisiones inesperadas.
- Configurar registros CAA restrictivos que limiten qué autoridades de certificación pueden emitir certificados para el dominio. Aunque CAA no impide emisiones durante un secuestro DNS activo, una política restrictiva y su restauración posterior pueden evitar que atacantes reutilicen validaciones en caché para nuevas emisiones.
- Vincular cuentas ACME (cuando proceda) para agregar controles adicionales en la automatización de emisión de certificados.
- Monitorear la integridad de los registros DNS autoritativos y emplear controles de acceso más estrictos en los registros de los registros y registradores, incluyendo autenticación multifactor y procedimientos de verificación administrativa.
- Planificar respuesta: conocer cómo presentar solicitudes de revocación rápido con las CAs y cómo desplegar mitigaciones en navegadores y CDN si se detecta una emisión fraudulenta.
Impacto para la comunidad del hosting y próximos pasos
El incidente subraya la importancia de la seguridad de la infraestructura DNS y de la supervisión continua de CT para administradores de servidores, proveedores de hosting y propietarios de sitios web. Google anuncia que seguirá impulsando cambios en el ecosistema HTTPS, como reducir periodos de validez de certificados y limitar la reutilización de validaciones de control de dominio para dificultar el abuso derivado de compromisos de DNS.
Nota: la información publicada por Google no incluye una lista completa de organizaciones afectadas ni cifras exactas; los administradores deben asumir que cualquier dominio con delegación en las zonas mencionadas podría haber estado en riesgo y aplicar las medidas recomendadas.
Lee también:
- FBI y autoridades francesas intervienen sitios que vendían imágenes íntimas robadas de más de 17.000 víctimas
- Cisco publica parches por más de una docena de vulnerabilidades críticas que afectan a Meraki, NX‑OS y APIC
Fuente: medio original
