Chiến dịch Gheist đánh cắp bí mật từ các repo GitHub riêng tư thông qua nhật ký Actions

Một chiến dịch tấn công tự động mới có tên là Gheist đang khai thác các token GitHub bị đánh cắp để trích xuất dữ liệu nhạy cảm từ các repository riêng tư. Kể từ giữa tháng Chín, các nhà nghiên cứu bảo mật tại Wiz đã quan sát thấy tin tặc cài đặt các workflow độc hại in trực tiếp bí mật của repository vào nhật ký GitHub Actions. Các cuộc tấn công này nhắm mục tiêu cụ thể vào các repository riêng tư và các phiên bản GitHub Enterprise Server, nơi mà các biện pháp phòng ngừa tự động hiện có kém hiệu quả hơn.

Chuyện gì đã xảy ra

Chiến dịch Gheist hoạt động bằng cách sử dụng thông tin đăng nhập bị xâm phạm để tạo các nhánh mới trong các repository mục tiêu. Mỗi nhánh tuân theo một mẫu đặt tên cụ thể, bắt đầu bằng ci-sync- theo sau là sáu ký tự ngẫu nhiên. Tin tặc cam kết (commit) một tệp workflow duy nhất vào các nhánh này, được thiết kế để thực thi ngay lập tức khi push. Workflow này truy cập vào các biến môi trường và bí mật của repository, mã hóa chúng dưới định dạng base32 trước khi in ra đầu ra chuẩn (standard output). Do dữ liệu được mã hóa, nó vượt qua các tính năng che giấu bí mật tự động của GitHub, cho phép toàn bộ giá trị xuất hiện trong nhật ký build.

Sau khi workflow hoàn tất, công cụ của tin tặc tải xuống tệp nhật ký thông qua API GitHub, sau đó xóa lần chạy workflow và chính nhánh đó. Việc dọn dẹp nhanh chóng này khiến việc phát hiện trở nên khó khăn, vì bằng chứng biến mất rất nhanh. Wiz báo cáo rằng mặc dù GitHub đã triển khai một biện pháp bảo vệ tạm dừng các lần chạy workflow đáng ngờ trong các repository công khai, nhưng sự bảo vệ này hiện không mở rộng đến các repository riêng tư hoặc các cài đặt GitHub Enterprise Server tự lưu trữ (self-hosted). Do đó, mọi nỗ lực trên repository công khai mà Wiz phân tích đều bị chặn, nhưng các môi trường riêng tư và doanh nghiệp vẫn dễ bị tổn thương trước việc rò rỉ dữ liệu thành công.

Quy mô của chiến dịch là đáng kể. Wiz đã xác định hơn 13.500 nhánh bị cài cắm trên hơn 850 tài khoản bị xâm phạm. Các tài khoản này trải dài từ những nhà phát triển cá nhân đến các tổ chức doanh nghiệp lớn. Trong một số trường hợp doanh nghiệp, tin tặc đã luân chuyển nhiều token người dùng và token tự động hóa chỉ trong vài phút, sao chép mã nguồn riêng tư và cài đặt workflow trên nhiều repository. Các token bị đánh cắp thường có nguồn gốc từ phần mềm gián điệp (infostealer malware) hoặc các vụ vi phạm chuỗi cung ứng trước đó, chẳng hạn như sự cố vào tháng Ba liên quan đến trình quét lỗ hổng Trivy.

Chi tiết chính

• Chiến dịch sử dụng chuỗi user agent gheist cho tất cả các yêu cầu API.
• Các nhánh độc hại được đặt tên là ci-sync- theo sau bởi sáu ký tự chữ thường và số.
• Tệp workflow được cam kết luôn là .github/workflows/sync-check.yml với thông điệp commit ci: sync config.
• Bí mật bị rò rỉ bằng cách mã hóa chúng dưới dạng base32 để vượt qua cơ chế che giấu nhật ký của GitHub.
• Cơ chế giữ tự động của GitHub đối với các lần chạy đáng ngờ hiện chỉ áp dụng cho các repository công khai trên github.com.
• Wiz đã thu hồi hơn 13.500 nhánh bị cài cắm từ hơn 850 tài khoản bị xâm phạm kể từ ngày 15 tháng 9.

Bối cảnh

