Una sola consulta SQL bastó para entrar en la nube ajena: qué se sabe sobre el ataque LeakyLooker a la infraestructura de Google

Los especialistas de Tenable descubrieron en el servicio de análisis Google Looker Studio nueve vulnerabilidades que pueden exponer datos de distintos clientes en la nube y ejecutar consultas SQL arbitrarias en bases de datos ajenas. Los problemas afectan las conexiones con diversas fuentes de datos y potencialmente permiten a un atacante controlar la información dentro de proyectos de Google Cloud.

Los investigadores agruparon todas las vulnerabilidades detectadas bajo el nombre clave LeakyLooker. Se informó a Google sobre el hallazgo en junio de 2025, tras lo cual la empresa solucionó los problemas. No se hallaron indicios de ataques reales al momento de publicar el informe.

Las fallas violaban principios básicos del servicio. La arquitectura de Looker Studio supone que un usuario con rol "visualizador" solo ve el informe y no influye en la fuente de datos. Sin embargo, los errores detectados permitían eludir las restricciones y ejecutar consultas SQL en nombre del propietario del informe. Ese escenario permitía acceder, modificar o eliminar información en la infraestructura de Google Cloud.

Según la estimación de Tenable, el riesgo potencial afectaba a un amplio conjunto de organizaciones que usan los conectores de Looker Studio. Entre las fuentes de datos estaban Google Sheets, BigQuery, Spanner, PostgreSQL, MySQL, Cloud Storage y otros servicios. En un ataque exitoso, un atacante podría acceder a conjuntos de datos y a proyectos de distintos inquilinos de la nube.

Uno de los escenarios empezaba buscando informes públicos de Looker Studio o obteniendo acceso a un informe privado con una base de datos conectada, por ejemplo BigQuery. A partir de ahí, el atacante podía apropiarse del control de la conexión y ejecutar consultas arbitrarias en la base de datos. Otra variante está relacionada con un error lógico en la función de duplicar informes. El clon conservaba las credenciales del propietario del informe original, lo que permitía modificar o eliminar tablas en la base conectada.

Un método separado permitía extraer datos con una sola acción del usuario. Un informe especialmente preparado hacía que el navegador de la víctima ejecutara código malicioso y se conectara al proyecto del atacante. A través de los registros de operaciones era posible reconstruir la estructura y el contenido de las bases de datos.

Según Liv Matan, quien realizó la investigación, los problemas detectados crearon de hecho una nueva clase de ataques contra los servicios analíticos en la nube y ponían en riesgo los datos relacionados con productos de Google, incluidos BigQuery y Google Sheets.

Esta historia ilustra claramente la vulnerabilidad de los servicios en la nube complejos ante errores de diseño: incluso un rol con permisos mínimos puede convertirse en un punto de entrada a datos críticos si la arquitectura del sistema permite eludir restricciones lógicas ocultas.