Critical Google Cloud Setting Hackers Hope You Overlook

Summary TL;DR

By addressing this critical setting, you can significantly improve the security posture of your Google Cloud environment and thwart potential attacks

Default Google Cloud settings pose significant security risks. Outside of insecure compute default there is another concern. Once authenticated with a gcloud profile, users are not required to re-authenticate with 2FA unless specific settings enforce it. Here’s how to mitigate this vulnerability. Check Mitigation

Overview

I see this with many clients:

• a corporate environment
• 500+ developers
• gcloud cli used daily by many
• SSO and 2FA everywhere
• Dosen or so SaaS products intermingled together with Service Accounts
• things locked down to an absurd level of people not being able to do their work

Despite these precautions, a critical Google Cloud configuration often remains overlooked, leaving a significant security gap.

The Vulnerability

By default, Google Cloud settings are insecure. Once a user authenticates with a gcloud profile, they are not required to re-authenticate with 2FA unless specific settings are enabled. The underlying mechanism involves a refresh token that can be used to obtain a new, short-lived OAuth access token. This token can be easily transferred to another endpoint controlled by a threat actor, allowing them to impersonate a legitimate user.

If the attacker manages to steal OAuth tokens, they can:

• Impersonate the compromised user or service account. API traffic that uses the compromised tokens is logged as if it came from the compromised user or service account, making it difficult to distinguish normal and malicious activity in logs
• Refresh the access token indefinitely using a persistent refresh token associated with a user or a private key associated with a service account
• Bypass authentication with the user’s password or 2-step verification because the tokens are granted after the sign-in flow

Types of credentials stored by the gcloud CLI

The gcloud CLI uses OAuth 2.0 access tokens to authenticate requests for Google Cloud APIs. The OAuth flow varies by the credential types used, but generally the access token and other credentials are accessible locally. In each case, the access token expires after 60 minutes, but other credential types might be persistent.

When you authorize the gcloud CLI with a user account, the gcloud CLI initiates a three-legged OAuth consent flow to access Google Cloud APIs on the user’s behalf. After the user completes the consent flow, the gcloud CLI receives an access token and a refresh token that allows it to request new access tokens. Under the default settings, the long-lived refresh token persists until its expiration conditions are met.

Expiration conditions

A refresh token might stop working for one of these reasons:

• The user has revoked your app’s access.
• The refresh token has not been used for six months.
• The user changed passwords and the refresh token contains Gmail scopes.
• The user account has exceeded a maximum number of granted (live) refresh tokens.
• If an admin set any of the services requested in your app’s scopes to Restricted (the error is admin_policy_enforced).
• For Google Cloud Platform APIs - the session length set by the admin could have been exceeded Source

When you authorize the gcloud CLI with a service account, the gcloud CLI initiates a two-legged OAuth flow to access Google Cloud APIs as the service account identity. After you activate a service account from a private key file, this key is used to periodically request an access token. The long-lived private key is stored in the gcloud CLI configuration and remains valid until you delete the service account key. When you run the gcloud CLI inside a Google Cloud environment, like Compute Engine or Cloud Shell, the application can automatically find credentials and authenticate as a service account. For example, in Compute Engine, an application like the gcloud CLI can query the metadata server for an access token. Google manages and rotates the private signing key that is used to create the access token, and the long-lived credentials aren’t exposed to the application.

(…)

Mitigation

Set session length for Google Cloud services

The fix is a special Google Workspace security settings designed to require re-authentication for all kinds of “connected apps” like gcloud cli tools:

• Expire active tokens for all user accounts with Google Cloud session control
• Programmatically invalidate tokens for many user accounts

The session length setting change will apply to:

• The Google Cloud console
• The gcloud command-line tool (Cloud SDK)
• Any applications (including third-party applications, or your own applications) that require user authorization for Google Cloud scopes.

Additionally you should also consider:

• Configure VPC Service Controls
• Configure BeyondCorp Enterprise
• Enforce 2-step verification for remote server access (OSLogin with 2fa)
• Restrict the use of service account keys
• Consider the principle of least privilege
• Protect your endpoints
• Align your response teams

Stay curious, stay ethical, and keep exploring!