Chèn cấu hình qua rewrite-target dẫn đến thực thi mã trong Kubernetes ingress-nginx

Một vấn đề bảo mật được phát hiện trong ingress-nginx, trong đó annotation Ingress nginx.ingress.kubernetes.io/rewrite-target có thể được dùng để chèn cấu hình vào nginx. Điều này có thể dẫn đến thực thi mã tùy ý trong context của ingress-nginx controller và tiết lộ các Secrets mà controller có thể truy cập. (Lưu ý rằng trong cài đặt mặc định, controller có thể truy cập mọi Secrets trên toàn cluster.)

Kubernetes ingress-nginx được đánh dấu affected theo mặc định trong các ranh giới semver sau:

• Các phiên bản nhỏ hơn 1.13.8.
• Các phiên bản nhỏ hơn 1.14.4.
• Các phiên bản nhỏ hơn 1.15.0.

Các ranh giới này đại diện cho các nhánh phát hành song song được advisory nêu. Trạng thái của một nhánh hoặc bản dựng khác không được liệt kê ở trên không nên được suy ra chỉ từ các ranh giới này.

Lỗi nằm trong cách ingress-nginx xử lý annotation nginx.ingress.kubernetes.io/rewrite-target trên tài nguyên Ingress. Giá trị do người dùng kiểm soát có thể được đưa vào cấu hình nginx mà không được kiểm tra đầy đủ, tạo ra lỗi improper input validation và cho phép chèn cấu hình vào nginx. Kẻ tấn công cần quyền tạo hoặc sửa Ingress trong một cluster đang chạy ingress-nginx; khi controller xử lý tài nguyên đó, mã tùy ý có thể được thực thi trong context của ingress-nginx controller. Kết quả cũng có thể bao gồm việc đọc các Secrets mà controller được phép truy cập, và trong cài đặt mặc định quyền này có thể bao phủ toàn bộ Secrets trong cluster. Advisory nêu rằng dữ liệu đáng ngờ trong trường rules.http.paths.path có thể là dấu hiệu của một nỗ lực khai thác. Chi tiết chính xác về parser hoặc hàm nội bộ chịu trách nhiệm cho việc tạo cấu hình không được xác nhận trong advisory.

Đánh giá được cung cấp mô tả đây là đường tấn công qua network, yêu cầu mức quyền thấp, độ phức tạp thấp và không cần tương tác của người dùng cuối. Maintainer giải thích rằng điều kiện thực tế liên quan là tài khoản có quyền tạo Ingress, trong khi mức độ leo thang quyền phụ thuộc vào cấu hình cluster. Bản ghi đánh dấu rằng exploit công khai đã tồn tại, và một public training lab có các thành phần phục vụ việc khai thác được công bố. Điều này xác nhận khả năng tiếp cận exploit material công khai, không chứng minh rằng hệ thống cụ thể nào đã bị khai thác. Trường known_exploited và ransomware_campaign không có giá trị xác nhận; sự thiếu vắng này không phải bằng chứng rằng chưa từng có khai thác.

Lỗi có thể cho phép thực thi mã tùy ý trong context của ingress-nginx controller và đọc các Secrets mà controller được cấp quyền truy cập. Về quyền hạn, tác động có thể bắt đầu từ một principal chỉ có quyền tạo hoặc sửa Ingress rồi mở rộng tới controller và các tài nguyên nằm trong phạm vi quyền của controller. Maintainer cảnh báo rằng kết quả có thể gần với quyền cluster-admin tùy cấu hình cluster, nhưng quyền này không được bảo đảm trong mọi triển khai. Tính toàn vẹn của cấu hình ingress, tính bí mật của Secrets và có khả năng tính sẵn sàng của dịch vụ đều có thể bị ảnh hưởng. Advisory không xác định một blast radius cố định ngoài phạm vi quyền thực tế của controller.

Bảo mật dữ liệu: Secrets mà ingress-nginx controller được phép đọc có thể bị tiết lộ; trong cài đặt mặc định, phạm vi quyền được mô tả là toàn cluster.

Toàn vẹn và quyền kiểm soát: Thực thi mã trong context của controller có thể cho phép thay đổi hành vi của thành phần ingress và các tài nguyên mà context đó truy cập được.

Vận hành: Việc chiếm quyền controller có thể ảnh hưởng đến routing hoặc tính sẵn sàng của dịch vụ ingress, nhưng advisory không mô tả một kịch bản gián đoạn cụ thể.

Phạm vi: Mức độ ảnh hưởng thực tế phụ thuộc vào RBAC và cấu hình quyền của controller; không phải mọi cluster đều có cùng phạm vi truy cập Secrets.

1. Nâng cấp ingress-nginx lên bản sửa lỗi tương ứng với nhánh đang triển khai: 1.13.8, 1.14.4 hoặc 1.15.0.
2. Nếu chưa thể nâng cấp ngay, dùng admission control để chặn việc sử dụng annotation nginx.ingress.kubernetes.io/rewrite-target, theo biện pháp giảm thiểu được advisory công bố.
3. Kiểm kê tất cả cluster, controller deployment và Ingress resource để bảo đảm không còn bản affected hoặc tài nguyên có dữ liệu đáng ngờ trong quá trình chuyển đổi.
4. Nếu phát hiện dấu hiệu khai thác, coi các Secrets nằm trong phạm vi truy cập của controller là có nguy cơ bị lộ, kích hoạt quy trình incident response và liên hệ nhóm bảo mật Kubernetes theo hướng dẫn của advisory.

1. Kiểm tra cluster có chạy ingress-nginx hay không bằng selector được advisory nêu: kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx.
2. Kiểm kê image hoặc release thực tế của ingress-nginx controller trên từng cluster và đối chiếu với các ranh giới affected trong advisory.
3. Rà soát các Ingress có annotation nginx.ingress.kubernetes.io/rewrite-target, đặc biệt các tài nguyên chứa dữ liệu bất thường trong rules.http.paths.path.
4. Kiểm tra Kubernetes audit logs để xác định principal nào đã tạo hoặc sửa các Ingress liên quan. Đây là bước điều tra theo điều kiện khai thác đã công bố, không phải một IOC riêng biệt.
5. Có thể dùng controller logs và audit telemetry để tìm các thay đổi đáng ngờ như biện pháp phòng ngừa. Không được coi việc không thấy log đáng ngờ là bằng chứng hệ thống an toàn.