Tweet
Title: IAM Concerned: OAuth Token Hijacking in Google Cloud (GCP)
Description:
Imagine you've protected your production Google Cloud environment from compromised credentials, using MFA and a hardware security key. However, you find that your GCP environment has been breached through hijacking of OAuth session tokens cached by gcloud access. Tokens were exfiltrated and used to invoke API calls from another host. The tokens were refreshed by the attacker and did not require MFA. Detecting the breach via Strackdriver was confusing, slowing incident response. And revoking the active OAuth sessions required finding OAuth tokens from logs and using a REST API call, causing further delays in remediation.
This talk will demonstrate a compromised credential attack in Google Cloud Platform by:
- hijacking cached OAuth tokens stored on a GCP administrator's client machine and
- reusing existing gcloud CLI sessions to gain access to multiple GCP environments
- showing that MFA does not apply to OAuth token refreshes for cached credentials (only the initial login)
The POC takes advantage of several issues with GCP IAM design or configuration: OAuth tokens are cached and unencrypted, allowing easy access once the client endpoint has been exploited.
- Tokens can have long or no expiration, allowing potentially long time windows for compromise.
- The attacker can easily refresh tokens, allowing persistence.
- Token refresh does not require MFA making it easy to maintain persistence, creating a false sense of security when MFA is enabled.
- Authentication and Access policies are defined in different admin areas, are confusing, and easily misconfigured.
- Configuring Stackdriver Logging is confusing, leading to slow or ineffective incident response.
- OAuth tokens cannot be revoked easily making remediation difficult.
We will discuss various approaches and challenges to defending:
1. Prevention
- MFA is not required to refresh the OAuth token
- Google cloud session timeout (GSuite Admin)
- IP whitelisting (using VPC Service Controls and Access Context Manager)
- Explicit client-side revokes (manual)
2. Detection
- Stackdriver logging data access events must be enabled for all services or else the abuse of OAuth tokens will not be logged and remediation will not be possible.
- Periodic audit checks on the logs or IAM configurations can be somewhat useful for compliance, but are not real-time so are of limited use for detection.
3. Remediation
- OAuth tokens can be revoked, but there are caveats:
+ "gcloud auth revoke" only works on the compromised user's endpoint and requires the user account in order to look up the locally cached OAuth token. This will fail if the attacker deletes the gcloud credential cache.
+ A REST API revoke call works and requires the OAuth token, so reliable logging and event parsing must be implemented to ensure tokens can be extracted quickly for IR.
- Deletion of user accounts has a huge impact.
- Browser sessions can be revoked but does not apply to Google Cloud sessions.
Speaker(s): Jenko Hwong
Location: Cloud Vlg
Discord: https://discord.com/channels/7082082...33373172285520
Event starts: 2020-08-07 11:20 (11:20 AM) PDT (UTC -07:00)
Event ends: 2020-08-07 12:05 (12:05 PM) PDT (UTC -07:00)
For the most up-to-date information, please either visit https://info.defcon.org, or use HackerTracker, which is available for iOS and Android. This is an automated message, and this data was last modified 2020-08-07T00:35 (UTC).
Description:
Imagine you've protected your production Google Cloud environment from compromised credentials, using MFA and a hardware security key. However, you find that your GCP environment has been breached through hijacking of OAuth session tokens cached by gcloud access. Tokens were exfiltrated and used to invoke API calls from another host. The tokens were refreshed by the attacker and did not require MFA. Detecting the breach via Strackdriver was confusing, slowing incident response. And revoking the active OAuth sessions required finding OAuth tokens from logs and using a REST API call, causing further delays in remediation.
This talk will demonstrate a compromised credential attack in Google Cloud Platform by:
- hijacking cached OAuth tokens stored on a GCP administrator's client machine and
- reusing existing gcloud CLI sessions to gain access to multiple GCP environments
- showing that MFA does not apply to OAuth token refreshes for cached credentials (only the initial login)
The POC takes advantage of several issues with GCP IAM design or configuration: OAuth tokens are cached and unencrypted, allowing easy access once the client endpoint has been exploited.
- Tokens can have long or no expiration, allowing potentially long time windows for compromise.
- The attacker can easily refresh tokens, allowing persistence.
- Token refresh does not require MFA making it easy to maintain persistence, creating a false sense of security when MFA is enabled.
- Authentication and Access policies are defined in different admin areas, are confusing, and easily misconfigured.
- Configuring Stackdriver Logging is confusing, leading to slow or ineffective incident response.
- OAuth tokens cannot be revoked easily making remediation difficult.
We will discuss various approaches and challenges to defending:
1. Prevention
- MFA is not required to refresh the OAuth token
- Google cloud session timeout (GSuite Admin)
- IP whitelisting (using VPC Service Controls and Access Context Manager)
- Explicit client-side revokes (manual)
2. Detection
- Stackdriver logging data access events must be enabled for all services or else the abuse of OAuth tokens will not be logged and remediation will not be possible.
- Periodic audit checks on the logs or IAM configurations can be somewhat useful for compliance, but are not real-time so are of limited use for detection.
3. Remediation
- OAuth tokens can be revoked, but there are caveats:
+ "gcloud auth revoke" only works on the compromised user's endpoint and requires the user account in order to look up the locally cached OAuth token. This will fail if the attacker deletes the gcloud credential cache.
+ A REST API revoke call works and requires the OAuth token, so reliable logging and event parsing must be implemented to ensure tokens can be extracted quickly for IR.
- Deletion of user accounts has a huge impact.
- Browser sessions can be revoked but does not apply to Google Cloud sessions.
Speaker(s): Jenko Hwong
Location: Cloud Vlg
Discord: https://discord.com/channels/7082082...33373172285520
Event starts: 2020-08-07 11:20 (11:20 AM) PDT (UTC -07:00)
Event ends: 2020-08-07 12:05 (12:05 PM) PDT (UTC -07:00)
For the most up-to-date information, please either visit https://info.defcon.org, or use HackerTracker, which is available for iOS and Android. This is an automated message, and this data was last modified 2020-08-07T00:35 (UTC).