Tenable Uncovers ‘LeakyLooker’ Flaws Turning Google Looker Studio into a Cloud Backdoor

Business Intelligence (BI) tools are often viewed as “polished mirrors reflecting an organization’s data in beautiful, actionable charts”. However, a groundbreaking investigation by Tenable Senior Security Researcher Liv Matan has revealed that these mirrors could be turned into windows for attackers. Dubbed “LeakyLooker,” this set of nine novel cross-tenant vulnerabilities broke the fundamental promise of the platform: “that a ‘viewer’ should never be able to control, modify nor exfiltrate the data they are viewing”.

The vulnerabilities, which Google has since remediated, exposed sensitive data across Google Cloud Platform (GCP) environments, potentially affecting any organization using BigQuery, Google Sheets, Spanner, PostgreSQL, and more.

To understand the gravity of LeakyLooker, one must look at how Looker Studio handles “trust”. The platform relies on two primary credential models:

• Owner Credentials: The report uses the owner’s permissions to fetch data, allowing them to share insights with others who don’t have direct database access.
• Viewer Credentials: The report uses the viewer’s own permissions, ensuring they only see what they are explicitly allowed to see.

Tenable’s research revealed that these two paths created “two very different ‘trust boundaries’ that can be attacked independently”.

The LeakyLooker cluster introduced a new class of attacks that could exfiltrate, insert, or even delete data in a victim’s environment.

By targeting owner credentials, researchers found they could talk directly to the backend of a report.

“By sending a crafted request to a public report or a shared report, the attacker triggers the Looker Studio service to fetch or manipulate data using the owner’s identity,” Liv warns.

One such flaw, Alias Injection, abused the way Looker Studio generates unique column aliases. By “breaking out” of these user-controlled strings using SQL comments (/**/), researchers bypassed filters to run arbitrary SQL queries across an owner’s entire GCP project without the victim ever clicking a link.

The research also exploited Looker Studio’s “live data” feature, where the platform acts as a proxy, translating browser requests into real-time SQL queries. One vulnerability utilized Native Functions (NATIVE_DIMENSION) to execute custom SQL on a report load. By sharing a malicious report with a victim, the victim would unknowingly “execute our malicious SQL while viewing and loading the shared report… without even noticing”.

Perhaps the most ingenious part of the research was the “ping” mechanism for stealing data. Because attackers couldn’t directly insert stolen data into their own tables without permission, they used cross-tenant log analysis.

1. The attacker creates empty, public BigQuery tables named after every possible character (e.g., exfil-a, exfil-l).
2. When the injected script finds a character in the victim’s data, it attempts to read from the corresponding attacker table.
3. “By monitoring these logs and piecing together the sequence of table accesses, we could reconstruct the victim’s data”.

The reality uncovered by Tenable is that “one of the world’s most widely deployed BI platforms could have become a stealthy entry point into the heart of your cloud infrastructure”. While Google has patched these issues globally and no user action is required, the research serves as a stark reminder for organizations.

Administrators should always “audit who has ‘View’ access to your reports,” treat BI connectors as a critical part of the attack surface, and “do not allow the service to access a connector you do not use anymore”.