PyPI 供应链攻击：LiteLLM 1.82.7/1.82.8版本被植入后门

近期，一起针对开源软件供应链的攻击事件浮出水面，可能已影响全球数十万开发者。一个名为 LiteLLM 的热门Python工具包被黑客植入后门，尽管恶意版本在发布后不到一天就被下架，但在此期间，大量敏感信息面临泄露风险。

LiteLLM 是什么？为何影响巨大？

简单来说，LiteLLM 是一个大模型API调用抽象层。面对 OpenAI、Google、Anthropic 等厂商各异的接口，它提供了一套统一的调用方式，极大简化了开发者的集成工作。

正因如此，LiteLLM 在开发者社区中非常受欢迎，日下载量超过 340 万次，GitHub 星标超 4 万，许多知名的人工智能应用和框架都将其作为核心依赖。大量开发者可能并未直接安装它，但在使用其他工具时，它已被间接引入到本地环境或生产服务器中。

事件复盘：一次“教科书式”的供应链攻击

根据安全公司的披露，2024年3月24日，一个名为 TeamPCP 的黑客组织成功入侵了 LiteLLM 项目维护者账户，并向 Python 官方软件仓库 PyPI 推送了两个包含后门的恶意版本：1.82.7 和 1.82.8。

这次攻击完美演绎了现代软件供应链攻击的典型路径：层层递进，环环相扣。

黑客的攻击手法具有明确的层次：

第一步：窃取凭证
黑客首先攻陷了一个名为 Trivy 的漏洞扫描工具（本身也是一个热门安全项目）。通过这次入侵，他们窃取到了包括 LiteLLM 项目维护者用于上传 PyPI 包的身份凭证（Token）。这相当于拿到了 LiteLLM “官方仓库”的“门禁卡”。

第二步：投毒发布
凭借窃取的凭证，黑客得以将恶意代码打包进 LiteLLM 的新版本中，并“合法”地发布到 PyPI。这两个恶意版本在存活数小时后被官方下架，但其潜在影响已经产生。

第三步：静默触发
最危险之处在于恶意代码的触发方式。它没有依赖任何特定的用户操作，而是利用了 Python 包的 setup.py 机制。一旦用户通过 pip install 安装了带毒版本，恶意代码就会在安装过程中自动执行。这意味着，无论开发者是否有意使用 LiteLLM，只要完成安装，攻击便已悄然开始。

恶意代码行为分析：“全方位”信息窃取

那么，这个后门程序究竟做了什么？其功能堪称一台“全自动信息收割机”，主要执行以下三类操作：

1. 疯狂收集敏感数据

   • 云凭证：扫描环境变量、配置文件（如 .env, ~/.aws/credentials），窃取 AWS、Azure、Google Cloud 等云服务的访问密钥。
   • 访问令牌：窃取 SSH 私钥、GitHub Token、数据库连接字符串等。
   • 加密货币：搜寻与比特币、以太坊等相关的钱包文件。
   • 系统信息：收集主机名、用户名、网络配置等环境信息，为后续横向移动做准备。

2. 横向移动与持久化

   • 如果检测到自身运行在 Kubernetes 集群环境中，它会尝试利用窃取的云凭证，在集群内其他节点上部署具备更高权限的“间谍”容器，实现攻击面的快速扩散。
   • 在受感染系统上创建隐藏的持久化后门，确保即使在重启后，攻击者仍能远程控制该主机。

3. 数据外传

   • 将所有窃取到的数据进行加密，并通过 HTTPS 协议发送到黑客控制的命令与控制（C2）服务器。这些服务器使用了 models.litellm[.]cloud 等伪装成官方服务的域名。

如何被发现？攻击者自露马脚

此次事件能迅速曝光，颇具戏剧性。一位开发者在日常工作中发现自己的电脑内存被异常进程快速耗尽，导致系统卡顿。经过排查，根源竟是 LiteLLM 恶意代码中的一个 Bug——该后门程序触发了一个无限循环，不断创建新进程，最终“撑爆”了内存。

正是这个编程失误引起的明显异常，才让开发者警觉并顺藤摸瓜发现了投毒事件。知名 AI 研究员 Andrej Karpathy 在社交媒体上评论道：“如果攻击者在编写恶意代码时没有犯下这个 Bug，这次投毒可能好几天甚至好几周都不会被发现。”

应对措施：立即检查与补救

如果你是 Python 开发者，或者所在团队使用了相关技术栈，请立即按照以下步骤进行检查：

1. 检查本地版本
在终端中运行以下命令，查看已安装的 LiteLLM 版本：

pip show litellm

如果显示的版本号为 1.82.7 或 1.82.8，则表明你的环境可能已受影响。1.82.6 及之前的所有版本被认为是安全的。

2. 紧急补救措施
如果不幸安装了恶意版本，应立即假设所有在该环境中存储过的凭据、密钥、密码均已泄露。请立刻执行以下操作：

• 轮转所有凭证：立即更改可能已泄露的各类密码、API 密钥、云服务访问密钥、SSH 密钥、数据库密码等。
• 检查系统痕迹：排查系统是否存在名为 sysmon 的可疑服务或进程。
• 审查网络连接：检查是否有异常外连到 models.litellm[.]cloud 或 checkmarx[.]zone 等可疑域名的记录。
• 彻底清理环境：卸载恶意版本，并从可信来源重新安装或升级到安全版本。

事件启示

这起事件并非孤例，而是近期针对开源软件供应链和安全/渗透/逆向工具一系列攻击中的最新一环。它清晰地揭示了现代软件生态的脆弱性：一个深层依赖中的微小漏洞，足以通过复杂的供应链传递，引发广泛的信任危机。

对于开发者而言，这再次敲响了警钟：必须重视依赖库的安全管理，定期更新、审查依赖关系，并考虑使用具备安全扫描功能的 CI/CD 工具。开源社区的健康发展，离不开每一位参与者的安全意识和共同努力。

本文资讯整理自 BleepingComputer 与 The Hacker News 的相关报道。对于此类深度技术安全动态，云栈社区将持续关注，为开发者社区提供及时的资讯与解读。