The presentation discusses the importance of preventing and detecting cloud session hijacking, and the need for better support from cloud vendors. It also covers the use of OAuth and an attack scenario involving bulk copying of credentials.
- Cloud session hijacking is a relatively new but easy-to-do method of authentication hijacking that requires better prevention and detection support from cloud vendors
- Concrete steps can be taken to prevent and detect session hijacking, such as session timeouts and low false positive detection
- OAuth is a common method of granting access to third-party apps and involves the use of access and refresh tokens
- An attack scenario involving bulk copying of credentials is demonstrated, showing the ease with which an attacker can access and copy cached credentials from a compromised endpoint
The presenter demonstrates an attack scenario involving the bulk copying of credentials from a compromised endpoint to an attacker-controlled machine, highlighting the ease with which this can be done. The presentation emphasizes the need for better support from cloud vendors in preventing and detecting session hijacking.
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.Detection OAuth 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.