Software supply chain đang trở thành mục tiêu béo bở của các tác nhân độc hại, và các nền tảng CI/CD đóng vai trò trung tâm trong chuỗi này. Gần đây, chúng ta đã chứng kiến nhiều trường hợp các nhóm tấn công lợi dụng chính các công cụ CI/CD để thực hiện các cuộc tấn công tinh vi. Đặc biệt, GitHub Actions – một nền tảng tự động hóa mạnh mẽ, phổ biến trong cộng đồng mã nguồn mở – cũng không ngoại lệ. Bài viết này sẽ mổ xẻ một kịch bản tấn công thực tế từ cộng đồng open source, nơi kẻ tấn công tiêm mã độc qua Pull Request và quan trọng hơn, chỉ ra cách các tổ chức có thể phòng thủ bằng cách tận dụng OpenID Connect (OIDC) và Secrets Scanner.

I/ Kịch Bản Tấn Công: Inject Mã Độc Qua Pull Request

Hãy cùng xem xét một kịch bản đã từng xảy ra trong thực tế, nơi một dự án mã nguồn mở đã bị tấn công qua GitHub Actions:

1. Mục tiêu: Cộng đồng mã nguồn mở và sự tin cậy: Các dự án mã nguồn mở thường có nhiều người đóng góp từ khắp nơi trên thế giới. Quá trình đóng góp thông thường là thông qua việc tạo một Pull Request (PR), nơi các thay đổi mã được đề xuất để tích hợp vào main branch.

2. Kẻ tấn công tạo PR độc hại: Kẻ tấn công tạo một tài khoản GitHub giả mạo hoặc chiếm đoạt một tài khoản hợp lệ. Sau đó, chúng gửi một PR chứa mã độc. Mã độc này có thể được ngụy trang tinh vi để trông giống như một bản “bug fix”, một tính năng mới không đáng kể, hoặc thậm chí là một thay đổi liên quan đến CI/CD.

3. CI/CD Triggered: Khi PR được tạo, GitHub Actions trong repository sẽ tự động kích hoạt. Thường thì các workflow CI/CD được cấu hình để chạy trên mỗi PR để kiểm tra mã, chạy test, hoặc thậm chí là build và triển khai phiên bản thử nghiệm.

4. Mã độc được thực thi trong môi trường CI/CD: Do mã độc đã được nhúng trong PR và workflow CI/CD được phép chạy mã từ các PR, mã độc của kẻ tấn công sẽ được thực thi trong môi trường GitHub Actions. Môi trường này thường có quyền truy cập vào các secrets (khóa API, token, thông tin xác thực) được lưu trữ trong GitHub để tương tác với các dịch vụ bên ngoài.

5. Exfiltration data và Privilege escalation: Một khi mã độc được thực thi, nó có thể thực hiện nhiều hành vi độc hại:

• Đánh cắp secrets: Mã độc truy cập và đánh cắp các secrets của repository hoặc organization và gửi chúng về máy chủ của kẻ tấn công.

• Tiêm backdoor: Cài đặt backdoor vào các artifact được build (nếu workflow thực hiện build).

• Lợi dụng quyền truy cập: Sử dụng quyền truy cập của runner GitHub Actions để tương tác với các hệ thống khác mà nó được phép.

• Thao túng mã: Chèn mã độc vĩnh viễn vào các phiên bản phần mềm được phát hành.

Kịch bản này cho thấy một lỗ hổng nghiêm trọng: sự tin cậy mù quáng vào mã từ PRs, ngay cả khi đến từ các contribute chưa được xác minh, có thể dẫn đến việc thực thi mã độc trong một môi trường đặc quyền.

II/ Phòng Thủ Hiệu Quả: OIDC và Secrets Scanner

Để chống lại các cuộc tấn công chuỗi CI/CD thông qua GitHub Actions, các tổ chức cần triển khai một chiến lược phòng thủ đa lớp, tập trung vào việc giảm thiểu rủi ro liên quan đến secrets và xác thực.

1. Tận dụng OIDC cho secretless authentication

Một trong những rủi ro lớn nhất trong kịch bản trên là việc GitHub Actions runner truy cập các secrets tĩnh. OpenID Connect (OIDC) cung cấp một giải pháp thay thế an toàn hơn bằng cách cho phép GitHub Actions yêu cầu các token có thời gian tồn tại ngắn (short-lived tokens) trực tiếp từ nhà cung cấp dịch vụ đám mây (ví dụ: AWS, Azure, Google Cloud) hoặc các hệ thống bên ngoài.

Cơ chế hoạt động:

• Thay vì lưu trữ khóa truy cập AWS, Azure hay GCP trong GitHub Secrets, bạn cấu hình một Identity Provider (IdP) trong tài khoản đám mây của mình để tin tưởng GitHub (hoặc URL của GitHub Actions runner).

• Khi một workflow GitHub Actions cần truy cập một dịch vụ đám mây, nó sẽ yêu cầu một OIDC token từ GitHub. Token này chứa các thông tin xác thực về workflow (ví dụ: tên repository, tên workflow, tên job, tên branch).

