AWS CodeBuild 配置错误暴露 GitHub 仓库,引发潜在供应链攻击风险
HackerNews 编译,转载请注明出处: 亚马逊网络服务CodeBuild中的一个关键配置错误,可能导致攻击者完全接管该云服务提供商自身的GitHub仓库,包括其AWS JavaScript SDK,从而使每个AWS环境面临风险。 该漏洞被云安全公司Wiz命名为CodeBreach。在2025年8月25日进行负责任披露后,AWS已于2025年9月修复了该问题。 “通过利用CodeBreach,攻击者可能注入恶意代码,发起一次平台级的入侵,不仅可能影响无数依赖该SDK的应用程序,还可能威胁到控制台本身,危及每一个AWS账户,”研究员Yuval Avrahami和Nir Ohfeld在分享给The Hacker News的一份报告中表示。 Wiz指出,该漏洞源于持续集成流水线中的一个弱点,可能使未经身份验证的攻击者入侵构建环境、泄露特权凭证(如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过滤器,但存在一个”致命缺陷”:它们未包含确保完全正则表达式(regex)匹配所需的两个字符——即起始锚点 ^ 和结束锚点 $。相反,正则表达式模式允许任何是受批准ID超字符串(例如,755743)的GitHub用户ID绕过过滤器并触发构建。 由于GitHub按顺序分配数字用户ID,Wiz表示能够预测新用户ID(目前为9位长)大约每五天就会”超过”一位受信任维护者的六位ID。这一洞察,结合使用GitHub应用来自动化应用创建(这反过来会创建一个对应的机器人用户),使得通过触发数百次新的机器人用户注册来生成目标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流水线,可通过启用新的”拉取请求评论批准”构建门控功能、使用CodeBuild托管的运行器通过GitHub工作流管理构建触发器、确保Webhook过滤器中的正则表达式模式使用锚点、为每个CodeBuild项目生成唯一的PAT、将PAT的权限限制在所需的最低范围,并考虑为CodeBuild集成使用一个专用的无特权GitHub账户来实现。 网络安全 “此漏洞是一个典型的例子,说明了为什么攻击者将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工作流,绝不应在没有适当验证的情况下检出不受信任的代码。一旦这样做,它们就面临完全入侵的风险。” 消息来源:thehackernews; 本文由 HackerNews.cc 翻译整理,封面来源于网络; 转载请注明“转自 HackerNews.cc”并附上原文