Google Workspace weaknesses allow plaintext password theft

Novel weaknesses in Google Workspace have been exposed by researchers, with exploits potentially leading to ransomware attacks, data exfiltration, and password decryption.

Researchers at Bitdefender say the methods could also be used to access Google Cloud Platform (GCP) with custom permissions and could move from machine to machine.

The infoseccers say Google told them the weaknesses would not be addressed and won’t receive any security fixes since they fall outside the company’s threat model. 

Vulnerabilities that rely on compromised local machines, like those highlighted by Bitdefender today, aren’t considered Google-specific bugs since a compromise through methods like malware should be covered by an organization’s existing security controls.

Google also told the researchers during the vulnerability disclosure process that the data storage behavior is in line with Chrome’s intended practices.

Bitdefender says this shouldn’t be taken lightly and the weaknesses highlighted in its research are potentially realistically exploitable. Threat actors often seek out and exploit these gaps in coverage,” it says in its report.

Windows orgs

The attacks hinge on an organization’s use of Google Credential Provider for Windows (GCPW), which offers mobile device management (MDM) and single sign-on (SSO) capabilities.

When GCPW is installed on a machine, a local Google Accounts and ID Administration (GAIA) account is created, which has elevated privileges. GCPW then adds a credential provider to Windows’ Local Security Authority Subsystem Service (LSASS) so that users can log into their Windows machine using their Workspace credentials.

GAIA creates a fresh local account for new users authenticating using GCPW, associating that local account with the Workspace account. Stored inside the local account is also a refresh token that maintains access to Google APIs, removing the need to continually re-authenticate.

Generating access tokens and bypassing MFA

Despite the local compromise needing to take place before the MFA bypass, the weakness is notable given that it can be chained later on to steal plaintext passwords.

Attackers can steal an account’s refresh tokens in two different areas depending on the age of the token. Once created, they are first briefly stored in the Windows registry value and encrypted using the CryptProtectData function. They are then later stored more permanently in the user’s Chrome profile.

Decryption is possible in both locations. In the Windows registry, refresh tokens can be decrypted using oft-abused tools like Mimikatz or by calling the CryptUnprotectData function. It’s a stealthier method, Bitdefender says, but is only available in the registry for a shorter period of time.

The reverse is true for decrypting after being stored in the Chrome profile. It stays there for longer, offering greater certainties regarding its location, but is noisier, increasing the chances of detection.

A token can then be issued to the attacker via a specially crafted POST request, granting the attacker permission to access any service within the token’s scope. Data exfiltration in services like Gmail and Google Drive is possible, as well as a plethora of other abuses. 

Bitdefender says an “interesting” service to abuse would be the Vault API which is capable of exfiltrating all emails and files for all users within an organization.

If for some reason the attacker wasn’t able to extract the token, they are able to force re-authentication by changing the token handle’s value to an invalid or null value. 

Recovering plaintext passwords

The authentication bypass exploit can be used to help attackers retrieve the RSA key required to decrypt user passwords – the “more serious” exploit in the research, Bitdefender says. 

“Access tokens, when stolen, pose a security risk by allowing attackers to gain limited access within the boundaries defined by the token’s permissions,” it says. “These tokens are often time-bound and come with specific scope restrictions. 

“In contrast, having access to plaintext credentials, such as usernames and passwords, represents a more severe threat. This is because it enables attackers to directly impersonate legitimate users and gain unrestricted access to their accounts, potentially leading to complete account takeover.”

An attacker could feasibly use the previous exploit to generate a new access token with the OAuth scope and then send a GET request to a specific undocumented API endpoint to retrieve the required RSA key.

Lateral movement

The lateral movement exploit applies mainly to virtual machine (VM) deployments and uses the common practice of cloning VMs.

The GAIA account that’s created when GCPW is installed on a new machine always generates a unique password, but if the machine was created by cloning another machine, then the password across all machines will be the same. 

Scenarios in which multiple machines have been cloned from another can allow attackers to traverse them if they acquire the credentials to just one of those machines.

“VM cloning is very common, particularly in specific scenarios like VDI or RDP deployments,” Martin Zugec, technical solutions director at Bitdefender, told The Register. 

“Any solution promoting single-image management is susceptible to this attack method. This vulnerability is particularly crucial at present, with threat actors like LockBit actively exploiting CitrixBleed to gain unauthorized access to networks through remote desktop solutions. 

“The appeal of single-image management is a key feature in VDI and RDP deployments. It enables you to efficiently deploy tens of thousands of machines while handling only a minimal set of virtual machine images.”

The initial compromise of the device comes into play here, as Bitdefender says the way to find the GAIA account’s credentials is to use malware capable of listing secrets stored in LSASS such as Mimikatz.

No bugs here

There are caveats to the exploits outlined by Bitdefender, the main one being a compromise of a local machine is required to execute any of them. It’s the main reason why Google declined to address them, with attacks that require local compromise being outside of its threat model.

When a local machine is compromised to the degree where malware like Mimikatz can run, the exploits defined by Bitdefender offer just a small sample of the possibilities open to attackers.

During the original vulnerability disclosure process, Bitdefender security researcher Radu Tudorică argued that because a local compromise could lead to an attack on an organization’s cloud infrastructure, it warranted attention.

Responding, Roger Tawa at the Chromium Project said: “Even without GCPW, the refresh token is stored on disk inside the Chrome profile, encrypted using the same mechanism as when it is stored in the registry. 

“Running an app as the same OS user could always extract this value. With GCPW, this value is temporarily stored in the registry before being copied to the profile on disk. This was reviewed by Chrome security at the time and deemed as secure as any other part of Chrome’s user data and following best practices for Windows.”

Regarding the forced re-authentication to steal tokens, he also said this doesn’t increase the risk of a token being stolen. 

“If an app can write to HKLM to force a re-auth, it can also just read the encrypted refresh token directly out of the profile on disk.”

The bug report prompted a review with Chrome’s security team and was deliberated over for nearly a month, but was ultimately given a “won’t fix” status.

Bitdefender’s research today was presented more as an example of how to extend existing local breaches in Google Workspace, despite coming with a number of caveats. 

“But just because certain weaknesses fall outside the scope of a threat model, it does not mean that threat actors will not exploit them,” it says. ®

READ MORE HERE