🏢 公司C档 · NaN分

黑客不偷代码,只偷你的密钥

··约1分钟阅读

📋 总体概括

GitHub Actions 被注入恶意工作流,2577 个秘密成为目标、26 个确认失窃;npm 侧 MALFEX 战役用八个恶意包传播 RAT 与信息窃取器。本文拆解 CI/CD 密钥窃取的攻击链、攻击经济学与防御版图,给出可落地的三道闸门。

📄 正文

两起独立事件,同一个信号:攻击者不再费劲撬你的边界,而是直接走进你的构建流水线,把 SSH 私钥、云凭证、访问令牌装包带走。GitHub Actions 恶意工作流窃密与 npm 供应链投毒几乎同时浮出水面,暴露的是同一个结构性短板——开发者基础设施里的秘密,长期处于裸奔状态。

这不是又一次"狼来了"。看清攻击链怎么走、钱在哪里、防御卡在哪一环,比焦虑有用得多。

🔑 CI/CD 从效率工具变成攻击面

据 GBHackers 披露的情报,攻击者把恶意工作流伪装成"安全检查"注入 GitHub 仓库。表面上是一次常规的 CI 校验,实际上 Runner 一启动,环境变量里的秘密就成了待宰的羔羊:SSH 私钥、云平台凭证、各类 API 访问令牌,全在攻击者的读取范围内。

整个攻击链路并不复杂,复杂的是它对信任边界的精准利用:

CI/CD 系统的默认假设是"仓库里的工作流可信"。一旦这个假设被打破,Runner 拥有的权限就是攻击者的权限——而 Runner 恰恰是企业里权限最集中的节点之一,它要拉代码、要连云、要部署。

一位长期做红队的朋友私下说过一句话:"打一个硬化好的数据中心要三周,偷一个配错的 CI 密钥只要三分钟。" 产业逻辑就在这里:攻击者永远选择信任模型里最薄弱的那条缝。云原生时代,这条缝从网络边界挪到了流水线。

📊 2577 与 26:一笔攻击的账

这起事件里有两个数字值得反复咀嚼。

  • 2577:恶意工作流锁定、试图窃取的秘密数量;
  • 26:研究人员确认成功外泄的秘密数量,来自 13 个仓库。

差距接近两个数量级。这不是攻击者手下留情,而是"注入"和"执行"之间天然存在的漏斗损耗——工作流被投进去,不等于 payload 真的跑起来;秘密被盯上,不等于真的被偷走。研究者特意强调了这个区分:恶意注入不等于窃密成功。

从攻击经济学的角度看,这仍然是一笔划算的买卖。一次成功外泄的云凭证,在黑市上可以直接兑换出云主机、数据访问乃至后续勒索的入口。样本量足够小、成本足够低、回报足够高——这就是为什么 CI/CD 窃密会成为一个可复制、可规模化的攻击模式,而不是孤立的炫技。

据多位接近云厂商安全团队的人士透露,这类"流水线取钥匙"的手法,正在从定向攻击向半自动化扫荡演变。防御方的应对窗口,比多数人想象的要短。

🐛 npm 上的"单干户":MALFEX 织了十个月的网

如果说 GitHub Actions 事件是打企业流水线的主意,那 MALFEX 战役瞄准的就是开发者本人。

据披露,这是一场持续活跃的 npm 供应链投毒行动,通过八个恶意包分发 Windows 恶意软件,背后的运营者看起来只有一个人,自 2023 年 8 月起持续活动。载荷相当齐全:Overlord RAT 远控木马、一款类 movinlike 的信息窃取器,还有一个藏在 ASCII-art 小工具里的独立下载器——伪装得足够有"极客味",开发者没理由怀疑。

这场战役的时间线大致如下:

  • 2023 年 8 月:疑似单一运营者开始投递恶意包;
  • 此后持续:function-flag 等包长期携带恶意代码,未被及时下架;
  • 截至披露:八个包组成分发网络,窃取浏览器密码、Discord 令牌、加密货币钱包。

贡献最大的恶意包 function-flag 累计下载量达到 37,419 次。三万七千多次下载,意味着三万七千多个可能被植入信息窃取器的开发环境。

这起战役的恐怖之处在于它的"温火"属性。它不追热点、不赶工期,一个人安静地运营了十个月,把恶意逻辑埋进功能正常的工具包里,等开发者的浏览器密码、Discord 令牌和加密钱包自己送上门。

产业逻辑同样清晰:开发者个人机是整条软件供应链里权限最高、防护最弱的一环。偷到开发者的浏览器凭证和钱包令牌,等于同时拿到了身份、资产和向企业内网渗透的跳板。MBR 化的供应链攻击不需要 0day,只需要一点耐心。

🗺️ 两起事件拼出同一张地图

把两件事放在一张表里看,趋势一目了然:

维度GitHub Actions 窃密MALFEX npm 战役
攻击入口恶意工作流(伪装安全检查)恶意 npm 包
攻击目标SSH 密钥、云凭证、访问令牌浏览器密码、Discord 令牌、加密钱包
关键数字2577 个秘密被锁定,26 个确认外泄,涉及 13 仓库8 个恶意包,function-flag 下载 37,419 次
载荷Runner 上的窃密 payloadOverlord RAT、信息窃取器、下载器
攻击者画像疑似有组织、定向疑似单人、长线运营

入口不同、载荷不同,但窃取对象高度重合——凭证与秘密。这是新一代攻击者的共识:代码在仓库里,钱在密钥里。攻击者根本不需要理解你的业务逻辑,拿到一张有效的云凭证,业务逻辑就是他的了。

这也解释了为什么近年来大厂密集推动短效凭证、工作负载身份联邦这类机制——本质上是在釜底抽薪:让"偷一把万能钥匙"这件事,变得偷不到、用不久。

🛡️ 三道闸门:把秘密关进笼子

看完攻击链,防御思路其实已经摆在桌面上了。核心是三条:少放、短效、盯行为。

CI/CD 秘密防护三板斧
痛点 1
环境变量里长期躺着长期有效的主密钥
→
解法
改用短效联邦凭证与 OIDC 身份,令牌生命周期压到分钟级
痛点 2
恶意工作流伪装成安全检查即可触达 Runner
→
解法
工作流权限最小化,restrict 触发来源,高危仓库启用审批门禁
痛点 3
恶意 npm 包混入依赖树数月无人察觉
→
解法
引入依赖来源审计与 SBOM 追踪,新包锁定版本并做行为分析
痛点 4
秘密外泄往往数周后才被发现
→
解法
对 Runner 与构建环境做运行时行为监控与外联告警

三个动作按优先级排序的话:先减权,再换短效,最后上监控。多数团队的误区是把预算全砸在"发现"上,却对"根本不该有这把长期钥匙"无动于衷。安全预算的边际收益,往往在第一道闸门最高。

结语

GitHub Actions 上的 2577 比 26,npm 上的三万七千次下载,两组数字拼出同一个判断:软件供应链的攻击重心,已经从"偷代码"转向"偷凭证"。未来一两年,随着 AI 加速代码产出、依赖规模继续膨胀,这个面只会更大。对每一家用云、用 CI/CD、用开源的团队来说,问题不再是"要不要管好流水线里的秘密",而是"还能拖多久"。把长钥匙换成短令牌这件事,今天做,比 breach 通报发出后做,便宜一百倍。

本文由本站 AI 辅助聚合生成,原始来源如下:

🔎 本文基于以下资讯(素材溯源 · 信息来源)

📰 相关阅读推荐(与本文相关的其他资讯)