GitHub Actions cho phép các nhà phát triển tự động hóa các quy trình làm việc phần mềm, chẳng hạn như xây dựng và kiểm thử mã. Các workflow này thường yêu cầu quyền truy cập vào thông tin nhạy cảm như khóa API, mật khẩu cơ sở dữ liệu và thông tin đăng nhập đám mây, được lưu trữ dưới dạng bí mật repository. Theo mặc định, bất kỳ người dùng nào có quyền ghi vào repository đều có thể đọc các bí mật này. Khi một workflow chạy, GitHub cố gắng che giấu các giá trị bí mật đã biết trong nhật ký để ngăn chặn việc vô tình lộ thông tin. Tuy nhiên, việc che giấu này dựa trên khớp chuỗi chính xác. Nếu một bí mật bị sửa đổi, chẳng hạn như bằng cách mã hóa nó dưới dạng base32 hoặc chia nhỏ thành các phần, GitHub có thể không nhận diện và che giấu được nó, khiến giá trị thô hiển thị rõ ràng trong nhật ký.

Sự khác biệt giữa các biện pháp bảo vệ repository công khai và riêng tư là rất quan trọng ở đây. GitHub gần đây đã giới thiệu một tính năng giữ lại các lần chạy workflow từ các nguồn chưa được xác minh để chờ phê duyệt thủ công trong các repository công khai. Điều này đóng vai trò như một rào cản mạnh mẽ chống lại việc lạm dụng tự động trong các dự án mã nguồn mở. Tuy nhiên, tính năng này hiện chưa khả dụng cho các repository riêng tư hoặc GitHub Enterprise Server, vốn được nhiều công ty sử dụng cho phần mềm độc quyền nội bộ. Khoảng trống này khiến các môi trường tự lưu trữ và riêng tư phải phụ thuộc vào các biện pháp bảo mật khác, chẳng hạn như quản lý token nghiêm ngặt và ghi nhật ký kiểm toán, những thứ có thể khó giám sát theo thời gian thực hơn.

Tại sao điều này quan trọng

Đối với các đội ngũ vận hành phần mềm riêng hoặc quản lý mã nguồn riêng tư, sự cố này làm nổi bật một mắt xích mong manh trong chuỗi bảo mật CI/CD. Giả định rằng nhật ký an toàn vì bí mật được che giấu giờ đây không còn đúng nữa. Tin tặc đang chủ động sử dụng các kỹ thuật mã hóa để lách qua những biện pháp bảo vệ này. Nếu tổ chức của bạn sử dụng GitHub Actions cho việc triển khai, đặc biệt là với runner tự lưu trữ hoặc repository riêng tư, các bí mật của bạn sẽ gặp rủi ro nếu một token bị xâm phạm. Thực tế là tin tặc xóa các lần chạy ngay lập tức có nghĩa là việc giám sát truyền thống có thể bỏ sót hoàn toàn sự kiện trừ khi bạn đã bật và chủ động xem xét các nhật ký kiểm toán chi tiết.

Hơn nữa, chiến dịch này minh họa hiệu ứng domino của việc đánh cắp token. Một token truy cập cá nhân hoặc thông tin đăng nhập tự động hóa bị đánh cắp đơn lẻ có thể dẫn đến việc xâm phạm toàn bộ hạ tầng đám mây của một tổ chức. Trong các trường hợp được Wiz phân tích, tin tặc đã sử dụng quyền truy cập ban đầu để giả mạo (assume) các vai trò AWS thông qua OIDC, tiềm ẩn nguy cơ giành quyền kiểm soát rộng hơn đối với các tài nguyên đám mây. Đối với các trưởng nhóm IT và kỹ sư DevOps, điều này có nghĩa là bảo mật pipeline CI/CD không chỉ liên quan đến chất lượng mã mà còn là bảo vệ chìa khóa cho môi trường sản xuất của bạn. Việc thiếu cơ chế chặn tự động trong các repo riêng tư đặt gánh nặng phát hiện hoàn toàn lên vai đội ngũ bảo mật nội bộ.

Bạn có thể làm gì

• Tìm kiếm trong các repository của bạn những nhánh khớp với mẫu ci-sync- theo sau bởi sáu ký tự và xóa chúng nếu tìm thấy.
• Xoay vòng (rotate) tất cả các bí mật repository, tổ chức và môi trường ngay lập tức nếu bạn nghi ngờ bất kỳ token nào bị xâm phạm.
• Xem xét nhật ký kiểm toán GitHub cho các lần chạy workflow trên các nhánh ci-sync-* đã bị xóa trong vòng một phút sau khi hoàn tất.
• Kiểm tra nhật ký của nhà cung cấp đám mây, chẳng hạn như AWS CloudTrail, để tìm các giả mạo vai trò liên quan đến chủ thể của nhánh ci-sync-.
• Thu hồi bất kỳ token nào liên quan đến các tài khoản bị xâm phạm và quét thiết bị của chủ sở hữu để tìm phần mềm gián điệp (infostealer).
• Yêu cầu phê duyệt của người xem xét thủ công cho các lần triển khai tới các môi trường chứa bí mật sản xuất.