找回密码
立即注册
搜索
热搜: Java Python Linux Go
发回帖 发新帖

3027

积分

0

好友

412

主题
发表于 昨天 03:44 | 查看: 2| 回复: 0

AWS CodeBuild 服务中的一个严重配置错误,使得攻击者无需身份验证即可控制多个由 AWS 持有的关键 GitHub 代码仓库。其中,为 AWS 控制台本身提供支持的、被广泛使用的 AWS JavaScript SDK 也受到影响。这种供应链层面的漏洞直接威胁着整个 AWS 平台的安全,可能导致恶意代码被注入到全球无数依赖这些库的应用程序和控制台中。

这项由安全公司 Wiz Research 披露的漏洞被命名为 “CodeBreach” 。其根源在于 CodeBuild 的 Webhook 过滤器中,用于验证 GitHub 用户身份的 ACTOR_ID 参数所采用的正则表达式模式缺少了锚定符(^$)。这个过滤器本应只允许特定、受信任的 GitHub 用户 ID 触发构建任务。

然而,由于缺少首尾锚定,这个过滤器实际上会匹配任何包含已批准子字符串的用户 ID。攻击者可以利用 GitHub 的 “eclipse” 事件机制进行绕过——当用户更改用户名时,GitHub 会分配一个新的、更长的唯一数字 ID,但这个新 ID 会将旧的维护者 ID 包含在内。

AWS CodeBreach供应链攻击流程图

GitHub 每天会顺序生成约 20 万个新的用户 ID,这使得像 aws/aws-sdk-js-v3aws/aws-lccorretto/amazon-corretto-crypto-providerawslabs/open-data-registry 这四个目标仓库所设的 6-7 位短数字 ID 经常与其他新 ID 发生重叠。

攻击者正是利用了这一点,他们通过脚本批量创建 GitHub 应用来“争夺”这些可能包含目标 ID 的“eclipse ID”,然后向目标仓库提交拉取请求(PR),以此触发具有高权限的构建流程。

在针对 aws/aws-sdk-js-v3 仓库的一次概念验证攻击(PR #7280)中,攻击者在构建过程中执行了隐藏的有效载荷代码。这段代码从内存中转储信息,成功从 aws-sdk-js-automation 服务账户中提取出了 GitHub 个人访问令牌(PAT)。值得注意的是,尽管 AWS 此前已针对 2025 年初的 Amazon Q 事件采取了缓解措施,但此类令牌泄露风险依然存在。

针对CodeBuild的PR攻击示意图

窃取到的 PAT 令牌拥有 repoadmin:repo_hook 权限。这意味着攻击者可以邀请其他账户成为仓库协作者,实现权限提升,并最终获得直接向主分支推送代码的能力。

Wiz 向媒体透露,一旦 AWS JavaScript SDK 被攻陷,其每周发布的 NPM 包就可能被植入恶意代码。这将直接影响全球 66% 的云环境扫描结果,因为 AWS 控制台本身会将最新的 SDK 版本与用户凭证捆绑交付。这种攻击路径无疑对整个云计算生态的安全构成了严峻挑战。

被盗的 PAT 还可能控制相关的私有代码库,从而进一步放大供应链风险。这与之前的 Nx S1ngularity 攻击或 AWS-2025-015(Amazon Q)安全事件有相似之处。Wiz 在研究团队完成概念验证后立即停止了攻击模拟,并于 2025 年 8 月 25 日遵循负责任披露原则向 AWS 报告了该漏洞。

受CodeBreach漏洞影响的AWS GitHub仓库列表

AWS 在接到报告后的 48 小时内迅速响应并修复了正则表达式漏洞。安全团队不仅撤销了涉事的令牌,还加强了运行时的内存保护机制,审核了所有可能受影响的公共软件版本,并通过日志分析确认该漏洞在修复前未被实际利用。

AWS 确认,没有客户数据在此次事件中受到影响。此外,AWS 也启用或强化了多项防护功能,例如拉取请求评论审批流程和 CodeBuild 托管运行器,这些措施现在能够有效阻止来自不受信任来源的构建任务。

对于广大开发者和运维团队而言,此次事件提供了重要的安全实践教训:

  1. 锚定你的正则表达式:在配置 Webhook 或其他过滤规则时,务必使用 ^$ 来精确匹配,避免子字符串匹配带来的风险。
  2. 遵循最小权限原则:为自动化流程(如 CI/CD)使用的个人访问令牌(PAT)或密钥,应授予其完成工作所必需的最小权限,并定期轮换。
  3. 启用审批门禁:对于重要的代码仓库,务必启用拉取请求(PR)必须经过审批才能合并的规则,避免自动化构建被恶意 PR 直接触发。
  4. 定期审计配置:使用安全工具或脚本定期扫描 CI/CD 管道、仓库权限等配置,查找是否存在类似的不安全设置。

AWS 也建议用户,应谨慎对待来自不可信来源的自动化 PR 构建,必要时予以禁用。整个攻击流程凸显了一条清晰的路径:一个恶意的 PR 如何通过层层漏洞,最终威胁到核心云服务控制台的安全。对于此类复杂的供应链攻击,保持警惕和持续的安全加固至关重要。如果你想了解更多关于云原生环境下的攻防实践,欢迎来 云栈社区 与更多技术同仁交流探讨。




上一篇:Solana Pinocchio v0.10.1 托管合约实战:AccountView 零拷贝与 0.15s 极速编译
下一篇:Kubernetes 核心实践:为什么 Pod 重建后你的手工修改会消失?理解声明式配置与 YAML 的权威性
您需要登录后才可以回帖 登录 | 立即注册

手机版|小黑屋|网站地图|云栈社区 ( 苏ICP备2022046150号-2 )

GMT+8, 2026-2-7 08:54 , Processed in 0.298477 second(s), 40 queries , Gzip On.

Powered by Discuz! X3.5

© 2025-2026 云栈社区.

快速回复 返回顶部 返回列表