Fork Bomb 救了我们

LiteLLM 1.82.8中的恶意软件包含一个.pth文件，该文件在任何Python启动时都会执行。它收集SSH密钥、云凭证、加密货币钱包和CI/CD密钥，使用4096位RSA密钥加密后，将归档文件外传至攻击者控制的域名。载荷工程精良，加密方案可靠，数据外传手法干净利落。¹ 本文是我智能体安全系列的一部分，该系列聚焦于那些塑造我们在自动化系统中构建信任方式的真实安全事件。

.pth文件还会派生一个子Python进程来执行其任务。该子进程又触发了.pth文件，于是再次派生一个子进程，如此循环往复。一个指数级的Fork Bomb在数秒内吞噬了100% CPU和超过5GB内存。²

这个Fork Bomb是一个Bug。攻击者并不希望恶意软件暴露行踪。如果实现正确，它会在每个受感染系统的每次Python调用时悄无声息地运行，可能持续数周之久。然而开发者注意到机器陷入卡顿，展开调查后发现了凭证窃取程序。PyPI在发布后46分钟内隔离了两个版本。¹

四万六千次安装，四十六分钟。检测机制竟是恶意软件自身的实现缺陷。

摘要

• Bug所在：LiteLLM 1.82.8的凭证窃取程序存在Fork Bomb缺陷，导致受感染机器陷入卡顿。若非这个Bug，窃取程序本可静默运行数周。
• 防线缺口：静态分析、行为监控和代码审查全部未能发现攻击。每一层检测都假设另一层会拦截。结果无一奏效。³
• 攻击者进化曲线：攻击者的技术水平随迭代不断提升。.pth技术现已被公开记录，下一个攻击者将直接继承该技术——但不会继承那个Bug。
• 不依赖运气的防御手段：出站请求的域名年龄检查、包安装的行为基线、文件系统蜜罐、安装隔离。这些手段无论载荷质量如何都能发挥作用。
• 非对称优势：防御方掌握环境选择权。如果安装环境中没有可窃取的凭证，即便是完美的载荷也一无所获。

我们只是走运了

去掉载荷中的Fork Bomb，攻击便会悄然得逞。.pth文件在任何import之前、任何应用代码之前、任何Python级别沙箱之前执行。没有钩子点，没有日志记录。凭证窃取程序运行、加密、外传，然后Python进程照常继续。开发者毫无察觉，CI流水线毫无察觉，安全扫描器也毫无察觉——因为安全扫描器本身就是攻击载体。³

LiteLLM 1.82.8的发现过程并非”我们的监控系统捕获了它”，而是”攻击者发布了一个有Bug的版本”。

这绝非供应链安全的可靠基石。正如我在你的智能体沙箱不过是一个建议中所论述的，我们假定存在于可信代码与不可信代码之间的边界，远比大多数团队意识到的更加脆弱。

攻击者的质量进化曲线

软件质量随迭代而提升，攻击者亦然。TeamPCP的攻击行动在一周内打击了五个生态系统：GitHub Actions、Docker Hub、npm、Open VSX和PyPI。⁴ 每一次生态系统入侵都利用了从前一次中窃取的凭证。该行动展现出高度的操作成熟度：载荷投递前24小时注册域名、利用可变引用进行标签劫持、以及通过Aqua Security不完整的密钥更换来规避凭证轮换。

Fork Bomb是这次精心策划的行动中唯一的失误。下一次攻击不会重蹈覆辙。.pth文件技术现已被CrowdStrike、Microsoft、Wiz和Palo Alto公开记录并分析。³ 下一个攻击者将继承成熟的技术，而非那个Bug。

攻防能力遵循同样的进化曲线。技术是公开的，分析是公开的，下一个攻击者将从TeamPCP止步之处起步。我在无人监督下真正会出什么问题中探讨了这条曲线对自主系统的深远影响。

检测不能依赖攻击者的失误

当前的供应链检测模型包含三层防线，面对LiteLLM时全部失守：

