GhostToken Opens Google Accounts to Permanent Infection
A bug in how Google Cloud Platform handles OAuth tokens opened the door to Trojan apps that could access anything in users personal or business Google Drives, Photos, Gmail, and more.
A security vulnerability in Googles Cloud Platform (GCP) could have allowed cyberattackers to hide an unremovable, malicious application inside a victims 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 victims 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 victims Gmail account to perform social engineering attacks, [exfiltrate] sensitive data from Google Calendar, Photos, or Docs, and more,
researchers wrote in the posting
.
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 installers 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 victims 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 victims account, and then quickly hide the application again to restore its unremovable state. In other words, the attacker holds a ghost token to the victims 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 peoples personal Google Photos and their email accounts, he says. Its worth remembering that these different services that we use every day for everything are actually prone to these kinds [of] challenges, and its all about how we use it and, on the other side, how we secure it.
While details are scant, the technical issue generally arose from the way Google processes OAuth clients when theyre 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 its fully purged and deleted.
These pending-deletion projects can be completely restored at the owners 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 victims 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 victims perspective.
Whenever the attackers wish to get access to the victims data they restore the project, get a new access token, and use it to access the victims 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 applications access in this time window, the researchers explained. However, its a very limited time frame which lasts until the attacker executes Step 1 of the attack loop again.
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. Its actually nice to be able to revert to things that you did in the past, that you didnt 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 thats 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. Its much, much, much, easier to do before everything is implemented and hundreds or thousands of people are using it.
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 users app management screen. However, Astrix researchers warned that while they arent 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:
Looking for applications whose client ID is the same as the displayText field and removing their access if they prove to be malicious;
Or inspecting the OAuth log events in the Audit and Investigation feature of Google Workspace for token activity of any such apps.
Tags:
GhostToken Opens Google Accounts to Permanent Infection