IngressNightmare: CVE-2025-1974 Uzaktan Kod Yürütme Güvenlik Açığı ve Düzeltme

Mayıs 2025, bulut yerel altyapılarında yaygın olarak kullanılan Kubernetes ingress-nginx denetleyicisini etkileyen ve IngressNightmare olarak adlandırılan CVE-2025-1974 adlı kritik bir güvenlik açığının kamuya açıklanmasına işaret etti. Bu güvenlik açığı, kimliği doğrulanmamış saldırganların NGINX'e keyfi yapılandırmalar enjekte etmesine olanak tanıyarak yetkisiz RCE'ye (uzaktan kod yürütme) ve kümenin tamamen ele geçirilmesine yol açabilir.

OPSWAT Burs programının bir parçası olarak, bursiyerlerimiz bu yüksek önem derecesine sahip sorunun temel nedenini, istismar yolunu ve hafifletme stratejilerini daha iyi anlamak için derinlemesine bir teknik analiz gerçekleştirdiler.

1. Her yapılandırma ayrıştırılır ve önceden tanımlanmış NGINX şablonlarına göre biçimlendirilmek üzere generateTemplate 'e aktarılır.
2. Daha sonra, testTemplate oluşturulan yapılandırmayı temel NGINX ikili dosyasına karşı doğrular.

Tüm NGINX yapılandırmaları, ingress-nginx kaynak kodu içindeki nginx.tmpl dosyasında bulunan önceden tanımlanmış şablonlara dayanmaktadır:

generateTemplate işlevi içinde, yapılandırma aşağıdaki kod parçasında gösterildiği gibi işlenir:

Ancak girdi doğrulama ve sanitizasyon yetersizdir. Özellikle, bir Ingress Nesnesinden gelen uid alanı doğrudan NGINX yapılandırma şablonuna eklenir ve bir enjeksiyon noktası oluşturur. Bir saldırgan, uid="1234#;\n\n}\n}\n}\n injection_value" gibi hazırlanmış bir girdi sağlayarak bu durumdan yararlanabilir.

Bu kötü amaçlı girdi, NGINX şablonuna global kapsam enjeksiyonuna izin vererek saldırganların keyfi NGINX yönergelerini tetiklemesine ve potansiyel olarak RCE elde etmesine olanak tanır.

Güvenlik açığından faydalanmak için, bir saldırganın kötü amaçlı kod çalıştırabilecek bir yönerge belirlemesi gerekir. Başlangıçta, arkadaşlarımız load_module yönergesini potansiyel olarak yararlı olarak tanımladılar, çünkü bu yönerge NGINX'in harici eklentileri yüklemesine izin veriyor. Ancak, bu yönergeye yalnızca yapılandırma ayrıştırmasının ilk aşamasında izin verilir, bu da enjeksiyon noktamızla eşleşmez.

Bu zorluğu çözmek için araştırmaya devam ettik ve "Modül, yapılandırma testi sırasında OpenSSL tarafından dinamik olarak yüklenebilir." şeklinde tanımlanan ssl_engine yönergesine ulaştık. Bu, modülleri dinamik olarak yükleyebilme özelliği nedeniyle merak uyandırdı ve daha derin bir inceleme gerektirdi.

Başlangıçta NGINX ilk durumunu yükler, ardından yapılandırma dosyalarını satır satır ayrıştırır. Her yönerge nginx_command_t yapısı tarafından ele alınır, ssl_engine yönergesi doğrudan ngx_openssl_commands'ı çağırır.

ngx_openssl_commands işlevini analiz eden arkadaşlarımız, bu işlevin OpenSSL desteğine, özellikle de donanım hızlandırmalı SSL modülleri için kullanılan ENGINE_by_id işlevine dayandığını keşfetmişlerdir.

ENGINE_by_id fonksiyonunu analiz ederken, paylaşılan kütüphanelerin dinamik olarak yüklenmesini sağladığını tespit ettik. Dahası, eğer kütüphane __attribute__ ((constructor)) uzantısı ile derlenmişse, ilgili fonksiyon yüklendikten hemen sonra çalıştırılabilir. Bu, bir saldırganın ssl_engine yönergesinden yararlanarak ana bilgisayara rastgele paylaşılan kütüphaneler yükleyebileceğini ve potansiyel olarak RCE'ye yol açabileceğini gösterir.

Varsayılan olarak, gelen bir istek 8KB'yi aştığında, NGINX istek gövdesini /tmp/nginx/client-body adresinde bulunan geçici bir dosyaya cfg-{random_value} biçiminde bir dosya adı kullanarak yazar. Bu geçici dosyalar, alınan bir iletinin başarılı parçaları arasında 60 saniyeye kadar tutulur.

Kısmi bir istek gövdesini geçici bir dosyaya yazdıktan sonra, NGINX tüm gövde alınana kadar silmeyi erteler. İstek tamamlanmamış olarak kalırsa ve 60 saniyeye kadar veri alınmazsa, dosya sonunda temizlenir. Bununla birlikte, bir saldırgan son veri yığınını kasıtlı olarak saklayarak geçici dosyayı kullanımda tutabilir ve istismar edilebilir hale getirebilir.

Yüklenen dosya içeriği kontrol edilebilmesine rağmen, dosya adının rastgele olması nedeniyle dosya sisteminde yerini bulmak zordur. Depolama yolu client_body_temp_path kullanılarak yapılandırılabilir, ancak dosya adı çalışma zamanında rastgele oluşturulur ve tahmin edilemez hale gelir. Bu rastgelelik, kaba kuvvet yoluyla bile hedeflenen erişimi önemli ölçüde engeller. Ekip bunun üstesinden gelmek için Linux işletim sisteminin doğasında bulunan davranışlardan yararlandı. Aşağıdaki örneği ele alalım:

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).

Derlemeden sonra, ortaya çıkan paylaşılan kütüphanenin boyutu 8KB'yi rahatça aştı ve ek dolgu gerektirmeden NGINX tarafından arabelleğe alınmasına izin verdi.

Arkadaşlarımız daha sonra bir boyut uyuşmazlığı yaratmak için şişirilmiş bir İçerik-Uzunluğu değeri (örneğin 1MB) içeren bir istek hazırladılar. Bu, NGINX'in tüm gövdeyi hemen işlemek yerine arabelleğe almasına neden olarak paylaşılan nesnenin öngörülebilir bir konuma yazılmasını sağladı.

Başarılı bir RCE, ssl_engine yönergesinin tamponlanmış dosyanın doğru yoluna referans vermesini gerektirir. Bu, tamponlanmış paylaşılan nesneye işaret eden geçerli sembolik bağlantıyı tanımlamak için işlem kimliklerinin ve dosya tanımlayıcılarının olası kombinasyonlarını sistematik olarak yineleyen otomatik bir kaba kuvvet betiği aracılığıyla elde edilebilir.

Aşağıda, istismarı tetikleyen oluşturulan NGINX şablonunun bir örneği yer almaktadır.

Başarılı bir istismarın ardından saldırgan, varsayılan olarak hassas Kubernetes küme sırlarına erişimi olan ingress-nginx pod bağlamı altında kabuk erişimi elde edebilir.