Google Give Me Vulnz - Cameron Vincent

Google Give Me Vulnz - Cameron Vincent

Speakers: Cameron Vincent, Vulnerability and Mitigations Team, Microsoft Security Response Center (MSRC)

Conference: Nullcon

YouTube: https://www.youtube.com/watch?v=aTmIqV2W6cI

Overview

This talk, "Google Give Me Vulnz," presented by Cameron Vincent, delves into the pervasive and often underestimated vulnerability class of Insecure Direct Object Reference (IDOR), showcasing its critical impact across major Google products like Google Workspace and Google Ads. Vincent, a former top-ranked Google bug bounty hunter, shares his firsthand experiences and detailed methodologies for uncovering these authorization flaws, emphasizing that IDOR is not unique to Google but a widespread issue affecting the entire infosec ecosystem.

The presentation serves as a stark reminder that fundamental security principles, particularly robust authorization checks, remain paramount in web application and API design. Vincent meticulously breaks down several high-impact IDOR vulnerabilities he discovered, demonstrating how simple manipulation of object IDs in requests could lead to unauthorized access to sensitive administrative panels, the leakage of private organizational data, and even the potential for devastating supply chain attacks.

The talk is crucial for developers, security engineers, and bug bounty hunters alike, offering practical insights into identifying and mitigating IDORs. It highlights the importance of manual security testing, the critical role of tools like Burp Suite, and the severe consequences when applications fail to enforce proper access control at every interaction point, regardless of the perceived "guessability" of an object ID.

Background

▶ Watch: Talk introduction and conference welcome (0:00)

Cameron Vincent, a member of the Vulnerability and Mitigations Team at the Microsoft Security Response Center (MSRC), brings a wealth of experience to the stage. His team is responsible for reviewing incoming security reports from external researchers and conducting their own internal research, with Vincent personally focusing on authorization-related bugs. Prior to his role at MSRC, he spent six years as a full-time bug bounty hunter, achieving the prestigious rank of the number one researcher on Google's bug bounty program in 2019. This extensive background provided him with deep insights into common vulnerability patterns, particularly IDOR.

Insecure Direct Object Reference (IDOR) is a type of Broken Access Control vulnerability, listed in the OWASP Top 10. Vincent explains IDOR with a straightforward example: imagine accessing your medical records on a website, where the URL contains an ID like 12345. If changing this ID to 123456789 allows you to view someone else's medical records, that's an IDOR. It essentially means that an application exposes a direct reference to an internal implementation object, such as a file, directory, database record, or key, and fails to verify that the user is authorized to access the referenced object.

Vincent's statistics underscore the prevalence of IDORs: out of 175 valid submissions to Google's bug bounty program, an astonishing 160 were classified as IDOR vulnerabilities. This isn't just a Google-specific issue; Broken Access Control has consistently ranked high in the OWASP Top 10, reaching number one in 2021, indicating its widespread impact across web applications and APIs globally.

To identify these vulnerabilities, Vincent primarily relied on Burp Suite, a popular web application security testing tool. He explains Burp Suite's function as an intermediary proxy, allowing security researchers to intercept, view, and manipulate raw HTTP requests and responses between a browser and a server. The Repeater tab within Burp Suite becomes a critical tool for modifying requests and re-sending them to test for vulnerabilities like IDOR. Vincent emphasizes that his research was predominantly manual, without the use of automated extensions, highlighting the value of meticulous, hands-on analysis.

The targets of his research were two prominent Google products: Google Ads and Google Workspace (formerly known as G Suite). Google Workspace is a comprehensive collaboration environment, allowing organizations to manage users, groups, devices, and services like Gmail, Calendar, and Google Docs under a custom domain. A key feature, announced in 2018, allowed Workspace administrators to publish private applications to their organization, which users could then download or have force-installed on their Android or Chrome devices. This feature integrated with the Google Play Console, which is the platform for publishing and managing apps on the Google Play Store. Google Ads, on the other hand, is Google's advertising platform, enabling businesses to promote their websites, videos, and products across Google's network, featuring tools for managing campaigns, budgets, and bulk uploads.

