# CVE-2025-1974 - Unauthenticated Remote Code Execution Vulnerabilities in Ingress NGINX
# CVE-2025-1974 Overview
Đây là 1 lỗ hổng tấn công tiêm mã (injection attack), xuất hiện ở các phiên bản Ingress-Nginx trước 1.11.5 và phiên bản 1.12.0 cho phép người tấn công c hỉ cần có quyền truy cập vào mạng của cụm Kubernetes (cluster) có thể tải và thực thi mã độc mà không yêu cầu việc xác thực. Lợi dụng lỗ hổng bảo mật này kẻ tấn công có thể thực thi mã từ xa trên pod ingress-nginx-controller.

Hiện tại CVSS score của CVE này được CNA Kubernetes đưa ra là 9.8, với Attack Vector từ Network và độ phức tạp được đánh giá là thấp và không cần bất kỳ yêu cầu đặc quyền và tương tác từ người dùng và phạm vi ảnh hưởng được đánh giá không thay đổi, bởi vì có thể thực thi mã từ xa nên tam giác CIA (Confidentiality, Interrity, Availability) bị phá vỡ hoàn toàn nên CNA Kubernetes đánh giá ở mức High.


## Some components of the analysis
### What is Kubernetes ?
Một nền tảng mã nguồn mở để tự động hóa ứng dụng container hóa. Cung cấp các tính năng như triển khai, quản lý, và mở rộng quy mô.

### What is Ingress NGINX Controller ?
Một thành phần phần mềm mã nguồn mở được sử dụng bên trong cụm Kubernetes. Hoạt động như một proxy ngược và một bộ cân bằng tải cho cụm Kubernetes.

### What is AdmissionReview ?
Dịch vụ chịu trách nhiệm tạo và kiểm tra cấu hình nginx từ đối tượng ingress đến.Được cung cấp dưới dạng webhook để chấp nhận và xác thực cấu hình. Cho phép xác thực đối tượng ingress mà không cần xác thực.

## Overview CVE-2025-1974 reconstruction model


# CVE analysis
Nguyên nhân gốc rễ là chỉ cần có quyền truy cập vào mạng của cụm Kubernetes (cluster) có thể tải và thực thi mã độc thông qua các Admisson Review được gửi đến Admission Webhook có thể kích hoạt tấn công tiêm mẫu để buộc một thư viện chia sẻ độc hại được tải lên từ kẻ tấn công tại thời gian xử lý yêu cầu tải thư viện chia sẻ được nạp dẫn đến.

