近年来,软件供应链的安全问题逐渐受到广泛关注。特别是在开源社区和企业级项目中,供应链攻击已成为黑客重点攻击的对象。Nx供应链攻击,作为近期被曝光的重大安全事件,其攻击过程展示了黑客如何利用Github工作流的漏洞逐步渗透,并最终窃取关键机密令牌,进而控制发布流程。本文将深入剖析Nx供应链攻击的起因和利用手法,详细介绍如何复现攻击的第一步,以提醒开发者重视Github Actions配置安全,进而加强软件供应链防护。 Github工作流令牌的权限与风险 在Github Actions中,自动化工作流程可以利用静态令牌GITHUB_TOKEN进行身份验证。此前,该令牌默认拥有读写权限,方便调用仓库内容和提交代码。
直到2023年,Github才调整策略,将默认权限降级,限制该令牌的操作范围。但依旧存在大量历史仓库未及时更新设置,仍保留原有高权限。Nx项目正是受此影响的代表之一。值得注意的是,GITHUB_TOKEN并非个人访问令牌(PAT),它是运行时的临时令牌,仅在工作流执行期间有效。尽管如此,攻击者仍可利用该令牌的读写权限,发起一系列恶意操作。该令牌不会自动注入到环境变量中,且在shell中也不可直接访问,但Github的actions/checkout操作会在git配置中写入包含令牌的认证信息。
攻击者通过特殊命令获取这段base64编码的认证凭据,从而提取令牌。 命令注入漏洞与工作流触发的巧妙利用 Nx项目中存在一个名为pr-title-validation.yml的工作流,其作用是验证拉取请求(PR)的标题格式。该工作流中的命令注入漏洞允许攻击者在PR标题中植入恶意shell命令。尽管开发团队修复了主分支中的漏洞,但部分分支的工作流仍未更新,导致漏洞仍然存在。攻击的关键在于工作流的触发机制,即pull_request_target事件。此触发器在执行时使用目标分支的权限,而非PR作者的权限,因此攻击者拥有访问目标仓库秘密信息的能力。
Github官方文档对使用pull_request_target进行警告,强调应谨慎使用,避免安全隐患。 攻击的复现步骤与实战解析 为了更清晰地说明攻击过程,研究者搭建了一个模拟环境,包含两个分支和两个相应的工作流。其中,test分支保留了漏洞工作流pr-title.yaml,而主分支则已修复漏洞。此外,还设置了一个模拟发布工作流publish.yaml,并配置了名为TEST_SECRET的秘密变量模拟NPM令牌。攻击者首先通过fork该仓库,修改test分支代码。随后他们创建包含恶意命令注入的PR标题,利用漏洞获取Github临时令牌。
具体来说,攻击者在PR标题中嵌入了curl命令,将git配置中的认证信息发送到攻击者控制的服务器地址,同时利用sleep命令延长工作流执行时间,为下一步利用争取操作时间。成功窃取到令牌后,攻击者基于该令牌克隆仓库,检出test分支,并在新建的攻击分支中插入恶意代码。此恶意代码植入了发布工作流用到的脚本文件/scripts/publish-resolve-data.js,该脚本调用了publish.yaml工作流。利用流程中环境变量中注入的TEST_SECRET,攻击者将秘密令牌发送至远程服务器,从而获得NPM发布权限。攻击者最后通过Github API手动触发发布工作流workflow_dispatch,实现恶意发布的全过程。 安全隐患与防护建议 Nx供应链攻击揭示了软件开发过程中潜藏的多个安全风险。
首先,Github工作流默认令牌的高权限是核心风险点。团队应及时调整GITHUB_TOKEN权限为最小化原则,并避免在不同分支间权限配置不统一。其次,pull_request_target触发器在访问权限方面存在先天风险,尤其在处理外部贡献代码时,务必避免使用触发命令执行的验证策略。命令注入漏洞的存在为攻击提供了入口,代码审计及自动化安全检测手段应覆盖CI配置文件和自定义脚本。模拟环境下的复现也表明,秘密变量在公有库或多贡献者项目中一定要谨慎配置,仅供受信任分支和工作流使用。对工作流脚本进行签名或权限限制同样是强化安全的有效保障。
展望未来,开发者应将供应链安全列为项目治理核心。充分理解工作流权限机制、采用细粒度访问控制,以及引入多因素认证和异常检测技术都将极大降低被攻击风险。此外,及时修补公开漏洞,保持依赖的第三方包更新状态,同样不可或缺。 总结 Nx供应链攻击案例深刻揭示了自动化开发流程中多层面安全隐患如何被黑客连环利用。通过复现攻击的首步,我们了解到Github Actions中令牌权限、触发机制及命令注入漏洞共同构成攻破路径。安全从代码细节到运行环境、从配置策略到团队协作,每一步都不容忽视。
提升供应链安全不仅是技术问题,更是关乎企业信誉和用户信任的关键环节。希望广大开发者能借此警示,完善防护体系,共筑安全的开源生态环境。 。
