Cảnh báo chiến dịch Gheist: Hacker sử dụng GitHub Token đánh cắp để chiếm đoạt bí mật từ Actions Logs
Các nhà nghiên cứu từ Wiz vừa phát hiện chiến dịch Gheist, sử dụng GitHub token bị đánh cắp để tự động chèn các workflow độc hại, từ đó trích xuất bí mật (secrets) từ GitHub Actions...
- Giọng nữ Bắc
Một chiến dịch tự động hóa nguy hiểm mang tên Gheist đang nhắm mục tiêu vào các kho lưu trữ (repository) trên GitHub. Kẻ tấn công sử dụng các token bị đánh cắp để chèn các workflow độc hại, ép buộc hệ thống in ra các bí mật (secrets) của repository vào GitHub Actions logs, sau đó tải xuống và xóa dấu vết.
Table Of Content
Phương thức hoạt động của Gheist
Theo phân tích từ công ty bảo mật đám mây Wiz, chiến dịch này đã hoạt động từ giữa tháng 9. Kẻ tấn công sử dụng user agent có tên gheist khi thực hiện các yêu cầu API. Chúng tạo ra các nhánh (branch) mới với định dạng ci-sync-[6 ký tự ngẫu nhiên] và đẩy một file workflow độc hại .github/workflows/sync-check.yml vào repository.
Workflow này được thiết kế để in toàn bộ các biến môi trường và bí mật mà job có quyền truy cập dưới dạng mã hóa base32. Mặc dù GitHub có cơ chế che giấu (masking) các bí mật trong log, nhưng việc mã hóa base32 đã vô hiệu hóa lớp bảo vệ này, khiến các giá trị bí mật bị lộ hoàn toàn.
Tại sao các biện pháp bảo vệ hiện tại chưa đủ?
GitHub hiện có cơ chế tạm dừng các workflow đáng ngờ trên các repository công khai (public). Tuy nhiên, cơ chế này không áp dụng cho các repository riêng tư (private) hoặc môi trường GitHub Enterprise Server, nơi chiến dịch Gheist đang hoành hành mạnh mẽ nhất. Wiz đã ghi nhận hơn 13.500 nhánh độc hại được tạo ra từ hơn 850 tài khoản bị xâm nhập.
Đáng chú ý, kẻ tấn công không cần server trung gian để nhận dữ liệu, vì toàn bộ quá trình trích xuất đều diễn ra thông qua hạ tầng của chính GitHub, khiến việc chặn các kết nối outbound trở nên vô hiệu.
Nguy cơ đối với Self-hosted Runners
Gần đây, Gheist đã cập nhật công cụ để nhắm vào các self-hosted runners. Nếu một repository có sử dụng runner tự quản lý, kẻ tấn công sẽ thực thi các job nhằm tìm kiếm thông tin xác thực, bao gồm private keys, token của Kubernetes, và thông tin đăng nhập AWS. Mặc dù các phiên bản này được đánh giá là còn lỗi, đây vẫn là một dấu hiệu cảnh báo nghiêm trọng về khả năng leo thang đặc quyền.
Khuyến nghị bảo mật cho người dùng
Wiz khuyến cáo các tổ chức thực hiện ngay các bước sau:
- Kiểm tra repository: Tìm kiếm các nhánh có tên
ci-sync-*và filesync-check.yml. - Kiểm tra Audit Logs: Rà soát các hoạt động liên quan đến user agent
gheistvà các workflow bị xóa ngay sau khi chạy. - Xoay vòng bí mật: Nếu phát hiện dấu hiệu bị xâm nhập, cần thực hiện xoay vòng (rotate) toàn bộ các secret, token và thông tin xác thực đám mây liên quan.
- Thu hồi token: Hủy bỏ các token bị lộ và kiểm tra thiết bị của chủ sở hữu token để tìm kiếm dấu vết của malware (infostealer).
- Thắt chặt quyền hạn: Sử dụng GitHub Apps hoặc fine-grained tokens thay vì personal access tokens; giới hạn chính sách OIDC đối với các nhánh hoặc môi trường được bảo vệ.
Nếu một nhánh ci-sync đã chạy trên self-hosted runner, tổ chức cần coi máy chủ đó và các vai trò (role) đám mây liên quan là đã bị thỏa hiệp hoàn toàn.
Nguồn tham khảo: The Hacker News



No Comment! Be the first one.