Skip to content

Add GCP and Auth0 security skills #665

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
Ayush7614 wants to merge 2 commits into
base: main
Choose a base branch
from
+382 −0
Open

Add GCP and Auth0 security skills #665

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
d116cc6
Add GCP and Auth0 security skills
Ayush7614 Jul 3, 2026
27a5130
Address Greptile review: GCP and Auth0 recon guidance
Ayush7614 Jul 4, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
194 changes: 194 additions & 0 deletions strix/skills/cloud/gcp.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,194 @@
---
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**

Avoid `gsutil` for anonymous checks — it can use ambient `gcloud` or application-default credentials and produce false public-bucket findings. Unset `GOOGLE_APPLICATION_CREDENTIALS` and use unauthenticated HTTP instead.

```
# GCS bucket existence (403 = exists but private, 404 = not found/wrong region)
curl -I https://storage.googleapis.com/target-bucket/

# Anonymous listing (no Authorization header; confirms allUsers/allAuthenticatedUsers List)
curl https://storage.googleapis.com/target-bucket/

# Alternate URL forms
curl -I 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 # requires credentials
curl https://storage.googleapis.com/BUCKET/ # anonymous listing check
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.
188 changes: 188 additions & 0 deletions strix/skills/technologies/auth0.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,188 @@
---
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
```

**Authenticated Userinfo** (requires bearer access token — unauthenticated requests return 401)
```
GET https://TENANT.auth0.com/userinfo

@greptile-apps greptile-apps Bot Jul 3, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 security Userinfo Requires A Token

/userinfo is grouped with public discovery endpoints, but a correctly configured Auth0 tenant returns 401 unless the request includes a bearer access token. A tester following this literally can treat the expected auth failure as an OIDC discovery result instead of validating the authenticated userinfo path.

Suggested change
GET https://TENANT.auth0.com/userinfo
GET https://TENANT.auth0.com/userinfo
Authorization: Bearer <access_token>
Prompt To Fix With AI 
This is a comment left during a code review.
Path: strix/skills/technologies/auth0.md
Line: 43

Comment:
**Userinfo Requires A Token**

`/userinfo` is grouped with public discovery endpoints, but a correctly configured Auth0 tenant returns `401` unless the request includes a bearer access token. A tester following this literally can treat the expected auth failure as an OIDC discovery result instead of validating the authenticated userinfo path.

```suggestion
GET https://TENANT.auth0.com/userinfo
Authorization: Bearer <access_token>
```

How can I resolve this? If you propose a fix, please make it concise.

Authorization: Bearer <access_token>
```

**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.