Một tấn công chuỗi cung ứng phần mềm mới được phát hiện đã cho thấy tốc độ mà một tài khoản nhà phát triển đáng tin cậy có thể trở thành kênh phân phối mã độc. Chiến dịch này, được theo dõi là GHAPPIER, đã ảnh hưởng đến 65 kho lưu trữ GitHub, xâm phạm 73 tệp trên 22 tài khoản.
Chi tiết cuộc tấn công GHAPPIER
Cuộc tấn công này liên quan đến một gói npm hợp pháp đã phân phối một bộ tải mã độc đến người dùng. Những kẻ tấn công đã lợi dụng quyền truy cập vào một tài khoản duy trì gói để thay đổi mã nguồn và tự động hóa việc xuất bản từ nhánh chính của dự án. Phiên bản bị nhiễm độc xuất hiện hợp pháp vì nó được xây dựng thông qua quy trình xuất bản tự động của dự án, cho phép một bản cập nhật phụ thuộc thông thường mang bộ tải thực thi mã từ xa vào môi trường của nhà phát triển.
Vụ việc bắt đầu vào ngày 9 tháng 9, khi kẻ tấn công sử dụng tài khoản duy trì của gói @dforge-core/dforge-mcp trong khoảng 105 phút. Các nhà nghiên cứu không thể xác nhận cách thức truy cập được lấy, nhưng cho rằng một máy nhà phát triển bị nhiễm, một tiện ích mở rộng hoặc một gói độc hại là những con đường khả thi dẫn đến thông tin đăng nhập.
Cách thức hoạt động của mã độc
Trong quá trình xâm nhập, tác nhân đe dọa đã chèn một bộ tải từ xa, thay đổi ba dòng mã để các lần đẩy lên nhánh chính sẽ khởi động quy trình phát hành. Sau đó, chúng viết lại quy trình đó để xuất bản không cần giám sát. Phiên bản độc hại @dforge-core/dforge-mcp phiên bản 0.2.21 đã tồn tại trên kho lưu trữ trong 35 phút 38 giây trước khi người duy trì khôi phục dự án và phát hành phiên bản sạch 0.2.22.
Gói bị sửa đổi mang theo thông tin nguồn gốc npm hợp lệ. GitHub Actions đã tạo nó bằng OpenID Connect trusted publishing, và chứng nhận của nó trong Sigstore đã ghi lại commit của kẻ tấn công. Tuy nhiên, bản ghi này không thể xác nhận rằng mã đi vào quá trình build là an toàn. Quyền ghi vào kho lưu trữ đã trở thành quyền xuất bản, một rủi ro cũng được ghi nhận khi các gói npm bị xâm phạm trên quy mô lớn.
Bộ tải được ẩn trong một dòng mã gần dòng 3.320 của một tệp 99 KB và bắt đầu một chuỗi bốn giai đoạn. Thành phần cuối cùng của nó tự xóa, giảm khả năng tìm thấy dấu vết của mã độc thông qua tìm kiếm trên đĩa. Các nhà nghiên cứu cho biết tất cả các giai đoạn vẫn phản hồi khi được kiểm tra năm ngày sau khi gói bị rút. CloudSEK đã liên kết một bộ tải thứ hai trong một kho lưu trữ nạn nhân khác với PolinRider, một chiến dịch được ghi nhận là âm thầm nối mã vào các tệp cấu hình dự án thực tế.
Bộ tải đọc thông tin lệnh và kiểm soát (C2) từ một giao dịch blockchain Ethereum thay vì sử dụng tên miền hoặc máy chủ thông thường. Báo cáo lưu ý rằng một phiên bản tương tự vẫn đang hoạt động khi nghiên cứu được công bố. Mẫu quan sát được này có thể giải thích việc chiếm đoạt tài khoản ban đầu, vì PolinRider được ghi nhận là thu thập thông tin đăng nhập Git đã lưu trong bộ nhớ cache từ các máy bị nhiễm, cho phép kẻ tấn công đẩy mã dưới danh tính của nhà phát triển.
Tầm quan trọng và khuyến nghị
Vụ việc này nhấn mạnh lý do tại sao các quy trình xuất bản đáng tin cậy, quyền truy cập kiểm soát nguồn và thiết bị của nhà phát triển thuộc cùng một ranh giới bảo mật. Các chiến dịch tấn công workflow GitHub độc hại cho thấy kẻ tấn công có thể biến tự động hóa thành một con đường để đánh cắp thông tin đăng nhập và xâm phạm kho lưu trữ rộng hơn.
Khả năng này minh họa tại sao việc bảo vệ điểm cuối của nhà phát triển lại quan trọng ngang bằng với việc xem xét kho lưu trữ, đặc biệt là sau khi các kho lưu trữ riêng tư bị lộ trong các sự cố đánh cắp token chuỗi cung ứng. Các tổ chức sử dụng gói bị ảnh hưởng nên ghim nó vào phiên bản 0.2.22 và xem xét liệu phiên bản 0.2.21 có được cài đặt hoặc thực thi hay không.
Các nhóm bảo mật nên chặn các điểm cuối socket và tên máy chủ phân phối được xác định trong nghiên cứu chi tiết. Đồng thời, họ cần tìm kiếm các tạo tác còn lại bởi chuỗi mã độc thay vì chỉ tập trung vào dấu vết của bộ tải tự xóa. Việc kiểm toán các thay đổi trong quy trình phát hành, hạn chế quyền truy cập ghi vào nhánh chính, xoay vòng thông tin đăng nhập bị lộ và bảo tồn nhật ký kiểm soát nguồn cũng là những biện pháp cần thiết.
Việc rút một phiên bản gói độc hại có thể ngăn chặn các lượt tải xuống mới mà không thể vô hiệu hóa cơ sở hạ tầng của kẻ tấn công hoặc cảnh báo mọi người dùng đã tải xuống nó. Các cuộc tấn công trước đây lạm dụng tệp build phần mềm cho thấy tại sao việc kiểm tra tính toàn vẹn của gói phải đi đôi với việc giám sát hoạt động CI và tài khoản nhà phát triển.
Nghiên cứu chi tiết về vụ tấn công có thể được tìm thấy tại CloudSEK.
