GCP - Workflows Privesc
Last updated
Last updated
学习与实践 AWS 黑客技术:HackTricks 培训 AWS 红队专家 (ARTE) 学习与实践 GCP 黑客技术:HackTricks 培训 GCP 红队专家 (GRTE)
基本信息:
GCP - Workflows Enumworkflows.workflows.create
, iam.serviceAccounts.ActAs
, workflows.executions.create
, (workflows.workflows.get
, workflows.operations.get
)据我所知,无法通过访问包含与工作流关联的服务账户凭据的元数据端点来获得 shell。然而,可以通过在工作流中添加要执行的操作来滥用服务账户的权限。
可以找到连接器的文档。例如,这是 Secretmanager 连接器的页面. 在侧边栏中可以找到其他几个连接器。
在这里可以找到一个打印秘密的连接器示例:
从CLI更新:
如果您收到类似 ERROR: (gcloud.workflows.deploy) FAILED_PRECONDITION: Workflows service agent does not exist
的错误,请等待一分钟再试。
如果您没有网络访问权限,可以通过以下方式触发并查看工作流的执行:
您还可以检查先前执行的输出以查找敏感信息
请注意,即使您收到类似 PERMISSION_DENIED: Permission 'workflows.operations.get' denied on...
的错误,因为您没有该权限,工作流仍然已生成。
根据 文档,可以使用工作流步骤发送带有 OAuth 或 OIDC 令牌的 HTTP 请求。然而,就像在 Cloud Scheduler 的情况下,带有 Oauth 令牌的 HTTP 请求必须发送到主机 .googleapis.com
。
因此,通过指示用户控制的 HTTP 端点泄露 OIDC 令牌是可能的,但要泄露 OAuth 令牌,您需要 绕过 该保护。然而,您仍然可以使用连接器或带有 OAuth 令牌的 HTTP 请求 联系任何 GCP API 以代表 SA 执行操作。
workflows.workflows.update
...使用此权限而不是 workflows.workflows.create
,可以更新已存在的工作流并执行相同的攻击。
学习与实践 AWS 黑客技术:HackTricks 培训 AWS 红队专家 (ARTE) 学习与实践 GCP 黑客技术:HackTricks 培训 GCP 红队专家 (GRTE)