Startup Failure & Data Security: Google Login Risks

Data Theft Risk for Former Startup Employees

The situation is already difficult when a startup fails and employees lose their jobs. Now, security research indicates that individuals formerly employed by these companies face an elevated risk of data breaches.

This potential compromise extends to sensitive information, including private Slack messages, Social Security numbers, and even potentially, personal bank account details.

Researcher Uncovers the Vulnerability

The discovery was made by Dylan Ayrey, the co-founder and CEO of Truffle Security, a startup supported by Andreessen Horowitz. Ayrey is widely recognized as the creator of TruffleHog, an open-source project designed to detect data leaks, specifically focusing on compromised credentials like API keys, passwords, and tokens.

Ayrey is gaining prominence within the bug-hunting community. He recently presented his findings at the ShmooCon security conference, detailing a flaw identified in Google OAuth, the technology powering the “Sign in with Google” feature.

Google’s Responsible Disclosure Policy

Ayrey was able to publicly discuss his research because Google permits its bug hunters to share details of discovered vulnerabilities. This contrasts with some companies, like Google’s Project Zero, which often publicly reveals flaws found in products from other tech giants, such as Microsoft Windows.

How the Exploit Works

The vulnerability allows malicious actors to gain access to cloud software by acquiring the defunct domains of failed startups. These domains can then be used to log in to applications configured to grant access to all company employees, such as chat or video conferencing platforms.

Once inside, hackers can often locate former employees’ email addresses through company directories or user information pages within these applications.

With the domain and email addresses in hand, attackers can leverage the “Sign in with Google” option to access a wide range of the startup’s cloud-based software, potentially uncovering further employee email addresses.

Proof of Concept and Potential Impact

To demonstrate the flaw, Ayrey purchased a domain from a failed startup and successfully gained access to ChatGPT, Slack, Notion, Zoom, and an HR system containing Social Security numbers.

“The biggest threat is probably the data within cloud HR systems,” Ayrey explained to TechCrunch. “This data is the easiest to monetize, and the Social Security numbers and banking information contained within are highly likely targets.”

Google has confirmed that existing Gmail accounts, Google Docs, or any data created using Google’s applications are not at risk.

Startups are Particularly Vulnerable

While any company with a domain name for sale could be affected, startup employees are at a higher risk due to their frequent reliance on Google’s applications and a broad range of cloud-based software solutions.

Ayrey estimates that tens of thousands of former employees and millions of SaaS software accounts are potentially vulnerable. This assessment is based on his research, which identified 116,000 website domains currently available for sale from defunct tech startups.

Mitigation Exists, Though Not Flawless

Google possesses technology within its OAuth setup designed to mitigate the vulnerabilities detailed by Ayrey, provided the SaaS cloud provider implements it. This feature is known as a “sub-identifier,” a unique numerical string assigned to each Google account. A single Google account should consistently have only one sub-identifier, regardless of the number of email addresses associated with it.

When an employee attempts to access cloud software via OAuth, Google transmits both the email address and the sub-identifier for user identification, assuming it's configured correctly. Consequently, even if attackers successfully duplicate email addresses with domain control, replicating these unique identifiers should prove impossible.

The Reliability Concern

However, Ayrey’s investigation with a specific affected SaaS HR provider revealed the sub-identifier to be “unreliable.” The HR provider observed instances where the identifier changed, albeit in a small proportion of cases – 0.04%.

While seemingly negligible, this percentage translates to hundreds of login failures weekly for an HR provider managing a large user base, resulting in account lockouts. This is the primary reason the cloud provider opted against utilizing Google’s sub-identifier, according to Ayrey.

Google maintains that the sub-identifier remains constant and never changes. This observation originated with the HR cloud provider, not the researcher, and therefore wasn’t included in the initial bug report submitted to Google.

Google has stated that should evidence of sub-identifier unreliability emerge, they will promptly investigate and resolve the issue.

Google's Shifting Stance on a Security Issue

Initially, Google reversed its position regarding the significance of a reported issue. The company first disregarded a bug reported by Ayrey, swiftly closing the associated ticket and classifying it as a case of “fraud” rather than a technical flaw. This assessment wasn't entirely inaccurate, as the vulnerability stems from compromised domains and the malicious reuse of email accounts.

Ayrey acknowledged the validity of Google’s initial response, characterizing the situation as a data privacy concern where the OAuth software functioned as designed, despite potential user harm. He noted that the situation wasn’t straightforward.

However, a change occurred three months later, coinciding with the acceptance of his presentation at ShmooCon. Google reopened the ticket and awarded Ayrey a bounty of $1,337. A comparable scenario unfolded in 2021 when Google revisited his report following a highly-attended talk at the Black Hat cybersecurity conference.

Subsequently, Google recognized Ayrey and his colleague, Allison Donovan, with third prize in its annual security researcher awards, accompanied by a $73,331 prize.

Currently, Google has not released a technical solution for this vulnerability, nor has it provided a timeframe for potential implementation. It remains uncertain whether Google will ultimately implement a technical modification to address the issue.

The company has, however, revised its documentation to advise cloud providers to utilize the sub-identifier. Google also provides guidance to company founders on the correct procedures for decommissioning Google Workspace and mitigating the problem.

Google maintains that the primary solution lies with founders who are closing businesses, ensuring they properly terminate all associated cloud services. A spokesperson stated, “We appreciate Dylan Ayrey’s help identifying the risks stemming from customers forgetting to delete third-party SaaS services as part of turning down their operation.”

Ayrey, having experience as a founder himself, recognizes the challenges many face in ensuring complete cloud service deactivation. The process of shutting down a company is complex, often occurring during a difficult emotional period.

This process involves numerous tasks, including the disposal of company hardware, the closure of financial accounts, and the fulfillment of tax obligations. “When the founder has to deal with shutting the company down, they’re probably not in a great head space to be able to think about all the things they need to be thinking about,” Ayrey explained.