Chrome bloquea certificados tras los secuestros de los registros .gh, .sl y .as

El equipo de Chrome de Google intervino la semana pasada para bloquear certificados HTTPS no autorizados emitidos para dominios bajo las extensiones .gh, .sl y .as. El proveedor del navegador actuó después de que los atacantes comprometieran estos registros específicos de dominios de nivel superior de código de país (ccTLD), lo que les permitió modificar los registros DNS y solicitar certificados válidos para sitios objetivo. Este incidente destaca la fragilidad del sistema global de nombres de dominio y la necesidad crítica de un monitoreo proactivo de certificados por parte de los propietarios de dominios.

Qué ocurrió

La brecha de seguridad no se originó dentro de la infraestructura de Google, sino a nivel de los registros ccTLD de terceros de Ghana (.gh), Sierra Leona (.sl) y Samoa Americana (.as). Los atacantes obtuvieron el control de estos registros y modificaron los registros DNS autoritativos. Con el control del DNS, pudieron superar las verificaciones de validación de dominio requeridas por las Autoridades de Certificación (CA). Como consecuencia, los atacantes obtuvieron certificados HTTPS no autorizados para varios dominios de Google, así como para dominios pertenecientes a otras organizaciones.

Al detectar la anomalía, el Equipo de Web Segura y Redes de Chrome desplegó inmediatamente CRLSets para bloquear el uso de estos certificados no autorizados dentro del navegador Chrome. Los CRLSets son un mecanismo que utiliza Chrome para revocar certificados que siguen siendo técnicamente válidos pero que se sabe que están comprometidos o mal emitidos. El equipo también coordinó con las CA emisoras para asegurar que los certificados fueran formalmente revocados, protegiendo a los usuarios en otros navegadores. Chrome declaró que no hubo indicios de que las CA actuaran incorrectamente; emitieron certificados basándose en los datos DNS manipulados proporcionados por los atacantes.

Un análisis posterior de los registros públicos de Certificate Transparency (CT) reveló que la superficie de ataque era más amplia de lo inicialmente pensado. Varias marcas globales líderes y servicios online ampliamente utilizados también se vieron afectados por los mismos compromisos de registro. Chrome bloqueó proactivamente los certificados de estas entidades adicionales para proteger a los usuarios mientras contactaba a las organizaciones afectadas cuando fue posible. El proveedor del navegador enfatizó que los usuarios de Chrome no necesitaban tomar ninguna medida manual, ya que las protecciones se aplicaron automáticamente.

Detalles clave

• Espacios de nombres afectados: Los secuestros apuntaron específicamente a los ccTLD .gh (Ghana), .sl (Sierra Leona) y .as (Samoa Americana).
• Vector de ataque: La vulneración de los registros ccTLD de terceros permitió a los atacantes modificar los registros DNS autoritativos.
• Resultado: Los atacantes obtuvieron certificados HTTPS no autorizados para dominios de Google y de otras organizaciones.
• Respuesta de Chrome: Los certificados no autorizados fueron bloqueados mediante CRLSets y se contactó a las CA emisoras para su revocación.
• Impacto más amplio: Los registros de Certificate Transparency mostraron que probablemente otras marcas globales y servicios se vieron afectados.
• Involucramiento de las CA: Google no encontró evidencia de que las Autoridades de Certificación actuaran indebidamente durante la emisión.

Contexto

Para entender este incidente, es útil saber cómo se emiten los certificados HTTPS. Cuando un propietario de sitio web solicita un certificado, la CA debe verificar que el solicitante controla el dominio. Esto suele hacerse comprobando los registros DNS. Si un atacante controla el registro que gestiona esos registros DNS, puede redirigir las verificaciones de validación a sus propios servidores, engañando a la CA para que emita un certificado. Esto se conoce como secuestro DNS.

Certificate Transparency (CT) es un sistema de libro mayor público diseñado para detectar dicha mala emisión. Cada CA de confianza debe registrar cada certificado que emite en estos registros públicos. Esto permite a los propietarios de dominios y a los navegadores escanear en busca de certificados emitidos sin su conocimiento. En este caso, los registros CT fueron fundamentales para revelar el alcance total del ataque más allá de solo las propiedades de Google. Mientras tanto, los CRLSets son una función específica de Chrome que permite a Google enviar revocaciones de emergencia a los navegadores más rápido que el proceso estándar de revocación global.

Por qué importa

Para los equipos que ejecutan su propio software o gestionan dominios corporativos, este incidente sirve como un claro recordatorio de que no controlan completamente la seguridad de su dominio si dependen únicamente del comportamiento predeterminado de las CA. Incluso si sus sistemas internos son seguros, una vulneración a nivel de registro puede llevar a que se emitan certificados válidos para su dominio. Estos certificados pueden utilizarse para ataques de intermediario (man-in-the-middle), interceptando el tráfico de usuario y robando credenciales. Confiar en proveedores de navegadores como Google para detectar estos problemas es arriesgado, ya que sus intervenciones pueden no cubrir todos los navegadores ni todos los dominios afectados.

Además, la dependencia del DNS para la validación significa que cualquier debilidad en la cadena de confianza —desde el registrador hasta el registro— puede socavar su seguridad HTTPS. Para aplicaciones autoalojadas, donde podría gestionar su propio DNS y certificados, comprender las dependencias externas es crucial. Si su dominio está alojado en un TLD comprometido, sus medidas de seguridad internas podrían ser evadidas antes de que el tráfico llegue incluso a su servidor. El monitoreo proactivo ya no es opcional; es una capa necesaria de defensa contra fallos sistémicos de infraestructura.

Qué puede hacer

• Monitoree los registros de Certificate Transparency: Configure un monitoreo automatizado para todos sus dominios para recibir alertas cada vez que se emita un nuevo certificado. Esto proporciona detección casi en tiempo real de emisiones no autorizadas.
• Publique registros CAA restrictivos: Utilice registros DNS de Autorización de Autoridad de Certificación (CAA) para especificar exactamente qué CA tienen permitido emitir certificados para sus dominios. Esto limita la superficie de ataque incluso si el DNS está comprometido.
• Vincule cuentas ACME en CAA: Donde sea compatible, restrinja la emisión de certificados a vinculaciones específicas de cuentas ACME. Esto evita que los atacantes utilicen datos de validación en caché para acuñar nuevos certificados después de recuperar el control del DNS.
• Revise los ccTLD regionales: Si opera dominios en .gh, .sl o .as, u otras extensiones regionales, revise inmediatamente las entradas recientes de los registros CT ante cualquier actividad inesperada.
• Audite su cartera de dominios: Asegúrese de que su monitoreo cubra todos los dominios, incluyendo propiedades aparcadas o heredadas, ya que los atacantes suelen apuntar a activos menos monitorizados.
• No dependa exclusivamente del bloqueo del navegador: Implemente sus propias capacidades de detección y respuesta, ya que las intervenciones del lado del navegador no garantizan la protección de usuarios que no usan Chrome ni capturan cada instancia.