The collapse of a startup can be challenging, but security researchers have discovered that employees of failed startups face an increased risk of data theft. This includes sensitive information such as private Slack messages, Social Security numbers, and potentially bank account details.
The researcher, Dylan Ayrey, serves as the co-founder and CEO of Truffle Security, a startup financed by Andreessen Horowitz. He is widely recognised as the developer of TruffleHog, an open-source project designed to monitor data leaks and protect against identity compromise through stolen login credentials (for instance, API keys, passwords, and tokens).
Ayrey is rapidly gaining prominence in the bug-hunting community. Recently, at ShmooCon security conference, he presented on a vulnerability he identified within Google OAuth—the technology that enables users to “Sign in with Google” as an alternative to traditional passwords.
His presentation followed his report of the vulnerability to Google and other potentially affected companies. Ayrey was permitted to discuss the details because Google encourages its bug hunters to share their findings. For instance, Google’s Project Zero routinely highlights flaws discovered in other tech giants’ products, such as Microsoft Windows.
Ayrey found that if malicious actors acquired the expired domains of bankrupt startups, they could use those domains to gain access to cloud software that allowed all employees access, such as company chat or video conferencing applications. Many of these services often feature company directories or user information pages, where hackers could uncover former employees’ actual email addresses.
With control of the domain and access to emails, hackers could exploit the “Sign in with Google” functionality to access various cloud applications linked to the startup, potentially uncovering additional employee email addresses.
To test the identified vulnerability, Ayrey purchased the domain of a defunct startup and successfully logged into ChatGPT, Slack, Notion, Zoom, and an HR system that contained Social Security numbers.
Ayrey highlighted the gravity of the situation, stating that data from a cloud-based HR system presents “the greatest threat” as it is the simplest for hackers to monetise. He noted that information, such as Social Security numbers and banking details, is likely to be targeted. He assured that legacy Gmail accounts or Google Docs created by employees, along with any data generated within Google’s applications, remain secure, with Google confirming this information.
While the risk exists for any failed company with a domain available for sale, startup employees are particularly exposed. This vulnerability arises because startups frequently utilise Google’s applications and various cloud software for their operations.
Based on his research identifying 116,000 domains currently for sale from defunct tech startups, Ayrey estimates that tens of thousands of former employees, as well as millions of software-as-a-service (SaaS) accounts, are at risk.
Prevention Measures Available but Not Infalible
Google possesses technology within its OAuth configuration designed to mitigate the risks highlighted by Ayrey, provided that the SaaS cloud provider implements it correctly. This technology is referred to as a “sub-identifier,” a unique series of numbers assigned to each Google account. Although employees may associate multiple email addresses with their work Google account, there should only be one sub-identifier per account.
If implemented properly, when an employee attempts to log into a cloud application using OAuth, Google dispatches both the email address and the sub-identifier for identification. As a result, even if hackers create email addresses using the domain, they would not be able to reproduce these identifiers.
However, Ayrey, in collaboration with an impacted SaaS HR provider, found that this identifier was “unreliable.” The HR provider noted that it changed in a minimal fraction of cases: 0.04%. While this figure may seem statistically insignificant, for an HR provider managing vast numbers of daily users, it accumulates to hundreds of failed login attempts weekly, resulting in users being locked out of their accounts. Consequently, the cloud provider opted not to utilise Google’s sub-identifier, according to Ayrey.
Google contests that the sub-identifier is consistently stable. As this information originated from the HR cloud provider rather than Ayrey, it was not included in the bug report submitted to Google. The company stated that should it encounter evidence suggesting the sub-identifier is unreliable, it will take corrective action.
Google Reevaluates Its Position
Initially, Google downplayed the significance of this issue, promptly closing the ticket and labelling it a “fraud” concern rather than a bug. While Google’s stance contained some merit, the risk arises from hackers exploiting domains and misusing email accounts they recreate. Ayrey did not take issue with Google’s initial assessment, acknowledging it as a data privacy matter where the OAuth software functioned as designed, even though users could still face repercussions. He remarked that the situation was not straightforward.
However, three months later, following the acceptance of his talk at ShmooCon, Google reversed its decision, re-opening the ticket and awarding Ayrey a bounty of $1,337. A similar scenario occurred in 2021 when Google reopened a ticket after Ayrey delivered a highly regarded presentation about his findings at the Black Hat cybersecurity conference. Google further recognised both Ayrey and his fellow researcher Allison Donovan with third prize in its annual security researcher awards (along with $73,331).
Currently, Google has not issued a technical resolution for the vulnerability nor provided a timeline for its potential remediation, leaving it uncertain whether a technical amendment will ever occur. However, the company has updated its documentation to advise cloud providers on the utilisation of the sub-identifier. Furthermore, Google offers guidelines for founders on how to appropriately disable Google Workspace and avert the issue.
Ultimately, Google asserts that it is the responsibility of founders closing their companies to ensure that all cloud services are properly deactivated. A company spokesperson acknowledged Ayrey’s contributions in identifying risks associated with customers neglecting to terminate third-party SaaS services when dissolving their operations.
Ayrey, being a founder himself, understands why many founders may forget to disable their cloud services. The process of closing a company is intricate and typically unfolds during an emotionally taxing period—encompassing various tasks from disposing of employee computers to closing bank accounts and settling tax obligations.
Ayrey highlighted that when founders navigate the challenges of winding down a business, they are often in a difficult mental state to consider all the necessary actions required.