静态分析未能发现。 .pth文件是Python的合法特性。载荷经过双重base64编码，运行时才解码。寻找已知恶意模式的静态扫描器一无所获，因为这是一种全新的模式。

行为监控未能发现。 凭证窃取程序仅向一个貌似合法服务的域名（models.litellm.cloud）发送了一次HTTPS POST请求。出站监控若要识别此域名，需要知道它是24小时前刚注册的。大多数出站监控并不检查域名年龄。

代码审查未能发现。 恶意版本直接发布到PyPI，完全绕过了GitHub CI/CD流水线。没有Pull Request可供审查，没有diff可供检视。攻击者使用窃取的发布凭证上传了预构建的包。

每一层检测都假设攻击链的另一环节会拦截问题。结果无一奏效。最终是Fork Bomb暴露了问题。

真正能检测静默恶意软件的方法

既然不能依赖攻击者的失误，就需要无论实现质量如何都能生效的检测机制。

出站请求的域名年龄检查。 数据外传域名在攻击前24小时才注册。一条标记出站请求目标域名注册不满7天的防火墙规则即可拦截此类攻击。规则简单，误报率可控，且能捕获最常见的数据外传模式。

Python进程的行为基线。 一个pip install突然向未知域名发送HTTPS POST请求，这本身就是异常行为。在包安装过程中追踪网络活动的进程级行为监控会标记此类异常。

文件系统蜜罐。 在蜜罐路径放置伪造的SSH密钥，在另一个蜜罐路径放置伪造的AWS凭证，然后监控任何读取这些文件的进程。扫描标准路径的凭证窃取程序会触碰蜜罐，而合法进程不会。蜜罐在数据外传完成之前即可触发告警。

安装隔离。 在无法访问真实凭证的环境中运行pip install，安装完成后再将包复制到生产环境。.pth文件在pip自身的Python进程中触发，意味着凭证窃取程序在安装阶段就会运行。如果安装环境中没有可窃取的凭证，攻击便一无所获。

以上机制无一需要攻击者犯错，无论载荷质量如何都能发挥作用。这种架构模式——设计一个即便遭受完美攻击也毫无可窃取之物的环境——与部署与防御：智能体信任悖论中阐述的原则一脉相承。

非对称优势

防御方拥有一个结构性优势：防御方选择环境。攻击者必须在包被安装的环境中行事。如果该环境没有凭证、没有网络访问权限、且部署了文件系统蜜罐，载荷在技术层面虽然成功执行，但在实际操作层面彻底失败。

LiteLLM攻击之所以得逞，是因为安装环境与存放发布凭证、SSH密钥和云令牌的环境是同一个。Fork Bomb与安全架构无关，它只影响了发现的时间线。

下一次，Fork Bomb不会再出现。凭证仍将与包管理器处于同一环境中。问题在于：在下一个攻击者发布一个完美无缺的载荷之前，你是否已经改造了你的环境？我的Ralph智能体架构分析展示了如何构建智能体系统，使受损组件无法突破其隔离边界进行提权。

常见问题

攻击者为什么没有测试Fork Bomb？

.pth文件派生子进程来执行载荷而不阻塞父进程，这是一个合理的实现选择。递归触发是.pth与Python的site.py初始化之间的微妙交互。这类Bug在集成测试中会暴露，但在单元测试中不会——而恶意软件作者在真实环境中进行集成测试的机会极为有限。

Fork Bomb是否可能是有意为之？

极不可能。Fork Bomb使恶意软件立即暴露，这与攻击者的目标完全背道而驰。一个静默运行数周的凭证窃取程序所能收集的凭证量，比一个在46分钟内被发现的程序多出几个数量级。

域名年龄检查在大规模环境中是否可行？

完全可行。域名年龄可通过WHOIS或DNS注册日期APIs获取。检查为每个请求增加的延迟仅在毫秒级别。大多数组织可以为已知的新域名设置白名单。

参考来源