'GhostToken' Opens Google Accounts to Permanent Infection

A security vulnerability in Google’s Cloud Platform (GCP) could have allowed cyberattackers to hide an unremovable, malicious application inside a victim’s Google account, dooming the account to a state of permanent, undetectable infection.

The bug, dubbed “GhostToken,” was discovered and reported by Astrix Security researchers. According to an analysis released by the team on April 20, the malicious app could have paved the way for a startling array of nefarious activity, including reading the victim’s Gmail account, accessing files in Google Drive and Google Photos, viewing the Google calendar, and tracking locations via Google Maps.

Armed with that information, attackers could craft extremely convincing impersonation and phishing attacks, or even place the person in physical danger.

“In even worse cases … attackers may be able to delete files from Google Drive, write emails from the victim’s Gmail account to perform social engineering attacks, [exfiltrate] sensitive data from Google Calendar, Photos, or Docs, and more,” researchers wrote in the posting.

An App That ‘Ghosts’ the Victim

The Google Cloud Platform is built to host any of thousands of applications for end users, which, like other app ecosystems, have an official store where they can be easily downloaded — in this case, the Google Marketplace — along with third-party markets. Once authorized for download by the user, the application receives a token in the background, granting access to the installer’s Google account based on the permissions that the app asks for.

Using the GhostToken vulnerability, cyberattackers can craft a malicious application that they can plant in one of the app stores, masquerading as a legitimate utility or service. But once downloaded, the app will hide itself from the victim’s Google account application management page.

For the user, it basically disappears.

“Since this is the only place Google users can see their applications and revoke their access, the exploit makes the malicious app unremovable from the Google account,” according to the analysis. “The attacker on the other hand, as they please, can unhide their application and use the token to access the victim’s account, and then quickly hide the application again to restore its unremovable state. In other words, the attacker holds a ‘ghost’ token to the victim’s account.”

Idan Gour, researcher at Astrix, says that the flaw could have had far-reaching consequences for both businesses and individuals, and that it serves as a wake-up call to remember just how much access cloud apps have into our lives, and the danger that shadow IT can have for enterprises.

“This specific vulnerability allowed cyberattackers on one side to have access to organizational GCP environments, but on the other side, to people’s personal Google Photos and their email accounts,” he says. “It’s worth remembering that these different services that we use every day for everything are actually prone to these kinds [of] challenges, and it’s all about how we use it and, on the other side, how we secure it.”

Tracking Down a Phantom

While details are scant, the technical issue generally arose from the way Google processes OAuth clients when they’re decommissioned, the researchers said. Third-party OAuth clients are often integrated into apps to allow them to log users in more easily by making use of existing authentication with other trusted users. A common example is the “log in with Facebook” offered by many websites.

As far as how it could be exploited, it starts with the fact that every application offered to Google users in the Google Marketplace (or other websites) is associated with a single GCP “project” that hosts it. If the owner of the GCP project (usually the developer) deletes it, it enters what Astrix refers to as “a limbo-like, pending deletion state,” and it “stays that way for 30 days until it’s fully purged and deleted.”

These pending-deletion projects can be completely restored at the owner’s whim from a dedicated page made for that purpose. However, for end users, the app immediately disappears from the “apps with access to your account” management page.

Thus, the attack scenario goes like this:

• A victim authorizes a seemingly legitimate (but, in reality, evil) OAuth application. In the background, the attacker receives a token for the victim’s Google account.
• The attackers delete the project associated with the authorized OAuth application, which enters a pending deletion state — the application becomes hidden and unremovable from the victim’s perspective.
• Whenever the attackers wish to get access to the victim’s data they restore the project, get a new access token, and use it to access the victim’s data.
• The attackers then immediately re-hide the application from the victim.
• To maintain persistence, the attack loop must be executed periodically before the pending-deletion project is purged.

“During Step 2 of the attack loop, the access re-appears in the ‘Apps with access to your account’ page, which means the victim may technically remove the application’s access in this time window,” the researchers explained. “However, it’s a very limited time frame which lasts until the attacker executes Step 1 of the attack loop again.”

Eternal Battle of Usability & Security

Gour notes that the vulnerability was an unusual one because it related to a core feature that was, ostensibly, behaving as it should: Giving developers flexibility without bogging down end users with notes on apps they can no longer use.

“Normally when we talk about vulnerabilities, these are things that are broken that you can just patch and continue on,” he explains. “But in this case, it was actually a core feature of GCP and how you create projects in GCP. It’s actually nice to be able to revert to things that you did in the past, that you didn’t mean to erase. But on the other hand, with a little bit of creativity, and a very straightforward approach, it could be turned into something that can completely break the way that identity and access management is done by an external third party that was integrated to this environment (OAuth).”

And indeed, the bug speaks to the ongoing push-pull between usability and security that’s felt within all parts of an enterprise environment, Gour notes.

“The implications for cloud security, especially as it touches organizations and the private information of so many people nowadays, is that yes, sometimes it gets in the way of productivity or personal mobility, and is that what we want?” he says. “You have to be thinking of these things from the design phase and evaluate features for the balance between value to the user and security. It’s much, much, much, easier to do before everything is implemented and hundreds or thousands of people are using it.”

Banishing the Ghost: Mitigation & a Patch

Earlier this month, Google rolled out a global patch, fixing the issue by making sure that apps in a pending deletion state are still visible in a user’s app management screen. However, Astrix researchers warned that while they aren’t aware of active exploitation, Google Workspace administrators should look for applications that may have attacked users before the patch was initiated on April 7.

This can be done in two ways, the researchers said:

1. Looking for applications whose client ID is the same as the ‘displayText’ field and removing their access if they prove to be malicious;
2. Or inspecting the OAuth log events in the “Audit and Investigation” feature of Google Workspace for token activity of any such apps.