No-Slop Research & Human Thoughts on Security

Topic

gcp

A collection of 13 issues

GCP IAM 201 - OAuth Scopes

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

Working as Intended - The Unauditable, Unmanageable Keys in Google Cloud

This blog outlines three vulnerabilities with user-associated HMAC keys in Google Cloud. Vulnerability #1 - Insufficient Logging Vulnerability #2 - Unmanagable Long-Term Credentials Vulnerability #3 - Unauditable Long-Term Credentials TLDR; * HMAC keys serve a practical purpose. They can be used to create Sigv4 signed headers used to authenticate against the

GCP IAM 201 - Service Agents | What Can Go Wrong

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

GCP IAM 201 - Service Agents

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. Service Agent and Service Account Comparison Customer-managed SAs Google-managed SAs Colloquially called:

GCP IAM 101 Series

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

GCP AI Notebooks Vulnerability - Remediation

This is an update to my previous blog post which documented a mechanism for GCP Org Policy Bypass using custom metadata on compute instances. The Original Issue Google makes use of the custom metadata in compute instances to authorize access to AI Notebooks and their web UIs. Individuals granted access

Bypassing GCP Org Policy with Custom Metadata

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

GCP .actAs d-day > How not to remediate

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

GCP Roles and Permissions 101

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. Roles can range from containing just

GCP Users and Group 101

Users and Groups are two types of principals that can be granted access in GCP. When users and groups are members in IAM Policies, they are referenced by their Google email addresses. You won't find a directory in Google Cloud listing users or groups. Instead, users and groups