Một lỗi cấu hình nghiêm trọng trong Amazon Web Services (AWS) CodeBuild có thể đã cho phép chiếm đoạt hoàn toàn các kho lưu trữ GitHub của nhà cung cấp dịch vụ đám mây, bao gồm cả AWS JavaScript SDK, đe dọa mọi môi trường AWS.
Lỗ hổng này được đặt tên là CodeBreach bởi công ty bảo mật đám mây Wiz. AWS đã khắc phục sự cố vào tháng 9 năm 2025 sau khi được tiết lộ một cách có trách nhiệm vào ngày 25 tháng 8 năm 2025.
"Bằng cách khai thác CodeBreach, những kẻ tấn công có thể đã tiêm mã độc để thực hiện một cuộc tấn công trên toàn nền tảng, có khả năng ảnh hưởng không chỉ vô số ứng dụng phụ thuộc vào SDK, mà còn cả Console, đe dọa mọi tài khoản AWS," các nhà nghiên cứu Yuval Avrahami và Nir Ohfeld cho biết trong một báo cáo được chia sẻ với The Hacker News.
Wiz lưu ý, lỗ hổng này là kết quả của một điểm yếu trong các quy trình CI có thể cho phép những kẻ tấn công chưa được xác thực xâm nhập môi trường build, làm lộ các thông tin xác thực đặc quyền như GitHub admin tokens, và sau đó sử dụng chúng để đẩy các thay đổi độc hại vào kho lưu trữ bị xâm phạm – tạo ra con đường cho các cuộc tấn công chuỗi cung ứng.
Nói cách khác, vấn đề này làm suy yếu webhook filters được AWS giới thiệu để đảm bảo rằng chỉ một số sự kiện nhất định mới kích hoạt một build CI. Ví dụ, AWS CodeBuild có thể được cấu hình để một build chỉ được kích hoạt khi mã thay đổi được commit vào một branch cụ thể hoặc khi một GitHub hoặc GitHub Enterprise Server account ID (hay ACTOR_ID hoặc actor ID) khớp với mẫu regular expression. Các bộ lọc này nhằm bảo mật chống lại các pull request không đáng tin cậy.
Lỗi cấu hình đã ảnh hưởng đến các kho lưu trữ GitHub mã nguồn mở do AWS quản lý sau đây, được cấu hình để chạy các build trên pull request -
- aws-sdk-js-v3
- aws-lc
- amazon-corretto-crypto-provider
- awslabs/open-data-registry
Bốn dự án đã triển khai bộ lọc ACTOR_ID này mắc phải một "lỗi nghiêm trọng" là chúng không bao gồm hai ký tự để đảm bảo – cụ thể là dấu neo bắt đầu ^ và dấu neo kết thúc $ – cần thiết để tạo ra một kết quả khớp regular expression (regex) chính xác. Thay vào đó, mẫu regex cho phép bất kỳ GitHub user ID nào là một superstring của một ID đã được phê duyệt (ví dụ: 755743) để bỏ qua bộ lọc và kích hoạt build.
Vì GitHub gán các user ID số theo thứ tự, Wiz cho biết họ có thể dự đoán rằng các user ID mới (hiện dài 9 chữ số) sẽ "vượt qua" ID sáu chữ số của một người duy trì đáng tin cậy khoảng năm ngày một lần. Thông tin này, cùng với việc sử dụng GitHub Apps để tự động tạo ứng dụng (mà đến lượt nó lại tạo một người dùng bot tương ứng), đã giúp tạo ra một ID mục tiêu (ví dụ: 226755743) bằng cách kích hoạt hàng trăm lượt đăng ký người dùng bot mới.
Với ACTOR_ID, kẻ tấn công giờ đây có thể kích hoạt một build và lấy được các thông tin xác thực GitHub của dự án aws-sdk-js-v3 CodeBuild, một Personal Access Token (PAT) thuộc về người dùng aws-sdk-js-automation, người có toàn quyền quản trị đối với kho lưu trữ.
Kẻ tấn công có thể vũ khí hóa quyền truy cập nâng cao này để đẩy mã trực tiếp lên branch chính, phê duyệt pull request và đánh cắp các repository secrets, cuối cùng tạo tiền đề cho các cuộc tấn công chuỗi cung ứng.
"Các regular expression được cấu hình cho các bộ lọc webhook của AWS CodeBuild trên các kho lưu trữ nói trên, nhằm giới hạn các ACTOR_ID đáng tin cậy, đã không đủ mạnh, cho phép một ACTOR_ID có thể dự đoán được để có được quyền quản trị đối với các kho lưu trữ bị ảnh hưởng," AWS cho biết trong một thông báo được phát hành hôm nay.
"Chúng tôi có thể xác nhận đây là các lỗi cấu hình cụ thể của dự án trong các bộ lọc ACTOR_ID webhook cho các kho lưu trữ này chứ không phải là một vấn đề trong bản thân dịch vụ CodeBuild."
Amazon cũng cho biết họ đã khắc phục các vấn đề được xác định, cùng với việc triển khai các biện pháp giảm thiểu bổ sung, chẳng hạn như xoay vòng thông tin xác thực và các bước để bảo mật các quy trình build chứa GitHub tokens hoặc bất kỳ thông tin xác thực nào khác trong bộ nhớ. Hãng cũng nhấn mạnh rằng họ không tìm thấy bằng chứng nào về việc CodeBreach đã bị khai thác trong thực tế.
Để giảm thiểu những rủi ro như vậy, điều cần thiết là các đóng góp không đáng tin cậy không được kích hoạt các CI/CD pipelines đặc quyền bằng cách kích hoạt tính năng mới Pull Request Comment Approval build gate, sử dụng CodeBuild-hosted runners để quản lý các build trigger thông qua GitHub workflows, đảm bảo các mẫu regex trong các bộ lọc webhook được neo, tạo một PAT duy nhất cho mỗi dự án CodeBuild, giới hạn quyền của PAT ở mức tối thiểu cần thiết và xem xét sử dụng một tài khoản GitHub không đặc quyền dành riêng cho tích hợp CodeBuild.
"Lỗ hổng này là một ví dụ điển hình về lý do tại sao những kẻ tấn công nhắm mục tiêu vào các môi trường CI/CD: một lỗ hổng tinh vi, dễ bị bỏ qua có thể bị khai thác để gây ra tác động lớn," các nhà nghiên cứu Wiz lưu ý. "Sự kết hợp giữa độ phức tạp, dữ liệu không đáng tin cậy và thông tin xác thực đặc quyền này tạo ra một cơn bão hoàn hảo cho các vụ vi phạm tác động cao mà không yêu cầu quyền truy cập trước đó."
Đây không phải là lần đầu tiên bảo mật CI/CD pipeline bị xem xét kỹ lưỡng. Năm ngoái, nghiên cứu từ Sysdig chi tiết cách các GitHub Actions workflows không an toàn liên quan đến pull_request_target trigger có thể bị khai thác để làm lộ GITHUB_TOKEN đặc quyền và giành quyền truy cập trái phép vào hàng chục dự án mã nguồn mở bằng cách sử dụng một single pull request từ một fork.
Một hai phần tương tự từ Orca Security đã tìm thấy các pull_request_target không an toàn trong các dự án từ Google, Microsoft, NVIDIA và các công ty Fortune-500 khác có thể cho phép kẻ tấn công chạy mã tùy ý, đánh cắp các secrets nhạy cảm và đẩy mã hoặc các dependencies độc hại vào các branch đáng tin cậy. Hiện tượng này đã được đặt tên là pull_request_nightmare.
"Bằng cách lạm dụng các workflow bị cấu hình sai được kích hoạt thông qua pull_request_target, những kẻ tấn công có thể leo thang từ một pull request được fork không đáng tin cậy thành remote code execution (RCE) trên các GitHub-hosted hoặc thậm chí là self-hosted runners," nhà nghiên cứu bảo mật Roi Nisimi lưu ý.
"Các GitHub Actions workflows sử dụng pull_request_target không bao giờ nên checkout mã không đáng tin cậy mà không có xác thực phù hợp. Một khi chúng làm vậy, chúng sẽ có nguy cơ bị xâm phạm hoàn toàn."
