LeakyLooker: la falla de cruce de inquilinos en Looker Studio que podría exfiltrar datos de Google Cloud

A principios de este año, investigadores de seguridad desvelaron un conjunto de fallos que afectaban a Looker Studio, la herramienta de Google para crear informes y paneles a partir de fuentes de datos diversas. Tenable bautizó ese paquete de defectos como LeakyLooker y lo describió como una serie de debilidades de “cruce de inquilinos” (cross-tenant) capaces, en el peor de los escenarios, de permitir que un atacante ejecute consultas SQL arbitrarias contra bases de datos ajenas y extraiga información sensible alojada dentro de proyectos de Google Cloud.

Aunque no hay indicios de que estos agujeros se explotaran en entornos reales, la investigación dejó claro que el impacto potencial era serio. Tras una notificación responsable realizada en junio de 2025, Google aplicó correcciones. El informe público de Tenable sobre estas investigaciones está disponible con explicaciones técnicas detalladas, por ejemplo en este análisis general publicado por la propia Tenable.

Las vulnerabilidades identificadas incluyen múltiples vectores distintos: inyecciones SQL que no requieren interacción del usuario (zero-click), abusos de credenciales almacenadas en conectores JDBC, fallos en funciones nativas que permitían inyectar en BigQuery, fugas de fuentes de datos mediante enlaces o la renderización de imágenes, técnicas de filtrado por temporización y conteo de frames, e incluso un camino para provocar efectos de denegación de recursos en BigQuery. Tenable documentó cada caso con su propia ficha técnica, accesible públicamente, por ejemplo aquí sobre inyección a través de conectores y credenciales almacenadas TRA-2025-28 y TRA-2025-29, o los problemas específicos relacionados con BigQuery y Spanner TRA-2025-27 y TRA-2025-37.

Lo que hace que estas fallas sean particularmente inquietantes no es solo la posibilidad de ejecutar sentencias SQL maliciosas, sino la naturaleza transversal del problema: muchas organizaciones conectan Looker Studio con servicios como BigQuery, Spanner, Google Sheets, PostgreSQL, MySQL o Cloud Storage para construir paneles. Si un atacante consigue explotar una de estas cadenas, podría escanear informes públicos o aprovechar un informe compartido para alcanzar credenciales y, desde ahí, acceder a conjuntos de datos completos dentro de diferentes proyectos de GCP.

Un escenario descrito por los investigadores ilustra cómo un flujo aparentemente inocente —por ejemplo, hacer pública una visualización o compartirla con un colaborador— puede transformarse en un vector de ataque. Gracias a un fallo en la lógica del copiado de informes, un adversario podría clonar un informe y conservar las credenciales del propietario original, con la capacidad subsecuente de alterar o borrar tablas en la base de datos vinculada. En otros casos documentados, bastaba con que la víctima abriera o visualizara un informe diseñado ad hoc para que su navegador ejecutara código que contactaba con un proyecto controlado por el atacante, facilitando la reconstrucción de datos a partir de registros.

En palabras de la investigadora responsable, estas vulnerabilidades quebraban una de las garantías fundamentales del sistema: que un rol de solo lectura o de “espectador” no debe poder manipular ni controlar los datos que visualiza. En efecto, la investigación mostró caminos por los que un usuario con permisos mínimos podía, indirectamente, provocar la exfiltración o modificación de información en servicios como BigQuery y Google Sheets.

Desde la perspectiva defensiva, la publicación de Tenable y la respuesta de Google subrayan varias lecciones prácticas que todo equipo de seguridad o administrador de nube debería considerar. Es recomendable revisar qué informes de Looker Studio están expuestos públicamente, auditar los conectores que almacenan credenciales y aplicar el principio de menor privilegio en cuentas de servicio y credenciales vinculadas. Google mantiene documentación sobre Looker Studio que ayuda a entender cómo se comparten y administran los informes, por ejemplo en el centro de ayuda de Looker Studio, y quienes usan BigQuery pueden repasar las mejores prácticas en la página de BigQuery y las guías de seguridad de Google Cloud en cloud.google.com/security.

Es importante subrayar que los fallos fueron el resultado de combinaciones lógicas complejas y no de un único error trivial: el ataque completo exige encadenar varias condiciones y apalancar comportamientos inesperados en la plataforma. Aun así, la existencia de esos encadenamientos demuestra que las interfaces entre servicios y la gestión de credenciales son áreas críticas que requieren pruebas rígidas y modelos de amenaza actualizados.

La divulgación responsable fue clave para reducir el riesgo: Tenable informó a Google en junio de 2025 y, tras la colaboración entre ambas partes, se desplegaron correcciones antes de que la información técnica se difundiera ampliamente. Esa coordinación evitó, muy probablemente, un uso malicioso masivo y dio tiempo a los administradores a tomar medidas preventivas.

Para las organizaciones que dependen de dashboards y datos en la nube, este episodio debería servir como recordatorio de que la comodidad de compartir y visualizar información no debe sacrificar controles básicos de seguridad. Rotar credenciales después de cambios, limitar el acceso a conectores sensibles, revisar políticas de compartición y monitorizar intentos inusuales de consulta en servicios como BigQuery son pasos prácticos que reducen la superficie de ataque.

En conjunto, LeakyLooker es otro ejemplo de cómo la complejidad de las plataformas cloud y la interacción entre componentes pueden generar vectores de ataque novedosos. La buena noticia es que los problemas fueron parcheados tras la notificación, y la publicación técnica de Tenable ofrece material para que equipos de seguridad aprendan y fortalezcan sus defensas. Para quienes quieran profundizar en los hallazgos, Tenable publicó notas técnicas individuales sobre cada vector, entre ellas las relativas a filtrado por imágenes y enlaces (TRA-2025-30), oráculos de temporización (TRA-2025-31) y rutas específicas hacia BigQuery y Spanner (TRA-2025-38).

La moraleja para responsables técnicos y directivos es clara: la seguridad en entornos de datos compartidos exige vigilancia constante, revisiones periódicas de permisos y una política firme sobre qué se publica y con quién se comparte. Mantenerse informado sobre los avisos de seguridad de proveedores y aprovechar los recursos de investigación —como los que ofrece Tenable— ayuda a cerrar rápidamente las brechas antes de que puedan ser explotadas.