## How is the request handled?
Trong quá trình xử lý, hàm `CheckIngress` được gọi để phân tích và chuyển đổi dịch cái IngressObject từ gói tin tới sang configuration của NGINX.
Hàm `generateTemplate` được gọi để chuyển chuyển các annotation sang các trường được định nghĩa theo mẫu và truyền hàm `testTemplate` để tạo file config mẫu, sau đó kiểm tra syntax và các trường được định nghĩa phù hợp cho quá trình chạy.
## What is being injected?
File `nginx.tmpl` có thể được tìm thấy trong mã nguồn của Ingress NGINX, chứa toàn bộ định dạng mẫu của các cấu hình hợp lệ có thể được định nghĩa. Ingress sẽ sử dụng template này để tạo ra file config hợp lệ từ các giá trị nhận được từ gói tin tới. Dưới đây là một mẫu template của việc setup một mirror cho server:
Tương tự, bên dưới là hàm chịu trách nhiệm chuyển đổi các giá trị cho trường Mirror
Có thể thấy, Hàm `Parse` sử dụng trực tiếp giá trị `uid` nhận được từ gói tin tới nhưng không thông qua quá trình sanitize. Vậy giả ta chèn một UID có giá trị như sau: `uid=“1234#;\n\n}\n}\n}\ninjection_value”`
Từ đó người tấn công có thể dể dàng inject một giá trị với scope Global trên NGINX template.
## Template to RCE
### testTemplate
Hàm `testTemplate` sẽ chịu trách nhiệm tạo một file configuration tạm, sau đó thực hiện gọi: `nginx -t -c {configfile}` trên file tạm này.
Khi xem xét sâu hơn về tính năng của NGINX, `load_module` có thể được sử dụng để tải các plugin để cải thiện tính năng của NGINX, nhưng khi sử dụng chỉ thị này, NGINX không cho phép tải thêm các thư mục trong thời gian thực.
Từ đó, ta cần một phương thức khác để kích hoạt việc tải thư viện lên. Tài liệu của NGINX còn định nghĩa một chỉ thị khác có thể đuợc lợi dùng để tải một thư viện trong thời gian kiểm thử cấu hình:
Tại sao NGINX binary lại có thể tải thư viện qua chỉ thị `ssl_engine` trong thời gian kiểm thử còn `load_module` thì không? Câu trả lời nằm ở việc OpenSSL cung cấp các hàm load dynamic các thư viện hỗ trợ gia tốc phần cứng cũng như định nghĩa các hàm mã hóa và giải mã tự hiện thực của người dùng. Khi đó OpenSSL cần kiểm tra và đảm bảo các thư viện này có tồn tại và ở đúng định dạng có thể tải lên được.
Cụ thể hơn trong NGINX, các chỉ thị có thể được định nghĩa các hàm thực thi chức năng một cách linh hoạt thông qua con trỏ `set` của cấu trúc `nginx_command_t`. Tương ứng, chỉ thị `ssl_engine` sẽ sử dụng `ngx_opensll_engine` để thực thi việc thử config này. Vậy nếu ở một version OpenSSL hỗ trợ tính năng tải các ENGINE, cờ `OPENSSL_NO_ENGINE` sẽ không được define tương ứng hàm `ENGINE_by_id` được gọi cùng với tham số là đường dẫn được định nghĩa trong chỉ thị. Từ đó, OpenSSL sẽ tìm và tải thư mục này lên để kiểm thử tính tương thích
### Target's library
Do sự đa dạng về môi trường của các hệ thống Linux/ UNIX có thể được dùng để triền khai, việc nhắm vào một thư viện có trong hệ điều hành có những hạn chế nhất định, từ đó ta chuyển mục tiêu sang hành vi của NGINX: Client body buffer. Khi một yêu cầu được gửi tới NGINX có độ dài phần nội dung quá lớn, NGINX sẽ thực hiện tạo một file tạm chỉ để chứa phần body này giúp tối ưu bộ nhớ của ứng dụng trước khi sử lý yêu cầu.
Với hành vi mặc định, NGINX sẽ tạo một file tạm tại đường dẫn `/tmp/nginx/` để chứa file này với một tiêu đề là `cfg-{randomvalue}`. File này sẽ được tạo nếu request có phần body lớn hơn 8KB và được giữ tối đa 60s giữa các lần đọc thành công.
Vậy nếu ta chỉ gửi một gói tin với kích cỡ vừa vượt hơn 8KB thì body của request này sẽ được NGINX lại và tạo thành vi upload giả mạo một thư mục.
Người tấn công có thể liên tục tái kích hoạt hành vi này bằng cách gửi thêm cái gói tin để đặt lại khung thời gian 60s đối với các cuộc tấn công dài hơn.
Tuy nhiên trường `client_body_temp_path` có thể được người dùng tự định nghĩa cùng với việc tên file được tạo ngẫu nhiên trong thời gian chạy dẫn đến việc tấn công trực tiếp file này là điều bất khả thi. Tuy nhiên tồn tại một cơ chế của Linux có thể được tận dụng để vượt qua vấn đề này.

#python3 test.py 

with open("testfile", "w+") as a:
    a.write("Test")
        while True: pass

Đoạn code trên mô phỏng một tiến trình tương đương với việc xử lý file của một process. Khi một file được tạo và sử dụng, tại thư mục `/proc/{pid}/fd` của ứng dụng sẽ tạo một symbolic link tương ứng đến vị trí thực tế của file này trong hệ điều hành. Do đó ta có thể tân công thử sai trên 2 số nguyên `pid` và `fd-count` tương ứng thày gì phải nhắm vào một chuỗi ký tự do người dùng định nghĩa.
# Attack Flow
Dưới đây là sơ đồ tổng quan về luồng khai thác CVE-2025-1974, Trong ngữ cảnh CVE này attacker đứng ở bất kỳ vị trí nào trong pod và lợi dụng việc pod ingress-nginx-controller không xác thực các yêu cầu được gửi đến, đầu tiên attacker tiến hành upload một share lib độc hại có kích thước lớn dẫn đến pod này sẽ lưu share lib tại vào thư mục tmp, tiếp theo attacker tiến hành gửi hàng loạt các yêu cầu admission review độc hại để kích hoạt share lib thực thi, từ đó attacker có thể đạt được thực thi mã từ xa trên pod ingress-nginx-controller.

Tóm lại luồng tấn công bao gồm 2 bước chính:
1. Ta sẽ thông qua hành vi `client-body-buffer` để upload payload dưới dạng share lib đến `pod nginx-ingress-controller`.
2. Sau đó, ở request thứ 2 ta sẽ gửi một yêu cầu `admission review` chứa một anotation độc hại (`ssl_engine directive`) để Nginx dựa vào và tải tệp dưới dạng thư viện chia sẻ, share lib được ta thiết kế để khi được import sẽ tự động thực thi.

