2025 年 5 月，一個被稱為 IngressNightmare 的重要安全漏洞 CVE-2025-1974 被公開揭露，此漏洞會影響廣泛部署於雲端原生基礎架構的 Kubernetes ingress-nginx 控制器。此漏洞允許未經認證的攻擊者將任意配置注入 NGINX，可能導致未經授權的 RCE (遠端程式碼執行) 和整個群集受損。
作為OPSWAT 研究員計畫的一部分，我們的研究員進行了深入的技術分析，以更好地瞭解其根本原因、剝削路徑以及圍繞這一高嚴重性問題的緩解策略。
CVE-2025-1974 概觀
CVE-2025-1974 是在 ingress-nginx 1.11.4 及 1.12.0 以下版本中發現的重要範本注入漏洞。擁有 Kubernetes 叢集節點層級存取權限的攻擊者可利用此漏洞，透過 ingress-nginx 控制器使用 RCE 執行任意程式碼。
Kubernetes 安全回應委員會將此漏洞的 CVSS v3.1 分數指定為 9.8 (嚴重程度)：
本分析的主要組成部分
Kubernetes 概觀
Kubernetes (K8s) 是一個開放原始碼平台，用來自動化容器化應用程式的部署、擴充與作業管理。Kubernetes 叢集通常由多台機器組成，其中可包括實體硬體和虛擬機器，共同運作以提供高度可用、可擴充和可管理的應用程式環境。
NGINX 入口控制器
NGINX 入口控制器 (ingress-nginx) 是建構在 NGINX 網頁伺服器之上的開放原始碼入口控制器。它在 Kubernetes 集群中運作，主要作為反向代理和負載平衡器。此控制器可解譯使用者定義的 Ingress 資源，並將其轉譯為可執行的 NGINX 配置，以將流量路由至群集內。
入學審查及其作用
Ingress-nginx 使用稱為 AdmissionReview 的 webhook 服務與 Kubernetes 整合。這項服務對於處理原生的 Kubernetes Ingress 物件，並將其轉換為經過驗證且語法正確的 NGINX 配置而言，至關重要。雖然 AdmissionReview 可確保配置的正確性，但它獨立於 ingress-nginx 控制器運作，通常缺乏嚴格的驗證控制。缺乏嚴格的驗證是造成 CVE-2025-1974 可被利用的關鍵因素。
漏洞開發與技術分析
開發機制
CVE-2025-1974 的攻擊核心始於惡意請求。攻擊者向 AdmissionReview webhook 發出惡意請求，迫使 NGINX 在執行時動態載入共用函式庫。根據此機制，我們的研究人員分析了 AdmissionReview webhook 和 NGINX 工作流程，以瞭解此攻擊路徑。
範本注入漏洞
在 AdmissionReview 的 webhook 中，當處理傳入請求時，CheckIngress 函式會將 Kubernetes Ingress 物件轉換為有效的 NGINX 配置檔案。流程如下：
- 每個設定都會被解析，並傳遞給 generateTemplate，以便根據預先定義的 NGINX 範本進行格式化。
- 隨後，testTemplate 會根據底層的 NGINX 二進位檔，對生成的設定進行驗證。
所有 NGINX 配置都基於 ingress-nginx 原始碼中的 nginx.tmpl 檔案中的預定義範本：
在 generateTemplate 函式中，配置的處理方式如下面的程式碼片段所示：
然而，僅靠輸入驗證與淨化並不足夠。具體而言，Ingress 物件中的 uid 欄位會直接插入 NGINX 配置範本中，從而形成一個注入點。攻擊者可透過提供經過特殊設計的輸入（例如 uid="1234#;\n\n}\n}\n}\n injection_value"）來利用此漏洞。
此惡意輸入允許全局範圍注入到 NGINX 模板，使攻擊者能夠觸發任意 NGINX 指令，並可能達到 RCE。
從模板注入到遠端程式碼執行
testTemplate() 函式說明
在 generateTemplate 函式產生 NGINX 設定檔後，testTemplate 函式會建立一個暫時性設定檔，並透過指令 nginx -c {config_file} -t 執行 NGINX 函式庫。此舉會強制 NGINX 二進位檔解析並驗證該設定檔。
要利用此漏洞，攻擊者必須找出能夠執行惡意程式碼的指令。起初，我們的團隊成員認為 `load_module` 指令可能派上用場，因為此指令允許 NGINX 載入外部外掛程式。然而，此指令僅在配置解析的早期階段才被允許使用，這與我們的注入點並不吻合。
為了解決這個挑戰，我們持續進行深入研究，進而發現了 ssl_engine 指令，其說明為：「該模組可能在配置測試期間由 OpenSSL 動態載入。」由於其具備動態載入模組的能力，這點引起了我們的興趣，因此有必要進行更深入的探究。
瞭解 ssl_engine 指令
為了更深入了解 NGINX 如何處理 `ssl_engine` 指令，並釐清 NGINX 在何種情況下會允許透過此指令動態載入額外的模組，我們仔細研究了 NGINX 的原始碼。
NGINX 在啟動時會載入其初始狀態，接著逐行解析設定檔。每個指令皆由 nginx_command_tstructure 處理，其中 ssl_engine 指令會直接呼叫 ngx_openssl_commands。
在分析 ngx_openssl_commands 函式後，我們的同事發現它依賴於 OpenSSL 的支援，具體而言是 ENGINE_by_id 函式，該函式用於硬體加速的 SSL 模組。
在分析 ENGINE_by_id 函式時，我們發現該函式可實現共用函式庫的動態載入。此外，若該函式庫是使用 __attribute__((constructor)) 擴充功能編譯而成，則相關函式可在載入時立即執行。這表明，攻擊者可透過利用 ssl_engine 指令，在主機上載入任意的共用函式庫，進而可能導致遠端程式碼執行（RCE）。
針對共用程式庫與攻擊策略
為了可靠地促進代碼的執行，下一步涉及到確定一個共享庫。與其依賴外部函式庫，NGINX 本身的行為會產生一個更可行且更受控制的方法：用戶端正文緩衝機制。此功能可讓 NGINX 將大量傳入的要求卸載到暫存檔案中，並根據可預測的檔案處理行為開啟利用機會。
預設情況下，當接收到的請求超過 8KB 時，NGINX 會將請求體寫入一個位於 /tmp/nginx/client-body 的臨時檔案，使用的檔案名稱格式為 cfg-{random_value}。這些臨時檔案在成功接收訊息的大塊之間最多保留 60 秒。
將部分請求正文寫入臨時檔案後，NGINX 會延遲刪除，直到收到完整的正文為止。如果請求仍未完成，且在長達 60 秒的時間內未收到任何資料，則檔案最終會被清除。然而，攻擊者可藉由故意保留最後一大塊資料，讓臨時檔案繼續使用，使它成為可利用的漏洞。
雖然可以控制上傳檔案的內容，但由於檔案名稱是隨機生成的，因此難以在檔案系統中定位該檔案。雖然可以透過 `client_body_temp_path` 來設定儲存路徑，但檔案名稱是在執行時隨機生成的，因此無法預測。這種隨機性即使透過暴力破解，也極大程度地阻礙了針對性存取。為克服此問題，團隊利用了 Linux 作業系統固有的行為特性。請參閱以下範例：
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).
模擬剝削
基於上述分析，Ingress-NGINX pod 內 RCE 的實用開發方法是：
- 使用 NGINX 的 client body buffer 機制上傳惡意的共用函式庫，將其暫時存放在檔案系統上。
- 使用範本注入啟動暴力嘗試，強迫 NGINX 透過易受攻击的指令載入先前上傳的共用函式庫。
製作包含共用資料庫的 Payload
為了確保在載入時執行程式碼，惡意共享函式庫中定義了一個具有構建器擴充的入口點函式。這個函式會在 NGINX 載入時執行，目的是建立與遠端主機的反向 shell 連線。
編譯完成後，產生的共用函式庫大小剛好超過 8KB，允許 NGINX 對其進行緩衝，而不需要額外的填充。
隨後，我們的研究人員製作了一個將 Content-Length 值誇大（例如 1MB）的請求，以製造大小不符的情況。這導致 NGINX 將整個請求正文緩存起來，而非立即處理，從而確保共享物件會被寫入可預測的位置。
透過注入觸發共用資料庫
在建立共用函式庫後，我們接著利用存在漏洞的 uidfield，將一項惡意指令注入 NGINX 設定中。此指令包含指向緩衝檔案路徑的 ssl_engine：
要成功執行 RCE，必須讓 `ssl_engine` 指令指向緩衝檔案的正確路徑。這可透過自動化的暴力破解腳本來實現，該腳本會系統性地遍歷所有可能的程序識別碼與檔案描述符組合，以找出指向緩衝共用物件的有效符號連結。
以下是觸發攻擊的 NGINX 模版產生範例。
成功利用後，攻擊者可在 ingress-nginx pod 的情境下取得 shell 存取權限，而該 pod 預設可存取敏感的 Kubernetes 群集機密。
緩解與補救
為了有效降低與 CVE-2025-1974 相關的風險，組織需要一套解決方案，對其開放原始碼元件提供可見性與控制。
OPSWAT SBOM 是MetaDefender® 平台中的一項基礎技術，可透過提供所有軟體元件、程式庫、Docker 容器和使用中的相依性清單，滿足此需求。它可讓組織主動追蹤、保護和更新其元件。
在上面的例子中，MetaDefender Core™ 中的SBOM 技術掃描了包含 CVE-2025-1974 漏洞的 nginx-ingress-controller 套件。系統自動將此問題標記為 Critical，並提供可用修復版本的指引，讓團隊能夠快速排定優先順序，並在漏洞被利用之前修補漏洞。
OPSWAT SBOM 可在MetaDefender Core 和MetaDefender Software Supply Chain™ 中使用，使安全團隊能夠更快地識別漏洞並採取行動。透過OPSWAT SBOM，安全團隊可以
- 快速找出易受攻擊的元件 - 立即找出受序列化攻擊影響的開放原始碼元件。這可確保迅速採取行動，修補或取代易受攻擊的函式庫。
- 確保主動修補與更新- 透過OPSWAT SBOM 持續監控開放原始碼元件，以掌握反序列化漏洞。OPSWAT SBOM 可偵測過時或不安全的元件，以便及時更新並降低遭受攻擊的風險。
- 維持法規遵循與報告- 隨著法規框架日益強制軟體供應鏈的透明度，OPSWAT SBOM 可協助組織符合法規遵循的要求。
