Mục lục lục
ToggleLiteLLM, một bộ phần mềm trí tuệ nhân tạo mã nguồn mở với lần triệu lượt tải xuống mỗi tháng , đã bị phát hiện là bị tấn công vào Chuỗi cung ứng vào ngày 24. Hai phiên bản bị xâm nhập (v1.82.7 và v1.82.8) đã bị nhiễm mã độc có khả năng đánh cắp một cách có hệ thống hầu hết các thông tin nhạy cảm như ví điện tử crypto, khóa SSH và thông tin đăng nhập đám mây.
23pds, giám đốc an ninh mạng của SlowMist Technology, đã trích dẫn tin tức trên X sáng nay và đưa ra một cảnh báo nghiêm trọng.
Ai đã phát hiện ra nó? Kẻ tấn công là ai?
Kỹ sư Daniel Hnyk của FutureSearch là người đầu tiên phát hiện ra lỗ hổng này. Anh và Callum McMahon đã phát hiện ra hành vi bất thường khi LiteLLM được đưa vào như một phần phụ thuộc gián tiếp của tiện ích bổ sung Cursor MCP, và sau đó bắt đầu phân tích ngược mã nguồn .
Sau đó, người ta phát hiện ra rằng thủ phạm là nhóm hacker TeamPCP . Nhóm này trước đó đã xâm nhập vào hệ thống CI/CD của phần mềm quét bảo mật mã mã nguồn mở có tiếng Trivy, từ đó lấy được thông tin đăng nhập tài khoản PyPI của người duy trì LiteLLM, và sau đó tải lên hai phiên bản độc hại có chứa cửa hậu.
Cơ chế tấn công ba giai đoạn
Việc thực thi mã độc bao gồm ba giai đoạn liên kết với nhau:
Giai đoạn 1 — Thu thập thông tin đăng nhập : Sau khi cài đặt, một tệp `.pth` độc hại (`litellm_init.pth`) sẽ tự động thực thi mỗi khi chương trình Python khởi chạy, mà không cần bất kỳ chỉ thị `import` nào để kích hoạt. Danh sách bị đánh cắp bao gồm khóa SSH, tệp `.env` (chứa khóa API), thông tin đăng nhập đám mây AWS/GCP/Azure, cấu hình Kubernetes, thông tin đăng nhập Git, lịch sử lệnh shell, tệp ví tiền điện tử và mật khẩu cơ sở dữ liệu.
Giai đoạn 2 — Rò rỉ dữ liệu : Tất cả dữ liệu bị đánh cắp đã crypto bằng khóa công khai RSA 4096 bit được mã hóa cứng và AES-256-CBC, đóng gói vào một tệp lưu trữ tar và gửi qua yêu cầu POST đến `https://models.litellm.cloud/` — tên miền này không có liên hệ gì với chính thức chính thức của LiteLLM và là điểm cuối rò rỉ do chính những kẻ tấn công thiết lập.
Giai đoạn 3 — Di chuyển ngang và Duy trì : Nếu máy có token Kubernetes, phần mềm độc hại sẽ đọc tất cả các thông tin bí mật của namespace và triển khai một Pod `alpine:latest` có quyền ưu tiên trên mỗi nút kube-system, gắn kết hệ thống tập tin của máy chủ. Nó cũng cài đặt một backdoor cố định trong `/root/.config/sysmon/sysmon.py` và thiết lập một dịch vụ người dùng systemd để đảm bảo khả năng tồn tại sau khi khởi động lại.
Dòng thời gian sự kiện
Toàn bộ sự việc diễn ra nhanh chóng chỉ trong vòng chưa đầy 10 giờ:
– 10:52 UTC, ngày 24 tháng 3 : Phiên bản v1.82.8 đã được tải lên PyPI
– 12:30 UTC : Phiên bản v1.82.7 cũng được xác nhận là đã bị xâm phạm. – 13:03 UTC: Vấn đề thông báo trên GitHub đã bị một bot gắn cờ nhầm là thư rác và đánh dấu là "không có kế hoạch", làm trì hoãn cảnh báo công khai. – 20:15 UTC : Phiên bản bị xâm phạm cuối cùng đã hủy niêm yết khỏi PyPI và lệnh cách ly đã được dỡ bỏ.
Từ lúc phiên bản độc hại ra mắt cho đến khi hủy niêm yết, nó đã có khoảng 9 giờ hoạt động.
Tại sao các nhà phát triển crypto lại được coi là nhóm rủi ro cao?
LiteLLM là một trong những bộ công cụ mô hình AI phổ biến nhất hiện nay, và lượng lớn dự án crypto và DeFi dựa vào nó như lớp định tuyến mô hình cho cơ sở hạ tầng tác nhân AI của họ. Cuộc tấn công này đã trực tiếp đưa các tệp ví tiền crypto vào danh sách bị đánh cắp, có nghĩa là bất kỳ nhà phát triển nào chạy LiteLLM trên cùng một máy và nắm giữ tài sản crypto tài sản rủi ro trực tiếp.
Điều đáng báo động hơn nữa là chính phương thức tấn công: bằng cách đưa vào các phụ thuộc gián tiếp thông qua tiện ích bổ sung MCP, các nhà phát triển thậm chí có thể không nhận ra rằng họ đã cài đặt LiteLLM. Điều này cho thấy một điểm mù về bảo mật cấu trúc trong Chuỗi AI Agent: Chuỗi phụ thuộc của hệ sinh thái tiện ích bổ sung càng phức tạp, bề mặt tấn công cho các cuộc tấn công Chuỗi cung ứng càng rộng.
Các bước sửa chữa khẩn cấp
Các nhà phát triển đã cài đặt LiteLLM nên thực hiện ngay các bước kiểm tra sau:
1. Sử dụng lệnh `pip show litellm` để xác nhận phiên bản hiện tại; v1.82.7 hoặc v1.82.8 là phiên bản bị lỗi.
2. Gỡ bỏ phiên bản bị ảnh hưởng và xóa bộ nhớ cache của pip.
3. Kiểm tra xem `~/.config/sysmon/sysmon.py` và `sysmon.service` có tồn tại hay không.
4. Hoàn cảnh Kubernetes: Quét không gian tên `kube-system` để tìm các Pod `node-setup-*`.
5. Tất cả các khóa SSH, thông tin đăng nhập đám mây (AWS/GCP/Azure), khóa API và private key crypto phải được coi là đã bị xâm phạm và cần được thay thế ngay lập tức.
