标签 个人访问令牌 下的文章

亚马逊网络服务(AWS)CodeBuild中的一项关键配置错误,可能导致攻击者完全接管该云服务提供商自身的GitHub仓库(包括其AWS JavaScript SDK),从而使每个AWS环境面临风险。

该漏洞已被云安全公司Wiz命名为CodeBreach。AWS在2025年8月25日收到负责任披露后,已于2025年9月修复此问题。

"通过利用CodeBreach,攻击者可能注入恶意代码以发起平台级入侵,不仅可能影响无数依赖该SDK的应用程序,还可能威胁控制台本身,危及每个AWS账户,"研究人员Yuval Avrahami和Nir Ohfeld在与The Hacker News分享的报告中表示。

Wiz指出,该漏洞源于持续集成(CI)管道中的一个弱点,可能使未经身份验证的攻击者侵入构建环境,泄露GitHub管理员令牌等特权凭证,然后利用这些凭证向受感染的仓库推送恶意更改——从而为供应链攻击开辟途径。

换言之,该问题破坏了AWS引入的webhook过滤器机制,这些过滤器原本用于确保只有特定事件才能触发CI构建。例如,AWS CodeBuild可以配置为仅当代码更改提交到特定分支时,或当GitHub或GitHub Enterprise Server账户ID(即ACTOR_ID或参与者ID)与正则表达式模式匹配时才触发构建。这些过滤器旨在防范不受信任的拉取请求。

此配置错误影响了以下AWS管理的开源GitHub仓库,这些仓库配置为在拉取请求时运行构建:

  • aws-sdk-js-v3
  • aws-lc
  • amazon-corretto-crypto-provider
  • awslabs/open-data-registry

这四个项目虽然实施了ACTOR_ID过滤器,但存在一个"致命缺陷":它们未包含两个确保精确正则表达式匹配所必需的字符——即起始锚点^和结束锚点$。相反,正则表达式模式允许任何作为已批准ID(例如755743)超字符串的GitHub用户ID绕过过滤器并触发构建。

由于GitHub按顺序分配数字用户ID,Wiz表示能够预测新用户ID(目前为9位)大约每五天就会"覆盖"一位受信任维护者的六位ID。这一发现,结合使用GitHub Apps自动化创建应用程序(进而创建相应的机器人用户),使得通过触发数百个新机器人用户注册来生成目标ID(例如226755743)成为可能。

获得参与者ID后,攻击者现在可以触发构建并获取aws-sdk-js-v3 CodeBuild项目的GitHub凭证——一个属于aws-sdk-js-automation用户的个人访问令牌(PAT),该令牌对仓库拥有完全管理员权限。

攻击者可以利用这种提升的访问权限直接向主分支推送代码、批准拉取请求并窃取仓库机密,最终为供应链攻击创造条件。

"上述仓库为AWS CodeBuild webhook过滤器配置的正则表达式本意是限制受信任的参与者ID,但存在不足,使得可预测获取的参与者ID能够获得受影响仓库的管理权限,"AWS在今天发布的公告中表示。

"我们可以确认,这些是这些仓库webhook参与者ID过滤器中的项目特定配置错误,而非CodeBuild服务本身的问题。"

亚马逊还表示已修复已发现的问题,并实施了额外的缓解措施,例如凭证轮换以及保护包含GitHub令牌或内存中任何其他凭证的构建流程的步骤。该公司进一步强调,未发现CodeBreach在野外被利用的证据。

为降低此类风险,必须确保不受信任的贡献不会触发特权CI/CD管道,具体措施包括:启用新的Pull Request Comment Approval构建门控、使用CodeBuild托管运行器通过GitHub工作流管理构建触发器、确保webhook过滤器中的正则表达式模式被锚定、为每个CodeBuild项目生成唯一的PAT、将PAT权限限制在最低必要范围,并考虑使用专用的无特权GitHub账户进行CodeBuild集成。

"此漏洞是一个教科书般的案例,说明了为什么攻击者以CI/CD环境为目标:一个微妙且容易被忽视的缺陷可能被利用以产生巨大影响,"Wiz研究人员指出。"复杂性、不受信任的数据和特权凭证的结合,为无需事先访问即可造成高影响入侵创造了完美条件。"

这并非CI/CD管道安全首次受到关注。去年,Sysdig的研究详细说明了如何利用与pull_request_target触发器相关的不安全GitHub Actions工作流,通过单个分叉拉取请求泄露特权GITHUB_TOKEN并获取对数十个开源项目的未授权访问。

Orca Security的一项类似的两部分分析发现,谷歌、微软、英伟达及其他财富500强公司的项目中存在不安全的pull_request_target配置,可能允许攻击者运行任意代码、窃取敏感机密并向受信任分支推送恶意代码或依赖项。这一现象被称为pull_request_nightmare。

"通过滥用通过pull_request_target触发的配置错误的工作流,攻击者可以从不受信任的分叉拉取请求升级为在GitHub托管甚至自托管运行器上执行远程代码(RCE),"安全研究员Roi Nisimi指出。

"使用pull_request_target的GitHub Actions工作流绝不应在没有适当验证的情况下检出不受信任的代码。一旦这样做,它们就面临完全被入侵的风险。"