IngressNightmare: Lỗ hổng CVE-2025-1974 thực thi mã từ xa & cách khắc phục

Tháng 5 năm 2025 đánh dấu sự tiết lộ công khai về lỗ hổng bảo mật nghiêm trọng, CVE-2025-1974, được gọi là IngressNightmare, ảnh hưởng đến bộ điều khiển Kubernetes ingress-nginx được triển khai rộng rãi trên các cơ sở hạ tầng đám mây gốc. Lỗ hổng này cho phép những kẻ tấn công chưa xác thực đưa các cấu hình tùy ý vào NGINX, có khả năng dẫn đến RCE (thực thi mã từ xa) trái phép và xâm phạm toàn bộ cụm.

Là một phần của OPSWAT Chương trình học bổng, các thành viên của chúng tôi đã tiến hành phân tích kỹ thuật chuyên sâu để hiểu rõ hơn nguyên nhân gốc rễ, con đường khai thác và các chiến lược giảm thiểu liên quan đến vấn đề nghiêm trọng này.

1. Mỗi cấu hình được phân tích cú pháp và chuyển đến generateTemplate để định dạng theo các mẫu NGINX được xác định trước.
2. Sau đó, testTemplate xác thực cấu hình đã tạo so với tệp nhị phân NGINX cơ bản.

Tất cả cấu hình NGINX đều dựa trên các mẫu được xác định trước có trong tệp nginx.tmpl trong mã nguồn ingress-nginx:

Trong hàm generateTemplate , cấu hình được xử lý như trong đoạn mã sau:

Tuy nhiên, xác thực và vệ sinh đầu vào là không đủ. Cụ thể, trường uid từ Đối tượng Ingress được chèn trực tiếp vào mẫu cấu hình NGINX, tạo ra điểm tiêm. Kẻ tấn công có thể khai thác điều này bằng cách cung cấp đầu vào được tạo thủ công như uid="1234#;\n\n}\n}\n}\n injection_value" .

Đầu vào độc hại này cho phép đưa phạm vi toàn cục vào mẫu NGINX, cho phép kẻ tấn công kích hoạt các lệnh NGINX tùy ý và có khả năng đạt được RCE.

Để khai thác lỗ hổng, kẻ tấn công cần xác định một chỉ thị có khả năng thực thi mã độc hại. Ban đầu, các cộng sự của chúng tôi xác định chỉ thị load_module có khả năng hữu ích, vì chỉ thị này cho phép NGINX tải các plugin bên ngoài. Tuy nhiên, chỉ thị này chỉ được phép trong giai đoạn đầu của quá trình phân tích cấu hình, không khớp với điểm tiêm của chúng tôi.

Để giải quyết thách thức này, chúng tôi đã tiếp tục nghiên cứu sâu hơn, dẫn đến chỉ thị ssl_engine , được mô tả là "Mô-đun có thể được OpenSSL tải động trong quá trình thử nghiệm cấu hình". Điều này gây tò mò vì khả năng tải động các mô-đun, đòi hỏi phải kiểm tra sâu hơn.

Khi khởi động, NGINX tải trạng thái ban đầu của nó, sau đó phân tích từng dòng tệp cấu hình. Mỗi chỉ thị được xử lý bởi cấu trúc nginx_command_t , với chỉ thị ssl_engine trực tiếp gọi ngx_openssl_commands .

Sau khi phân tích hàm ngx_openssl_commands , các cộng sự của chúng tôi phát hiện ra rằng hàm này dựa vào hỗ trợ OpenSSL, cụ thể là hàm ENGINE_by_id được sử dụng cho các mô-đun SSL tăng tốc phần cứng.

Và trong khi phân tích hàm ENGINE_by_id , chúng tôi xác định rằng nó cho phép tải động các thư viện chia sẻ. Hơn nữa, nếu thư viện được biên dịch với phần mở rộng __attribute__((constructor)) , hàm liên quan có thể được thực thi ngay khi tải. Điều này chỉ ra rằng bằng cách khai thác chỉ thị ssl_engine , kẻ tấn công có thể tải các thư viện chia sẻ tùy ý trên máy chủ, có khả năng dẫn đến RCE.

Theo mặc định, khi yêu cầu đến vượt quá 8KB, NGINX sẽ ghi nội dung yêu cầu vào tệp tạm thời nằm tại /tmp/nginx/client-body, sử dụng tên tệp theo định dạng cfg-{random_value}. Các tệp tạm thời này được lưu giữ trong tối đa 60 giây giữa các phần thành công của tin nhắn đã nhận.

Sau khi ghi một phần thân yêu cầu vào một tệp tạm thời, NGINX sẽ hoãn xóa cho đến khi nhận được toàn bộ thân yêu cầu. Nếu yêu cầu vẫn chưa hoàn tất và không nhận được dữ liệu trong tối đa 60 giây, tệp cuối cùng sẽ bị xóa. Tuy nhiên, bằng cách cố tình giữ lại phần dữ liệu cuối cùng, kẻ tấn công có thể giữ tệp tạm thời đang sử dụng, khiến nó có thể bị khai thác.

Mặc dù có thể kiểm soát được nội dung tệp đã tải lên, nhưng việc định vị tệp trên hệ thống tệp rất khó khăn do tên tệp được ngẫu nhiên hóa. Đường dẫn lưu trữ có thể được định cấu hình bằng client_body_temp_path , nhưng tên tệp được tạo ngẫu nhiên khi chạy, khiến nó trở nên không thể đoán trước. Tính ngẫu nhiên này cản trở đáng kể quyền truy cập có mục tiêu ngay cả khi sử dụng vũ lực. Để khắc phục điều này, nhóm đã tận dụng các hành vi vốn có của HĐH Linux. Hãy xem xét ví dụ sau:

This code opens a file and keeps it in an active state, closely mimicking the behavior of NGINX's client body buffer mechanism. Using /proc/{pid}/fd directory, attackers can find symbolic links created by the Linux kernel that map open file descriptors to their corresponding file paths. This route allows attackers to reduce the brute-force space to only two variables: the process ID (pid) and the file descriptor (fd).

Sau khi biên dịch, kích thước của thư viện chia sẻ kết quả đã vượt quá 8KB, cho phép NGINX lưu vào bộ đệm mà không cần thêm phần đệm.

Sau đó, các cộng sự của chúng tôi đã tạo một yêu cầu với giá trị Content-Length được thổi phồng (ví dụ: 1MB) để tạo ra sự không khớp về kích thước. Điều này khiến NGINX đệm toàn bộ nội dung thay vì xử lý ngay lập tức, đảm bảo đối tượng được chia sẻ sẽ được ghi vào một vị trí có thể dự đoán được.

RCE thành công yêu cầu chỉ thị ssl_engine tham chiếu đường dẫn chính xác đến tệp được đệm. Điều này có thể đạt được thông qua một tập lệnh brute force tự động lặp lại một cách có hệ thống các kết hợp có thể có của ID quy trình và mô tả tệp để xác định liên kết tượng trưng hợp lệ trỏ đến đối tượng được chia sẻ được đệm.

Dưới đây là mẫu NGINX được tạo ra đã kích hoạt lỗ hổng.

Sau khi khai thác thành công, kẻ tấn công có thể giành được quyền truy cập shell trong bối cảnh pod ingress-nginx, theo mặc định có quyền truy cập vào các bí mật cụm Kubernetes nhạy cảm.