Lộ dữ liệu Kubernetes Secret qua ServerSideDiff trong argoproj Argo CD

Argo CD là một công cụ phân phối liên tục theo mô hình khai báo và GitOps dành cho Kubernetes. Từ phiên bản 3.2.0 đến trước 3.2.11 và từ 3.3.0 đến trước 3.3.9, endpoint ServerSideDiff của Argo CD có thiếu sót trong authorization và data masking, cho phép kẻ tấn công chỉ có quyền read-only trích xuất dữ liệu Kubernetes Secret ở dạng plaintext từ etcd thông qua cơ chế Server-Side Apply dry-run của Kubernetes API server. Vấn đề này đã được vá trong các phiên bản 3.2.11 và 3.3.9.

Các phạm vi bị ảnh hưởng được CNA và vendor advisory xác nhận:

• argo-cd từ 3.2.0 đến trước 3.2.11.
• argo-cd từ 3.3.0 đến trước 3.3.9.
• Bản vá upstream được xác nhận tại 3.2.11 cho nhánh thứ nhất và 3.3.9 cho nhánh thứ hai. Không nên suy luận trạng thái của các nhánh song song hoặc bản dựng downstream chỉ từ hai mốc này.
• Red Hat xác nhận các image thuộc Red Hat OpenShift GitOps 1.19 và 1.20 trong dữ liệu CSAF của vendor ở trạng thái fixed. Red Hat cũng phát hành bản cập nhật Red Hat OpenShift GitOps 1.20.3 có nêu bản sửa cho lỗi này. Với image downstream, cần đối chiếu đúng erratum và image được vendor cung cấp thay vì chỉ so sánh số phiên bản upstream.

Lỗi nằm trong endpoint gRPC/REST ServerSideDiff của Argo CD. Không giống các endpoint khác sử dụng hideSecretData() để che dữ liệu Secret, endpoint này trả về trực tiếp các trạng thái PredictedLive và NormalizedLive chưa được masking.

Luồng xử lý gọi K8sServerSideDryRunner.Run(), tương đương với thao tác Server-Side Apply dry-run trên Kubernetes API server. Cơ chế removeWebhookMutation() thông thường loại bỏ các trường không do Argo CD quản lý khỏi kết quả dry-run và hợp nhất chúng với trạng thái live đã được che dữ liệu. Tuy nhiên, cơ chế bảo vệ này bị bỏ qua khi Application có annotation argocd.argoproj.io/compare-options: IncludeMutationWebhook=true.

Khi đó, phản hồi dry-run có thể chứa giá trị Secret thực được đọc từ etcd và được chuyển thẳng vào phản hồi API mà không masking. Việc trích xuất thành công còn phụ thuộc vào việc các trường dữ liệu của Secret được một SSA field manager khác ngoài argocd-controller sở hữu; nếu argocd-controller là field manager duy nhất, dữ liệu bị loại khỏi kết quả dry-run khi manifest đích không chứa các trường đó. Chính sách RBAC cụ thể của từng môi trường và phạm vi Secret thực tế có thể khác nhau.

Lỗ hổng có thể bị khai thác qua giao diện mạng của endpoint ServerSideDiff bằng gRPC hoặc REST. Kẻ tấn công cần tài khoản Argo CD đã xác thực với quyền read-only đủ để gọi chức năng này; advisory của vendor nêu rằng quyền get trên Application là đủ và cấu hình mặc định có thể cấp quyền này cho mọi người dùng đã xác thực thông qua policy role:catch-all.

Không cần người dùng khác tương tác trong quá trình khai thác, và điều kiện được mô tả là có độ phức tạp thấp. Với Application đã bật IncludeMutationWebhook=true, quyền read-only có thể đủ để lấy giá trị Secret nếu các điều kiện về ownership của SSA field manager cũng thỏa mãn.

Vendor advisory có kèm một public proof of concept. Record được cung cấp đánh dấu public exploit là có, nhưng không nêu một chiến dịch, nạn nhân hoặc báo cáo quan sát được về việc khai thác trong thực tế.

Kết quả kỹ thuật được xác nhận là giá trị Kubernetes Secret có thể xuất hiện ở dạng plaintext trong phản hồi ServerSideDiff. Điều này ảnh hưởng trực tiếp đến tính bí mật của dữ liệu được lưu trong Kubernetes và có thể bao gồm credential dùng cho cluster, workload hoặc dịch vụ bên ngoài.

