Google ha parcheado un conjuntode nueve fallas de seguridad en Looker Studio que, según los investigadores, podrían haber permitido a los atacantes acceder a datos a través de los límites de los inquilinos, ejecutar consultas SQL arbitrarias y, en algunos casos, modificar o eliminar registros en los servicios conectados.Los problemas, revelados por Tenabley denominados colectivamente "LeakyLooker", afectaron la forma en que Looker Studio manejaba informes compartidos, fuentes de datos vinculadas y modelos de credenciales. Google dice que no encontró evidencia de explotación activa y que los clientes no necesitan tomar medidas.
Los errores importanporque Looker Studio está diseñadopara extraer datos en vivo de servicios como BigQuery, Google Sheets, Cloud Storage, Spanner, PostgreSQL y MySQL. Esa conexión en vivo hace que los paneles sean útiles, pero también crea una mayor superficie de ataque cuando los permisos, el intercambio de informes y el manejo de credenciales no se comportan como se esperaba. Tenable dice que las fallas abrieron rutas de ataque con un solo clic y sin clic, dependiendo de si un informe utilizó credenciales de propietario o credenciales de espectador.
En el centro de la investigación hay un problema simple. Looker Studio admite dos formas de acceder a los datos. Con las credenciales del propietario, los espectadores pueden ver los datos del informe mediante la autorización del propietario del informe. Con las credenciales de lector, cada persona que abra el informe debe autenticarse con su propio acceso.Documentación propia de Googleexplica claramente esa diferencia, y Tenable dice que ambos modelos crearon formas distintas de cruzar los límites de la confianza en caso de abuso.
Lo que encontraron los investigadores
Tenable dice los defectos más gravespodría permitir a los atacantes hacer más que leer la salida del panel. En varios casos, podrían inyectar SQL en consultas de backend, filtrar fuentes de datos conectadas entre inquilinos, abusar de Linking API o desencadenar actividad de denegación de billetera a través de BigQuery. El artículo de la compañía enumera nueve problemas separados y dice que el impacto general incluyó una posible filtración de datos además de operaciones de inserción, actualización y eliminación en los entornos de las víctimas.
Una ruta de ataque se centró en informes que utilizaban credenciales de propietario. En ese escenario, Tenable dice que un atacante podría elaborar solicitudes contra un informe público o compartido y obligar a Looker Studio a buscar o manipular datos utilizando la identidad del propietario. Debido a que la acción ocurrió en el lado del servidor, el propietario del informe no tuvo que hacer clic en nada. Tenable describe esto como una ruta sin clic.
Otro camino apuntaba a las credenciales de los espectadores. En esos casos, el ataque necesitaba la interacción del usuario, como abrir un informe manipulado o visitar una página maliciosa. Tenable dice que eso aún les dio a los atacantes una ruta para inyectar consultas bajo la propia identidad de la víctima, lo que luego podría exponer metadatos y datos de fuentes conectadas.
Destacó el tema de las “credenciales pegajosas”
Uno de los hallazgos más alarmantes involucró la función Copiar informe de Looker Studio. Tenable dice que cuando un espectador copia un informe conectado a ciertas fuentes de datos JDBC, incluidos PostgreSQL o MySQL, el informe clonado podría conservar las credenciales de la base de datos almacenadas del propietario original. Si eso ocurría, el atacante que creó la copia se convertía en propietario del nuevo informe y podía obtener acceso a funciones como la consulta personalizada sin conocer la contraseña de la víctima. Tenable dice que esto podría permitir acciones CRUD arbitrarias contra la base de datos conectada.
Esa afirmación se alinea con el riesgo de diseño más amplio.Google ya documenta todocredenciales del propietario. Google señala que las credenciales del propietario permiten que otros usuarios accedan a los datos utilizando la autorización del propietario de la credencial, y los administradores de Google Workspace pueden controlar si los usuarios pueden configurar fuentes de datos para las credenciales del propietario. Esa configuración existe porque el acceso basado en el propietario puede exponer más datos de los que muchas organizaciones esperan si se usa de manera demasiado amplia.
Google dice que los problemas están solucionados
Estados del boletín de seguridad en la nube de Googleque Looker Studio solucionó las vulnerabilidades reportadas a través del Programa de recompensas por vulnerabilidades de Google y Alphabet. La compañía dice que no encontró evidencia de explotación, que los problemas están resueltos y que no se requiere ninguna acción por parte del cliente. Google también dice que las fallas involucraron acceso no autorizado a datos a través de informes compartidos, fuentes de datos con credenciales de espectador, Studio Linking API y Conversational Analytics.
Esa redacción oficial es importante porque confirma tanto el alcance como el estatus. Las fallas fueron lo suficientemente graves como para merecer un boletín formal, pero Google las trata como problemas del lado del servicio totalmente solucionados. Dado que Looker Studio es un producto administrado en la nube, Google implementó las correcciones globalmente en lugar de pedir a los clientes que instalen un parche localmente.
Por qué esto es importante para los defensores
Aunque Google ya ha solucionado las vulnerabilidades, los hallazgos resaltan una lección de seguridad más amplia para las plataformas de análisis y BI. Los paneles a menudo se encuentran encima de sistemas altamente confidenciales, pero los equipos a veces los tratan como herramientas de presentación en lugar de intermediarios de datos en vivo. Cuando esos paneles dependen de credenciales almacenadas, enlaces públicos, imágenes incrustadas o API entre servicios, una pequeña falla lógica puede convertirse en un camino hacia datos de la nube que nunca debieron salir de sus límites originales. Esta es una inferencia basada en la investigación y en la documentación del modelo de credenciales de Google.
Los equipos de seguridad también deberían revisar quién puede ver, copiar y compartir informes. Google proporciona controles de administrador para restringir el uso compartido externo, controlar el uso del conector y limitar quién puede usar las credenciales del propietario. Esos controles no solucionarán un error del proveedor después del hecho, pero pueden reducir el radio de explosión cuando una falla futura afecte los flujos de trabajo de análisis compartidos.
Desglose de los nueve defectos
| ID sostenible | Problema reportado |
|---|---|
| TRA-2025-28 | Inyección SQL sin clic en conectores de bases de datos |
| TRA-2025-29 | Inyección SQL sin clic a través de credenciales almacenadas |
| TRA-2025-27 | Inyección de SQL entre inquilinos en BigQuery a través de funciones nativas |
| TRA-2025-40 | Fuga de fuente de datos entre inquilinos con hipervínculos |
| TRA-2025-38 | Inyección de SQL entre inquilinos en Spanner y BigQuery a través de consultas personalizadas |
| TRA-2025-37 | Inyección de SQL entre inquilinos en BigQuery y Spanner a través de Linking API |
| TRA-2025-30 | Fuga de fuente de datos entre inquilinos con representación de imágenes |
| TRA-2025-31 | Fuga de XS entre inquilinos con oráculos de conteo de fotogramas y sincronización |
| TRA-2025-41 | Denegación de billetera entre inquilinos a través de BigQuery |
Fuente de la tabla: divulgación de LeakyLooker de Tenable.
Qué organizaciones deberían revisar ahora
- Audite quién tiene acceso de visualización a los informes públicos y privados de Looker Studio.
- Revise si los equipos realmente necesitan credenciales de propietario en fuentes de datos compartidas.
- Restrinja el uso compartido externo y los conectores de terceros innecesarios siempre que sea posible.
- Trate los conectores de BI como parte de la superficie de ataque de producción, no solo como herramientas de generación de informes. Este punto se desprende de la investigación de Tenable.
Preguntas frecuentes
¿Looker Studio fue pirateado en la naturaleza?
Google dice que no encontró evidencia de explotación.
¿Necesitaban los clientes parchear algo ellos mismos?
No. Google dice que los problemas están resueltos y que no es necesario que el cliente realice ninguna acción.
¿Qué hizo que estos insectos fueran peligrosos?
Tenable dice que las fallas podrían permitir el acceso entre inquilinos, la ejecución arbitraria de SQL, la filtración de datos y, en algunos casos, acciones de escritura o eliminación contra fuentes de datos conectadas.
¿Qué características de Looker Studio estuvieron involucradas?
El boletín de Google señala informes compartidos, fuentes de datos con credenciales de espectador, Studio Linking API y Conversational Analytics.
¿Cuál es la lección principal aquí?
Las plataformas de análisis compartidas pueden convertirse en superficies de ataque de alto valor cuando se basan en datos de producción en vivo y dependen de un amplio intercambio de credenciales. Esa conclusión se desprende de la investigación y de la propia documentación de Google sobre modelos de credenciales.