事件回顾：被“组合”出来的风险
近期，Token Security 的研究人员披露了一个针对 Zapier 平台的五阶段攻击链。虽然每一个环节在单点安全审查中看似都是“已知风险”或“低危隐患”，但通过攻击者的巧妙串联，最终演变成了一场针对 Zapier 核心 SDK 及前端组件的潜在供应链攻击。
从我们的应急响应经验来看，这种“缝隙中的风险”往往最难被发现。由于每一个环节（如 Lambda 运行时、AWS 权限配置、Docker 镜像构建、NPM 包发布）通常由不同的团队或部门负责，各团队往往只关注自身领域的合规性，而忽视了跨系统边界的风险叠加。
攻击链深度拆解
该攻击链的成功实施依赖于五个关键阶段的串联：
第一阶段：Lambda 环境逃逸。攻击者利用“Code by Zapier”功能运行自定义代码，通过读取 /proc/self/mem 并配合正则匹配，成功从内存中恢复了本应被擦除的 AWS STS 会话令牌。这一环节是很多企业容易忽视的，仅仅删除环境变量并不代表内存中的敏感信息被彻底清除。
第二阶段：AWS 权限枚举。攻击者获得的 allow_nothing_role 虽然权限受限，但通过其中的 ECR 镜像拉取权限，成功枚举并获取了 1,111 个生产环境的容器镜像。
第三阶段：敏感信息泄露。在容器镜像的构建历史中，攻击者发现了一个被错误留在 Dockerfile ARG 中的 NPM 发布令牌。该令牌不仅具备写权限，还配置了绕过双因子认证（Bypass 2FA）。
第四阶段：供应链投毒。利用获取的 NPM 令牌，攻击者理论上可以篡改包括 zapier-platform-core 和 zapier-design-system 在内的核心包。
第五阶段：前端劫持。由于 zapier-design-system 会在用户登录 Zapier 平台的每一个会话中加载，一旦被投毒，攻击者便能在用户浏览器中执行恶意 JavaScript，进而控制用户的 Zap、表格及集成服务。
Solar 团队安全洞察
类似攻击近年来明显增加，其核心逻辑在于利用云原生架构的复杂性进行“权限堆叠”。本次事件中，即便 Zapier 采取了常规的凭据擦除措施，但由于对进程堆内存残留缺乏足够防护，导致了第一块多米诺骨牌倒下。
对于广大开发者和安全团队，我们有以下几点建议：
首先，容器镜像安全是重中之重。严禁在 Dockerfile 中通过 ARG 传递敏感凭据，因为这些信息会永久固化在镜像层历史中。建议使用构建时的机密注入方案（如 BuildKit Secrets）。
其次，关注“权限下放”的最小化原则。虽然 allow_nothing_role 听起来权限极低，但结合 ECR 的读取能力，依然能造成信息泄露。在云环境配置中，应定期对 IAM 角色进行权限梳理，消除冗余的读取权限。
最后，建立跨团队的威胁建模机制。正如本案研究人员所言，风险往往隐藏在“不同系统之间的缝隙”里。安全团队不仅要盯着代码，更要盯着数据流转的全链路，确保每个环节的边界控制都经得起推敲。
目前，Zapier 已经完成了对相关令牌的撤销与权限收紧，并确认该路径未被恶意滥用。对于企业而言，这也是一次极佳的防御演练参考。
如果您想了解勒索病毒的最新发展趋势，或在实际业务中遇到类似安全事件，欢迎关注“Solar应急响应团队”。
全国热线：400-613-6816 官网：www.solarsecurity.cn / www.sierting.com