• Workflow gửi OIDC token này đến dịch vụ đám mây. Dịch vụ đám mây xác minh token với IdP mà nó tin tưởng (GitHub).

• Nếu token hợp lệ, dịch vụ đám mây sẽ cấp quyền truy cập tạm thời cho runner GitHub Actions dựa trên các chính sách đã định nghĩa.

• Lợi ích:

• Giảm thiểu bề mặt tấn công: Không còn secrets tĩnh bị lưu trữ trong GitHub, loại bỏ rủi ro bị đánh cắp nếu repository hoặc môi trường GitHub bị xâm phạm.

• Token có thời gian tồn tại ngắn: Ngay cả khi token bị lộ, nó chỉ có giá trị trong một thời gian rất ngắn (thường là vài phút đến một giờ), làm giảm đáng kể khả năng bị lạm dụng.

• Kiểm soát truy cập hạt mịn (Fine-grained Access Control): Bạn có thể định nghĩa các chính sách chi tiết trên IdP để chỉ cấp quyền truy cập cần thiết cho từng workflow, job, hoặc thậm chí từng branch cụ thể. Ví dụ, chỉ cho phép workflow trên nhánh main triển khai production, còn các PR chỉ được phép build và chạy test.

• Theo dõi và kiểm toán: Việc cấp phát token qua OIDC cho phép theo dõi và kiểm toán tốt hơn các yêu cầu truy cập từ CI/CD.

2. Triển khai Secrets Scanner 

Mặc dù OIDC giúp loại bỏ nhu cầu về secrets tĩnh, việc lộ lọt secrets vẫn có thể xảy ra ở nhiều nơi khác trong vòng đời phát triển phần mềm. Secrets Scanner là công cụ không thể thiếu để phát hiện và ngăn chặn việc này.

Cách thức triển khai và lợi ích:

• Tích hợp vào CI/CD Pipeline: Triển khai secrets scanner như một bước bắt buộc trong mọi workflow CI/CD, chạy trên mỗi commit hoặc PR. Các công cụ như GitGuardian, gitleaks, detect-secrets có thể tự động quét source code và các file cấu hình.

• Quét cả lịch sử Git: Không chỉ quét mã hiện tại, mà còn quét toàn bộ lịch sử Git để phát hiện bất kỳ secrets nào đã từng bị push lên repository, dù sau đó đã bị xóa.

• Quét các loại secrets đa dạng: Các scanner hiệu quả có thể nhận diện nhiều loại secrets khác nhau, từ API keys, database credentials, Private Keys cho đến các token xác thực.

• Phản ứng tự động: Cấu hình tự động chặn các commit hoặc PR nếu phát hiện secrets, hoặc cảnh báo ngay lập tức cho đội ngũ an ninh để có hành động khắc phục.

• Giảm thiểu rủi ro từ sơ suất: Nhiều trường hợp lộ lọt secrets không phải do ý đồ xấu mà do sơ suất của developer. Secrets scanner giúp tự động hóa quá trình kiểm tra, giảm thiểu rủi ro này.

• Tuân thủ quy định: Giúp các tổ chức tuân thủ các quy định về bảo mật dữ liệu và quản lý thông tin nhạy cảm.

III/ Các Biện Pháp Phòng Thủ Bổ Sung

Ngoài OIDC và Secrets Scanner, các biện pháp sau cũng rất quan trọng:

• Giới hạn quyền của GitHub Actions Runner: Đảm bảo rằng GitHub Actions runner chỉ có quyền tối thiểu cần thiết để thực hiện công việc của nó (Least Privilege).

• Kiểm tra và phê duyệt PRs cẩn thận: Đặc biệt là từ các contributor bên ngoài hoặc những người không quen thuộc. Đừng bỏ qua các thay đổi nhỏ, vì chúng có thể chứa payload độc hại.

• Sử dụng Protected Branches: Yêu cầu phê duyệt PR và vượt qua các kiểm tra CI/CD bắt buộc trước khi hợp nhất vào các nhánh quan trọng (main, release).

• Giám sát và ghi log: Giám sát chặt chẽ hoạt động của GitHub Actions và lưu trữ nhật ký chi tiết. Tìm kiếm các hành vi bất thường, như cố gắng truy cập các tài nguyên không liên quan hoặc exfiltrate dữ liệu.

• Học tập và Đào tạo: Nâng cao nhận thức về các rủi ro chuỗi CI/CD cho các nhà phát triển và đội ngũ DevOps.

Các cuộc tấn công chuỗi CI/CD thông qua GitHub Actions là một mối đe dọa thực tế và đang gia tăng. Chúng ta không thể hoàn toàn tin tưởng vào mọi mã được gửi đến, ngay cả trong cộng đồng mã nguồn mở. Bằng cách áp dụng nguyên tắc "không tin cậy ai cả" trong môi trường CI/CD, triển khai OpenID Connect để xác thực không cần secrets, và sử dụng Secrets Scanner một cách nhất quán, các tổ chức có thể xây dựng một lá chắn vững chắc hơn, bảo vệ chuỗi cung ứng phần mềm của mình khỏi các cuộc tấn công tinh vi.