Trong báo cáo mới đây trên WIZ, các nhà nghiên cứu bảo mật đã công bố chuỗi các lỗ hổng bảo mật nghiêm trọng trong Ingress NGINX Controller cho Kubernets, cho phép kẻ tấn công không xác thực có thể truy cập trái phép các dữ liệu nhạy cảm, thực thi mã từ xa (RCE - Remote Code Execution) hoặc chiếm đoạt cụm (cluster) Kubernets bị ảnh hưởng. Ước tính ban đầu có khoảng 43% môi trường đám mây và khoảng 6500 cụm Kubernets chịu tác động lập tức từ lỗ hổng do thông tin về cụm đều được công khai trên internet.

Ingress NGINX Controller cho Kubernetes là gì?

Ingress controller là một thành phần trong Kubernetes dùng để quản lý và điều phối lưu lượng HTTP và HTTPS đến các dịch vụ trong Kubernetes cluster. Nó thực hiện vai trò như một reverse proxy, giúp định tuyến các yêu cầu (requests) từ bên ngoài đến các dịch vụ nội bộ dựa trên các quy tắc (rules) đã được cấu hình trong Ingress resource. Có thể nói, Ingress controller cung cấp một cách tiếp cận dễ dàng và linh hoạt để xử lý các yêu cầu từ bên ngoài vào trong cluster mà không cần phải mở các cổng trực tiếp cho mỗi dịch vụ.

Ingress NGINX Controller là một loại Ingress controller cho Kubernetes, sử dụng NGINX như một reverse proxy và load balancer để điều phối lưu lượng HTTP và HTTPS vào các dịch vụ trong Kubernetes cluster. Nó thực hiện chức năng định tuyến các yêu cầu từ bên ngoài (các client) đến các dịch vụ bên trong Kubernetes thông qua các quy tắc được cấu hình trong Ingress resource. Có khoảng 41% các cụm Kubernetes mở giao tiếp với internet hiện nay đều sử dụng Ingress NGINX.

Hình 1: Sơ đồ đơn giản hoá của Ingress NGINX Controller - Nguồn: WIZ Research

Thông tin lỗ hổng

1. Định danh lỗ hổng: CVE-2025-24514

   • Điểm CVSS (3.1): 8.8

   • Mô tả: Annotation auth-url trong cấu hình Ingress có thể bị kẻ tấn công lợi dụng để chèn một cấu hình tuỳ ý vào NGINX. Điều này có thể dẫn đến việc thực thi mã độc trong quyền của ingress-nginx controller và làm lộ các dữ liệu nhạy cảm mà có thể truy cập được bởi controller.

2. Định danh lỗ hổng: CVE-2025-1097

• Điểm CVSS (3.1): 8.8

• Mô tả: Annotation auth-tls-match-cn trong Ingress có thể bị kẻ tấn công lợi dụng để chèn một cấu hình tuỳ ý vào NGINX. Điều này có thể dẫn đến việc thực thi mã độc trong quyền của ingress-nginx controller và làm lộ các dữ liệu nhạy cảm mà có thể truy cập được bởi controller.

3. Định danh lỗ hổng: CVE-2025-1098

• Điểm CVSS (3.1): 8.8

• Mô tả: Annotation mirror-target và mirror-host trong Ingress có thể bị kẻ tấn công lợi dụng để chèn một cấu hình tuỳ ý vào NGINX. Điều này có thể dẫn đến việc thực thi mã độc trong quyền của ingress-nginx controller và làm lộ các dữ liệu nhạy cảm mà có thể truy cập được bởi controller.

4. Định danh lỗ hổng: CVE-2025-1974

• Điểm CVSS (3.1): 9.8

• Mô tả: Kẻ tấn công không cần xác thực nhưng nếu có quyền truy cập vào mạng pod của cluster Kubernetes, có thể thực thi mã tùy ý trong ingress-nginx controller. Điều này có thể dẫn đến quyền kiểm soát hoàn toàn đối với controller và các dữ liệu nhạy cảm của cluster.

Hình 2: Vec-tơ tấn công - Nguồn: WIZ Research

Ingress NGINX có một thành phần gọi là admission controller chạy trong pod của nó, có nhiệm vụ kiểm tra và xác thực các đối tượng ingress trước khi chúng được triển khai. Tuy nhiên, admission controller này mặc định không yêu cầu xác thực và có thể truy cập qua mạng mà không bị kiểm soát, điều này khiến nó trở thành một mục tiêu hấp dẫn cho kẻ tấn công.

