Cảnh báo hai mã độc LiteLLM âm thầm quét ví Bitcoin, Ethereum và Solana

Một phiên bản LiteLLM bị đầu độc đã biến một thao tác cài đặt Python tưởng chừng bình thường thành một công cụ đánh cắp bí mật có nhận diện crypto, âm thầm quét ví, dữ liệu validator Solana và thông tin xác thực đám mây mỗi khi Python khởi động.

Vào ngày 24/3, trong khoảng từ 17:39 đến 23:00, hacker sau khi chiếm quyền tài khoản của một maintainer đã phát hành hai phiên bản LiteLLM độc hại lên PyPI: 1.82.7 và 1.82.8.

LiteLLM vốn được quảng bá là giao diện hợp nhất cho hơn 100 nhà cung cấp mô hình ngôn ngữ lớn, đồng nghĩa với việc nó thường tồn tại trong các môi trường phát triển giàu thông tin nhạy cảm. Theo PyPI Stats, gói này ghi nhận hơn 96 triệu lượt tải chỉ trong một tháng.

Hai phiên bản bị cài mã độc có mức độ rủi ro khác nhau. Bản 1.82.7 chỉ kích hoạt payload khi trực tiếp import litellm.proxy, trong khi bản 1.82.8 nguy hiểm hơn khi cài một file .pth (litellm_init.pth) vào môi trường Python.

Theo tài liệu chính thức của Python, các dòng lệnh trong file .pth sẽ tự động chạy mỗi khi Python khởi động. Điều này khiến phiên bản 1.82.8 thực thi mã độc mà không cần bất kỳ thao tác import nào. Bất kỳ máy nào cài bản này đều bị xâm phạm ngay khi Python được mở lại.

FutureSearch ước tính có gần 47.000 lượt tải chỉ trong 46 phút, riêng bản 1.82.8 chiếm hơn 32.000 lượt. Đồng thời, có 2.337 package trên PyPI phụ thuộc vào LiteLLM, trong đó 88% cho phép cài các phiên bản bị xâm phạm tại thời điểm xảy ra sự cố.

Trang thông báo sự cố của LiteLLM cảnh báo rằng bất kỳ môi trường nào sử dụng dependency không khóa phiên bản (unpinned) trong khoảng thời gian này đều có nguy cơ bị lộ dữ liệu.

Đội ngũ DSPy cũng xác nhận họ sử dụng ràng buộc phiên bản “>= 1.64.0”, đồng nghĩa các cài đặt mới trong khoảng thời gian đó có thể đã vô tình kéo về phiên bản độc hại.

Nhắm mục tiêu trực tiếp vào crypto

Phân tích ngược của SafeDep cho thấy mã độc được thiết kế rõ ràng để săn lùng tài sản số.

Malware này tìm kiếm file ví Bitcoin (wallet*.dat), thư mục keystore Ethereum, và cấu hình Solana tại đường dẫn ~/.config/solana. Đáng chú ý, Solana bị nhắm mục tiêu sâu hơn, với các truy vấn cụ thể tới key validator, vote account và thư mục deploy Anchor.

Trong hệ sinh thái Solana, file keypair mặc định nằm tại ~/.config/solana/id.json. Tài liệu của Anza cho biết chỉ cần bị lộ khóa “authorized withdrawer” là kẻ tấn công có thể toàn quyền kiểm soát validator và phần thưởng.

Ngoài ra, mã độc còn thu thập:

• SSH keys
• biến môi trường
• thông tin xác thực AWS/GCP/Azure
• Kubernetes secrets trên toàn cluster

Khi phát hiện credential AWS hợp lệ, nó tiếp tục truy vấn AWS Secrets Manager và SSM Parameter Store để mở rộng phạm vi khai thác.

Mã độc cũng tạo các pod đặc quyền trong kube-system và thiết lập cơ chế tồn tại lâu dài thông qua sysmon.py và systemd.

Rủi ro leo thang cho các đội crypto

Điểm nguy hiểm không chỉ nằm ở việc đánh cắp từng loại dữ liệu riêng lẻ, mà là sự kết hợp của chúng.

Nếu một hệ thống bị thu thập đồng thời file ví, passphrase, token CI/CD hoặc credential hạ tầng, kẻ tấn công có thể nhanh chóng chuyển từ “lộ thông tin” sang:

• rút tiền ví
• triển khai hợp đồng độc hại
• chiếm quyền signer hoặc validator

Đây chính xác là loại dữ liệu mà payload đã thu thập.

Một phần của chiến dịch lớn hơn

Sự cố LiteLLM không phải là đơn lẻ. Báo cáo cho thấy nó liên quan tới chuỗi tấn công TeamPCP, từng xuất hiện trong sự cố Trivy trước đó. Chuỗi này di chuyển qua nhiều hệ sinh thái developer trước khi tới PyPI.

Chiến lược xuyên suốt rất rõ ràng: nhắm vào các công cụ hạ tầng giàu bí mật để tiếp cận nhanh các tài nguyên liên quan đến ví và hệ thống crypto.

Kịch bản tích cực: thiệt hại được kiểm soát

Ở chiều tích cực, tốc độ phát hiện và xử lý khá nhanh. PyPI đã cách ly các phiên bản độc hại vào khoảng 11:25 UTC cùng ngày.

LiteLLM đã:

• gỡ bỏ các bản độc hại
• thay đổi credential maintainer
• phối hợp điều tra với Mandiant

Nếu các đội ngũ kịp thời:

• xoay vòng toàn bộ secrets
• kiểm tra file litellm_init.pth
• coi các máy bị ảnh hưởng là “đã cháy” (burned)

thì thiệt hại có thể chỉ dừng ở mức lộ thông tin, chưa dẫn tới khai thác thực tế.

Sự cố cũng thúc đẩy các thực hành bảo mật tốt hơn như:

• Trusted Publishing (OIDC thay token dài hạn)
• build hermetic (đóng kín dependency)
• tách biệt vai trò và khóa nhạy cảm

Kịch bản tiêu cực: rủi ro kéo dài

Ở chiều ngược lại, vấn đề lớn nhất là độ trễ phát hiện.

Mã độc không chỉ đánh cắp dữ liệu mà còn:

• lan rộng trong Kubernetes
• thiết lập persistence

Các API key, credential hay file ví bị đánh cắp không tự hết hạn. Kẻ tấn công có thể giữ lại và khai thác sau nhiều tuần hoặc nhiều tháng.

Đặc biệt nguy hiểm là các môi trường dùng chung như:

• sàn giao dịch
• validator
• đội phát triển bridge
• nhà cung cấp RPC

Nếu dependency bị đầu độc được cài trong hệ thống build hoặc cluster, toàn bộ control plane có thể bị lộ.

Kết luận

Sự cố LiteLLM cho thấy một kịch bản tấn công cực kỳ nguy hiểm:

• xâm nhập chuỗi cung ứng phần mềm
• tận dụng gói có hàng chục triệu lượt tải
• nhắm chính xác vào dữ liệu off-chain quan trọng của crypto
• thiết lập persistence trước khi bị phát hiện

Nó nhấn mạnh một thực tế: hạ tầng off-chain – nơi lưu trữ khóa, ví và credential – chính là mắt xích dễ bị tổn thương nhất, và cũng là mục tiêu ưu tiên của các cuộc tấn công hiện đại.