LeakyLooker Exploits: Defending Google Looker Studio Against Cross-Tenant SQL Attacks

In the modern SaaS ecosystem, the boundaries between "trusted" business intelligence tools and critical infrastructure are often blurred. We routinely authorize visualization platforms to query our most sensitive databases, assuming the tenant isolation model holds firm. However, the recent disclosure of the "LeakyLooker" vulnerabilities by researchers at Tenable shatters that assumption, revealing a chink in the armor of Google Looker Studio that could have allowed attackers to pivot across environments and execute arbitrary SQL queries.

Introduction

Business Intelligence (BI) tools are the eyes of the organization, aggregating data to drive decision-making. But what happens when those eyes are used to spy on you? The "LeakyLooker" research details nine distinct cross-tenant vulnerabilities in Google Looker Studio. In essence, these flaws provided a mechanism for an attacker to escape their own isolated environment and execute SQL commands against the databases of entirely unrelated victims within the Google Cloud ecosystem. While Google has patched these issues following responsible disclosure, the incident serves as a critical reminder: the integrity of our data relies not just on the database itself, but on every tool granted permission to touch it.

Analysis: Breaking the Tenant Barrier

The "LeakyLooker" vulnerabilities are not simple SQL injection flaws in the traditional sense. Instead, they represent a complex chain of logic errors and improper access controls within the Looker Studio connector ecosystem. By exploiting these flaws, an attacker could manipulate the connection parameters between Looker Studio and a victim's Google Cloud SQL instance.

The attack vector generally follows this progression:

1. Initialization: The attacker creates a Looker Studio report configured to connect to a database they control (or a benign public data source).
2. Manipulation: Through specific API calls or parameter tampering exploiting the disclosed vulnerabilities, the attacker alters the backend resource references of the report.
3. Cross-Tenant Access: The manipulated connection attempts to authenticate or query a target Cloud SQL instance belonging to a different organization (the victim).
4. Execution: Due to the specific nature of the flaws, Looker Studio's backend service would validate the request against the victim's credentials or implicit permissions, allowing the attacker to inject arbitrary SQL.

This is particularly dangerous because it bypasses standard perimeter defenses. The attack originates from a trusted Google service IP, effectively bypassing IP-based allowlists. The traffic looks like legitimate BI usage, making it incredibly difficult to detect with conventional network monitoring.

TTPs (Tactics, Techniques, and Procedures)

• Initial Access: Compromise of a Google Workspace account or utilization of a free Looker Studio account to access the vulnerable interface.
• Execution: Use of Looker Studio connector APIs to send unauthorized SQL payloads (SELECT, INSERT, UPDATE, DELETE) to Cloud SQL databases.
• Exfiltration: Leveraging the visualization rendering engine to capture query results and display them within the attacker's controlled dashboard interface.

Detection and Threat Hunting

Detecting this type of activity requires a shift from network-based monitoring to identity and audit log analysis. You must hunt for anomalies in who is querying your data and which applications are initiating those connections.

1. Google Cloud Audit Log Hunting (Bash)

Security teams should immediately query their Cloud Audit Logs for Looker Studio service agents accessing SQL instances. The following gcloud command helps identify access attempts made by Looker Studio's infrastructure, allowing you to cross-reference them with authorized reports.

gcloud logging read \n  'protoPayload.authenticationInfo.principalEmail:"lookerstudio.googleusercontent.com" \n  AND protoPayload.methodName:"cloudsql.instances.connect" \n  AND protoPayload.resourceName:"projects/YOUR_PROJECT_ID"' \n  --format="table(timestamp,protoPayload.authenticationInfo.principalEmail,protoPayload.methodName,protoPayload.resourceName)" \n  --project=YOUR_PROJECT_ID

2. Microsoft Sentinel / Azure Defender KQL

If you are forwarding Google Cloud logs to Microsoft Sentinel, use the following KQL query to detect SQL connections initiated by Looker Studio. Note any activity originating from Looker Studio where the Report ID or User is not recognized or whitelisted.

GoogleCloudAuditLogs
| where ServiceName == "cloudsql.googleapis.com"
| where Method in ("cloudsql.instances.connect", "cloudsql.instances.get")
| extend LookerPrincipal = tostring(AuthenticationInfo.principalEmail)
| where LookerPrincipal contains "lookerstudio.googleusercontent.com"
| extend ReportID = extract("@(reports/[^/]+)", 0, tostring(ResourceLabels.report_id))
| project Timestamp, AuthenticationInfo.principalEmail, LookerPrincipal, Method, ResourceName, ReportID
| order by Timestamp desc

Mitigation

While Google has addressed these specific vulnerabilities, the underlying risk of SaaS-to-Database connectivity remains. Security Arsenal recommends the following immediate and long-term actions:

1. Implement Cloud SQL IAM Authorization: Do not rely solely on self-signed certificates or password authentication. Use Cloud SQL's IAM authentication feature. This allows you to explicitly define which Google Workspace accounts or service accounts (including Looker Studio service agents) are permitted to connect to a specific database instance.

2. Enforce VPC Service Controls: Use VPC Service Controls to create a security perimeter around your Google Cloud resources. This allows you to prevent Looker Studio (or any other external service) from accessing your Cloud SQL instances unless the traffic is explicitly allowed via an ingress rule, effectively mitigating cross-tenant data exfiltration risks.

3. Review Authorized Looker Studio Reports: Audit your Google Cloud SQL instance configurations to identify which Looker Studio reports have been granted access. Revoke any legacy or unknown connections.

4. Database-Level Least Privilege: Ensure the database users configured for Looker Studio connectors have strictly limited permissions (e.g., SELECT only on specific views) and never DROP or UPDATE privileges unless absolutely necessary.

Related Resources

Security Arsenal Alert Triage Automation AlertMonitor Platform Book a SOC Assessment platform Intel Hub