Chuỗi cung ứng phần mềm tiếp tục là điểm bị khai thác khi gói JavaScript node-ipc bị phát hiện chứa payload stealer và backdoor được làm rối. Theo xác nhận từ Socket và StepSecurity, ba phiên bản mới phát hành gồm [email protected], [email protected] và [email protected] đã bị chèn mã độc, đánh dấu vụ xâm nhập chuỗi cung ứng lớn thứ hai của gói này kể từ năm 2022. Tham chiếu thêm tại Socket Security Advisory.
Lỗ hổng chuỗi cung ứng trong node-ipc
Đây không phải lỗ hổng CVE theo nghĩa truyền thống, mà là một cảnh báo CVE-like về rủi ro từ gói phụ thuộc bị chiếm quyền phát hành. Điểm đáng chú ý là mã độc chỉ xuất hiện trong CommonJS entrypoint node-ipc.cjs, được nối thêm dưới dạng một obfuscated IIFE. Phần ESM module vẫn sạch.
Điều này khiến hệ thống dùng require("node-ipc") có nguy cơ cao hơn, trong khi các consumer chỉ dùng ESM có thể không bị ảnh hưởng trực tiếp. Mức độ ảnh hưởng phụ thuộc vào cách ứng dụng load gói này trong quá trình khởi tạo.
Vector xâm nhập và chiếm quyền phát hành
Nhà nghiên cứu an ninh Ian Ahl (@TekDefense), CTO tại Permiso, cho biết vector tấn công có khả năng cao là chiếm quyền tài khoản maintainer đã bị bỏ quên. Tài khoản “atiertant”, một trong mười hai maintainer được liệt kê của npm package, đã không hoạt động trong nhiều năm.
Dữ kiện liên quan cho thấy tên miền khôi phục email atlantis-software[.]net đã hết hạn rồi bị tái đăng ký sau đó, qua đó cho phép kẻ tấn công thực hiện quy trình đặt lại mật khẩu npm và giành quyền publish mà không cần chạm vào hạ tầng gốc của maintainer. Trường hợp này phản ánh rủi ro an toàn thông tin đặc trưng của các tài khoản phát hành bị bỏ hoang.
Hành vi của payload độc hại
Payload được kích hoạt khi module load thông qua setImmediate(). Sau đó, mã độc fork một tiến trình con ở chế độ detached với cờ môi trường __ntw=1. Từ đây, thành phần độc hại triển khai các hành vi sau:
- Thực hiện truy vấn DNS TXT với tần suất cao.
- Gửi burst truy vấn đến miền bt[.]node[.]js.
- Khởi tạo bootstrap resolver domain để phục vụ cơ chế tải hoặc liên lạc tiếp theo.
Quan sát của nhà nghiên cứu cho thấy một archive nén 500 KiB có thể tạo ra khoảng 29.400 DNS TXT queries. Đây là dấu hiệu phát hiện xâm nhập quan trọng cho hệ thống giám sát mạng và IDS.
Đặc điểm forensic của gói độc hại
Tất cả tệp trong các tarball độc hại đều mang timestamp pháp chứng 26/10/1985. Đây là artifact có chủ đích và có thể dùng để nhận diện bản sao đã được cache hoặc mirror. Khi rà soát kho gói nội bộ, dấu thời gian bất thường này là một chỉ báo cần kiểm tra ngay.
Tác động lên hệ thống
Hệ thống tải phải ba phiên bản bị nhiễm của node-ipc cần được xem là đã tiếp xúc với mối đe dọa đánh cắp thông tin. Bất kỳ biến môi trường, SSH key, cloud credential hoặc API token nào hiện diện trên máy khi CommonJS entrypoint được nạp đều phải được xem là đã bị xâm nhập.
Trong bối cảnh này, rủi ro không chỉ là rò rỉ dữ liệu mà còn là khả năng lạm dụng thông tin xác thực để mở rộng truy cập sang các dịch vụ nội bộ hoặc hệ thống đám mây liên quan. Với các môi trường CI/CD, mức độ nguy hiểm tăng lên nếu package-lock hoặc cache cục bộ đã ghi nhận phiên bản bị nhiễm.
Kiểm tra gói và rà soát phụ thuộc
Nhóm vận hành nên xác định nhanh liệu dự án có đang phụ thuộc vào các bản phát hành bị ảnh hưởng hay không. Việc kiểm tra cần tập trung vào lock file, cache npm cục bộ và cách ứng dụng import module.
npm ls node-ipc
cat package-lock.json | grep -n "node-ipc"
grep -n "node-ipc" yarn.lock
npm cache verify
Nếu phát hiện [email protected], [email protected] hoặc [email protected], cần loại bỏ ngay và thay thế bằng phiên bản an toàn đã được xác minh từ nguồn phát hành đáng tin cậy.
Các tệp cần kiểm tra ngay
- package-lock.json
- yarn.lock
- npm cache nội bộ và cache trên máy phát triển
- Các pipeline CI/CD đã từng thực thi
require("node-ipc")
IOC cần theo dõi
Dưới đây là các IOC nổi bật liên quan đến hành vi độc hại của gói bị chiếm quyền:
- [email protected]
- [email protected]
- [email protected]
- node-ipc.cjs chứa obfuscated IIFE
- __ntw=1 environment variable flag
- bt[.]node[.]js
- DNS TXT query bursts
- Timestamp 1985-10-26 trong tarball độc hại
Biện pháp xử lý và săn tìm
Đối với cảnh báo CVE dạng supply chain này, bước xử lý ưu tiên là gỡ bỏ các bản phát hành độc hại, xoay vòng toàn bộ thông tin xác thực có thể đã xuất hiện trên máy tải gói, và rà soát log DNS để tìm burst truy vấn TXT bất thường. Nếu endpoint hoặc sandbox có lưu telemetry, cần đối chiếu thời điểm load module với truy vấn đến miền nêu trên.
Security teams nên triển khai hunting dựa trên hai tín hiệu chính: DNS TXT query bursts tới bt[.]node[.]js và sự xuất hiện của __ntw=1 trong tiến trình con. Với hệ thống giám sát, đây là chỉ báo đủ mạnh để dựng rule phát hiện sớm mối đe dọa mạng liên quan đến package bị xâm nhập.
Hành động khuyến nghị
- Xóa ba phiên bản bị ảnh hưởng khỏi hệ thống build và registry nội bộ.
- Rà soát lại toàn bộ dependency tree để xác định nơi sử dụng
require("node-ipc"). - Xoay vòng SSH keys, cloud credentials và API tokens trên máy đã load CommonJS entrypoint.
- Chặn hoặc giám sát miền bootstrap resolver và truy vấn DNS TXT bất thường.
- Đối chiếu cache, artifact và tarball để tìm dấu timestamp 1985-10-26.
Điểm kỹ thuật cần lưu ý
Mẫu sự cố này cho thấy chuỗi cung ứng phần mềm có thể bị lạm dụng mà không cần khai thác một remote code execution truyền thống. Thay vào đó, kẻ tấn công chỉ cần giành quyền publish, nhúng payload vào entrypoint được tải rộng rãi, rồi lợi dụng hành vi khởi tạo module để thực thi mã.
Với các dự án JavaScript phụ thuộc sâu vào npm, việc kiểm soát khóa gói, theo dõi bản vá và đối chiếu nguồn phát hành là một phần bắt buộc của an toàn thông tin và bảo mật mạng. Trong trường hợp này, tín hiệu phát hiện hiệu quả nhất vẫn là các truy vấn DNS TXT bất thường, các file tarball có timestamp lạ và dấu vết của phiên bản node-ipc bị ảnh hưởng.
