Một gói npm phổ biến đã trở thành kênh phân phối đánh cắp thông tin xác thực sau khi kẻ tấn công chèn một payload Shai-Hulud tự lan truyền vào các bản phát hành của nó. Gói bị ảnh hưởng là @7nohe/openapi-react-query-codegen, chịu trách nhiệm tạo mã TanStack Query và có hơn 150.000 lượt tải hàng tuần.
Các bản phát hành độc hại này có thể thực thi trong quá trình nhà phát triển cài đặt dependencies hoặc khi npm xử lý một tệp cấu hình build được chế tạo đặc biệt. Điều này tạo cơ hội cho mã độc xâm nhập vào máy trạm và các trình chạy build tự động, nơi thường chứa các thông tin xác thực quan trọng như publishing, cloud và mã nguồn.
Phát hiện chiến dịch Trinitite
Các nhà nghiên cứu của JFrog đã xác định hoạt động này là một làn sóng Mini Shai-Hulud mới, được đặt tên là Trinitite, xuất hiện vào ngày 28 tháng 8. Mười bản phát hành đã được công bố chỉ trong khoảng 20 phút, cho thấy tốc độ lây lan nhanh chóng của một gói đáng tin cậy bị xâm phạm có thể ảnh hưởng đến các dự án hạ nguồn.
Theo báo cáo của JFrog được chia sẻ với Cyber Security News, sự cố này đặc biệt nghiêm trọng vì mã độc tự lan truyền này đánh cắp các token và cố gắng xuất bản các gói đã bị sửa đổi ở bất kỳ đâu mà nạn nhân có quyền. Phản hồi này tạo ra một vòng lặp, biến một dependency bị nhiễm độc thành một vấn đề lớn hơn trên chuỗi cung ứng phần mềm, tương tự như các cuộc tấn công chuỗi cung ứng Shai-Hulud trước đây và các đợt bùng phát npm gần đây.
Các bản phát hành độc hại này có thể được coi là một sự xâm phạm hệ thống máy chủ.
Cơ chế hoạt động của Trinitite
Kẻ tấn công dường như đã lạm dụng quy trình release của dự án thay vì bản thân npm. Phân tích cho thấy bất kỳ bình luận pull-request nào chứa một trigger release chính xác đều có thể bắt đầu một công việc xuất bản. Công việc này sau đó sẽ checkout pull-request và sử dụng GitHub Actions OpenID Connect (OIDC) để lấy một token xuất bản đáng tin cậy.
Việc thiếu kiểm tra người bảo trì (maintainer check) đã cho phép một người dùng GitHub mở các pull request, kích hoạt quy trình release và đẩy các gói với nguồn gốc (provenance) hợp lệ. Provenance xác nhận rằng một công việc release đã chạy trong kho lưu trữ, nhưng nó không thiết lập rằng mã được phát hành là an toàn, một điểm phân biệt quan trọng khi xem xét các cảnh báo về dependency.
Ban đầu, hai bản pre-release chứa một thành phần cài đặt bị vũ khí hóa nhưng chưa phải là mã độc hoàn chỉnh. Tám phiên bản stable sau đó đã chứa payload đầy đủ.
Bốn bản đầu tiên dựa vào một tệp binding.gyp bị vũ khí hóa, trong khi bốn phiên bản sau đó còn bổ sung thêm một hook preinstall, một kỹ thuật đã được đề cập trong cuộc tấn công chuỗi cung ứng binding.gyp.
Trình tải mã độc (loader) được ngụy trang kỹ lưỡng. Nó có thể tải runtime Bun nếu chưa có, giải mã mã độc, chạy nó từ một vị trí tạm thời và sau đó xóa tệp đó. Một điểm quan trọng là việc bỏ qua các script lifecycle của npm có thể không ngăn chặn được trường hợp này, bởi vì node-gyp có thể xử lý binding.gyp trong quá trình cài đặt.
Báo cáo không quy kết hoạt động này một cách dứt khoát, mặc dù nó lưu ý rằng gói độc hại xuất hiện khoảng một ngày sau khi các thành viên nghi ngờ của TeamPCP bị bắt giữ tại Úc.
Mục tiêu đánh cắp thông tin xác thực
Khi hoạt động, Trinitite sẽ tìm kiếm các thông tin xác thực được liên kết với GitHub, npm, PyPI, RubyGems, các dịch vụ cloud, HashiCorp Vault và Kubernetes. Nó cũng nhắm mục tiêu vào các bí mật CI và dữ liệu trong các vị trí công cụ phát triển AI.
Các thông tin bị đánh cắp được mã hóa và cam kết vào các kho lưu trữ công khai bằng cách sử dụng token GitHub của nạn nhân. Mã độc này có thể sử dụng quyền truy cập xuất bản đã khôi phục để sửa đổi và xuất bản lại các gói. Nó cũng thêm một quy trình được thiết kế để thu thập các bí mật của kho lưu trữ.
Sự kết hợp này ảnh hưởng đến các nhà phát triển và tổ chức có hệ thống build có thể xuất bản phần mềm hoặc lưu trữ thông tin xác thực triển khai, như đã thấy trong các báo cáo về việc đánh cắp thông tin xác thực workflow bị xâm phạm.
Tồn tại và cơ chế phòng vệ
Các nhà nghiên cứu cũng tìm thấy các thành phần tồn tại (persistence components) cho Linux và macOS, cùng với một trình giám sát token để theo dõi GitHub. Nếu phát hiện token bị thu hồi, nó có thể kích hoạt một quy trình dọn dẹp có tính hủy diệt. Điều này nhấn mạnh tầm quan trọng của thứ tự phản ứng: cần cô lập máy bị ảnh hưởng hoặc CI runner trước khi thu hồi thông tin xác thực.
Các nhóm đã cài đặt một bản phát hành bị ảnh hưởng nên thực hiện các hành động sau: cô lập thiết bị hoặc CI runner, dừng và vô hiệu hóa các dịch vụ người dùng được xác định, và xóa các tệp tạm thời và các tệp duy trì sự tồn tại đã liệt kê.
Họ cũng nên gỡ bỏ dependency độc hại, ghim các phiên bản đã biết là an toàn, xây dựng lại các tệp khóa (lockfiles) và điều tra các kho lưu trữ cùng lịch sử phát hành để tìm các thay đổi trái phép.
Chỉ sau khi trình giám sát bị loại bỏ, các chuyên gia bảo mật mới nên thực hiện xoay vòng (rotate) thông tin xác thực GitHub, npm, PyPI, RubyGems, cloud, SSH và CI từ một hệ thống sạch.
Các nhóm cũng nên đảm bảo rằng các bình luận pull-request không đáng tin cậy không thể kích hoạt quá trình xuất bản và xem xét các thông tin có nguồn gốc đáng tin cậy như một tín hiệu chứ không phải bằng chứng về sự an toàn. Các tổ chức có thể so sánh mô hình lây lan này với chiến dịch Mini Shai-Hulud mới.
Các chỉ số xâm phạm (Indicators of Compromise – IoCs) có thể bao gồm các địa chỉ IP và tên miền độc hại. Lưu ý: Địa chỉ IP và tên miền được cố tình làm mất hiệu lực (ví dụ: [.] ) để ngăn chặn việc phân giải hoặc tạo liên kết ngoài không mong muốn. Chỉ khôi phục lại định dạng ban đầu trong các nền tảng tình báo mối đe dọa được kiểm soát như MISP, VirusTotal hoặc SIEM của bạn.
Tăng cường khả năng của đội ngũ Tier 1 với tình báo mối đe dọa từ 15.000 SOC bằng cách tích hợp tra cứu TI vào SOC của bạn.
