Lỗ hổng Trusted Publishing trên npm: Hơn 1.500 gói phần mềm đối mặt nguy cơ chiếm quyền

• Lỗ hổng SlugFest: Một khiếm khuyết trong cơ chế xác thực Trusted Publishing của npm cho phép kẻ tấn công chiếm quyền kiểm soát các gói phần mềm mà không cần đánh cắp token.
• Phạm vi ảnh hưởng: Hơn 1.500 gói phần mềm với tổng cộng 10 triệu lượt tải xuống mỗi tháng đang nằm trong tầm ngắm của các tác nhân đe dọa.
• Cơ chế khai thác: Kẻ tấn công lợi dụng việc thay đổi quyền sở hữu repository trên GitHub để nhận credential xuất bản hợp lệ từ npm.
• Khuyến nghị: Các nhà phát triển cần rà soát lại cấu hình Trusted Publishing, xóa bỏ các liên kết cũ và đảm bảo tính toàn vẹn của các repository được kết nối.

Các nhà nghiên cứu bảo mật vừa công bố phát hiện về một lỗ hổng nghiêm trọng trong tính năng Trusted Publishing của npm, được đặt tên là SlugFest. Lỗ hổng này tạo ra một con đường tấn công chuỗi cung ứng phần mềm (software supply-chain attack) tinh vi, cho phép kẻ tấn công chiếm quyền điều khiển các gói phần mềm mà không cần phải xâm nhập vào tài khoản npm của người bảo trì hay đánh cắp các token xác thực dài hạn.

Cơ chế khai thác lỗ hổng SlugFest

Tính năng Trusted Publishing được thiết kế để tăng cường bảo mật cho quy trình phát hành gói npm bằng cách thay thế các token dài hạn bằng các credential ngắn hạn thông qua giao thức OpenID Connect (OIDC). Tuy nhiên, vấn đề nằm ở cách npm liên kết gói phần mềm với repository GitHub trong cấu hình ban đầu.

Thay vì lưu trữ định danh (ID) vĩnh viễn của repository, npm lại lưu trữ đường dẫn dạng văn bản (slug) như organization/project. Khi một dự án bị đổi tên, chuyển nhượng hoặc xóa bỏ, kẻ tấn công có thể đăng ký lại chính tên repository đó trên GitHub. Nếu gói phần mềm chưa từng thực hiện lần xuất bản tin cậy nào, npm sẽ chấp nhận tên repository mới này và cấp credential xuất bản hợp lệ cho kẻ tấn công.

Kẻ tấn công sau đó có thể phát hành các phiên bản mới của gói phần mềm, bao gồm cả việc chèn các mã độc hại thông qua script postinstall. Khi người dùng hoặc các hệ thống CI/CD cài đặt gói này, mã độc sẽ tự động được thực thi trong môi trường của nạn nhân.

Rủi ro từ AI Coding Agents

Nghiên cứu từ các chuyên gia bảo mật cũng nhấn mạnh vai trò của các AI coding agents trong việc gia tăng rủi ro. Các công cụ này thường tự động chọn, cài đặt và thực thi các gói phần mềm mà không có sự kiểm soát chặt chẽ từ con người. Với tần suất cài đặt lên tới hàng trăm gói mỗi tháng trên mỗi hệ thống, khả năng một gói phần mềm bị chiếm quyền được tự động đưa vào môi trường phát triển là rất cao.

Bảng tổng hợp các chỉ số IOCs và điều kiện khai thác

Khuyến nghị phòng thủ và khắc phục

GitHub đã triển khai bản vá bằng cách giới hạn thời gian tồn tại của các cấu hình Trusted Publishing chưa được xác thực xuống còn 48 giờ. Sau thời gian này, cấu hình sẽ hết hạn nếu không có lần xuất bản thành công nào được thực hiện. Để đảm bảo an toàn, các nhà phát triển cần thực hiện các bước sau:

• Rà soát cấu hình: Kiểm tra toàn bộ các thiết lập Trusted Publisher hiện có và đảm bảo các repository liên kết vẫn nằm trong tầm kiểm soát.
• Cập nhật quy trình: Xóa bỏ và tạo lại các liên kết nếu repository đã trải qua quá trình đổi tên, chuyển nhượng hoặc xóa bỏ.
• Thay đổi sự kiện kích hoạt: Chuyển các quy trình xuất bản sang các sự kiện an toàn hơn như push, release hoặc workflow_dispatch thay vì các sự kiện dễ bị lợi dụng.
• Giám sát hoạt động: Theo dõi chặt chẽ các hoạt động phát hành bất thường và thực hiện ghim phiên bản (version pinning) cho các phụ thuộc quan trọng.

⚠️ Cảnh báo quan trọng: Việc sở hữu bằng chứng xuất bản hợp lệ (provenance) không đồng nghĩa với việc mã nguồn hoặc môi trường xây dựng là an toàn. Hãy luôn kiểm tra kỹ các thay đổi trong các bản cập nhật phụ thuộc để tránh các cuộc tấn công tương tự như sự cố ChainDrop.

Để tìm hiểu thêm về các tiêu chuẩn bảo mật trong quy trình CI/CD, bạn có thể tham khảo tài liệu hướng dẫn từ CISA về bảo mật chuỗi cung ứng phần mềm.