Phân tích sự cố tấn công chuỗi cung ứng LiteLLM và bài học rút ra

Cuộc tấn công chuỗi cung ứng vào LiteLLM - một proxy Python dùng để định tuyến các cuộc gọi LLM giữa các nhà cung cấp - đã khiến cộng đồng bảo mật và phát triển phần mềm phải suy nghĩ lại về việc quản lý phụ thuộc và bảo vệ hệ thống. Phiên bản 1.82.7 và 1.82.8 của LiteLLM bị chèn mã độc đánh cắp thông tin bao gồm khóa SSH, token đám mây, bí mật Kubernetes và ví tiền mã hóa. Dưới đây là bài học và giải pháp mà tác giả đã trải qua sau sự cố này.

Chuỗi tấn công diễn ra như thế nào?

LiteLLM bị tấn công qua một lỗ hổng trong quá trình CI/CD, nơi pipeline dùng Trivy - một công cụ quét bảo mật - nhưng không cố định phiên bản. Phiên bản Trivy bị tấn công đã đánh cắp token PYPI_PUBLISH trong GitHub Actions runner của dự án LiteLLM. Kẻ tấn công TeamPCP dùng token này để đẩy bản phát hành chứa payload độc hại lên PyPI.

Ở phiên bản 1.82.7, payload được nhúng trong tập tin proxy/proxy_server.py và thực thi khi import. Đến phiên bản 1.82.8, hiểm họa còn lớn hơn khi gói chứa một file .pth (litellm_init.pth) thực thi tự động mỗi khi Python khởi động, dù LiteLLM có được import hay không. Đây là cơ chế thực thi bí mật mà Python cho phép, khiến phần mềm độc hại được kích hoạt trên mọi tiến trình Python.

Payload malware giải mã qua base64 hai lần, chạy 3 giai đoạn:

• Giai đoạn 1: Thu thập các thông tin nhạy cảm như khóa SSH, token AWS/GCP/Azure, biến môi trường, file .env, cấu hình Kubernetes, dữ liệu Docker, mật khẩu CSDL, cookie trình duyệt và ví tiền mã hóa.
• Giai đoạn 2: Triển khai các pod Alpine được cấp quyền cao trong namespace kube-system của Kubernetes để đánh cắp bí mật cluster và token service account.
• Giai đoạn 3: Cài đặt một dịch vụ sysmon.py dưới dạng systemd service, liên tục lấy payload bổ sung từ máy chủ điều khiển, đảm bảo quyền truy cập lâu dài cho hacker.

Dữ liệu đánh cắp được mã hóa và gửi về một domain giả mạo models.litellm.cloud do hacker kiểm soát.

Mức độ ảnh hưởng vượt xa tưởng tượng

Cơ chế thực thi .pth khiến mã độc và đánh cắp dữ liệu xảy ra ở mức hệ thống Python, không chỉ khi sử dụng LiteLLM. Điều này làm ảnh hưởng đến tất cả những ai có LiteLLM trong môi trường Python, bất kể họ có cài trực tiếp hay qua phụ thuộc gián tiếp.

Đáng ngại hơn, tác giả phát hiện LiteLLM là một phụ thuộc bị kéo vào môi trường họ qua một framework khác mà họ đã cài từ nhiều tháng trước. Điều này cho thấy việc quản lý phụ thuộc phức tạp và dễ bị bỏ qua trong các thư viện Python nhiều tầng.

Các bước kiểm tra và ứng phó sự cố

Tác giả đã thực hiện các bước sau để đánh giá và xử lý:

• Dùng pip show litellm để kiểm tra phiên bản và find để tìm file .pth.
• Quét log thoát ra ngoài (egress logs) tìm các truy cập tới domain lạ như models.litellm.cloud hoặc checkmarx.zone.
• Kiểm tra các phụ thuộc gián tiếp có kéo theo LiteLLM.
• Dừng mọi container và triển khai Kubernetes liên quan đến LiteLLM.
• Thay đổi toàn bộ khóa và token bị ảnh hưởng (đám mây, SSH, API keys, ví tiền mã hóa...).
• Tìm và xóa các pod, service “lạ” trong Kubernetes và tệp tin backdoor sysmon.py.
• Gỡ hoàn toàn LiteLLM và cache liên quan, xây dựng lại container sạch.

