|
Getting your Trinity Audio player ready... |
Threat actors may use a variety of newly demonstrated attack techniques against Google Workspace and the Google Cloud Platform to carry out ransomware, data exfiltration, and password recovery attacks.
Martin Zugec, technical solutions director at Bitdefender, stated in a recent report that “threat actors could progress in several ways, starting from a single compromised machine: they could move to other cloned machines with GCPW installed, gain access to the cloud platform with custom permissions, or decrypt locally stored passwords to continue their attack beyond the Google ecosystem.”
Since the bug “falls outside of our threat model and the behavior is in line with Chrome’s practices of storing local data,” Google has marked it as unfixable. This is because the attacker must have previously obtained access to the local machine through some other method.
Nonetheless, threat actors may take advantage of these openings to turn a single endpoint compromise into a network-wide intrusion, according to the Romanian cybersecurity company.
Google Credential Provider for Windows (GCPW) Plays Vital Role
The attacks depend on the use of Google Credential Provider for Windows (GCPW) by an organization, that provides single sign-on (SSO) and mobile device management (MDM) features.
With this, users can access their Windows devices with the same login credentials they use to access their Google accounts, and administrators can remotely manage and control Windows devices within their Google Workspace environments.
The company detailed in its report how hackers can exploit the way Google Credential Provider for Windows operates, which is to use the local privileged service account Google Accounts and ID Administration to verify users’ credentials and then store a refresh token that removes the need for re-authentication.
This allows hackers who have already gained unauthorized access to a local machine through other means. Thus, an account’s refresh OAuth token can be extracted by attackers who have already compromised a machine in order to get around multifactor authentication.
A different exploit, meanwhile, uses the Golden Image lateral movement technique to create another virtual machine with the pre-installed GCPW and clones the password linked to the GAIA account in the process. In a third exploit, the attacker obtains the private RSA key required to decrypt the password field by sending an HTTP GET request to an undocumented API endpoint using a previously obtained access token.
The GCPW authenticates users with Google Workspace credentials using a local “Gaia” service account. This account, which has elevated privileges, is created during the installation of GCPW.
This feature allows the Local Security Authority Subsystem Service (LSASS), which handles Windows OS authentication, to integrate a Credential Provider. When users unlock or log into their devices, this Credential Provider checks their credentials.
A new local user account called “Gaia” is created for each new user who authenticates with GCPW and is connected to their Workspace account. In order to avoid receiving multiple authentication prompts, the user uses this local profile to log in, and a refresh token is saved in their profile.
When transferring files to and from Google Drive, there are two different kinds of log records: “source_copy” and “copy.” Only the former kind of record can be created by employees without a paid license when they use an organization’s cloud storage. This allows possible threat actors to evade detection after pilfering important information.
According to Mitiga, “there are absolutely no logs of the download actions from the user private drive.” Therefore, “the company will miss the exfiltration detection if they check only for ‘copy’ events and not also ‘ source_copy’ for data theft [and] the copying is done by a user with an unpaid license.”
The cybersecurity analyst implies that Mitiga’s claim that its attempts to inform Google of the blindspot have been met with a lack of response is a common one for the tech giant in similar situations.
In order to include it in this advisory, Mitiga stated, “We have contacted Google’s security team but have not yet received an official response.” “Google’s security team generally does not recognize forensics deficiencies as a security problem, based on prior advisories.”
