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.
Prezentare generală a CVE-2025-1974
CVE-2025-1974 este o vulnerabilitate critică de injectare a șablonului identificată în versiunile ingress-nginx până la 1.11.4 și în special 1.12.0. Atacatorii cu acces la nivel de nod la un cluster Kubernetes pot exploata această deficiență pentru a executa cod arbitrar utilizând RCE prin intermediul controlerului ingress-nginx care, în mod implicit, are privilegii extinse, inclusiv acces la secrete critice din cadrul clusterului.
Kubernetes Security Response Committee a atribuit acestei vulnerabilități un scor CVSS v3.1 de 9.8 (gravitate critică):
Componente cheie în această analiză
Prezentare generală Kubernetes
Kubernetes (K8s) este o platformă open-source pentru automatizarea implementării, scalării și gestionării operaționale a aplicațiilor containerizate. Clusterele Kubernetes constau de obicei din mai multe mașini, care pot include atât hardware fizic, cât și mașini virtuale, care lucrează împreună pentru a oferi medii de aplicații foarte disponibile, scalabile și gestionabile.
Controler de intrare NGINX
Controlerul de intrare NGINX (ingress-nginx) este un controler de intrare open-source construit pe serverul web NGINX. Acesta funcționează în cadrul unui cluster Kubernetes, funcționând în principal ca un proxy invers și un distribuitor de sarcină. Acest controler interpretează resursele Ingress definite de utilizatori și le transformă în configurații NGINX acționabile pentru a direcționa fluxul de trafic în și în cadrul clusterului.
Evaluarea admiterii și rolul său
Ingress-nginx se integrează cu Kubernetes utilizând un serviciu webhook numit AdmissionReview. Acest serviciu este esențial pentru procesarea obiectelor native Kubernetes Ingress și traducerea lor în configurații NGINX validate și corecte din punct de vedere sintactic. Deși AdmissionReview asigură acuratețea configurației, acesta funcționează independent de controlerul ingress-nginx și, în general, nu dispune de controale stricte de autentificare. Această lipsă de autentificare strictă este un factor-cheie care a contribuit la exploatabilitatea CVE-2025-1974.
Exploatarea vulnerabilităților și analiza tehnică
Mecanism de exploatare
În esența sa, exploatarea CVE-2025-1974 începe cu o cerere rău intenționată. Atacatorii elaborează o cerere rău intenționată către webhook-ul AdmissionReview, forțând NGINX să încarce dinamic o bibliotecă partajată în timpul execuției. Pe baza acestui mecanism, colegii noștri au analizat atât webhook-ul AdmissionReview, cât și fluxul de lucru NGINX pentru a înțelege această cale de exploatare.
Vulnerabilitate de injectare a șabloanelor
În cadrul webhook-ului AdmissionReview, la procesarea cererilor primite, funcția CheckIngress transformă obiectele Ingress din Kubernetes în fișiere de configurare NGINX valide. Fluxul se desfășoară după cum urmează:
- Fiecare configurație este analizată și transmisă către `generateTemplate` pentru a fi formatată conform șabloanelor NGINX predefinite.
- Ulterior, testTemplate validează configurația generată în raport cu fișierul binar NGINX aferent.
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ă așa cum se arată în următorul fragment de cod:
Cu toate acestea, validarea și curățarea datelor de intrare sunt insuficiente. Mai exact, câmpul „uid” dintr-un obiect Ingress este inserat direct în șablonul de configurare NGINX, creând astfel un punct de injectare. Un atacator poate exploata această vulnerabilitate furnizând date de intrare special create, cum ar fi „uid="1234#;\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.
De la injectarea de șabloane la execuția de cod de la distanță
Explicarea funcției testTemplate()
După ce configurația NGINX este generată de funcția `generateTemplate`, funcția `testTemplate` creează un fișier de configurație temporar și execută biblioteca NGINX cu comanda `nginx -c {config_file} -t`. Aceasta obligă binarul NGINX să analizeze și să valideze configurația.
Pentru a exploata vulnerabilitatea, un atacator trebuie să identifice o directivă capabilă să execute cod rău intenționat. 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ă doar în faza inițială a analizării configurației, ceea ce nu corespunde punctului nostru de injectare.
Pentru a rezolva această provocare, am continuat cercetările, ceea ce a dus la descoperirea directivei ssl_engine, descrisă astfel: „Modulul poate fi încărcat dinamic de OpenSSL în timpul testării configurației.” Acest lucru ne-a stârnit curiozitatea datorită capacității sale de a încărca module în mod dinamic, ceea ce a necesitat o analiză mai aprofundată.
Înțelegerea directivei ssl_engine
Pentru a înțelege mai bine modul în care NGINX gestionează directiva `ssl_engine`, precum și pentru a stabili condițiile în care NGINX permite încărcarea dinamică a unor module suplimentare prin intermediul acestei directive, am analizat codul sursă al NGINX.
La pornire, NGINX încarcă starea inițială, apoi analizează fișierele de configurare rând cu rând. Fiecare directivă este gestionată de structura nginx_command_tstructure, directiva ssl_engine apelând direct ngx_openssl_commands.
În urma analizei funcției `ngx_openssl_commands`, colegii noștri au descoperit că aceasta se bazează pe suportul OpenSSL, mai exact pe funcția `ENGINE_by_id`, care este utilizată pentru modulele SSL cu accelerare hardware.
În urma analizei funcției ENGINE_by_id, am constatat că aceasta permite încărcarea dinamică a bibliotecilor partajate. Mai mult, 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ă, ceea ce ar putea duce la executarea de cod la distanță (RCE).
Direcționarea bibliotecilor partajate și strategia de atac
Pentru a facilita în mod fiabil executarea codului, următorul pas implică identificarea unei biblioteci partajate. În loc să se bazeze pe biblioteci externe, o abordare mai viabilă și mai controlată reiese din propriul comportament al NGINX: mecanismul de tamponare a corpului clientului. Această caracteristică permite NGINX să descarce solicitările mari primite în fișiere temporare, deschizând oportunități de exploatare bazate pe comportamentul previzibil de gestionare a fișierelor.
Î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 în sistemul de fișiere este dificilă din cauza numelui de fișier aleatoriu. Calea de stocare poate fi configurată folosind client_body_temp_path, dar numele fișierului este generat aleatoriu în timpul rulării, ceea ce îl face imprevizibil. Această aleatorietate îngreunează semnificativ accesul țintit, chiar și prin metoda forței brute. Pentru a depăși această problemă, echipa a valorificat comportamentele inerente sistemului de operare Linux. Să luăm î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).
Simularea exploatării
Pe baza analizei de mai sus, o abordare practică de exploatare pentru RCE în cadrul podului Ingress-NGINX este:
- Încărcați o bibliotecă partajată malițioasă utilizând mecanismul de tamponare a corpului clientului NGINX pentru a o stoca temporar pe sistemul de fișiere.
- Utilizați injectarea șablonului pentru a iniția o încercare de forță brută care forțează NGINX să încarce biblioteca partajată încărcată anterior prin directive vulnerabile.
Crearea încărcăturii utile care conține biblioteca partajată
Pentru a asigura executarea codului la încărcare, în cadrul bibliotecii partajate malițioase este definită o funcție de punct de intrare cu extensie de constructor. Această funcție este executată la încărcare de NGINX și este concepută pentru a stabili o conexiune reverse shell la o gazdă la distanță.
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 solicitare cu o valoare exagerată a parametrului „Content-Length” (de exemplu, 1 MB) pentru a provoca o neconcordanță de dimensiune. Acest lucru a determinat NGINX să stocheze în buffer întregul corp al mesajului, în loc să îl proceseze imediat, asigurându-se astfel că obiectul partajat va fi scris într-o locație previzibilă.
Declanșarea bibliotecii partajate prin injectare
Odată ce biblioteca partajată a fost configurată, am introdus apoi o directivă rău intenționată în configurația NGINX, folosind câmpul vulnerabil „uidfield”. Această directivă includea „ssl_engine”, care indica calea către fișierul stocat în buffer:
Pentru ca RCE să aibă succes, este necesar ca directiva `ssl_engine` să facă referire la calea corectă către fișierul stocat în buffer. Acest lucru se poate realiza printr-un script automat de tip „brute force” care parcurge sistematic toate combinațiile posibile de ID-uri de proces și descriptori de fișiere pentru a identifica legătura simbolică validă care indică spre obiectul partajat stocat în buffer.
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.
Mitigare și remediere
Pentru a reduce în mod eficient riscurile asociate cu CVE-2025-1974, organizațiile au nevoie de o soluție care să ofere vizibilitate și control asupra componentelor open-source.
OPSWAT SBOM, o tehnologie fundamentală din cadrul platformei MetaDefender®, răspunde acestei nevoi prin furnizarea unui inventar al tuturor componentelor software, bibliotecilor, containerelor Docker și dependențelor în uz. Aceasta permite organizațiilor să urmărească, să securizeze și să își actualizeze proactiv componentele.
În exemplul de mai sus, tehnologia SBOM din MetaDefender Core™ a scanat pachetul nginx-ingress-controller care conținea vulnerabilitatea CVE-2025-1974. Sistemul a marcat automat problema ca fiind critică și a oferit îndrumări cu privire la versiunile corectate disponibile, permițând echipelor să prioritizeze rapid și să remedieze vulnerabilitatea înainte ca aceasta să poată fi exploatată.
OPSWAT SBOM este disponibil în MetaDefender Core și MetaDefender Software Supply Chain™, permițând echipelor de securitate să identifice și să acționeze mai rapid asupra vulnerabilităților. Cu OPSWAT SBOM, echipele de securitate pot:
- Localizarea rapidă a componentelor vulnerabile - Identificați imediat componentele open-source afectate de atacurile de deserializare. Acest lucru asigură o acțiune rapidă de remediere sau înlocuire a bibliotecilor vulnerabile.
- Asigurați patch-uri și actualizări proactive - Monitorizați continuu componentele open-source prin intermediul OPSWAT SBOM pentru a rămâne în fața vulnerabilităților de deserializare. OPSWAT SBOM poate detecta componente învechite sau nesigure, permițând actualizări în timp util și reducerea expunerii la atacuri.
- Mențineți conformitatea și raportarea - OPSWAT SBOM ajută organizațiile să îndeplinească cerințele de conformitate, deoarece cadrele de reglementare impun tot mai mult transparența în lanțurile de aprovizionare cu software.
