现代企业安全栈在许可和人员费用上耗资数百万美元。这些组织部署顶级漏洞扫描器和严格的访问控制，以维护坚固的周界。然而，今年 3 月的一个 40 分钟窗口证明，一个流行 AI 工具中的单个恶意依赖项就足以完全绕过这些防御。LiteLLM 供应链攻击导致了来自全球一些最安全环境（包括由微软、亚马逊和三星管理的环境）的数 TB 敏感凭据被窃取。
从风险角度来看，这一事件揭示了我们在审查用于构建 AI 驱动软件的工具方面存在系统性失败。违规并非因为人工智能本身的缺陷而发生，而是因为我们用于部署 AI 的 DevOps 基础设施非常脆弱。当 2,500 家组织的开发人员从 Python Package Index 下载了 LiteLLM 的 1.82.7 和 1.82.8 版本时，他们无意中将数字特洛伊木马引入了他们最敏感的系统。
安全扫描器的悖论
这次违规最令人震惊的方面在于其起源。感染始于对 Trivy 的供应链攻击，Trivy 是一款广受推崇的开源漏洞扫描器。组织专门使用 Trivy 来查找安全漏洞。通过感染旨在提供安全的工具，攻击者获得了绝对信任的地位。在幕后，攻击者利用了 Trivy 开发人员管理其自动化令牌时的疏忽。尽管团队尝试轮换受损令牌，但他们在 20 天内未能将其完全撤销。这一疏忽给了威胁行为者一个为期三周的窗口，将恶意代码强制推送到下游构建中。
这种感染蔓延到了其他软件包，包括 KICS 和 Telnyx Python SDK，最后落地到 LiteLLM。这创造了一个架构悖论：旨在加固攻击面的工具反而成为了利用的主要媒介。在我审计云环境的经验中，我经常发现团队盲目信任他们的安全工具。他们认为如果一个扫描器是官方且流行的，其完整性就有保障。这一事件证明，这种假设是一个关键漏洞。
通往云端核心的四十分钟窗口
LiteLLM 实际的主动感染窗口非常短暂。受损版本在官方 Python Package Index (PyPI) 仓库中仅存在了 40 分钟。在这短时间内，全球各地的自动化 CI/CD 流水线和开发人员拉取了恶意代码。现代软件交付的速度意味着 40 分钟足以感染数十万个系统。
安全公司 CloudSEK 和 Hudson Rock 在获得包含被盗数据的 195TB 文件后分析了其后果。信息量之大令人震惊。转储内容包括云密钥、仓库令牌、SSH 密钥和 Kubernetes 机密。这些是通往数字王国的万能钥匙。主动地看，40 分钟的窗口就能产生数 TB 的数据，这表明感染代码在识别和窃取高价值机密方面效率极高。
内存抓取与存储机密的毒性资产
攻击机制既简单又具破坏性。LiteLLM 的受损版本包含旨在访问受感染机器内存的代码。大多数开发人员认为，如果机密没有保存在文本文件中，它就是安全的。这是一个谬论。恶意代码抓取系统内存的内容，寻找环境变量和活动会话令牌。
如果处理不当，数据就是一种毒性资产。在这种情况下，“数据”由管理 434,000 条 CI/CD 流水线所需的凭据组成。这些流水线是软件开发的流水线。如果攻击者拥有流水线的凭据，他们就可以在公司发布给客户的每一次未来更新中注入自己的代码。研究人员指出，许多凭据是内存中的纯文本变量，完全没有保护。收集到的数据包括活动数据库密码和缺乏任何识别信息的第三方 API 密钥，这使得研究人员甚至难以通知正确的受害者。
青少年威胁与 DevOps 近视的现实
这次攻击的责任归于 TeamPCP，一个主要由青少年组成的团体。虽然他们的方法可能不涉及高度复杂的零日漏洞利用，但他们的成功是不可否认的。独立安全研究员 Kevin Beaumont 指出，这些攻击者正让那些目前痴迷于匆忙将 AI 产品推向市场的组织团团转。
这种冲动创造了 DevOps 近视。组织优先考虑 AI 集成的速度，而忽视了软件供应链安全的基本卫生。当我通过加密渠道与白帽黑客交流时，共识总是一致的：如果目标没锁门，你就不需要复杂的漏洞利用。通过专注于 AI 的“下一个大事件”，许多公司忽略了验证其依赖项完整性的基本要求。
不完整凭据轮换的失败
这个故事中最令人担忧的部分也许是受影响组织的反应姿态。在违规行为披露后，几家大型科技公司声称他们已经轮换了密钥，并称该事件“微不足道”。然而，安全社区的验证工作却说明了不同的情况。
Kevin Beaumont 报告称，在一家美国主要科技公司声称所有凭据都已轮换后，他针对其面向公众的基础设施测试了泄露的密钥。几乎每个密钥仍然有效。这表明事件响应方法流于表面。轮换密钥不等于撤销密钥。如果旧密钥在辅助系统或遗留环境中仍然有效，则违规行为仍然处于活动状态。在发生这种规模的违规事件时，组织必须假设受感染环境可访问的每个机密都已泄露。部分轮换本质上等同于没有轮换。
供应链韧性的实际步骤
如果您的组织使用 LiteLLM、Trivy 或任何 AI 代理基础设施，被动响应的时间已经过去。评估攻击面需要对过去六个月中通过 CI/CD 流水线的每个凭据进行细致审计。
立即缓解清单：
- 核查版本： 审计您的环境中是否存在 LiteLLM 1.82.7 和 1.82.8 版本。即使您后来进行了更新，数据也很可能在这些版本活跃的窗口期内被窃取。
- 激进的凭据撤销： 不要仅仅更新密码。使环境变量中存在的每个云密钥 (AWS/Azure/GCP)、Kubernetes 服务帐户令牌和 Git 个人访问令牌 (PAT) 失效并轮换。
- 审计日志与出口流量： 查找 3 月份期间发往未知 IP 地址的异常出站流量。如果配置得当，数 TB 数据的外泄本应触发出口过滤警报。
- 实施版本锁定和哈希校验： 展望未来，不要允许您的 CI/CD 流水线拉取软件包的“最新”版本。使用依赖项锁定，并在每个外部库进入构建环境之前验证其 SHA-256 哈希值。
这次攻击的规模将行业推向了一个新的现实。在一个我们每隔几分钟就自愿从互联网下载代码的时代，网络周界已是过时的城堡护城河。作为对策，组织必须将每个外部依赖项视为潜在恶意的，直到证明其安全。安全不是你每年完成一次的清单；它是一个持续的验证过程。
来源：
- CloudSEK Threat Intelligence Report on LiteLLM Supply Chain Attack
- Hudson Rock Analysis of TeamPCP Data Dump
- MITRE ATT&CK Framework: Supply Chain Compromise (T1195)
- NIST Software Supply Chain Security Guidance
免责声明：本文仅供信息和教育目的，不替代专业的网络安全审计或事件响应服务。
