模型调用总闸门再次被投毒

作者:秉钧、望宸、澄潭

编者按:去年,OneAPI 镜像遭投毒,今年 LiteLLM PyPI 包遭投毒,模型调用闸门为何总能被"算计"?是否可以防范?本文为您一一解读。

北京时间 3 月 24 日 19 点,PyPI 仓库出现了 LiteLLM 1.82.7 版本。13 分钟后,1.82.8 紧随其后。这两个版本没有经过 GitHub 的 PR 流程,官方仓库中找不到对应的 commit。被第三方安全情报中心监测到这两个版本中混淆了恶意代码

恶意代码会窃取受害系统的敏感数据(包括系统环境变量、SSH 密钥、AWS/Azure 云服务凭据、K8s/Git/Docker/数据库配置、SSL 证书私钥、加密钱包配置及密钥等),数据最终被 RSA 加密打包后外传到攻击者服务器;此外,攻击者还会在目标系统中生成脚本后门,并利用系统服务进行后门持久化驻留。

LiteLLM SDK 在 PyPI 仓库历史总下载量超过 4.8 亿次,包括知名的开源项目 OpenClaw 也依赖了该开源项目。

Karpathy 在 X 平台警告:"像这样的供应链攻击基本上是现代软件中最令人恐惧的事情。"马斯克转发并评论"Caveat emptor"(买者自负)。

一些背景信息

PyPI 是 Python 官方的包管理仓库,所有 Python 项目的维护者都会把新版本发布到这里。

当企业项目依赖某个 Python 开源项目,开发者们通常会通过运行 pip install -r requirements.txt,pip 会自动从 PyPI 下载所有依赖,这有利于版本的自动化管理。

PyPI 官方对所有发布包,会进行包格式验证、元数据完整性等基础的技术检查,PyPI Token 或密码等身份验证,恶意软件扫描等自动化的审查,但不会提供代码审计、源码一致性验证、沙箱测试等依赖人力或付费资源的测试。

因此这种信任是建立在:相信 PyPI 上的包是安全的,相信包维护者不会上传恶意代码,相信 PyPI Token 不会泄露。

正因为 PyPI 如此便利、如此普及,它才成为攻击者的理想目标。攻击者只需要:

  • 窃取一个 PyPI Token。
  • 推送一个恶意版本。
  • 等待全世界的开发者自动下载。

而开发者几乎不可能发现,因为:

  • pip install 是自动化的,没人会检查每个包。
  • 依赖树太深,无法全面审计。
  • 大家习惯性地信任 PyPI。

此次 LiteLLM 被投毒事件,猜测是因为目开发者的 PyPI Token 被盗而引发的。

无独有偶。

此前,DockerHub 也发生了 OneAPI 镜像被投毒事件。DockerHub 是世界上最大的容器镜像托管服务,有来自软件供应商、开源项目的超过十万个容器镜像。很多开源软件项目选择在这里发布他们的容器镜像。这使得用户可以很方便地获取、安装和使用这些软件。

如何防范-镜像投毒

本文作者是另一款开源 AI 网关项目 Higress 的维护成员之一。在关注 Litellm 时,看到了这个问题,所以向大家分享下 Higress 防范此类风险的相关经验。

Higress 是由阿里云开源的网关软件,基于 API 网关的能力之上构建了 AI 网关能力,并且由阿里云 API 网关这款商业产品背后的研发团队共同维护,而非个人项目。Higress 一直使用阿里云容器镜像服务用于镜像存储,并有自己官方的 Helm 仓库(K8s 环境的安装包管理)。

使用阿里云容器镜像服务至少有两个好处:

  • 不受 DockerHub 网络封禁影响,对国内用户更友好,镜像拉取速度也更快。
  • 可以进行镜像安全扫描,自动拦截有风险的镜像提交。

第二点,也是防范开源镜像投毒的核心,如下截图所示:

基于阿里云容器镜像服务的云原生交付链功能,可以在镜像推送之后,立即进行恶意脚本扫描,如若发现风险可以立即删除镜像。

此外,每次新版本发布,不依赖人,而是由程序自动完成也很重要。Higress 社区在每次版本 release 发布后,会通过 GitHub Action 自动制作容器镜像以及安装包,镜像仓库密钥基于 GitHub Secret 存储。发布版本的权限可以给到社区里其他合作者,但无需提供给合作者镜像仓库的密码。

如何防范-PyPI 包投毒

不同于镜像投毒,我们可以通过阿里云容器镜像服务来避免。但是 PyPI 包投毒,我们必须要从安全防范体系来应对。

阿里云 API 网关(以开源项目 Higress 为内核)从架构设计上就将安全性作为第一优先级。针对凭证泄露、恶意攻击、插件投毒等典型威胁,阿里云 API 网关构建了三重纵深防线。

第一重防线:KMS 密钥托管,凭证从不明文落地

API 网关作为流量入口,需要管理各类敏感凭证。LiteLLM 事件中,攻击者重点收割的正是存储在环境变量和配置文件中的明文密钥。

阿里云 API 网关深度对接阿里云密钥管理服务(KMS),凭证通过 KMS 进行加密托管,而非以明文形式存储在网关配置中。以消费者认证为例,阿里云 API 网关支持为 API 的调用方创建独立的消费者身份,通过 API Key 对调用者进行身份认证。消费者的 API Key 由 KMS 加密存储,网关配置中只保留加密后的引用,凭证明文由 KMS 统一保管。

