Bad.Build:最新的 Google Cloud 漏洞

Bad.Build:威胁软件供应链的最新 Google Cloud 漏洞

介绍

Orca Security 最近发现了 Google Cloud Build 服务中的一个设计缺陷,名为“Bad.Build”。此缺陷带来了严重的安全风险,因为它使攻击者能够执行特权升级,从而允许他们未经授权进入 Google 的 Artifact Registry 的代码存储库。

此漏洞的影响延伸至软件供应链,因为攻击者可利用此漏洞恶意篡改应用程序映像。因此,安装被篡改应用程序的不知情的用户和客户可能会成为感染的受害者。

这种情况让我们想起了过去供应链攻击造成的重大影响,例如 SolarWinds, 3CX移动它,强调此类安全漏洞的深远影响。

如何运作的?

Google 云构建 代表持续集成/持续交付(CI/CD) 是 Google Cloud 生态系统中提供的服务。它通过与其他基本服务(例如 Artifact Registry 和 App Engine)无缝交互,在基于云的应用程序中发挥着至关重要的作用。

当前存在的缺陷是由于权限过高造成的。具体来说,“日志记录.privateLogEntries.列表”操作无意中允许将审计日志列给非预期角色,即“角色/cloudbuild.builds.builder设立的区域办事处外,我们在美国也开设了办事处,以便我们为当地客户提供更多的支持。“

遗憾的是,此默认角色被分配给云构建服务帐户。这种情况带来了严重风险,因为审计日志包含敏感信息,揭示了与项目相关的所有权限。这种意外访问使攻击者能够冒充云构建帐户,从而了解不同的 Google 帐户可以执行哪些操作。因此,这为横向移动和特权升级打开了大门,带来了极其危险的安全漏洞。

模拟构建服务帐户只需要 cloudbuild.builds.创建 许多预定义角色都具有该权限,并且该权限可以以任何合理的方式授予开发人员 CI/CD 使用 Cloud Build 构建环境。因此,如果您有权访问此类开发者帐户,则创建定制的构建配置文件实际上会运行 gcloud logs 读取命令,其中将列出权限。

但问题还不止于此: Google Cloud Build 服务帐户具有高度特权,其中包含许多与 Goggle 的 Artifact Registry 进行交互的操作。

 图片:Bad.Build 工作原理说明

利用允许冒充默认 Cloud Build 服务帐号的漏洞,恶意行为者可以通过注入恶意代码来篡改存储在 Google Artifact Registry 中的映像。因此,任何基于这些受感染映像构建的应用程序都可能遭受潜在后果,包括拒绝服务 (DoS) 攻击、数据窃取和恶意软件传播。

当这些被操纵的应用程序准备部署到客户环境中时,情况的严重性就会升级,无论 on-premise 或半 SaaS。这将风险扩展到供应组织的基础设施之外,导致供应链攻击渗透并破坏客户的环境。此类攻击类似于之前在软件供应链漏洞中看到的事件,例如 SolarWinds 漏洞。此类攻击的影响可能很严重,造成广泛损害并影响供应链中的多个组织

有一个类似的特权升级 PoC, 犀牛安全实验室,它以不同的方式利用了默认 Cloud Build 帐户的过多权限。 

为什么是危险的?

此漏洞的严重性在于攻击者可能利用 Artifact Registry 并将恶意代码引入工件。因此,任何基于这些受感染镜像构建的应用程序都容易受到各种不利影响。

这些影响包括拒绝服务攻击、数据窃取和恶意软件传播的可能性。此外,如果这些受感染的应用程序随后被部署 on-premise 或者在半 SaaS 环境中,风险不仅会波及受害组织,还会波及他们的客户。这种情况类似于 SolarWinds 事件中见证的供应链攻击,突显了对组织及其客户群的潜在后果。

  •  Xygeni 推荐

     

    应用最小特权原则

     

  • Xygeni 传感器 监控部署系统中的用户操作,并将其与我们的核心平台共享,该平台可识别异常行为或偏离正常模式的行为,例如异常 login 时间或地点、大量数据传输或用户访问权限的变化超出了所建模的“正常”用户行为范围。

    Xygeni 的政策和审计强制执行访问控制、多因素身份验证要求和基于角色的权限应用程序方面的最佳实践,以限制用户对关键系统和数据的访问。

    这些工具监控用户操作,例如代码更改、系统访问或数据传输,并将它们与预定义的策略和行为模式进行比较。 它们还会标记可疑活动,例如未经授权的访问、过度的权限或不寻常的数据传输模式.

如何处理漏洞

在通知 Google 安全团队该漏洞后,他们采取行动,撤销了默认 Cloud Build 服务帐户的 logsing.privateLogEntries.list 权限。他们承认,虽然 setIamPolicy 审计日志与审计目的相关,但从 Cloud Build 服务帐户的角度来看,授予对这些日志的访问权限是不必要的。

然而,必须明白的是,这一响应并没有直接解决 Artifact Registry 中的根漏洞。因此,特权升级向量和供应链攻击的潜在风险仍未受到影响。从本质上讲,Google 的修复限制了该问题,但并未完全消除它,使组织仍然面临重大的软件供应链风险。

针对这种情况,谷歌建议其客户修改默认云构建服务帐户的权限,删除任何偏离最小特权原则 (PoLP) 的授权凭据。此措施旨在通过确保帐户仅具有执行其预期任务所需的最低必要权限来增强安全性。

为了防御这种特权升级攻击,有必要限制授予云构建服务帐户的权限,并谨慎授予 cloudbuild.builds.创建 向组织中的任何用户授予权限。最重要的是,您需要知道,任何被授予权限的用户 cloudbuild.builds.创建,也间接授予了授予 Cloud Build 服务帐户的所有权限。如果您不介意的话,那么您可能不需要担心这个攻击媒介,但仍然强烈建议您修改授予 Cloud Build 服务帐户的默认权限。

Google 简洁地推荐,但没有提供进一步的细节:

“如果您不打算在构建过程中执行某项操作,我们建议您从 Cloud Build 服务帐户中撤销相应的权限,以遵守最小特权的安全原则。”

时间线

2020年XNUMX月

Rhino Security Labs 发布了有关权限提升问题的信息并为其创建了一个 PoC python 脚本*。

六月 - 2023

Orca Security 向 Google 安全团队报告了他们的发现。

08 年 2023 月 XNUMX 日

谷歌进行了调查并实施了部分修复。

然而,必须注意的是,谷歌的补救措施并没有完全消除发现的特权升级 (PE) 向量。相反,它限制了其影响,实际上将其转变为一个设计缺陷,仍然使组织面临更广泛的供应链攻击风险。因此,安全团队需要采取额外措施来防范这种挥之不去的风险。

结语

攻击者可以利用授予默认 Google Cloud Build 帐户的过多权限,使用允许创建云构建的开发者帐户发起攻击。攻击者可能会窃取容器映像,使用恶意行为对其进行篡改,然后将其推送到 Artifact Registry,从而发起软件供应链攻击,这可能会造成灾难性的后果。

谷歌的回应将缓解工作留给了使用 Cloud Build 服务的组织,这些组织需要撤销权限来控制风险。人们可能会要求谷歌在未来提供额外的帮助来处理其安全问题 CI/CD 系统。

了解有关 Xygeni 平台的更多信息,下载 Xygeni 平台数据表

sca-tools-软件-成分分析工具
确定软件风险的优先级、进行补救并加以保护
注册免费账号。
不需要信用卡。

保护您的软件开发和交付

使用 Xygeni 产品套件