In the OAuth 2.0 specification, a scope defines the limits of an access token. When applied to Google APIs, a scope specifies which APIs and resources the token can access.
If you only take away one thing about OAuth 2.0 Scopes for Google APIs, it is: do not use them as a primary access control mechanism.
This blog outlines three vulnerabilities with user-associated HMAC keys in Google Cloud.
This post aims to answer the question, ‘What can go wrong when using Google Cloud services that leverage Service Agents/P4SAs?’ For an introduction to Service Agents, see GCP IAM 201 - Service Agents.
Below, you’ll find an overview of possible threats to Google Cloud customers due to the presence of Service Agents organized around the STRIDE framework.
Service Agents are nothing more than a type of a Service Account.
Also known as a P4SA (Per-Project, Per-Product; Service Account), a Service Agent is typically created automatically whenever its associated Google API is enabled in a Project.
Recently, a friend admitted to me they were resorting to a ‘Hail Mary’ approach for their upcoming talk, scribbling notes on notecards like a nervous high school student. “But no! That’s actually a pro move,” I assured them, not just a desperate scramble to find order amidst chaos.
The GCP IAM 101 series is intended to give a brief, succinct overview of essential Google Cloud authorization concepts, answering questions like ‘How does Alice gain access to the Bucket?’
These pages are the TLDR; for Google Cloud IAM, supplemented with links to official, more verbose Google documentation where needed.
Leverage The DeRF for attacker simulations, validating security controls or enhancing cloud detection capabilities.
»The cloud scrambled context for defenders who are accustomed to leaning on their understanding of traditional on-prem architecture
Mining LastPass communications for new cloud IOCs
But how would you distinguish between legitimate backup activity and malicious data exfiltration on AWS S3?
How to exploit the Log4J software vulnerability in cloud-hosted VMs for maximum impact
This is an update to my previous blog post which documented a mechanism for GCP Org Policy Bypass using custom metadata on compute instances.
»TLDR;
Google makes use of custom metadata to authorize access to AI Notebooks and their web UIs.
Individuals granted access via custom metadata need not have any IAM permissions on the compute instance, on the service account running the Notebook or even be a member of the Organization. Authorization via custom metadata, bypasses a specific Organization Policy Constraint which restricts cross-domain resource sharing.
This vulnerability was awarded $1337.00 by the Google VRP Review Panel.
On January 27, 2021 a major, potentially breaking change is coming to GCP. If you’re using the default service account as the backing identity for several of GCP’s data science PaaS services, the end user will be required to have the .actAs permission on the default service account.
In GCP, access to resources is ultimately governed by Cloud IAM Permissions however, individual permissions are not directly assigned to principals. Instead, permissions are grouped together to create roles. These roles, rather than individual permissions, are then granted to principals in an IAM Policy.
»