这套机制带来了多层安全保障:首先,凭证不会以明文出现在配置文件、环境变量或日志中,从源头上降低了泄露风险;其次,KMS 背后是阿里云 RAM(资源访问管理)的完整权限体系,对凭证的访问有严格的身份认证和权限校验;此外,不同消费者拥有独立的 API Key 和访问权限,即使某个消费者凭据泄露,影响范围也被严格限制在该消费者的权限范围内,不会波及其他凭证。

第二重防线:WAF 防火墙联动,在流量入口筑起安全屏障

阿里云 API 网关可一键对接阿里云 Web 应用防火墙(WAF),在 API 网关的流量入口处增加一层强大的安全防护。

API 网关作为所有请求的入口,天然面对各类恶意流量的威胁。对接 WAF 后,每一笔进入网关的请求都会经过 WAF 的深度检测:

  • 恶意请求拦截:WAF 维护实时更新的威胁情报库,可自动识别并拦截 SQL 注入、XSS、命令注入等常见 Web 攻击。
  • 异常流量检测:对请求内容进行深度分析,识别异常的参数构造和攻击特征。
  • CC 攻击防护:防止攻击者对 API 发起大规模恶意调用,保障后端服务的稳定性。
  • Bot 防护:识别并阻止自动化攻击工具的探测和扫描行为。

这相当于在 API 网关的入口处加装了一道智能"安检门",恶意流量在到达后端服务之前就被识别和拦截。

第三重防线:Wasm 沙箱插件,扩展能力,但隔离风险

API 网关的可扩展性是刚需,但扩展能力往往伴随着安全风险------如果插件代码与网关核心共享同一进程空间,一个有问题的插件就可能影响整个网关。

阿里云 API 网关基于 Higress 内核,采用 Wasm(WebAssembly)沙箱插件机制来解决这一问题。每个 Wasm 插件运行在独立的沙箱环境中,支持使用 Go、Rust、JavaScript 等语言编写:

  • 内存隔离:插件无法访问网关核心进程的内存空间,无法读取其他插件或网关配置中的敏感信息。
  • 系统调用受限:Wasm 沙箱严格限制了插件可以发起的系统调用,插件无法扫描文件系统、读取环境变量或随意进行 I/O 操作。
  • 热更新无损:插件的安装、更新和卸载不需要重启网关进程,支持版本独立升级,对流量完全无损。
  • 多语言支持:支持 Go、Rust、JavaScript 等多种语言开发,社区贡献的插件代码完全开源可审计。

即使某个 Wasm 插件存在安全漏洞,其影响也被严格限制在沙箱内部,不会波及网关管理的凭证和其他敏感资源。在保持灵活扩展能力的同时,从架构层面实现了安全隔离。

值得一提的是,阿里云 API 网关还提供了专用的 WebIDE 插件开发环境,支持在线编写、AI 辅助生成和一键构建 Wasm 插件。WebIDE 默认集成了云效企业构建流水线,插件的构建过程在云效托管的 VPC 构建集群中完成------构建任务在企业专有网络内部执行,代码拉取、依赖下载、制品产出全程在 VPC 内完成,敏感信息不会经过公网暴露。回顾 LiteLLM 事件,正是 CI/CD 流水线中引入了被投毒的第三方工具(Trivy),才导致发布凭证被窃取。而阿里云 API 网关的插件构建流水线由云效托管,构建环境与公网隔离,从构建环节就降低了被外部投毒渗透的风险。

更多安全能力:全方位守护 API 安全

除了上述三重核心防线,阿里云 API 网关还提供了一系列安全能力:

  • mTLS 双向认证:网关与后端服务之间的通信通过双向 TLS 证书进行身份验证,防止中间人攻击。
  • JWT/OIDC 认证:内置多种标准认证协议,支持对接企业现有的身份认证体系。
  • 精细化访问控制:基于消费者维度的调用权限和额度管理,不同团队、不同项目使用独立的凭证和配额。
  • 可观测性:完善的监控面板,可以实时查看每个路由、每个消费者的调用量和延时,任何异常调用模式都能被快速发现。

目前,LiteLLM 1.82.7 和 LiteLLM 1.82.8 已被 PyPI 下架。

阿里云 API 网关:

www.aliyun.com/product/api...

Higress 开源社区:

higress.io

相关推荐
SilentSamsara6 小时前
存储卷体系:EmptyDir/HostPath/PV/PVC/StorageClass 的选型决策树
服务器·微服务·云原生·容器·架构·kubernetes·k8s
王的宝库7 小时前
【K8s】集群安全机制(二):授权(Authorization)详解与实战
学习·云原生·容器·kubernetes
东北甜妹9 小时前
Docker 容器故障排查
云原生·eureka
Shining059610 小时前
QEMU 编译开发环境搭建
人工智能·语言模型·自然语言处理·云原生·qemu·vllm·华为昇腾
匀泪1 天前
云原生(Kubernetes service微服务)
微服务·云原生·kubernetes
倔强的胖蚂蚁1 天前
Ollama Modelfile 配置文件 全指南
云原生·开源
AutoMQ1 天前
AWS 新发布的 S3 Files 适合作为 Kafka 的存储吗?
云原生·消息队列·云计算
MY_TEUCK1 天前
从零开始:使用Sealos Devbox快速搭建云原生开发环境
人工智能·spring boot·ai·云原生·aigc
没有口袋啦2 天前
《基于 GitOps 理念的企业级自动化 CI/CD 流水线》
阿里云·ci/cd·云原生·自动化·k8s
柯西劝我别收敛2 天前
Koordinator-Scheduler 调度器源码解析
后端·云原生