Quan trọng là không hạ phiên bản mà phải xóa hoàn toàn và thay thế.

Vấn đề lớn hơn với proxy Python tự quản lý

LiteLLM kéo theo hàng trăm phụ thuộc, từ ML framework cho tới SDK nhà cung cấp, khiến phạm vi tin tưởng rất rộng. Mỗi lần chạy lệnh pip install --upgrade là một quyết định tin tưởng tự động vào nhiều bên thứ ba.

Cơ chế .pth là một vector tấn công mới rất khó phát hiện bằng các công cụ quét chuỗi cung ứng truyền thống. Các công cụ chỉ chú trọng đến setup.py hay entry points, trong khi .pth là dạng cấu hình path hợp lệ của Python nhưng có thể bị lợi dụng để tiêm mã độc.

Thời gian phản ứng của nhóm maintainers LiteLLM cũng quá chậm, không xoay vòng lại các credentials kịp thời sau vụ việc ban đầu với Trivy. Điều đó dẫn đến ảnh hưởng lan rộng, không chỉ ở LiteLLM mà cả hệ sinh thái downstream.

Giải pháp: chuyển sang gateway quản lý API có giám sát

Sau sự cố, tác giả quyết định thay thế LiteLLM bằng một gateway quản lý API được vận hành bởi bên thứ ba có chuyên môn (managed gateway), tiêu biểu là Prism của Future AGI. Thay vì chạy một proxy Python tự cài đặt với hàng trăm phụ thuộc tiềm ẩn rủi ro, phần mềm chỉ cần trỏ SDK đến endpoint do Prism cung cấp và dùng API key duy nhất.

Việc chuyển đổi cực kỳ đơn giản, chỉ cần thay 2 dòng code trong Python hay TypeScript, giữ nguyên tên model, kiểu phản hồi và cách gọi API:

# Trước (dùng LiteLLM)
from litellm import completion
response = completion(model="gpt-5", messages=[{"role": "user", "content": "Hello"}])

# Sau (dùng Prism managed gateway)
from openai import OpenAI
client = OpenAI(base_url="https://gateway.futureagi.com", api_key="sk-prism-your-key")
response = client.chat.completions.create(
    model="gpt-5", messages=[{"role": "user", "content": "Hello"}]
)

Ngoài ra, Prism còn hỗ trợ tính năng semantic caching và các biện pháp bảo vệ an toàn như phát hiện dữ liệu nhạy cảm (PII), ngăn prompt injection ở lớp routing.

Với Kubernetes, chỉ cần thay đổi biến môi trường trỏ tới gateway mới và xoá hẳn LiteLLM cùng các service liên quan.

Bài học và xu hướng bảo mật tương lai

• Các tổ chức giờ đây chịu trách nhiệm pháp lý về bảo mật chuỗi cung ứng mã nguồn mở theo EU Cyber Resilience Act.
• Kiểm toán SOC 2 Type II đòi hỏi quản lý nghiêm phụ thuộc (dependency management), không thể tùy tiện kéo bản mới nhất từ PyPI.
• Chỉ cố định phiên bản (pinning) thôi chưa đủ, cần kiểm tra hash digest đầy đủ khi cài gói.
• Các tổ chức phải cân nhắc rõ ràng giữa tự quản lý proxy với rủi ro chuỗi cung ứng rộng lớn và chuyển sang mô hình gateway quản lý tập trung thu hẹp phạm vi tin tưởng.
• Vụ tấn công LiteLLM là lời cảnh tỉnh về sự phức tạp và nguy hiểm khi tin tưởng mù quáng vào hàng trăm thư viện bên thứ ba không được kiểm tra kỹ lưỡng.

Tác giả đúc kết: "Tôi đã mất hai ngày để đổi hết credentials và rà soát Kubernetes chỉ vì một package mà tôi còn không biết có trong hệ thống. Tôi thà dành thời gian để phát triển tính năng thay vì đi xử lý hậu quả."

---

Tin tức này rất đáng để các đội phát triển phần mềm và DevOps tại Việt Nam, đặc biệt những ai đang vận hành các ứng dụng AI/ML với các thư viện nguồn mở, cân nhắc lại chiến lược bảo mật chuỗi cung ứng và quản lý phụ thuộc nhằm tránh sự cố nghiêm trọng tương tự xảy ra trong tương lai.