Google bloquea certificados falsos de dominios .gh, .sl y .as

Google informó el 6 de octubre que atacantes secuestraron dominios de país en Ghana (.gh), Sierra Leona (.sl) y Samoa Americana (.as) y los usaron para conseguir certificados HTTPS falsos de sitios de Google y de otras organizaciones. Lo dijo el equipo de seguridad de Chrome en el blog de seguridad de Google, donde cuenta que se enteró "la semana pasada". Chrome ya bloquea esos certificados y quien lo usa no tiene que hacer nada.

Un certificado HTTPS es lo que permite al navegador fiarse de la identidad de un sitio. Antes de emitirlo, una autoridad certificadora verifica que el solicitante controla el dominio, y una de las pruebas pasa por el DNS, el sistema que indica a qué servidor apunta cada nombre. Según Google, los atacantes comprometieron a operadores externos que administran esos tres dominios y cambiaron los registros DNS autoritativos, con lo que pasaron esa validación.

Con esos certificados, apunta BleepingComputer, un sitio falso habría podido hacerse pasar por la marca sin que el navegador avisara. Google asegura que sus sistemas quedaron intactos y que no ve razones para pensar que las autoridades certificadoras actuaron mal.

Qué hizo Chrome

Chrome bloqueó los certificados de las propiedades de Google con CRLSets, un mecanismo de bloqueo de emergencia del navegador, y pidió su revocación a las autoridades que los emitieron. Los registros públicos de Certificate Transparency, donde se anota cada certificado emitido, permitieron dar con otras organizaciones afectadas. Google habla de marcas globales y de servicios en línea muy usados, pero no las nombra. Chrome bloqueó también esos certificados.

La protección tiene un límite que Google reconoce: CRLSets solo funciona en Chrome, y la empresa admite que quizá no identificó todos los dominios afectados.

Lo que Google pide a los dueños de dominios

Para quienes administran dominios, incluidos los estacionados y los regionales, la empresa recomienda vigilar los registros de Certificate Transparency y publicar registros CAA restrictivos, que limitan quién puede emitir certificados. Aclara que un CAA no impide la emisión mientras el secuestro sigue activo, pero evita que se reutilicen validaciones guardadas una vez que se recupera el DNS. Chrome dice trabajar en protecciones a más largo plazo, como certificados de menor vigencia.

No hay CVE: no es una vulnerabilidad de software con versión y parche, sino un compromiso de infraestructura. Todo lo anterior descansa en el anuncio de Google y en la nota de BleepingComputer, que se basa en él; esta redacción no encontró un análisis de especialistas ajenos a Google ni una declaración de los operadores de los registros. Tampoco se sabe quién está detrás, cuántos certificados se emitieron ni cuándo ocurrieron exactamente los secuestros.