Phạm vi ảnh hưởng vượt ra ngoài quyền đọc trạng thái Application của Argo CD, vì một principal read-only có thể nhận dữ liệu Secret mà endpoint đáng lẽ phải masking. Nếu credential bị lộ vẫn hợp lệ, bên thứ ba có thể sử dụng chúng để thực hiện các hành động ngoài Argo CD theo quyền của từng credential; đây là hậu quả có thể xảy ra, không phải quyền ghi trực tiếp đã được chứng minh của endpoint.

Lỗ hổng này không được mô tả là gây mất khả dụng trực tiếp. Tác động thực tế phụ thuộc vào các Application có annotation liên quan, ownership của trường Secret trong Server-Side Apply và quyền của từng Secret.

Lỗ hổng có thể làm lộ các giá trị Secret thực, bao gồm service account token, TLS certificate, thông tin xác thực cơ sở dữ liệu và API key.

Việc rò rỉ các giá trị này có thể mở rộng quyền truy cập sang Kubernetes cluster hoặc các dịch vụ bên ngoài nếu credential vẫn còn hợp lệ và có quyền tương ứng. Đây là một đường dẫn từ quyền đọc trong Argo CD sang dữ liệu nhạy cảm mà người dùng đó không nhất thiết được phép xem.

Vấn đề được mô tả trực tiếp là disclosure dữ liệu. Việc gây thay đổi hệ thống hoặc gián đoạn dịch vụ không phải là kết quả trực tiếp được advisory xác nhận, dù credential bị lộ có thể tạo ra rủi ro downstream tùy quyền của từng Secret.

1. Nâng cấp Argo CD lên 3.2.11 đối với nhánh 3.2.x, hoặc lên 3.3.9 đối với nhánh 3.3.x. Đây là biện pháp khắc phục chính đã được vendor xác nhận.
2. Nếu sử dụng Red Hat OpenShift GitOps, áp dụng erratum hoặc image đã được Red Hat đánh dấu fixed cho phiên bản triển khai tương ứng. Đối với nhánh Red Hat OpenShift GitOps 1.20, bản cập nhật 1.20.3 được Red Hat mô tả là có bản sửa cho lỗi này. Không tự suy luận rằng một image downstream khác đã được sửa nếu chưa kiểm tra thông báo và image cụ thể của vendor.
3. Trong thời gian chờ nâng cấp, rà soát và nếu phù hợp thì loại bỏ annotation argocd.argoproj.io/compare-options: IncludeMutationWebhook=true để khôi phục lớp bảo vệ masking trong các Application không cần hành vi này. Đây chỉ là biện pháp giảm rủi ro tạm thời, không thay thế bản vá.
4. Rà soát việc cấp quyền get trên Application và giảm quyền của các principal không cần gọi ServerSideDiff. Biện pháp này có thể hạn chế phạm vi tiếp cận, nhưng không nên được xem là bản vá hoàn chỉnh.
5. Nếu không thể loại trừ khả năng Secret đã bị đọc qua endpoint này, xử lý các giá trị liên quan như có nguy cơ đã bị lộ và xoay vòng token, certificate, password hoặc API key theo quy trình ứng phó sự cố của tổ chức. Ưu tiên các Secret có field manager khác ngoài argocd-controller và các credential có quyền truy cập rộng.

1. Kiểm kê tất cả Argo CD instance và xác định instance nào đang chạy các nhánh bị ảnh hưởng được nêu trong affected_summary.
2. Kiểm tra cấu hình Application để tìm annotation argocd.argoproj.io/compare-options: IncludeMutationWebhook=true. Đây là điều kiện quan trọng vì nó làm bỏ qua lớp bảo vệ removeWebhookMutation().
3. Rà soát RBAC để xác định các principal có quyền get trên Application hoặc có thể gọi ServerSideDiff, đặc biệt các principal được cấp quyền qua role:catch-all.
4. Đối với Secret có giá trị nhạy cảm, kiểm tra managedFields để xác định các trường dữ liệu được sở hữu bởi SSA field manager khác ngoài argocd-controller. Điều này giúp ưu tiên các Secret có khả năng xuất hiện trong kết quả dry-run.
5. Nếu có request logging, rà soát các yêu cầu tới ServerSideDiff như một biện pháp điều tra thận trọng. Advisory không định nghĩa một IOC hoặc mẫu log duy nhất, và không nên xem việc không thấy log là bằng chứng hệ thống an toàn.