鹭羽 发自 凹非寺
量子位 | 公众号 QbitAI
Python程序员小心了！PyPI又双叒叕被投毒——
最新上传的LiteLLM Python 版本1.82.7和1.82.8，已被人为恶意植入信息窃取程序。
一旦安装，SSH密钥、AWS凭证和API密钥等数据均会立即泄漏。
目前LiteLLM的维护者Krrish Dholakia，已经公开证实此事。
在恶意版本存在三小时后，PyPI迅速发现了这一漏洞，并将软件包隔离。但LiteLLM每天下载量约为340万次，许多自动安装新版本的程序员已经遭殃。
社区迅速引起热议，卡帕西也出面提醒，让程序员小心LiteLLM供应链攻击。
值得注意的是，即使没有手动安装过LiteLLM，但你的电脑上可能也有它。
比如OpenClaw就会调用该库......
那么已经不慎中招的你，应该做的是——
发生了什么？具体事情经过是这样的：
LiteLLM是一个开源的Python库，它提供了一个统一接口，可以使用标准的OpenAI输入/输出格式调用100多个LLM（OpenAI、Anthropic、VertexAI等）。
每月下载量高达9700万次，GitHub超4万星，也是人工智能开发领域安装量最高的Python包之一。
3月24日，LiteLLM 1.82.8版本被发布到PyPI，其中包含一个名为litellm_init.pth的恶意文件。该文件会在LiteLLM安装完成后，无需主动调用该库，只要Python进程启动就会自动执行。
而此前的1.82.7版本也被同样证实存在相同的安全漏洞。
该漏洞是被FutureSearch的Callum McMahon第一时间发现的，当时他正在测试一个Cursor MCP插件，该插件引入了LiteLLM。
但是在Python启动后不久，他的机器就因内存耗尽而停止响应。于是他追踪问题，一路查到了新安装的LiteLLM包上，并在目录下找到了litellm_init.pth文件。
该文件大小为34628字节，并经过双重base64编码，其中一个base64编码的有效载荷会负责窃取信息并持久存在于受影响的机器上。
它将通过三个阶段对用户信息进行盗取：
1、收集：
Python脚本将会从主机上收集用户的各种敏感文件，包括SSH私钥和配置文件、 AWS/GCP/Azure 凭证、Kubernetes配置、数据库密码等。它还会运行命令来导出环境变量并查询云元数据端点（IMDS、容器凭证）。
2、数据外泄：
收集到的数据将会使用硬编码的4096位RSA公钥，通过 AES-256-CBC进行加密，打包成tar归档文件，并通过POST请求发送到一个不属于LiteLLM的攻击者云端。
3、横向扩散：
如果检测到用户存在Kubernetes服务帐户token，恶意软件会读取所有命名空间中的所有集群密钥，并尝试在每个节点上创建一个具有特权的pod。每个pod都会挂载主机文件系统，并安装一个带有systemd用户服务的持久化后门。
根据LiteLLM的维护者Krrish Dholakia描述，这一漏洞源自于项目管道中使用的安全工具Trivy。
攻击者通过篡改Trivy的GitHub Action，向其注入恶意窃取代码，并连续攻击Checkmarx KICS和Aqua Security仓库。
随后，LiteLLM的CI/CD在构建过程中接触到了被污染的Trivy，并让攻击者窃取到了维护者的PyPI凭证。利用该凭证，攻击者先后发布恶意版本LiteLLM 1.82.7和LiteLLM 1.82.8。
用户只要正常下载就会中招，期间不会产生任何异常提示。其中1.82.7的恶意代码需要用户运行LiteLLM时触发，1.82.8则只要用户启动Python就会执行窃取程序。
目前受影响的版本已经被撤回，PyPI也已解除对LiteLLM的隔离，代理者目前正在处理后续事宜，预计将审查所有Berriai代码库的影响，以及整体扫描CI情况并减轻其作用。
但如果是那些在过去24小时内有安装LiteLLM新版本的程序员，就需要额外注意了，其系统可能已经被入侵，以下是自检流程：
Step 1：检查已安装的版本。
pip show litellm | grep Version
同时在uv缓存和CI/CD虚拟环境中搜索litellm_init.pth。如果输出版本号为1.82.7或1.82.8，则表明系统已被植入恶意程序，需要执行修复步骤，切勿进行直接升级。
Step 2：移除软件包并清除缓存。
用户需立即从所有受影响的环境中删除版本，并使用命令行清除软件包管理器缓存，以防止从缓存的wheel文件重新安装。
rm -rf ~/.cache/uv
或者
pip cache purge
Step 3：检查持久化工件。
~/.config/sysmon/sysmon.py
~/.config/systemd/user/sysmon.service
如果运行在Kubernetes中，需要审核kube-system是否存在匹配node-setup-*的Pod，并检查集群密钥是否存在未经授权的访问。
Step 4：切换个人凭证。
将个人的所有凭证全部进行更换，以绝后患。
至于还尚未安装1.82.7或1.82.8版本的程序员，可以先暂时锁定1.82.6版本，等到安全的新版本发布。
供应链攻击将常态化 而这并非偶发事件，近段时间以来，有关供应链的攻击已经成规模化，而且更多地集中在自动化流水线里那些拥有高权限的工具上，比如Trivy、KICS、LiteLLM。
这些工具从设计之初，就拥有广泛的读取权限，一旦被入侵，所泄漏的数据规模也比一般应用程序要广得多。
而且这类供应链攻击的影响范围也会更大，即使是用户没有直接安装恶意程序，只要依赖的底层工具依赖它，同样也会被影响。
尤其是对于那些拥有大量依赖项的大型项目而言，风险非常之高。
反观开发者们，在此之前也通常会忽略这类依赖，很少检查深层工具的安全性，对安装新版本的警惕性不够，所以这件事也为广大程序员朋友们敲醒了警钟。
卡帕西也提醒各位：
传统的软件工程会让你相信依赖关系是好事，就像用砖块建造金字塔，但我认为这需要重新评估，这也是我越来越反感依赖关系的原因，我更喜欢在足够简单和可行的情况下使用LLM来“窃取”功能。
《从零开始构建大模型》一书的作者Sebastian Raschka也表示，几年前PyPI也发生过类似的“投毒”事件，最好的办法是将源代码保留在自己的库中。
也有部分网友表示，未来类似的供应链攻击将成为新常态，针对开发工具的供应链安全需要尽快提上日程。
同时有网友认为，本次泄漏问题能够被及时发现，是Vibe Coding救了我们。
如果攻击者编写的代码更简洁，那么该程序就可以在数百万台机器上悄无声息地运行数天甚至数周。
参考链接：[1]https://futuresearch.ai/blog/litellm-pypi-supply-chain-attack/[2]https://x.com/KanikaBK/status/2036502940031328266[3]https://snyk.io/articles/poisoned-security-scanner-backdooring-litellm/[4]https://x.com/i/trending/2036436459386024371
— 完 —
量子位 QbitAI
关注我们，第一时间获知前沿科技动态