The Security Research Group at Astrix discovered a zero-day vulnerability in Google’s Cloud Platform (GCP), which means that all Google customers are at risk. Because of this vulnerability, which has been given the moniker “GhostToken,” threat actors may be able to make a malicious program undetectable and impossible to remove, which would result in the victim’s Google account becoming permanently infected with a trojan software. Attackers have the potential to conceal their malicious application from the Google account application management page of their victim by exploiting a vulnerability known as GhostToken. Due to the fact that this is the sole location where Google users can see their apps and cancel access for those programs, the vulnerability renders the malicious app impossible to remove from the Google account. The attacker, on the other hand, may unhide their program whenever they want, use the token to log in to the victim’s account, and then quickly hide the application again to return it to its unremovable condition. This is because the token is stored in the attacker’s application. To put it another way, the attacker is in possession of a “ghost” token that belongs to the victim’s account.
It is crucial to note that, since the program is completely concealed from the victim’s perspective, they are prevented from ever knowing their account is at danger in the first place, and even if they do suspect it, they are unable to do anything about it other than establish a totally new Google account. This is one of the reasons why it is so vital for the application to be completely hidden from the victim’s view.
The victim’s private Gmail messages, Google Drive and Photos files, Google Calendar events, Google Maps locations, and Google Cloud Platform services could all be accessible to attackers if the victim grants the malicious app access to these features.
Even more seriously, if users provide attackers crucial rights, the latter may be able to remove files from Google Drive, send emails from the victim’s Gmail account in order to carry out social engineering attacks, steal sensitive data from Google Calendar, Photos, or Docs, and carry out further malicious activities.
Attack Scenario
The following attack scenario may be built using the primitives that have been discussed above:
The victim gives permission to a 3rd-party OAuth application that seems to be completely trustworthy. An attacker either acquires ownership of the application or takes control of it, at which point the attacker is rewarded with a refresh token 1//refresh for the victim’s Google account.
The attacker is the one who starts the attack loop, which consists of:
The Attacker deletes the project that is connected to the approved OAuth application, which results in the project entering a state where it is in the process of being deleted. As was said, this causes the program to become invisible to the Victim and makes it impossible for them to delete it.
When the attacker wants access to the victim’s data, they restore the project, use the same refresh token 1//refresh> to receive an access token, and then use that access token to access the victim’s data. This process is repeated whenever the attacker wants access to the victim’s data.
As soon as this is finished, the attacker will go back to the first stage to once again conceal the program from the victim.
As was said before, the only method for a Google user to disable the access of an OAuth application is by going to the page that lists all of the applications that have access to their account.
Because of this, and the fact that the vulnerability wasn’t fixed, Google users were effectively unable to delete rogue programs that used the GhostToken flaw.
The fix that was issued by Google makes it so that programs that are in a condition that is described as “pending-deletion” are still visible in the Apps with access to your account page. As a result, the user may uninstall these applications in the same manner that they remove any other application. Users are encouraged to go to this page in order to confirm that they are conversant with all allowed third-party applications and that each one has the required minimum permissions.
Information security specialist, currently working as risk infrastructure specialist & investigator.
15 years of experience in risk and control process, security audit support, business continuity design and support, workgroup management and information security standards.