Các gói phần mềm nguồn mở (open-source packages) thường được phát triển để tiết kiệm thời gian cho các lập trình viên. Tuy nhiên, trong chiến dịch GemStuffer, sự tin tưởng này đã bị lạm dụng để phát tán mã độc, có khả năng thực thi trên các hệ thống tài liệu, thu thập thông tin trực tuyến và đánh cắp thông tin xác thực RubyGems.
Phạm vi và Phương thức Hoạt động của Chiến dịch GemStuffer
Phân tích chi tiết cho thấy quy mô hoạt động của chiến dịch này lớn hơn nhiều so với các báo cáo ban đầu. Hoạt động diễn ra từ tháng 5 đến tháng 7 năm 2026, với đỉnh điểm vào ngày 12 tháng 5. Một số gói phần mềm độc hại không yêu cầu người dùng cài đặt trực tiếp để kích hoạt.
Các đối tượng tấn công đã lợi dụng quy trình xử lý tài liệu tự động, biến một tính năng dịch vụ thông thường thành điểm thực thi mã không đáng tin cậy. Các nhà phân tích từ JFrog đã xác định được 3.022 gói RubyGems liên quan đến chiến dịch, bao gồm 3.315 kết hợp giữa gói và phiên bản.
Kết quả này mở rộng phạm vi của cuộc điều tra RubyHack trước đó, vốn đã liên kết các hoạt động vào tháng 5 và tháng 6 với các tác nhân liên quan đến OpenAI thông qua nội dung gói và sự trùng lặp với một sự cố wiki công khai. Bằng chứng chỉ ra đây là một chiến dịch do các tác nhân liên kết thực hiện, không phải là phát hiện về việc OpenAI cố tình vận hành nó. JFrog báo cáo rằng các gói này đã sử dụng các trình xử lý tài liệu để truy xuất trang web và gửi kết quả trở lại thông qua RubyGems. Để biết thêm chi tiết, vui lòng tham khảo báo cáo của JFrog tại đây.
Chiến dịch này bao gồm việc tải gói lên, các trình xử lý tự động, khóa xuất bản, siêu dữ liệu công khai và các chế độ xem quản trị. Các nhóm theo dõi các mối đe dọa từ các gói nhà phát triển bị đầu độc nên lưu ý rằng mối nguy hiểm có thể phát sinh khi một dịch vụ xử lý một gói, chứ không chỉ khi ai đó cài đặt nó. Sự khác biệt này mở rộng tác động tiềm ẩn: một trình xử lý tập trung có thể xử lý nhiều tệp đính kèm và nắm giữ quyền truy cập mạng hoặc thông tin xác thực mà những người tiêu dùng gói thông thường không bao giờ nhận được. Tốc độ xuất bản nhanh chóng cũng làm phức tạp đáng kể quá trình xem xét.
Chi Tiết Kỹ Thuật và Phương Pháp Tấn Công
Tên của các gói đã cung cấp manh mối cho các nhà điều tra về quy mô và mức độ tự động hóa đằng sau các lần tải lên. JFrog phát hiện nhiều tên chứa các từ khóa như “oai” và “probe”, cùng với các tham chiếu đến việc lấy dữ liệu (fetching), proxy, scraping, YARD và payloads. Một số gói chứa dấu thời gian Unix khớp chặt chẽ với thời gian xuất bản; các gói khác sử dụng tên ngắn, tuần tự hoặc ngẫu nhiên.
Một phương pháp tấn công chính đã sử dụng cài đặt RubyDoc để tải mã Ruby được kiểm soát bởi gói. Khi một trình xử lý tài liệu xử lý một gói được chế tạo, mã độc có thể thực thi, thu thập các trang lịch và tài liệu liên kết, sau đó đóng gói kết quả để xuất bản trở lại kho lưu trữ. Điều này khác với các vụ đánh cắp thông tin xác thực RubyGems độc hại, nơi nạn nhân thường là nhà phát triển cài đặt gói.
Một mẫu khác đã cố gắng thu thập các khóa API RubyGems thông qua nhiều hình thức của một điểm cuối cũ trước khi tải dữ liệu lên. RubyGems sau đó cho biết họ đã khắc phục sự cố bộ nhớ cache và thu hồi các khóa cũ. Tuy nhiên, dòng thời gian cho thấy một nỗ lực trước khi công bố công khai, nhưng không chứng minh được rằng việc bỏ qua bộ nhớ cache đã hoạt động.
Một mẫu khác đã đặt kết quả thu thập được mã hóa vào cấu hình webhook thay vì một gói mới. Việc sử dụng kho lưu trữ làm kênh trả về đã giảm nhu cầu về một máy chủ lệnh riêng biệt. Do đó, các chuyên gia bảo mật nên điều tra các hành động bất thường trong kho lưu trữ cũng như lưu lượng truy cập build đáng ngờ.
Các lượt tải lên vào tháng 7 đã bổ sung các payload thử nghiệm vào phần mô tả gói và các trường tác giả. Chúng cố gắng thực hiện các cuộc tấn công cross-site scripting (XSS) và template-expression injection chống lại các trang gói, bảng điều khiển quản trị hoặc trình phân tích siêu dữ liệu. Một gói có thể tạo ra lỗ hổng ngay cả khi mã thư viện của nó trông có vẻ vô hại, đặc biệt là khi một trang web hiển thị văn bản do gói cung cấp. Các tổ chức tạo tài liệu hoặc xử lý các gói được tải lên nên xem xét các tác vụ gần đây liên quan đến các phiên bản bị ảnh hưởng.
Khuyến nghị Bảo mật và Giảm thiểu Rủi ro
Để giảm thiểu rủi ro, các tổ chức nên cô lập một trình xử lý có thể đã thực thi một payload không đáng tin cậy, bảo toàn nhật ký và các tạo tác liên quan. Sau đó, tiến hành xây dựng lại từ một hình ảnh đáng tin cậy và xoay vòng các thông tin xác thực mà nó có thể truy cập được. Các biện pháp bảo vệ tương tự cũng rất quan trọng trong các trường hợp đánh cắp thông tin xác thực trong quy trình CI, nơi tự động hóa thường nắm giữ các bí mật có giá trị.
Các quy trình build tài liệu cho các gói không đáng tin cậy nên sử dụng môi trường dùng một lần, không có khóa xuất bản, thông tin xác thực đám mây, mount ổ đĩa hoặc quyền truy cập mạng không cần thiết. Các tùy chọn tải được gói kiểm soát không bao giờ được thực thi trong một quy trình đáng tin cậy. Trong trường hợp không thể tránh khỏi các trình trợ giúp có thể thực thi, các nhóm phải coi tác vụ đó là mã không đáng tin cậy từ đầu đến cuối.
Quản trị viên nên xem xét lịch sử tài khoản để phát hiện các bản phát hành bất thường, các phiên bản đã bị xóa, thay đổi chủ sở hữu, nhà xuất bản đáng tin cậy và các webhook. Việc sử dụng thông tin xác thực được giới hạn phạm vi, có thời hạn ngắn và xác thực đa yếu tố cho các hành động API có thể giảm thiểu tác động của việc đánh cắp khóa.
Cần thoát các siêu dữ liệu trong các trang công khai và quản trị, đồng thời coi các trường đáng ngờ là văn bản, không phải là mẫu có thể thực thi hoặc đối tượng được serialize không an toàn. Các bước này củng cố những bài học từ các cuộc tấn công chuỗi cung ứng nguồn mở rộng lớn hơn.
Các chỉ số xâm phạm (IoC) có thể được tìm thấy trong báo cáo gốc.
Lưu ý: Các địa chỉ IP và tên miền đã được làm mờ (ví dụ: [.]) để ngăn chặn việc phân giải hoặc liên kết ngoài ý muốn. Chỉ giải mờ 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.
