BEGIN:VCALENDAR PRODID:-//vBulletin 6//EN VERSION:2.0 CALSCALE:GREGORIAN BEGIN:VEVENT UID:43714b43-25e2-434b-9b9b-f78fb2210ee8 DTSTAMP:20260621T131500Z SUMMARY:IAM Concerned: OAuth Token Hijacking in Google Cloud (GCP) DESCRIPTION:Title: IAM Concerned: OAuth Token Hijacking in Google Cloud (GC P)\n\nDescription:\nImagine you've protected your production Google Cloud environment from compromised credentials\, using MFA and a hardware securi ty key. However\, you find that your GCP environment has been breached thr ough hijacking of OAuth session tokens cached by gcloud access. Tokens wer e exfiltrated and used to invoke API calls from another host. The tokens w ere refreshed by the attacker and did not require MFA. Detecting the breac h via Strackdriver was confusing\, slowing incident response. And revoking the active OAuth sessions required finding OAuth tokens from logs and usi ng a REST API call\, causing further delays in remediation.\n\nThis talk w ill demonstrate a compromised credential attack in Google Cloud Platform b y:\n\n- hijacking cached OAuth tokens stored on a GCP administrator's clie nt machine and\n- reusing existing gcloud CLI sessions to gain access to m ultiple GCP environments\n- showing that MFA does not apply to OAuth token refreshes for cached credentials (only the initial login)\n\nThe POC take s advantage of several issues with GCP IAM design or configuration: OAuth tokens are cached and unencrypted\, allowing easy access once the client e ndpoint has been exploited.\n\n- Tokens can have long or no expiration\, a llowing potentially long time windows for compromise.\n- The attacker can easily refresh tokens\, allowing persistence.\n- Token refresh does not re quire MFA making it easy to maintain persistence\, creating a false sense of security when MFA is enabled.\n- Authentication and Access policies are defined in different admin areas\, are confusing\, and easily misconfigur ed.\n- Configuring Stackdriver Logging is confusing\, leading to slow or i neffective incident response.\n- OAuth tokens cannot be revoked easily mak ing remediation difficult.\n\nWe will discuss various approaches and chall enges to defending:\n\n1. Prevention\n\n- MFA is not required to refresh t he OAuth token\n- Google cloud session timeout (GSuite Admin)\n- IP whitel isting (using VPC Service Controls and Access Context Manager)\n- Explicit client-side revokes (manual)\n2. Detection\n\n- 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.\n- Periodi c audit checks on the logs or IAM configurations can be somewhat useful fo r compliance\, but are not real-time so are of limited use for detection.\ n3. Remediation\n\n- OAuth tokens can be revoked\, but there are caveats:\ n+ "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 tok en. This will fail if the attacker deletes the gcloud credential cache.\n+ A REST API revoke call works and requires the OAuth token\, so reliable l ogging and event parsing must be implemented to ensure tokens can be extra cted quickly for IR.\n- Deletion of user accounts has a huge impact.\n- Br owser sessions can be revoked but does not apply to Google Cloud sessions. \n\nSpeaker(s): Jenko Hwong\n\nLocation: Cloud Vlg\n\nDiscord: https://dis cord.com/channels/708208267699945503/732733373172285520\n\nEvent starts: 2 020-08-07 11:20 (11:20 AM) PDT (UTC -07:00)\n\nEvent ends: 2020-08-07 12:0 5 (12:05 PM) PDT (UTC -07:00)\n\nFor the most up-to-date information\, ple ase either visit https://info.defcon.org\, or use HackerTracker\, which is available for iOS and Android. This is an automated message\, and this da ta was last modified 2020-08-07T00:35 (UTC). URL:https://forum.defcon.org/node/234712 DTSTART:20200807T192000Z DTEND:20200807T200501Z LOCATION:Cloud Vlg END:VEVENT END:VCALENDAR