Key Findings

▶ Watch: Introduction to Insecure Direct Object Reference (IDOR) (4:00)

Cameron Vincent's research uncovered several critical IDOR vulnerabilities across Google Workspace and Google Ads, demonstrating the severe impact of broken access control. The key findings include:

1. Unauthorized Access to Google Workspace Play Store Admin Panels: It was possible to gain full administrative access to any Google Workspace organization's private Play Store admin panel. This allowed an attacker to manage, edit, and release new versions of internal applications published by other organizations.
2. Leakage of Google Workspace Email Subject Logs: An IDOR vulnerability enabled attackers to configure their own Google Cloud BigQuery project to receive the Gmail subject logs and metadata for any Google Workspace organization, effectively siphoning off sensitive communication data.
3. Unauthorized Access and Leakage of Google Ads Uploaded Files: Attackers could load and view the entire file upload history, including details of files, for any Google Ads account. This exposed sensitive campaign-related documents and data.
4. Re-leakage of Google Ads Uploaded Files via New API: After the initial fix for the file leakage bug in Google Ads, a newly introduced API for downloading files was also found to be vulnerable. This allowed direct download of any file from any Google Ads account by manipulating file and customer IDs in a direct URL.

Technical Deep Dive

▶ Watch: IDOR's high prevalence in Google bug bounty findings (5:30)

Vincent's presentation meticulously detailed four distinct IDOR vulnerabilities, each stemming from a failure to properly validate user authorization against requested object IDs.

Bug 1: Unauthorized Access to Google Workspace Play Store Admin Panels

This vulnerability exploited the feature allowing Google Workspace administrators to publish private apps for their organization. When an admin would navigate to their "publish private apps" or "manage private apps" UI, a POST request would be sent. This request contained an ID parameter, which represented the Google Workspace organization ID.

The core of the vulnerability was that the server-side logic failed to verify if the authenticated user was indeed an administrator of the organization corresponding to the ID in the request. By intercepting this POST request using Burp Suite and changing the organization ID to that of any other Google Workspace organization, an attacker could generate a valid access token. This token would then allow the attacker to log directly into the target organization's private Play Store admin panel. Once inside, the attacker could view, edit, and even release new versions of the target organization's internal applications. Vincent highlighted the profound supply chain attack implications here: an attacker could replace a legitimate internal HR or grade-viewing application with a malicious version, which would then be pushed out and downloaded onto employees' or students' devices within the compromised organization.

Bug 2: Leakage of Google Workspace Email Subject Logs

This IDOR targeted Google Workspace's feature for storing Gmail logs (including subject lines, timestamps, and other metadata) within a BigQuery project. To enable this feature, an administrator would configure their settings, associating a Google Cloud project and a data set name (e.g., "Gmail logs") with their Workspace organization.

When an admin clicked "save" to enable or modify these log settings, a POST request to /gmail/admin/settings would be sent. Crucially, this request included a customer ID parameter corresponding to the Google Workspace organization. Similar to the first bug, the server did not adequately verify that the authenticated user was authorized to modify the settings for the customer ID provided. An attacker could intercept their own "save settings" request, change the customer ID to that of any other Google Workspace organization, and then send the modified request. This action would effectively "save" the attacker's BigQuery project settings onto the target organization's configuration. As a result, all subsequent Gmail subject logs from the victim organization would begin streaming into the attacker's designated Google Cloud BigQuery project, providing a continuous stream of sensitive communication metadata.

Bug 3: Unauthorized Access and Leakage of Google Ads Uploaded Files

Google Ads incorporates a bulk upload feature that allows users to manage multiple campaigns by uploading pre-created templates (e.g., to pause 100 campaigns at once). When a user would access their "file history" or "upload history" to view previously uploaded files, two requests were typically sent: a POST request to a bulk execution service and a subsequent request to an execution Detail Service.

