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.
CVE-2025-1974'e Genel Bakış
CVE-2025-1974, 1.11.4 ve özellikle 1.12.0'a kadar olan ingress-nginx sürümlerinde tespit edilen kritik bir şablon enjeksiyonu güvenlik açığıdır. Bir Kubernetes kümesine düğüm düzeyinde erişimi olan saldırganlar, varsayılan olarak küme içindeki kritik sırlara erişim de dahil olmak üzere kapsamlı ayrıcalıklara sahip olan ingress-nginx denetleyicisi aracılığıyla RCE kullanarak rastgele kod çalıştırmak için bu kusurdan yararlanabilir.
Kubernetes Güvenlik Müdahale Komitesi bu güvenlik açığına 9.8 (kritik önem derecesi) CVSS v3.1 puanı vermiştir:
Bu Analizdeki Temel Bileşenler
Kubernetes'e Genel Bakış
Kubernetes (K8s), konteynerli uygulamaların dağıtımını, ölçeklendirilmesini ve operasyonel yönetimini otomatikleştirmek için kullanılan açık kaynaklı bir platformdur. Kubernetes kümeleri tipik olarak hem fiziksel donanım hem de sanal makineler içerebilen ve yüksek oranda kullanılabilir, ölçeklenebilir ve yönetilebilir uygulama ortamları sağlamak için birlikte çalışan birden fazla makineden oluşur.
NGINX Giriş Denetleyicisi
NGINX giriş denetleyicisi (ingress-nginx), NGINX web sunucusunun üzerine inşa edilmiş açık kaynaklı bir giriş denetleyicisidir. Bir Kubernetes kümesi içinde çalışır ve öncelikle bir ters proxy ve yük dengeleyici olarak işlev görür. Bu denetleyici, kullanıcılar tarafından tanımlanan Ingress kaynaklarını yorumlar ve trafik akışını kümeye ve küme içine yönlendirmek için bunları eyleme geçirilebilir NGINX yapılandırmalarına dönüştürür.
Kabul İncelemesi ve Rolü
Ingress-nginx, AdmissionReview adlı bir web kancası hizmeti kullanarak Kubernetes ile entegre olur. Bu hizmet, yerel Kubernetes Ingress nesnelerini işlemek ve bunları doğrulanmış ve sözdizimsel olarak doğru NGINX yapılandırmalarına çevirmek için çok önemlidir. AdmissionReview yapılandırma doğruluğunu sağlarken, ingress-nginx denetleyicisinden bağımsız olarak çalışır ve genellikle sıkı kimlik doğrulama kontrollerinden yoksundur. Bu sıkı kimlik doğrulama eksikliği, CVE-2025-1974'ün istismar edilebilirliğine katkıda bulunan önemli bir faktördür.
Güvenlik Açığı İstismarı ve Teknik Analiz
İstismar Mekanizması
CVE-2025-1974'ün istismarı özünde kötü niyetli bir istekle başlar. Saldırganlar, AdmissionReview web kancasına kötü niyetli bir istek göndererek NGINX'i çalışma zamanında paylaşılan bir kütüphaneyi dinamik olarak yüklemeye zorlar. Bu mekanizmaya dayanarak, arkadaşlarımız bu istismar yolunu anlamak için hem AdmissionReview webhook'unu hem de NGINX iş akışını analiz etti.
Şablon Enjeksiyonu Güvenlik Açığı
AdmissionReview webhook’unda, gelen istekler işlenirken CheckIngress işlevi, Kubernetes Ingress nesnelerini geçerli NGINX yapılandırma dosyalarına dönüştürür. İş akışı şu şekilde ilerler:
- Her yapılandırma ayrıştırılır ve önceden tanımlanmış NGINX şablonlarına göre biçimlendirilmek üzere generateTemplate işlevine aktarılır.
- Ardından, testTemplate oluşturulan yapılandırmayı altta yatan NGINX ikili dosyasıyla karşılaştırarak 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 temizleme işlemleri yetersizdir. Özellikle, bir Ingress Nesnesinden alınan uid alanı doğrudan NGINX yapılandırma şablonuna eklenmekte ve bu da bir enjeksiyon noktası oluşturmaktadır. Bir saldırgan, uid="1234#;\n\n}\n}\n}\n injection_value" gibi özel olarak hazırlanmış bir girdi sağlayarak bu durumu istismar edebilir.
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.
Şablon Enjeksiyonundan Uzak Kod Çalıştırmaya
testTemplate() Fonksiyonunun Açıklaması
generateTemplate işlevi tarafından NGINX yapılandırması oluşturulduktan sonra, testTemplate işlevi geçici bir yapılandırma dosyası oluşturur ve nginx -c {config_file} -t komutuyla NGINX kütüphanesini çalıştırır. Bu işlem, NGINX ikili dosyasının yapılandırmayı ayrıştırmasını ve doğrulamasını sağlar.
Bu güvenlik açığından yararlanmak için, bir saldırganın kötü amaçlı kod çalıştırabilen bir yönergeyi belirlemesi gerekir. Başlangıçta, ekip arkadaşlarımız load_module yönergesini potansiyel olarak kullanışlı buldular; çünkü bu yönerge, NGINX’in harici eklentileri yüklemesine olanak tanır. Ancak bu yönerge, yapılandırma çözümlemesinin yalnızca ilk aşamasında izin verilmektedir ve bu da bizim enjeksiyon noktamızla uyuşmamaktadır.
Bu sorunu çözmek için araştırmalarımıza devam ettik; bu da, “Modül, yapılandırma testleri sırasında OpenSSL tarafından dinamik olarak yüklenebilir” şeklinde tanımlanan ssl_engine yönergesine yol açtı. Modülleri dinamik olarak yükleyebilme özelliği nedeniyle bu durum merak uyandırdı ve daha derinlemesine bir inceleme gerektirdi.
ssl_engine Yönergesini Anlama
NGINX’in ssl_engine yönergesini nasıl işlediğini daha iyi anlamak ve NGINX’in bu yönerge aracılığıyla ek modüllerin dinamik olarak yüklenmesine hangi koşullarda izin verdiğini belirlemek amacıyla NGINX kaynak kodunu inceledik.
NGINX, başlatıldığında başlangıç durumunu yükler, ardından yapılandırma dosyalarını satır satır işler. Her bir yönerge, nginx_command_tstructure tarafından işlenir; ssl_engine yönergesi ise doğrudan ngx_openssl_commands’ı çağırır.
ngx_openssl_commands işlevini inceledikten sonra, ekip arkadaşlarımız bu işlevin OpenSSL desteğine dayandığını, özellikle de donanım hızlandırmalı SSL modülleri için kullanılan ENGINE_by_id işlevine bağlı olduğunu keşfettiler.
ENGINE_by_id işlevini incelerken, bu işlevin paylaşımlı kütüphanelerin dinamik olarak yüklenmesini sağladığını tespit ettik. Ayrıca, kütüphane __attribute__((constructor)) uzantısıyla derlenmişse, ilgili işlev yüklendiği anda hemen çalıştırılabilir. Bu durum, bir saldırganın ssl_engine yönergesini istismar ederek ana bilgisayara rastgele paylaşımlı kütüphaneler yükleyebileceğini ve bunun da potansiyel olarak uzaktan komut yürütme (RCE) sorununa yol açabileceğini göstermektedir.
Paylaşılan Kütüphaneleri Hedefleme ve Saldırı Stratejisi
Kodun yürütülmesini güvenilir bir şekilde kolaylaştırmak için, bir sonraki adım paylaşılan bir kütüphane tanımlamayı içerir. Harici kütüphanelere güvenmek yerine, NGINX'in kendi davranışından daha uygulanabilir ve kontrollü bir yaklaşım ortaya çıkar: istemci gövde tampon mekanizması. Bu özellik, NGINX'in gelen büyük istekleri geçici dosyalara aktarmasını sağlayarak öngörülebilir dosya işleme davranışına dayalı istismar fırsatları sunar.
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 dosyanın içeriği kontrol edilebilse de, dosya adı rastgele oluşturulduğu için dosyanın dosya sistemindeki konumunu belirlemek zordur. Depolama yolu client_body_temp_path kullanılarak yapılandırılabilir, ancak dosya adı çalışma zamanında rastgele oluşturulur ve bu da onu öngörülemez kılar. Bu rastgelelik, kaba kuvvet yöntemiyle bile hedefe yönelik erişimi önemli ölçüde engeller. Bu sorunu aşmak için ekip, Linux işletim sistemine özgü 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).
İstismar Simülasyonu
Yukarıdaki analize dayanarak, Ingress-NGINX bölmesi içinde RCE için pratik bir istismar yaklaşımı şudur:
- Dosya sisteminde geçici olarak depolamak için NGINX'in istemci gövdesi arabellek mekanizmasını kullanarak kötü amaçlı bir paylaşılan kitaplık yükleyin.
- NGINX'i savunmasız yönergeler aracılığıyla önceden yüklenmiş paylaşılan kitaplığı yüklemeye zorlayan bir kaba kuvvet girişimi başlatmak için şablon enjeksiyonu kullanın.
Paylaşılan Kitaplığı İçeren Yükün Hazırlanması
Yükleme sırasında kodun yürütülmesini sağlamak için, kötü amaçlı paylaşılan kütüphanede kurucu uzantılı bir giriş noktası işlevi tanımlanmıştır. Bu işlev NGINX tarafından yüklendikten sonra çalıştırılır ve uzak bir ana bilgisayara ters kabuk bağlantısı kurmak için tasarlanmıştır.
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.
Ardından, ekip üyelerimiz boyut uyuşmazlığı yaratmak için Content-Length değeri abartılmış (örneğin, 1 MB) bir istek oluşturdular. Bu durum, NGINX’in gövdeyi hemen işlemek yerine tamamını arabelleğe almasına neden oldu ve böylece paylaşılan nesnenin öngörülebilir bir konuma yazılmasını sağladı.
Enjeksiyon Yoluyla Paylaşılan Kitaplığı Tetikleme
Paylaşımlı kütüphane hazır hale geldikten sonra, güvenlik açığı bulunan uidfield'ı kullanarak NGINX yapılandırmasına kötü amaçlı bir yönerge ekledik. Bu yönerge, tamponlanmış dosya yoluna işaret eden ssl_engine'i içeriyordu:
RCE'nin başarılı olması için, `ssl_engine` yönergesinin tamponlanmış dosyaya giden doğru yolu belirtmesi gerekir. Bu, tamponlanmış paylaşımlı nesneye işaret eden geçerli sembolik bağlantıyı tespit etmek amacıyla işlem kimlikleri ve dosya tanımlayıcılarının olası kombinasyonlarını sistematik olarak tarayan otomatik bir kaba kuvvet komut dosyası aracılığıyla gerçekleştirilebilir.
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.
Etki Azaltma ve İyileştirme
CVE-2025-1974 ile ilişkili riskleri etkili bir şekilde azaltmak için kuruluşların açık kaynak bileşenleri üzerinde görünürlük ve kontrol sağlayan bir çözüme ihtiyacı vardır.
MetaDefender® platformunda temel bir teknoloji olan OPSWAT SBOM, kullanılan tüm yazılım bileşenlerinin, kütüphanelerin, Docker konteynerlerinin ve bağımlılıkların bir envanterini sağlayarak bu ihtiyacı karşılar. Kurumların bileşenlerini proaktif olarak izlemelerine, güvence altına almalarına ve güncellemelerine olanak tanır.
Yukarıdaki örnekte, MetaDefender Core™'daki SBOM teknolojisi, CVE-2025-1974 güvenlik açığını içeren nginx-ingress-controller paketini taradı. Sistem, sorunu otomatik olarak Kritik olarak işaretledi ve mevcut düzeltilmiş sürümler hakkında rehberlik sağlayarak ekiplerin güvenlik açığı istismar edilmeden önce hızlı bir şekilde önceliklendirmesini ve yamalamasını sağladı.
OPSWAT SBOM, MetaDefender Core ve MetaDefender Software Supply Chain™'de mevcuttur ve güvenlik ekiplerinin güvenlik açıklarını daha hızlı tespit etmesini ve harekete geçmesini sağlar. OPSWAT SBOM ile güvenlik ekipleri şunları yapabilir
- Savunmasız bileşenleri hızla bulun - Derileştirme saldırılarından etkilenen açık kaynaklı bileşenleri hemen belirleyin. Bu, savunmasız kütüphanelerin yamalanması veya değiştirilmesi konusunda hızlı hareket edilmesini sağlar.
- Proaktif yama ve güncellemeler sağ layın - Derileştirme güvenlik açıklarının önüne geçmek için OPSWAT SBOM aracılığıyla açık kaynaklı bileşenleri sürekli izleyin. OPSWAT SBOM eski veya güvensiz bileşenleri tespit ederek zamanında güncelleme yapılmasını ve saldırılara daha az maruz kalınmasını sağlayabilir.
- Uyumluluğu ve raporlamayı sürdürün - OPSWAT SBOM, düzenleyici çerçevelerin yazılım tedarik zincirlerinde şeffaflığı giderek daha fazla zorunlu kılması nedeniyle kuruluşların uyumluluk gereksinimlerini karşılamasına yardımcı olur.