Lỗ hổng bảo mật xảy ra trong quá trình kiểm tra cấu hình NGINX. Khi admission controller nhận một đối tượng ingress, nó sẽ tạo một cấu hình NGINX từ đối tượng đó và tiến hành xác thực cấu hình bằng cách sử dụng NGINX binary. Tuy nhiên, nếu kẻ tấn công gửi một đối tượng ingress độc hại qua mạng đến admission controller, nó có thể cho phép chèn các cấu hình NGINX tùy ý vào quá trình này. Khi cấu hình NGINX độc hại được chèn vào, quá trình xác thực cấu hình sẽ thực thi mã, dẫn đến thực thi mã từ xa trên pod của Ingress NGINX Controller.

Hệ quả của nó cho phép kẻ tấn công thực thi mã từ xa trên pod của Ingress NGINX Controller, vì admission controller có quyền cao và không bị giới hạn về quyền truy cập mạng. Điều này mở ra một con đường tấn công nghiêm trọng, cho phép kẻ tấn công chiếm quyền kiểm soát toàn bộ cluster, có thể truy cập và chiếm đoạt tất cả các dữ liệu nhạy cảm trong cluster, bao gồm các tài nguyên và thông tin bí mật trong các namespaces.

Mặt khác, các ứng dụng chạy trên container (Containerization) không thực sự đảm bảo tính an toàn tuyệt đối. Nhiều ứng dụng chạy trên Kubernetes (K8s) có thể dễ dàng bị tấn công bằng kỹ thuật container escape (thoát khỏi container) khiến cho việc xâm nhập vào mạng pod của một cluster trở lên dễ dàng hơn rất nhiều. Nguy hiểm hơn, kẻ tấn công thường kết hợp khai thác các lỗ hổng này với các lỗ hổng SSRF (Server-Side Request Forgery) - vốn khá phổ biến trong các ứng dụng web, nhằm làm tăng khả năng tấn công vào cluster.

Khai thác lỗ hổng

Thông qua các kịch bản tấn công được xây dựng, các chuyên gia bảo mật thuộc WIZ đã đưa ra tổng quan các bước khai thác chuỗi lỗ hổng trên như sau:

1. Kẻ tấn công tải lên các payload dưới dạng thư viện chia sẻ (shared library) vào pod bằng cách khai thác tính năng client-body buffer của NGINX.

2. Gửi các yêu cầu AdmissioinReview đến admission controller của Ingress NGINX Controller. Các yêu cầu độc hại này có chứa các phần chỉ thị (directive) được tuỳ chỉnh và tiêm vào.

3. Phần chỉ thị được tiêm vào yêu cầu NGINX thực thi các payload độc hại được tải lên dưới dạng thư viện chia sẻ ở trên, được đặt tên là ssl_engine.

4. Kẻ tấn công chỉ định đường dẫn của ProFS, đây là một hệ thống tệp ảo trong linux cung cấp thông tin về các tiến trình đang chạy. Kẻ tấn công chỉ định đường dẫn của ProcFS đến file descriptor của payload để chỉ ra vị trí của payload được tải lên.

5. Hoàn tất quá trình trên cho phép kẻ tấn công thực thi mã từ xa thông qua thư viện chia sẻ và mã độc được tải lên.

Hình 3: Kịch bản tấn công giả định - Nguồn: WIZ Research

Khuyến nghị & khắc phục

Cũng trong báo cáo của mình, các chuyên gia bảo mật thuộc WIZ đã đưa ra một số khuyến nghị và phương pháp khắc phục tới người dùng. Người dùng nên thực hiện kiểm tra các cụm Kubernetes của mình hiện có đang sử dụng ingress-nginx hay không thông qua câu lệnh:

kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx

Đối với các hệ thống có thể nâng cấp ngay lập tức

• Tiến hành nâng cấp lên phiên bản 1.12.1, 1.11.5 và 1.10.7 mới nhất của Ingress NGINX Controller.

• Đảm bảo điểm cuối của admission webhook không thể truy cập được từ bên ngoài mạng. Có thể sử dụng các mẫu kiểm tra của Nuclei để quét và phát hiện admission controller của Ingress-NGINX bị lộ ra ngoài.

Đối với các hệ thống chưa thể nâng cấp ngay lập tức

• Thực thi các chính sách mạng nghiêm ngặt: Chỉ để máy chủ API Kubernetes mới có thể truy cập vào admission controller.

• Vô hiệu hoá tạm thời: vô hiệu hoá admission controller của Ingress NGINX nếu như chưa thể thực hiện nâng cấp hệ thống ngay lập tức.

  • Nếu ingress-nginx được cài đặt bằng Helm, có thể cài đặt lại với tham số controller.admissionWebhooks.enabled=false.

  • Nếu ingress-nginx được cài đặt thủ công, có thể xoá các thành phần như ValidatingWebhookConfiguration, ingress-nginx-admission, --validating-webhook, ingress-nginx-controller.

  • Bật Validating Admission controller để bảo vệ cấu hình Ingress.

Tham khảo

1. WIZ Research blog