## Preparing Payload
### Build payload as a shared library:

Từ mã khai thác ta định nghĩa một constructor tên `entrypoint()` và khi nginx import share lib độc hại này, `entrpoint()` sẽ tự động thực thi và gọi đến `fork()` tạo một process con là bản sao của tiến trình đang gọi và đảm bảo tiến trình này luôn > 0 và gọi đến `cmd_excute()` với tham số là chuỗi lệnh cmd trả về reverse shell đến máy host (máy tấn công) và port mà ta đang lắng nghe.


Tiến hành compile đoạn code c này thành định dạng của tệp share lib và có thể thấy share lib độc hại này có kích thước 17kb và đáp ứng được điều kiện để kích hoạt hành vi `client-body-buffer` của ingress-nginx-controller.


Sau khi có được share lib độc hại ta lợi dụng việc có thể gửi bất kỳ yêu cầu mà không cần xác thực để upload share lib lên ingress-nginx-controller. từ mã khai thác bên dưới ta định nghĩa một ContentLength trong yêu cầu luôn là 1MB (đảm bảo luôn lớn hơn phần body mà ta sẽ gửi đến ingress-nginx-controller) nhằm giữ yêu cầu này được xử lý ở trạng thái treo dẫn đến ingress-nginx-controller giữ cho sharelib độc hại có thể tồn tại trên hệ thống trong lúc ta xác định được vị trí của nó.

### Trigger shared library:

Vì cấu trúc đường dẫn của share lib phức tạp và ngẫu nhiên nên ta không thể xác định nó trong 60s timeout của nginx-ingress-controller, vì vậy ta cần một đường dẫn dễ xác định hơn là /proc/x/fd/y

Khi nghiên cứu và xem xét thực tế trong quá trình triển khai, Nginx và ingress-nginx cùng nằm trong 1 pod và PID của nginx luôn nằm trong khoảng từ 1->50.


Và khi quan sát cách mà ingress-nginx-controller xử lý yêu cầu upload ta thấy được, tại một trong những tiến trình của Nginx sẽ tạo thêm những file descriptor với tên file các giá trị từ 1 -> 30 tham chiếu đến share lib trong thư /tmp/nginx/xxxxxx.


Tuy nhiên, Để share lib độc hại được nginx import thông qua `ssl_engine directive`, ta phải inject được một định nghĩa `ssl_engine directive` vào file cấu hình nginx ở global scope, như ban đầu ta đề cập về thành phần anotation và uid trong admission review không được vệ sinh đúng cách vì vậy ta có thể thông qua đây để inject các định nghĩa `ssl_engine directive`, như ảnh dưới:
Bởi vì ta đã xác định được vị trí mà các giá trị anotation và uid được chèn vào file cấu hình nginx, từ đó có thể thêm các ký tự `\n` và `}` để thoát khỏi các khối cấu hình và ghi định nghĩa ssl_engine directive ở global scope như một cấu hình chính xác. và chuỗi foobar là một place holder mà thực tế ta sẽ thay thế các đường dẫn trỏ đến vị trí file descriptior.

Sau khi có được phạm vi pid và fd cũng như là body ta sẽ gửi trong yêu cầu admission review độc hại, ta có thể thấy mã khai thác từ bên dưới như sau:


Pid và fd sẽ được thay thế vào đường dẫn và phía trước đường dẫn đến fd của share lib ta sử dụng 6 lần `../` mục đích đảm bảo ta có thể truy cập được /proc đối với hệ thống xử lý admission review ở các thư mục nhiều cấp, và "foobar" là một chuỗi place holder mà thực tế sẽ được thay thế bằng các đường dẫn này, Đầu ra của payload được trả về cho attacker thông qua phản hồi của `admission webhook`, và nếu phản hồi admission review chứa dòng "code injected" ta đã inject thành công.

Kết quả ta có một file cấu hình nginx mà ta đã inject các ký tự `n` và `}` để thoát khỏi các khối cấu hình và ghi một định nghĩa`ssl_engine directive` ở global scope trỏ đến vị trí fd share lib mà ta kiểm soátết quả một file cấu hình nginx mà ta đã inject các ký tự `n` và `}` để thoát khỏi các khối cấu hình và ghi một định nghĩa`ssl_engine directive` ở global scope trỏ đến vị trí fd share lib mà ta kiểm soát trước đó.


Khi Nginx tiến hành thử file cấu hình nginx, nó sẽ tiến hành đánh giá theo thứ tự từ trên xuống và khi thấy dòng định nghĩa `ssl_engine ../../../../../../proc/31/fd/10` và tiến hành tải share lib dựa vào đường dẫn này và từ đó mã độc sẽ được thực thi.

# POC