# LiteLLM供应链攻击技术分解：初始访问向量与恶意代码注入机制 > 从攻击链技术分解角度，深入分析LiteLLM供应链攻击的恶意代码植入路径、payload行为特征，并提供工程化的供应链安全审计检查清单。 ## 元数据 - 路径: /posts/2026/03/27/litellm-supply-chain-attack-initial-access-vector/ - 发布时间: 2026-03-27T18:57:59+08:00 - 分类: [security](/categories/security/) - 站点: https://blog.hotdry.top ## 正文 2026年3月，开源AI网关LiteLLM遭遇供应链投毒攻击，影响版本1.82.7和1.82.8。该事件之所以引起安全社区高度关注，不仅因为LiteLLM本身月下载量达9500万、总下载量超4.8亿次，更因为攻击者采用了极为隐蔽的持久化技术，使得一次简单的pip install即可导致主机环境被全面渗透。本文将从攻击链技术分解的角度，剖析恶意代码的植入路径、payload行为特征，并给出可落地的供应链安全审计参数与检测清单。 ## 攻击向量分析：从PyPI发布环节突破 LiteLLM供应链攻击的核心突破点在于发布环节。与传统依赖GitHub Release进行分发的开源项目不同，LiteLLM的部分版本直接向PyPI提交了恶意构建产物，绕过了项目官方的GitHub发行流程。攻击者获取了PyPI的发布令牌（可能是通过钓鱼、凭证泄露或其他方式），从而能够以项目维护者身份上传带有后门的wheel包。 这种攻击方式之所以致命，是因为绝大多数开发者和CI/CD流水线默认信任PyPI官方仓库，认为从PyPI直接安装的包即为可信版本。当用户执行pip install litellm时，如果恰好拉取到被污染的1.82.7或1.82.8版本，恶意代码便在不知不觉中进入目标环境。值得注意的是，攻击者选择了proxy组件作为突破口——LiteLLM的proxy/proxy_server.py是整个项目中最常用的模块之一，许多用户部署AI网关时必须加载该模块，这为payload的自动触发提供了天然条件。 ## 恶意代码注入机制：两阶段payload演进 ### 第一阶段：proxy_server.py直接注入 在版本1.82.7中，攻击者将base64编码的恶意payload直接嵌入到litellm/proxy/proxy_server.py文件内部。当任何代码导入该模块时，Python解释器会执行模块加载逻辑，此时隐藏在代码中的payload被解码并写入临时文件，随后被执行。整个过程发生在import阶段，不需要任何显式的函数调用。 这种注入方式的技术关键在于利用了Python模块导入时的代码执行特性。攻击者将payload经过base64编码后嵌入正常代码字符串中，通过字符串解码、文件写入、子进程执行三步完成恶意代码的投放。由于proxy_server.py是LiteLLM proxy功能的入口模块，几乎所有使用proxy的用户都会在服务启动时触发这段代码。 ### 第二阶段：litellm_init.pth持久化劫持 如果說1.82.7版本的攻击依赖显式的模块导入，那么1.82.8版本的进化则展现了更为深入的持久化思路。攻击者新增了一个名为litellm_init.pth的文件到site-packages目录。.pth文件是Python的一项特性，允许开发者在site-packages目录放置包含Python代码的文件，这些代码会在每次Python解释器启动时自动执行——无论是否真正导入该包。 这意味着即使用户只是运行pip list、python -c "print(1)"，甚至在IDE中打开包含该环境的Python项目，litellm_init.pth中的代码都会触发。攻击者利用这一特性实现了攻击面的极大扩展：不仅限于使用LiteLLM的应用，任何在相同Python环境中运行的工具都可能成为payload的受害者。理论上，攻击者可以窃取该Python解释器可访问的所有凭证、SSH密钥、云配置以及Kubernetes访问令牌。 ## Payload行为特征与攻击链还原 ### 凭证窃取范围 安全研究人员的分析表明，LiteLLM恶意payload的主要目标是大规模凭证收集。具体而言，payload会扫描以下几类敏感资源：首先是环境变量，遍历全部环境变量并筛选出包含KEY、TOKEN、SECRET、PRIVATE等关键字的变量；其次是AWS凭证，包括~/.aws/credentials和~/.aws/config中的访问密钥和会话令牌；再次是SSH私钥，扫描~/.ssh/目录下所有以id_开头的私钥文件；此外还有Kubernetes配置，读取~/.kube/config中的集群访问凭证，以及CI/CD流水线中常见的各类API令牌和部署密钥。 ### 数据外传与持久化 窃取到的凭证数据会被打包为tar.gz格式，通过HTTP请求外传至攻击者控制的C2服务器。外传过程通常采用分阶段策略：先收集元数据建立目标画像，再根据价值评估决定是否完整外传。在持久化层面，攻击者在受感染系统上注册名为"System Telemetry Service"的systemd服务或用户级服务，实现机器重启后仍能保持控制权。该服务的实现伪装成系统监控服务，名称本身即体现了攻击者试图规避管理员注意的意图。 ### 横向移动能力 由于LiteLLM常被部署在Kubernetes集群中作为AI流量网关，攻击者还设计了针对容器编排环境的横向移动能力。payload能够检测所在容器的Service Account令牌，并利用该令牌访问Kubernetes API Server，实现集群内部的服务间横向渗透。这意味着单一节点的失陷可能导致整个AI基础设施的全面沦陷。 ## 供应链安全审计工程化检查清单 面对此类供应链攻击，单纯依赖事件响应远远不够，需要将安全审计嵌入软件生命周期的各个环节。以下检查清单可直接应用于工程化环境： ### 依赖版本核验与锁定 在依赖管理层面，必须执行以下操作：第一，核查当前环境安装的LiteLLM具体版本，使用pip show litellm或pip list | grep litellm确认版本号，若版本为1.82.7或1.82.8立即进入应急响应流程；第二，在requirements.txt或pyproject.toml中严格锁定依赖版本，使用==精确指定而非>=，避免自动升级到恶意版本；第三，搭建私有PyPI镜像或使用PyPI镜像代理，在镜像层实施版本白名单机制，仅同步经过安全评估的版本。 ### 文件系统异常检测 针对pth文件持久化机制，建议部署以下检测规则：第一，扫描site-packages目录下所有.pth文件，使用find /path/to/site-packages -name "*.pth" -exec ls -la {} \;列出详细信息，特别关注名称包含litellm或异常命名的文件；第二，监控新增.pth文件的创建行为，可通过文件系统审计规则（auditd规则或OSQuery）实现实时告警；第三，检查systemd服务列表，使用systemctl list-units --type=service | grep -i telemetry确认是否存在名为System Telemetry Service的可疑服务。 ### 网络行为监控 在网络层面，需要关注的异常指标包括：第一，审查所有出站HTTP/HTTPS连接，重点关注非标准端口或指向可疑域名的流量，IOC中已知C2域名包括类似checkmarx.zone的域名模式；第二，分析TLS元数据，恶意外传通常产生异常的证书链和SNI特征；第三，部署DNS安全日志，监控解析到已知恶意域名的查询行为。 ### 凭证轮换与访问控制 应急处置阶段的核心动作是凭证止损：第一，立即轮换在受影响环境中使用过的所有凭证，包括AWS访问密钥、GitHub个人访问令牌、PyPI API令牌、Kubernetes集群凭证等；第二，审查云平台IAM角色绑定，撤销非必要的过度权限，遵循最小权限原则；第三，检查GitHub仓库的部署密钥和Webhook secret，确保攻击者未利用窃取的凭证建立持久化后门。 ### CI/CD流水线加固 由于CI/CD环境通常持有高权限凭证，必须作为重点加固对象：第一，在所有CI/CD流水线中加入依赖完整性校验步骤，使用pip hash -r或自定义脚本比对包签名；第二，优先使用虚拟环境（venv或conda）隔离项目依赖，避免全局Python环境被污染；第三，CI/CD runner的凭证应配置为短期临时凭证，避免长期有效令牌泄露后造成持续影响。 ## 结语 LiteLLM供应链攻击事件深刻揭示了开源AI基础设施面临的现实威胁。从技术分解角度看，攻击者巧妙利用了Python生态的发布机制和运行时特性，通过两阶段payload实现了从单点渗透到全环境控制的技术升级。对抗此类威胁，需要将供应链安全从「事后响应」转向「事前预防」，在依赖引入、版本管理、运行时监控三个层面建立纵深防御体系。唯有将审计检查清单固化为自动化流水线的一部分，才能在攻击发生前构建起真正的安全屏障。 **资料来源**：本文技术细节参考了Securelist、Kaspersky、NetSPI、Mend.io等安全研究机构发布的LiteLLM供应链攻击分析报告及IOC披露信息。 ## 同分类近期文章 ### [微软终止VeraCrypt账户：平台封禁下的供应链安全警示](/posts/2026/04/09/microsoft-terminates-veracrypt-account-platform-lock-risk/) - 日期: 2026-04-09T00:26:24+08:00 - 分类: [security](/categories/security/) - 摘要: 从VeraCrypt开发者账户被终止事件，分析Windows代码签名的技术依赖、平台封禁风险与开发者应对策略。 ### [GPU TEE 远程认证协议在机密 AI 推理中的工程实现与安全边界验证](/posts/2026/04/08/gpu-tee-remote-attestation-confidential-ai-inference/) - 日期: 2026-04-08T23:06:18+08:00 - 分类: [security](/categories/security/) - 摘要: 深入解析 GPU 可信执行环境的远程认证流程，提供机密 AI 推理场景下的工程参数配置与安全边界验证清单。 ### [VeraCrypt 1.26.x 加密算法演进与跨平台安全加固深度解析](/posts/2026/04/08/veracrypt-1-26-encryption-algorithm-improvements/) - 日期: 2026-04-08T22:02:47+08:00 - 分类: [security](/categories/security/) - 摘要: 深度解析 VeraCrypt 最新版本的核心加密算法改进、跨平台兼容性与安全加固工程实践，涵盖 Argon2id、BLAKE2s 及内存保护机制。 ### [AAA 游戏二进制混淆：自研加壳工具的工程现实与虚拟化保护参数](/posts/2026/04/08/binary-obfuscation-in-aaa-games/) - 日期: 2026-04-08T20:26:50+08:00 - 分类: [security](/categories/security/) - 摘要: 解析 AAA 级游戏二进制保护中的自研加壳工具、代码虚拟化性能开销与反调试实现的技术选型。 ### [将传统白帽黑客习惯引入氛围编程：构建 AI 生成代码的防御纵深](/posts/2026/04/08/old-hacker-habits-for-safer-vibecoding/) - 日期: 2026-04-08T20:03:42+08:00 - 分类: [security](/categories/security/) - 摘要: 将传统白帽黑客的安全实践应用于氛围编程，通过隔离环境、密钥管理与代码审计，为 AI 生成代码建立防御纵深，提供可落地的工程参数与清单。