Một cuộc tấn công chuỗi cung ứng npm mới đã biến các gói phần mềm đáng tin cậy thành công cụ đánh cắp thông tin đăng nhập.
Chiến dịch này bắt đầu sau khi kẻ tấn công xâm phạm tài khoản bảo trì của thư viện Keyv, được sử dụng rộng rãi. Chúng lợi dụng quyền truy cập này để đẩy các bản phát hành độc hại lên ngày càng nhiều dự án.
Điều này rất quan trọng vì các gói npm thường được cài đặt tự động trong quá trình phát triển và xây dựng. Một sự phụ thuộc bị nhiễm độc có thể tiếp cận máy tính xách tay, máy chủ và các quy trình tự động mà không cần người dùng tương tác với trang web đáng ngờ hoặc mở tệp đính kèm độc hại.
Mini Shai-Hulud và Tấn công Chuỗi Cung ứng
Microsoft và Socket đã xác định hoạt động này là một chiến dịch Mini Shai-Hulud đang hoạt động. Đây là một hoạt động mã độc tự lan truyền, được thiết kế để đánh cắp các token truy cập và tái sử dụng chúng.
Cả Microsoft và Socket đều báo cáo rằng những kẻ tấn công dường như đã sử dụng nhiều token xuất bản bị đánh cắp. Quy mô của cuộc tấn công đã mở rộng nhanh chóng, với Socket báo cáo 2.234 tạo tác gói bị ảnh hưởng trên 444 gói duy nhất trong khi hoạt động vẫn đang lan rộng.
Điều này cho thấy một tài khoản bảo trì bị xâm phạm duy nhất có thể tạo ra rủi ro bảo mật sâu rộng cho các nhóm trên toàn thế giới dựa vào mã nguồn mở.
Khởi đầu từ Thư viện Keyv
Cuộc tấn công bắt đầu bằng việc xâm phạm tài khoản đáng tin cậy liên kết với Keyv, một thư viện lưu trữ key-value phổ biến. Sau khi kẻ tấn công giành được quyền xuất bản, chúng có thể phát hành các gói đã bị thay đổi, trông giống như các bản cập nhật thông thường và có sẵn thông qua quy trình cài đặt npm tiêu chuẩn.
Quyền truy cập ban đầu này đã mang lại cho chiến dịch một lượng người dùng lớn bất thường. Keyv có lượng tải xuống hàng tuần đáng kể, do đó, việc xâm phạm nó đã đặt một sự phụ thuộc quen thuộc vào trung tâm của một sự cố rộng lớn hơn.
Các bản phát hành độc hại sử dụng một chỉ dẫn tại thời điểm cài đặt để bắt đầu cuộc tấn công trước khi nhà phát triển có thể sử dụng gói.
Sự lan rộng của Mã độc
Thay vì dừng lại ở một máy, mã độc tìm kiếm thông tin đăng nhập cho phép nó xuất bản các bản phát hành đã thay đổi từ những người bảo trì khác, tạo ra phản ứng dây chuyền trên toàn bộ registry. Hành vi này làm cho sự cố khác biệt so với việc đầu độc một gói đơn lẻ.
Mối đe dọa được thiết kế để di chuyển qua các mối quan hệ xuất bản phần mềm, có nghĩa là mỗi token bị đánh cắp có thể mở ra một con đường khác tới các nhà phát triển, hệ thống xây dựng và các tổ chức phụ thuộc vào các gói đó.
Chiến dịch này cũng phù hợp với một mô hình đáng lo ngại đã thấy trong các chiến dịch đánh cắp thông tin đăng nhập npm gần đây. Trong các cuộc tấn công đó, các nhà điều hành tội phạm tập trung vào các tài khoản và quy trình tự động hóa xuất bản mã, biết rằng một tài khoản hợp pháp có thể hữu ích hơn một lượng lớn các gói giả.
Sau khi chạy, mã độc tìm kiếm thông tin đăng nhập được kết nối với npm, tài khoản lưu trữ mã, dịch vụ đám mây và các hệ thống tích hợp liên tục. Những bí mật này có thể cung cấp quyền truy cập vượt xa dự án bị ảnh hưởng, đặc biệt là khi một hệ thống xây dựng có quyền xuất bản gói hoặc triển khai phần mềm.
Đánh cắp Thông tin đăng nhập và Tái phát hành
Thông tin bị đánh cắp được gửi ra khỏi môi trường nạn nhân, sau đó quyền xuất bản được sử dụng để thay đổi kho lưu trữ gói, tăng số phiên bản của chúng và phát hành lại. Vòng lặp tự động này giúp giải thích lý do tại sao các nhà phân tích thấy số lượng tạo tác bị ảnh hưởng tăng nhanh như vậy.
Các nhóm nên coi bất kỳ việc cài đặt bản phát hành độc hại nào được liệt kê là một sự cố lộ thông tin đăng nhập tiềm ẩn, không chỉ đơn thuần là một bản cập nhật phụ thuộc bị lỗi.
Các biện pháp phòng ngừa và khắc phục
Các đội nên gỡ bỏ các phiên bản bị ảnh hưởng, xây dựng lại các tệp khóa phụ thuộc từ thông tin đáng tin cậy và xem xét các thay đổi gói gần đây trước khi cho phép tiếp tục triển khai tự động. Việc luân chuyển thông tin đăng nhập cũng quan trọng không kém.
Các token npm, token truy cập lưu trữ mã, khóa đám mây và bí mật tích hợp liên tục có sẵn trên các máy bị ảnh hưởng nên được thu hồi và thay thế. Đồng thời, những người bảo trì nên kiểm tra kho lưu trữ và lịch sử xuất bản để tìm các bản phát hành hoặc chỉnh sửa quy trình làm việc bất ngờ.
Các tổ chức có thể giảm thiểu rủi ro trong tương lai bằng cách yêu cầu xác thực đa yếu tố cho các tài khoản xuất bản, sử dụng thông tin xác thực tự động có thời hạn ngắn và phạm vi hẹp, đồng thời tách quyền xây dựng khỏi quyền phát hành.
Giám sát các phiên bản gói bất thường và hành vi cài đặt không mong muốn cũng có thể giúp phát hiện sự tái diễn sớm hơn.
Tóm tắt Bài học Kinh nghiệm
Bài học trước mắt rất đơn giản: sự tin tưởng vào tên gói là không đủ trong công việc sản xuất hàng ngày khi tài khoản bảo trì hoặc token xuất bản của nó đã bị xâm phạm. Đối với bối cảnh bổ sung, độc giả có thể xem lại các báo cáo về làn sóng tấn công Mini Shai-Hulud và các biện pháp phòng thủ chuỗi cung ứng phần mềm.
Các Chỉ số Lỗi (IoCs)
Các chỉ số về sự cố (IoCs) được liệt kê dưới đây. Lưu ý: Địa chỉ IP và tên miền được cố tình làm mờ (ví dụ: [.]) để ngăn việc phân giải hoặc siêu liên kết vô tình. Chỉ khôi phục lại dạng đầy đủ 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.
Dữ liệu IoC cụ thể không được cung cấp trong nội dung gốc.
