IAM Concerned: OAuth Token Hijacking in Google Cloud (GCP) presented at BlackHatEurope 2020

by Jenko Hwong,

Summary : 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 there are multiple confusing options to revoking the active OAuth sessions and most do not work, 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 andreusing existing gcloud CLI sessions to gain access to multiple GCP environmentsshowing that MFA does not apply to OAuth token refreshes for cached credentials (only the initial login)We will then discuss various approaches and challenges to defending:PreventionMFA is not required to refresh the OAuth token. Google cloud session timeout (GSuite Admin) is effective and should be set. IP whitelisting (using VPC Service Controls and Access Context Manager) should be used but is not well understood. Explicit client-side revocation of cached accounts by the user can help but is manual and unreliable.DetectionOAuth token values are not logged in Stackdriver logging, nor in G Suite Audit logs, meaning that suspicious behavior can be tracked to the account but not the token itself, causing more confusion during incident response, as well as limiting remediation options.RemediationOAuth tokens can be revoked, but there are multiple options, some of which are not useful/effective as they do not affect API/CLI sessions or require an OAuth token, which is not logged.