Full Report
OAuth is a common way that websites do authentication. Google OAuth is a identity provider that websites can use to not handle usernames, passwords and such. When you click the Sign in with Google button, Google sends the application a set of cryptographically information about the user in a JWT. Of these fields, is the hd (hosted domain) and email. The application would verify both of these claims to be correct before logging in. Here's an interesting question: what happens when the domain is owned by somebody different? Apparently, there is no verification on then. The sub field could be used for this but it's inherently unreliable on Google OAuth for some reason. By purchasing the domain of an old startup, it's possible to login to these other accounts. You can't see old emails in Google workspace but you can access accounts from previous employees. Initially, Google decided to not fix the issue. They categorized this as an abuse issue. After the talk got accepted to ShmooCon, they decided to pay $1,337 for the bug. They rated this as low likelihood and high impact, which I think is a fair assessment. They claimed they are working on a fix but nothing has been shared yet. The author brings up a good point about password resets. If an attacker controls the email then they could reset the password on an account as well. Unless the only 2FA is on the email, this will not work because of things like Google Authenicator and SMS 2FA. To me, they try to hype up the numbers a little much. They claim millions of accounts but are making assumptions about A) the amount of startups that use Google workspaces, B) each has 10 employee, and C) each has 10 accounts. Although it's technically correct, it feels overhyped. Alongside this, who cares about data of old startups? Not many people. Regardless, it was a cool bug and I appreciated the write up.
Analysis Summary
# Vulnerability: Domain Hijacking via Unverified Google OAuth Claims
## CVE Details
- CVE ID: Not specified in the source material.
- CVSS Score: Not specified in the source material. (Author assessed as low likelihood, high impact).
- CWE: Likely related to CWE-287: Improper Authentication or CWE-613: Insufficient Session Expiration, depending on the downstream application's reliance on the claims.
## Affected Systems
- Products: Downstream applications and SaaS platforms utilizing Google OAuth for login that verify the `hd` (hosted domain) and/or `email` claims without robust, unique cross-referencing or verification mechanisms. Examples mentioned include ChatGPT, Slack, Notion, Zoom, and various HR systems utilizing Google Workspaces for identity.
- Versions: Not specified, presumed to affect any configuration relying solely on unverifiable `hd` and `email` claims from Google OAuth ID Tokens.
- Configurations: Applications configured to trust the `hd` (hosted domain) and/or `email` claims within the JWT to authorize access to organization-specific resources, without sufficient reliance on the immutable `sub` claim or other unique identifiers.
## Vulnerability Description
This vulnerability arises from a design deficiency or inadequate implementation on the consumer side of Google's OAuth flow. When an identity provider (Google) issues an ID token (JWT) during a "Sign in with Google" event, it includes claims like `hd` (hosted domain) and `email`. If a domain associated with a defunct startup is subsequently purchased by an attacker, and consumer applications rely only on these claims to grant access to their resources (e.g., a company Slack workspace), the attacker can impersonate former employees of that company. This is possible because Google may still issue an ID token containing the newly acquired domain in the `hd` claim, and the downstream application fails to verify that the associated user identity (`sub`) has not fundamentally changed ownership or context. The reliance on the `sub` claim is noted as unreliable by some parties, forcing dependency on the potentially mutable `hd`/`email` pair.
## Exploitation
- Status: Proof-of-Concept (PoC) demonstrated by the researcher (successful account takeover after purchasing a defunct domain).
- Complexity: Low, assuming the attacker can acquire a relevant, expired domain name.
- Attack Vector: Network (remote exploitation via the standard OAuth flow).
## Impact
- Confidentiality: High (Access to sensitive data in platforms like HR systems, chat logs, internal documents, etc., potentially including SSNs, tax documents).
- Integrity: High (Ability to modify data or perform actions within the compromised accounts).
- Availability: Low to Medium (Depends on the specific service; primary impact is on confidentiality and integrity).
## Remediation
### Patches
- Google is reportedly working on a fix, potentially involving the introduction of immutable OIDC claims (a unique, unchanging user ID and a unique workspace ID tied to the domain). No specific patch version or timeline was provided.
### Workarounds
- **Downstream Application Configuration:** Rely strongly on the `sub` (subject identifier) claim, despite its noted inconsistencies, or mandate a secondary verification factor tied uniquely to the account lifecycle rather than the domain.
- **Require Immutable Identifiers:** OAuth consumers should ideally require an immutable user ID identifier from Google that does not change across logins, and potentially a unique workspace ID, to confirm the user's identity remains consistent, irrespective of domain registration status.
- **Password Reset Mitigation:** While password resets could be performed if the attacker controls the email/domain, most services likely require 2FA (like Google Authenticator or SMS) beyond email access, mitigating full account takeover via password reset if strong 2FA is enforced by the downstream application.
## Detection
- Indicators of Compromise: Unexpected geographic or time-of-day logins associated with newly created accounts that utilize previously inactive or expired corporate domains via Google OAuth. Changes in organizational membership signaled via Google Workspace logs that don't align with known HR processes.
- Detection methods and tools: Monitoring application access logs specifically for sessions initiated via Google OAuth where the `hd` claim changes context unexpectedly, especially in conjunction with attempts to access highly sensitive organizational data.
## References
- Vendor Advisories: Google acknowledged the issue and paid a bounty; official advisory pending.
- Relevant links:
- ShmooCon presentation details (implied): `https://www.shmoocon.org/speakers/#millionaccounts` (Defanged)