Mối đe dọa tấn công chuỗi cung ứng CodeQL – sự cố bảo mật bắt nguồn từ GitHub secret bị lộ công khai

 (praetorian.com)
1 điểm bởi GN⁺ 2025-04-01 | 1 bình luận | Chia sẻ qua WhatsApp
  • Do GitHub secret bị lộ công khai, CodeQL — công cụ phân tích tĩnh của GitHub — đã bị đặt vào nguy cơ tấn công chuỗi cung ứng
  • Khóa liên quan có hiệu lực trong 1.022 giây, và trong khoảng thời gian đó, kẻ tấn công có thể thực thi mã tùy ý trong workflow GitHub Actions
  • Lỗ hổng này đã được đăng ký thành CVE công khai: CVE-2025-24362

Các kịch bản thiệt hại chính

Thông qua lỗ hổng này, kẻ tấn công có thể thực hiện các cuộc tấn công sau:

  • Rò rỉ mã nguồn của các repository sử dụng CodeQL (xâm phạm sở hữu trí tuệ)
  • Đánh cắp secret của GitHub Actions và mở đường cho các đợt tấn công tiếp theo
  • Thực thi mã trong hạ tầng nội bộ thông qua workflow CodeQL
  • Thậm chí có thể đánh cắp secret của các workflow sử dụng GitHub Actions Cache

Phát hiện tấn công và quá trình thử nghiệm

  • Nhóm nghiên cứu Praetorian đã phát triển một công cụ quét secret nằm trong workflow artifact được tạo bởi GitHub Actions
  • Phát hiện debug artifact chứa secret trong repository liên quan đến CodeQL
  • Tạo và chạy công cụ PoC artifact_racer.py để chứng minh rằng trong lúc khóa còn hiệu lực, kẻ tấn công có thể tạo branch/tag và push file

Kết quả thử nghiệm cốt lõi

  • Với token đó, kẻ tấn công có thể:
    • Tạo branch mới
    • Push file
    • Thêm tag
  • Theo mặc định, CodeQL tham chiếu tag v3, và kẻ tấn công có thể ghi đè tag này → có thể phân phối mã độc tới mọi người dùng CodeQL

Khả năng lan rộng: vì sao điều này nguy hiểm?

  • Phần lớn người dùng không tự cấu hình CodeQL thủ công mà chỉ nhấn nút "Enable CodeQL" trong phần cài đặt repository GitHub
  • Workflow được tự động cấu hình khi đó sẽ tham chiếu repository github/codeql-action, dựa trên tag v3
  • Nếu kẻ tấn công ghi đè tag v3 bằng một commit độc hại, mã độc sẽ tự động được thực thi trên vô số dự án

Khả năng tấn công bổ sung: cache poisoning

  • Workflow CodeQL mặc định sử dụng GitHub Actions Cache
  • Từ đó, kẻ tấn công có thể chèn cache độc hại vào pipeline build, rồi tiếp tục đánh cắp secret và truy cập nội bộ trong các workflow chạy sau
  • Một số mục tiêu tiêu biểu:

Phản ứng và bản vá từ GitHub

  • Sau khi nhận báo cáo lỗ hổng vào ngày 22 tháng 1 năm 2025, GitHub đã trong vòng 3 giờ:
    • Dừng workflow dễ bị tấn công
    • Tạo PR để ngăn upload secret
    • Phát hành bản vá: CodeQL Action v3.28.3
  • Thông báo bảo mật chính thức: GHSA-vqf5-2xx6-9wfm

Biện pháp ứng phó

  • Khi upload artifact trong workflow, cần giới hạn rõ các file được phép upload
  • Cẩn trọng để không bao gồm biến môi trường, .git/config hoặc các file trong thư mục _temp/
  • GITHUB_TOKEN chỉ nên được cấp quyền chỉ đọc
  • Khuyến nghị quét secret trước khi upload (dùng các công cụ như Nosey Parker)

Kết luận

  • Ngay cả với cấu hình mặc định của CodeQL, rất nhiều dự án cũng có thể bị phơi bày trước tấn công chuỗi cung ứng
  • Lỗ hổng bảo mật trong GitHub Actions vẫn là mối đe dọa nghiêm trọng, và cộng đồng cần tiếp tục quan tâm cũng như xây dựng chiến lược phòng vệ

Thông tin liên quan

Bài viết liên quan

1 bình luận

 
GN⁺ 2025-04-01
Ý kiến trên Hacker News
  • Có ý kiến cho rằng khi GitHub phát hành immutable actions, hơn 70% các cuộc tấn công có thể sẽ được giải quyết
    • Nghĩ rằng các sự cố hằng tuần của GitHub sẽ buộc họ phát hành tính năng này
  • Không thấy đề cập vì sao token tạm thời lại có quyền tạo bản triển khai mới và tạo chứng thực artifact
    • Dù đã tắt log debug để khắc phục vấn đề, vẫn chưa có câu trả lời liệu quyền của token tạm thời đã được điều chỉnh cho phù hợp hơn với engine phân tích mã hay chưa
  • Ngày càng tin chắc rằng CI và CD phải là các môi trường tách biệt hoàn toàn
    • Việc CI bị xâm phạm không nên dẫn đến rò rỉ token liên quan đến CD
  • Thời gian phản ứng của GitHub rất ấn tượng
  • Có ý kiến rằng, với tư cách là một người mang họ Prater, họ muốn sở hữu praetorian.com
  • Việc sử dụng GitHub Actions công khai có thể gây ra vấn đề, và dùng chúng mà không phân tích quy trình workflow thì còn rủi ro hơn
    • Thay vào đó, khuyến nghị dùng woodpecker hoặc một trình xây dựng CI tốt khác (circle, travis, gitlab, v.v.) và tự host
  • Có đề cập rằng họ đang dùng CodeQL cho PR của OpenZFS và OpenZFS không gặp vấn đề gì
    • Mã của OpenZFS không phải là bí mật
  • Có ý kiến thắc mắc liệu vấn đề đã được giải quyết hay chưa
  • Có phàn nàn rằng hiệu năng của trang quá kém, đến mức gần như không thể cuộn được