The bulk execution service POST request, responsible for loading the list of files, contained an ID parameter representing the user's Google Ads account ID. By intercepting this request and substituting the attacker's account ID with any other Google Ads account ID, the attacker could force the service to return the file upload history of the target account. This allowed the attacker to view all files uploaded by the victim, potentially exposing sensitive campaign strategies, targeting data, or even financial information. Vincent also mentioned that it was initially possible to upload files to other accounts, but this was less severe due to an "approval process" where an admin had to manually approve the changes before they were executed.

Bug 4: Re-leakage of Google Ads Uploaded Files via New API

Following the fix for Bug 3, Google introduced a new API endpoint specifically for downloading files from Google Ads accounts. This new API was accessed via a direct URL, which contained two critical parameters: X ID (the ID of the specific file) and operating customer ID (the ID of the user who owned that file).

This new API, despite being implemented after a previous IDOR fix, still suffered from a lack of proper authorization. If an attacker could obtain or guess a valid X ID for a file and the operating customer ID for its owner (which, for Google Ads, were often numeric and somewhat guessable, although longer than Workspace IDs), they could construct a direct URL to download the file. This meant that simply navigating to the crafted URL would initiate the download of the target user's file, bypassing any authorization checks. Vincent stressed that while the entropy of these IDs (their length and randomness) might make them harder to guess, an ID, regardless of its complexity, is never a security boundary. Proper authorization checks are always required when accessing personal data or information.

Demo / Proof of Concept

▶ Watch: IDOR as a top OWASP Broken Access Control issue (6:00)

Cameron Vincent provided a clear video demonstration of the first vulnerability: unauthorized access to a Google Workspace organization's Play Store admin panel. The demonstration unfolded as follows:

