最近公司部分 GitHub 仓库里忽然冒出一些奇怪的文件，开发同事发现后第一时间交给我分析。一查之下，确认是木马脚本。这就让人纳闷了：这脚本到底是怎么混进来的？按理说不应该啊。
赶紧去翻看 GitHub 的提交记录（commit），发现是一个同事强行推送到主分支的提交里携带的。看到这儿，我心里咯噔一下：完了，同事的电脑八成是中毒了。
立刻跑到那位同事工位检查他的电脑。果不其然，系统里存在一个持久化进程（形如 node -e “恶意代码”）。接着我们找到了这个持久化进程的配置文件（plist），打开一看，好家伙，配置得明明白白。
我们删除了相关配置和文件，确认病毒程序不再自启动后，大致分析了这段恶意代码的行为。其主要功能是在被感染的机器上建立外联通信，窃取敏感信息，并安装浏览器插件来劫持网络请求数据。哦，对了，它还会挖矿（emmmmm，真是“物尽其用”）。
回过头来复查 GitHub 的日志以及服务器日志，发现恶意行为在问题暴露前就已经零星出现了。万幸的是，在后续的风险排查中我们发现，这些被成功推送到仓库的恶意代码，在持续集成（CI）环节不是被拦截就是报错了，并没有真正部署到生产环境里——这真是不幸中的万幸。
不过，经过一番排查，我们当时仍无法准确定位到底是哪个依赖组件引发的这场“灾难”。直到去 GitHub 上搜索了相关代码片段，才恍然大悟：好家伙，这不是孤例，而是一波有组织的集中攻击！
Python 木马特征检索片段：
eNq9W19z3MaRTyzJPrmiy93VPSSvqbr44V4iUZZkSaS
JavaScript 木马特征检索片段：
w=w.codePointAt(0),w>=0xFE00&&w<=0xFE0F?w-0xFE00:w>=0xE0100&&w<=0xE01EF?w-0xE0100+16:null
简单调查后，确认这波攻击源自名为 GlassWorm 的大规模供应链投毒活动，攻击高峰集中在今年2到3月。从搜索结果看，中招的项目不少，我们很不幸身在其中；但从影响范围看，我们又很幸运地控制住了损失。
我粗略看了一下这次活动涉及的恶意 Visual Studio Code 扩展，数量高达72个！各位开发者朋友，赶紧检查一下自家的项目和环境有没有被这波攻击污染吧。
这次事件也给我们敲响了警钟。在享受 Node.js 和 Python 等生态丰富依赖带来的便利时，必须对供应链安全保持高度警惕。定期审计依赖、审查异常提交、强化CI/CD流程的安全检查都至关重要。
如果你在排查中遇到类似问题，或想了解更多关于安全防护的实践，欢迎到 云栈社区 的安全板块与其他开发者交流探讨。 | 
发表于 4 小时前
|
查看: 4|
回复: 0
