IngressNightmare: CVE-2025-1974 Vulnerabilitate de execuție a codului la distanță și remediere

Luna mai 2025 a marcat dezvăluirea publică a unei vulnerabilități de securitate critice, CVE-2025-1974, denumită IngressNightmare, care afectează controlerul Kubernetes ingress-nginx implementat pe scară largă în infrastructurile native de cloud. Această vulnerabilitate permite atacatorilor neautentificați să injecteze configurații arbitrare în NGINX, ceea ce poate duce la RCE (executarea codului de la distanță) neautorizat și la compromiterea întregului cluster.

Ca parte a programului de burse OPSWAT , bursierii noștri au efectuat o analiză tehnică aprofundată pentru a înțelege mai bine cauza principală, calea de exploatare și strategiile de atenuare din jurul acestei probleme de mare gravitate.

1. Fiecare configurație este analizată și transmisă către generateTemplate pentru a fi formatată în conformitate cu modelele NGINX predefinite.
2. Ulterior, testTemplate validează configurația generată față de binarul NGINX de bază.

Toate configurațiile NGINX se bazează pe șabloane predefinite găsite în fișierul nginx.tmpl din codul sursă ingress-nginx:

În cadrul funcției generateTemplate, configurația este procesată după cum se arată în următorul fragment de cod:

Cu toate acestea, validarea și igienizarea intrărilor sunt insuficiente. Concret, câmpul uid dintr-un obiect de intrare este introdus direct în șablonul de configurare NGINX, creând un punct de injectare. Un atacator poate exploata acest lucru prin furnizarea de date de intrare modificate, cum ar fi uid="1234#;\n\n\n}\n}\n}\n injection_value".

Această intrare malițioasă permite injectarea domeniului de aplicare global în șablonul NGINX, permițând atacatorilor să declanșeze directive NGINX arbitrare și să obțină potențial RCE.

Pentru a exploata vulnerabilitatea, un atacator trebuie să identifice o directivă capabilă să execute un cod malițios. Inițial, colegii noștri au identificat directiva load_module ca fiind potențial utilă, deoarece această directivă permite NGINX să încarce pluginuri externe. Cu toate acestea, această directivă este permisă numai în faza inițială a analizei configurației, ceea ce nu corespunde punctului nostru de injectare.

Pentru a rezolva această provocare, am continuat cercetările, care au condus la directiva ssl_engine, descrisă ca "Modulul poate fi încărcat dinamic de OpenSSL în timpul testării configurației". Acest lucru a stârnit curiozitate datorită capacității sale de a încărca dinamic module, necesitând o examinare mai aprofundată.

La pornire, NGINX își încarcă starea inițială, apoi analizează fișierele de configurare linie cu linie. Fiecare directivă este gestionată de structura nginx_command_t, directiva ssl_engine invocând direct ngx_openssl_commands.

Analizând funcția ngx_openssl_commands, colegii noștri au descoperit că aceasta se bazează pe suportul OpenSSL, în special pe funcția ENGINE_by_id care este utilizată pentru modulele SSL accelerate hardware.

Analizând funcția ENGINE_by_id, am constatat că aceasta permite încărcarea dinamică a bibliotecilor partajate. În plus, dacă biblioteca este compilată cu extensia __attribute__((constructor)), funcția asociată poate fi executată imediat după încărcare. Acest lucru indică faptul că, prin exploatarea directivei ssl_engine, un atacator ar putea încărca biblioteci partajate arbitrare pe gazdă, putând duce la RCE.

În mod implicit, atunci când o cerere primită depășește 8KB, NGINX scrie corpul cererii într-un fișier temporar situat la /tmp/nginx/client-body, folosind un nume de fișier în formatul cfg-{random_value}. Aceste fișiere temporare sunt păstrate timp de până la 60 de secunde între bucățile de succes ale unui mesaj primit.

După scrierea unui corp parțial al cererii într-un fișier temporar, NGINX amână ștergerea până la primirea întregului corp. Dacă solicitarea rămâne incompletă și nu se primesc date timp de 60 de secunde, fișierul este în cele din urmă șters. Cu toate acestea, prin reținerea intenționată a ultimei bucăți de date, un atacator poate menține fișierul temporar în uz, făcându-l exploatabil.

Deși conținutul fișierului încărcat poate fi controlat, localizarea acestuia pe sistemul de fișiere este dificilă din cauza numelui de fișier aleatoriu. Calea de stocare poate fi configurată utilizând client_body_temp_path, dar numele fișierului este generat aleatoriu în timpul execuției, ceea ce îl face imprevizibil. Această aleatorizare împiedică în mod semnificativ accesul direcționat chiar și prin forța brută. Pentru a depăși acest lucru, echipa a valorificat comportamentele inerente sistemului de operare Linux. Luați în considerare următorul exemplu:

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

După compilare, dimensiunea bibliotecii partajate rezultate a depășit cu ușurință 8KB, permițându-i să fie tamponată de NGINX fără a fi nevoie de umplutură suplimentară.

Colegii noștri au creat apoi o cerere cu o valoare Content-Length umflată (de exemplu, 1MB) pentru a introduce o neconcordanță de dimensiune. Acest lucru a determinat NGINX să stocheze întregul corp al cererii în loc să îl proceseze imediat, asigurându-se că obiectul partajat va fi scris într-o locație previzibilă.

O RCE reușită necesită ca directiva ssl_engine să facă trimitere la calea corectă către fișierul tamponat. Acest lucru poate fi realizat prin intermediul unui script automatizat de forță brută care trece sistematic peste combinațiile posibile de ID-uri de proces și descriptori de fișier pentru a identifica legătura simbolică validă care indică obiectul partajat tamponat.

Mai jos este prezentat un exemplu de șablon NGINX generat care a declanșat exploatarea.

La exploatarea cu succes, atacatorul putea obține acces la shell în contextul podului ingress-nginx, care în mod implicit avea acces la secrete sensibile ale clusterului Kubernetes.