1. Target Setup: Vincent first showed a legitimate Google Workspace administrator (the "target") logged into their account. The target navigated to their private apps admin panel, where an internal application, humorously named "gfh" (a result of Vincent's keyboard spamming during testing), was visible. This represented a typical scenario where an organization would publish its custom internal tools. The target's interaction generated the crucial POST request that contained their organization's ID.
2. Attacker Setup: Next, an attacker's Google Workspace account was shown. This attacker's private apps admin panel was empty, indicating no apps had been published by their organization.
3. Exploitation: The attacker, using Burp Suite, intercepted the target's POST request that was sent when the target initially opened their apps admin panel. From this request, the attacker extracted the target organization's unique ID. The attacker then went to their own Burp Suite, where they had captured a similar POST request from their own attempt to access the private apps panel. The attacker replaced their own organization ID in the request body with the target's ID.
4. Unauthorized Access: Upon sending this modified request, the attacker's browser successfully loaded the target's private apps admin panel. The attacker could now see the "gfh" app, which was originally only visible and manageable by the target organization's administrator.
5. Impact Demonstration: To illustrate the critical impact, the attacker then proceeded to "edit" the "gfh" app. They changed its title from "gfh" to "gfh test" (simulating a change to the underlying APK file). This modification was saved.
6. Verification: Finally, the target administrator refreshed their Google Workspace page. When they reopened their private apps admin panel, the app's name had been updated to "gfh test." This concrete demonstration showed how an attacker could not only view but also modify and potentially inject malicious code into applications used by an entirely different organization, highlighting the severe supply chain attack implications.

Defensive Implications

▶ Watch: Using Burp Suite for web application security testing (6:45)

The IDOR vulnerabilities exposed by Cameron Vincent underscore fundamental security principles that developers and security teams must rigorously uphold to protect applications and user data.

1. Strict Server-Side Authorization Checks: This is the paramount defense against IDOR. Every single request that accesses, modifies, or deletes an object (whether it's an organization ID, a file ID, or a customer ID) must include a robust server-side check to ensure that the authenticated user is explicitly authorized to perform that specific action on that specific object. Relying solely on client-side controls or the obscurity of an ID is insufficient and leads directly to IDORs.
2. Never Trust Client-Side Input for Authorization: As demonstrated, attackers can easily manipulate IDs sent from the client. The server must never assume that an ID provided in a request belongs to the authenticated user without explicit verification. The user's session should be tied to their authorized resources, and any request for a resource must check if the session's user has permission to access that particular resource.
3. Implement Centralized Access Control: Instead of scattering authorization logic throughout the codebase, implement a centralized access control mechanism. This makes it easier to enforce consistent rules, audit permissions, and prevent authorization bypasses. Frameworks or libraries specifically designed for access control can be invaluable.
4. Avoid Guessable or Sequential IDs: While not a security boundary, using high-entropy, cryptographically secure random IDs (e.g., UUIDs) instead of sequential or easily guessable numeric IDs can make it significantly harder for attackers to enumerate and test for IDORs. This increases the "work factor" for an attacker, even if the underlying authorization flaw still exists.
5. Thorough API Security Testing: New API endpoints, especially those handling file uploads, downloads, or administrative settings, are prime targets for IDORs. These endpoints must undergo rigorous security testing, including manual penetration testing and automated dynamic application security testing (DAST), specifically looking for authorization bypasses by manipulating object references.
6. Secure Supply Chain Management: For platforms that allow organizations to distribute private applications (like Google Workspace's private Play Store), robust checks are essential to prevent malicious updates. Organizations using such platforms should also implement their own internal verification processes for app updates, even from trusted sources, if feasible.
7. Isolate Organizational Data: In multi-tenant environments (like Google Workspace), it is critical to ensure that data and resources belonging to one organization are strictly isolated from others. This means that an ID from one tenant should never grant access to another tenant's resources without explicit, cross-tenant authorization.
8. Ethical Hacking Practices: For security researchers, it's crucial to follow coordinated vulnerability disclosure (CVD) and always perform testing on accounts and resources that you own or have explicit permission to test. This prevents accidental harm and maintains the integrity of bug bounty programs.

Key Takeaways

• IDOR is a Pervasive and Critical Vulnerability: Insecure Direct Object Reference (IDOR) remains a top concern, consistently ranking high in the OWASP Top 10, demonstrating its widespread presence and significant impact across web applications and APIs.
• Authorization is Non-Negotiable: The fundamental defense against IDOR is strict, server-side authorization. Every request to access or modify a resource must verify that the authenticated user has explicit permission for that specific object, not just that they are logged in.
• IDs Are Not Security Boundaries: The complexity, length, or randomness of an ID does not make it a security control. While high-entropy IDs can increase the difficulty of exploitation, they do not negate the need for proper authorization checks.
• Manual Security Testing Remains Essential: Despite advancements in automated tools, Cameron Vincent's success highlights that meticulous manual hunting, particularly with tools like Burp Suite, is still incredibly effective at uncovering complex authorization flaws that automated scanners might miss.
• Supply Chain Attacks Are a Major Risk: IDORs in platforms that distribute internal applications can lead to devastating supply chain attacks, allowing attackers to inject malicious code into trusted software used by entire organizations.
• Impact on Sensitive Data and Operations: IDOR vulnerabilities can lead to unauthorized administrative access, sensitive data leakage (e.g., email subject logs, private files), and the ability to tamper with critical organizational operations (e.g., managing ads, deploying applications).

About the Speaker(s)

Cameron Vincent is a prominent security researcher currently working on the Vulnerability and Mitigations Team within the Microsoft Security Response Center (MSRC). In this role, he is involved in two primary areas: reviewing and triaging incoming vulnerability reports from external security researchers, and conducting his own internal research projects, with a particular focus on authorization and access control bugs.

Before joining MSRC, Vincent dedicated approximately six years to full-time bug bounty hunting. His expertise and consistent success in identifying critical vulnerabilities were recognized when he was ranked as the number one researcher on Google's bug bounty program in 2019. His extensive experience as a bug bounty hunter has given him a deep understanding of common vulnerability patterns and effective methodologies for uncovering them, especially in complex web applications and APIs.