Add GCP and Auth0 security skills

Expand cloud and technology coverage for GCP IAM/storage and Auth0 tenant/API misconfiguration testing.
2026-08-16 01:16:40 +02:00 · 2026-07-10 08:15:22 -07:00
parent 882664f70b
commit 054725ccb6
2 changed files with 373 additions and 0 deletions
@@ -0,0 +1,190 @@
+---
+name: gcp
+description: GCP cloud security testing covering IAM misconfigurations, public storage buckets, metadata abuse, and service account privilege escalation
+---
+
+# Google Cloud Platform (GCP)
+
+GCP misconfigurations expose project data, service account keys, and lateral movement paths across Compute, Cloud Storage, Cloud Functions, and GKE. This skill covers direct GCP API testing and post-compromise enumeration from VMs/containers. For SSRF-mediated metadata access, combine with the `ssrf` skill.
+
+## Attack Surface
+
+**Identity**
+- IAM policies: project/folder/org level bindings
+- Service accounts, keys (JSON), Workload Identity, impersonation
+- OAuth scopes on compute instances and Cloud Functions
+
+**Storage & Data**
+- Cloud Storage (GCS) buckets and objects
+- BigQuery datasets, Cloud SQL instances, Firestore (see `firebase_firestore` skill)
+- Secret Manager, Cloud KMS keys
+
+**Compute**
+- Compute Engine VMs, Cloud Run, Cloud Functions, GKE clusters
+- Metadata server at `http://metadata.google.internal/computeMetadata/v1/`
+- Startup scripts, instance templates, custom images
+
+**Management**
+- Cloud Console, gcloud CLI, Deployment Manager, Terraform state buckets
+- Cloud Logging, Error Reporting, Cloud Build triggers
+
+## Reconnaissance
+
+**Credential Discovery**
+- Service account JSON keys in repos, CI/CD, `.env`, backup buckets
+- `GOOGLE_APPLICATION_CREDENTIALS` environment variable
+- Default Compute Engine service account on VMs (often overprivileged)
+- OAuth tokens in browser/local `gcloud` config (`~/.config/gcloud/`)
+
+**Unauthenticated Enumeration**
+```
+# GCS bucket existence and listing (allUsers / allAuthenticatedUsers)
+gsutil ls gs://target-bucket
+curl -I https://storage.googleapis.com/target-bucket/
+curl https://storage.googleapis.com/target-bucket/
+
+# Firebase/GCP storage alternate URLs
+https://target-bucket.storage.googleapis.com/
+```
+
+**Authenticated Enumeration**
+```
+gcloud auth list
+gcloud config get-value project
+gcloud projects get-iam-policy PROJECT_ID
+gcloud iam service-accounts list
+gcloud storage ls
+gcloud compute instances list
+gcloud container clusters list
+```
+
+## Key Vulnerabilities
+
+### Cloud Storage Misconfigurations
+
+- Public buckets: `allUsers` or `allAuthenticatedUsers` with `roles/storage.objectViewer` or `objectAdmin`
+- Listable buckets revealing object keys: backups, `.env`, `terraform.tfstate`, SA keys
+- Uniform bucket-level access disabled with legacy ACL public-read
+- Signed URL with excessive TTL or overly broad object prefix
+
+**Test:**
+```
+gsutil iam get gs://BUCKET
+gsutil ls gs://BUCKET
+curl -I https://storage.googleapis.com/BUCKET/sensitive.sql
+```
+
+### IAM Privilege Escalation
+
+Common escalation paths (verify with `gcloud iam` / policy simulator):
+
+| Permission | Escalation |
+|------------|------------|
+| `iam.serviceAccounts.actAs` + `compute.instances.create` | VM with privileged SA |
+| `iam.serviceAccountKeys.create` | Export key for higher-priv SA |
+| `iam.serviceAccounts.setIamPolicy` | Grant yourself roles on SA |
+| `cloudfunctions.functions.create` + `actAs` | Deploy function as privileged SA |
+| `run.services.create` (Cloud Run) + `actAs` | Deploy service with admin SA |
+| `storage.buckets.update` + `setIamPolicy` | Open bucket to public or self |
+
+**Test:**
+```
+gcloud projects get-iam-policy PROJECT --flatten="bindings[].members" --filter="bindings.members:user:YOU"
+gcloud iam roles list --project=PROJECT
+```
+
+### Metadata Server Abuse
+
+From any code execution on a GCP VM, Cloud Run (if metadata accessible), or compromised pod:
+
+```
+curl -H "Metadata-Flavor: Google" \
+  http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token
+
+curl -H "Metadata-Flavor: Google" \
+  http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/email
+```
+
+- Default compute SA may have `editor` role on project (legacy projects)
+- Requested OAuth scopes may allow `cloud-platform` full access
+- Workload Identity misconfiguration in GKE → cross-namespace SA token theft
+
+### GKE Misconfigurations
+
+- Dashboard/UI exposed, anonymous RBAC (see `kubernetes` skill for K8s layer)
+- Workload Identity not enforced; pods use node SA with broad GCP permissions
+- `kubectl` proxy or `kubelet` read-only port exposed
+- Secrets in ConfigMaps; GCR/Artifact Registry images pulling without auth
+
+### Cloud Functions / Cloud Run
+
+- HTTP-triggered functions without authentication (`--allow-unauthenticated`)
+- Environment variables containing API keys (`gcloud functions describe`)
+- Overprivileged runtime service account (`roles/editor`)
+- Event triggers accepting attacker-controlled Pub/Sub messages
+
+### BigQuery & Cloud SQL
+
+- Public datasets (`allUsers` on dataset IAM)
+- Cloud SQL public IP with weak/no password
+- Exported snapshots in public GCS buckets
+
+### Secret Manager & KMS
+
+- `secretmanager.versions.access` granted to unintended principals
+- Secrets replicated to logs via misconfigured Cloud Functions env vars
+- KMS cryptoKey IAM with `allAuthenticatedUsers`
+
+## Advanced Techniques
+
+**Terraform State in GCS**
+- `terraform.tfstate` in listable bucket → all resource addresses, sometimes secrets in plain text
+
+**Service Account Impersonation Chain**
+- `roles/iam.serviceAccountTokenCreator` on target SA → short-lived access tokens
+
+**Org/Fold Policy Gaps**
+- Project-level deny policies not applied; child project inherits permissive folder IAM
+
+## Testing Methodology
+
+1. **Discover credentials** — Keys in code, metadata, SSRF, public buckets
+2. **Identify principal** — `gcloud auth list`, effective project IAM
+3. **Enumerate storage** — Public/listable buckets, sensitive object names
+4. **Escalation paths** — Map `actAs`, key creation, function deploy permissions
+5. **Metadata** — From any shell in GCP workload, fetch SA token and scopes
+6. **GKE layer** — Pivot from GCP IAM to cluster (combine with `kubernetes` skill)
+
+## Validation
+
+1. Demonstrate unauthorized GCS object read/list with bucket URL and object key
+2. Show IAM escalation path with exact role/member binding and resulting access
+3. Prove metadata token theft from compute context with redacted token scope
+4. Document project ID, resource name, and IAM binding root cause
+5. Confirm fix blocks the specific principal/permission/resource combination
+
+## False Positives
+
+- Intentionally public static asset bucket with no sensitive objects
+- Metadata server unreachable from tested context (no RCE/SSRF)
+- SA token from metadata has only `devstorage.read_only` on single bucket (note scope, not full breach)
+- `403` on bucket HEAD indicating existence but not readable content
+
+## Impact
+
+- Mass data exfiltration from GCS/BigQuery/Cloud SQL backups
+- Project or org compromise via SA key theft or IAM escalation
+- Lateral movement from GKE pod to cloud control plane
+- Regulatory exposure (PII in public buckets or exports)
+
+## Pro Tips
+
+1. Always check both `gsutil iam get` and anonymous `curl` — IAM and ACL layers differ
+2. Search public buckets for `*.json` service account keys and `terraform.tfstate`
+3. Default compute SA email: `PROJECT_NUMBER-compute@developer.gserviceaccount.com`
+4. Combine with `kubernetes` skill when target runs on GKE
+5. Firebase-hosted apps often use GCP project underneath — pivot from web to GCP project ID in configs
+
+## Summary
+
+GCP security requires least-privilege IAM, no public data paths, tight metadata/scopes on compute, and protected service account keys. Enumerate from any credential or shell — even read-only GCS access often reveals escalation artifacts.
@@ -0,0 +1,183 @@
+---
+name: auth0
+description: Auth0 tenant security testing covering misconfigured rules/actions, scope escalation, MFA bypass, and cross-application token confusion
+---
+
+# Auth0
+
+Auth0 misconfigurations enable account takeover, cross-tenant data access, and privilege escalation through Rules/Actions, loose application settings, weak API authorization, and token acceptance bugs in consuming applications. Test both the Auth0 tenant configuration and how downstream APIs validate Auth0-issued tokens.
+
+## Attack Surface
+
+**Auth0 Components**
+- Applications: SPA, Regular Web, Native, Machine-to-Machine (M2M)
+- APIs (Resource Servers): identifiers, scopes, RBAC, permissions
+- Connections: database, social, enterprise (SAML/OIDC)
+- Rules (legacy) and Actions (post-login, pre-user-registration, credentials exchange)
+- Organizations (multi-tenant B2B), roles, permissions
+- Universal Login, custom domains, custom database scripts
+
+**Token Types**
+- ID Token (OIDC), Access Token (JWT or opaque), Refresh Token
+- Management API tokens, client credentials tokens (M2M)
+- PAR, PKCE flows for public clients
+
+**Management**
+- Auth0 Management API (`/api/v2/`)
+- Tenant settings, attack protection, MFA policies, anomaly detection
+- Logs streaming, hooks, custom prompts
+
+## Reconnaissance
+
+**Tenant Discovery**
+```
+# From app config, JS bundles, mobile apps
+domain: tenant.us.auth0.com / tenant.eu.auth0.com / login.customdomain.com
+client_id, audience, scope values in authorize URLs
+```
+
+**OIDC Discovery**
+```
+GET https://TENANT.auth0.com/.well-known/openid-configuration
+GET https://TENANT.auth0.com/.well-known/jwks.json
+GET https://TENANT.auth0.com/userinfo
+```
+
+**Application Fingerprint**
+- Login redirect to `https://TENANT.auth0.com/authorize?client_id=...`
+- `auth0-js`, `@auth0/auth0-spa-js`, `auth0-react` in frontend bundles
+- API `audience` parameter in token requests
+
+**Management API Exposure**
+- Leaked M2M credentials with `read:users`, `update:users`, `create:users` scopes
+- Management API called from browser (CORS misconfiguration)
+
+## Key Vulnerabilities
+
+### Application Configuration
+
+**Callback URL / Origin Misconfigurations**
+- Wildcard or overly broad Allowed Callback URLs: `https://app.com/*`, `http://localhost:*`
+- Allowed Logout URLs, Web Origins, CORS origins too permissive
+- Native app custom scheme hijacking (`com.app://callback`)
+
+**Token Settings**
+- ID Token used as API access token (audience/scope confusion)
+- Refresh token rotation disabled; overly long TTL
+- Signing algorithm downgrade if RS256 not enforced downstream
+
+### API Authorization (Resource Server)
+
+**Missing Scope/RBAC Enforcement**
+- API accepts any valid access token without required `scope` or `permissions` claim
+- RBAC enabled in Auth0 but API doesn't call `/userinfo` or validate `permissions` array
+- Wrong `audience` accepted — token for App A works on App B's API
+
+**Test:**
+```
+# Token for audience A used against API B
+Authorization: Bearer <token_with_audience_A>
+```
+
+### Rules and Actions Abuse
+
+**Post-Login Rule/Action Injection**
+- Rules that add claims based on unvalidated user metadata:
+  ```javascript
+  user.app_metadata.role = 'admin'  // if user can set app_metadata via signup/API
+  ```
+- `context.authorization` manipulation in Actions
+- Secrets in Rule code exposed to tenant admins or via Management API leak
+
+**Signup / Registration Actions**
+- `pre-user-registration` not blocking disposable emails or role self-assignment
+- Social connection account linking without verified email → account takeover
+
+### Organizations (B2B Multi-Tenancy)
+
+- Missing `org_id` validation in API — user from Org A accesses Org B data
+- Invitation flows accepting attacker email domains
+- Organization membership not re-checked after role change
+
+### MFA Bypass
+
+- MFA not enforced on Management API or high-risk applications
+- Remember-browser cookie bypasses step-up for sensitive actions
+- MFA challenge only on Universal Login but API accepts password-grant tokens without MFA
+- Recovery codes/brute-force on enrollment endpoints
+
+### Account Takeover Vectors
+
+- Password reset link not invalidated after use; predictable reset tokens
+- Email verification not required before sensitive actions
+- Change password without re-auth or MFA
+- Linking attacker's social IdP to victim account (same email, unverified)
+
+### Management API
+
+- M2M app with excessive scopes: `delete:users`, `update:users_app_metadata`
+- Management API token in frontend JavaScript or mobile app
+- Rate limiting absent on `/api/v2/users` enumeration
+
+### Custom Database Scripts
+
+- Custom login script with SQL injection in username lookup
+- `get_user` script returning excessive profile fields
+- Scripts with hardcoded credentials or weak hashing
+
+## Advanced Techniques
+
+**Cross-Application Token Confusion**
+- Same `client_secret` reused across environments (dev/prod)
+- Multiple APIs sharing signing keys without `aud` validation
+
+**Resource Owner Password Grant (if enabled)**
+- Legacy grant enabled — direct username/password to token endpoint, bypassing Universal Login MFA
+
+**Impersonation / Delegation**
+- `act_as` or delegation features misconfigured (legacy features in older tenants)
+
+## Testing Methodology
+
+1. **Extract tenant config** — Domain, client_id, audience, scopes from app
+2. **Callback/origin matrix** — Fuzz Allowed Callback URLs and Web Origins
+3. **Token validation** — Swap audiences, strip scopes, expired tokens, wrong signing keys
+4. **Org boundary** — Two org users accessing each other's org-scoped resources
+5. **MFA policy** — Sensitive actions without step-up; API paths bypassing MFA
+6. **Management API** — Hunt for leaked M2M creds; test scope boundaries
+7. **Rules/Actions** — Trace claim injection from `user_metadata` / `app_metadata`
+
+## Validation
+
+1. Demonstrate account takeover or cross-org access with token/callback/metadata abuse
+2. Show API accepting token without required scope/permission/audience
+3. MFA bypass PoC on protected application flow
+4. Document Auth0 setting (Rule, Application config, API RBAC) root cause
+5. Provide authorize → callback → API request chain with evidence
+
+## False Positives
+
+- Callback URL validation rejects all fuzz attempts consistently
+- API validates `aud`, `iss`, `scope`/`permissions` on every request
+- MFA enforced via Auth0 Action on every login for sensitive apps
+- `app_metadata` writable only by admin via Management API, not user signup
+- Organizations feature correctly binds `org_id` in token and API enforces it
+
+## Impact
+
+- Full account takeover across Auth0-connected applications
+- Cross-tenant data breach in B2B org deployments
+- Privilege escalation via metadata/claim injection in Rules
+- Mass user enumeration/modification via Management API abuse
+
+## Pro Tips
+
+1. Always capture full authorize URL — `audience` and `scope` reveal API targets
+2. Decode access token JWT — check `permissions`, `scope`, `org_id`, `https://.../roles` claims
+3. Test dev/stage tenants separately — often weaker callback rules
+4. Pair with `oauth` and `authentication_jwt` skills for flow/token layer testing
+5. Management API M2M creds in CI logs are high-value — search GitHub, buckets, artifacts
+
+## Summary
+
+Auth0 security spans tenant configuration (callbacks, MFA, Rules) and downstream API token validation (`aud`, `scope`, `permissions`, `org_id`). A perfectly configured Universal Login fails if the API accepts tokens without enforcing Auth0's authorization model.