– Articol scris de Radu Ailenei, CTO Fort.
Pe 22 septembrie, WordPress a publicat un update de securitate pentru o vulnerabilitate critică în core, adică în codul de bază al platformei. Problema atinge aproape toate versiunile lansate în ultimii nouă ani, iar primele tentative de exploatare au apărut la doar câteva ore după publicare.
Vestea bună este că fix-ul există pentru fiecare versiune afectată și se aplică repede. Așa că, dacă organizația ta folosește WordPress, întrebarea de azi nu mai este dacă trebuie făcut update-ul, ci dacă patch-ul a ajuns cu adevărat pe fiecare site, inclusiv pe cele de care nu-și mai amintește nimeni.
Ce s-a întâmplat
Ori de câte ori cineva deschide o pagină, WordPress trebuie să aleagă din temă fișierul care va servi drept template pentru afișare. Alegerea o face funcția get_page_template(): ea construiește o listă de nume de fișiere candidate, iar unul dintre ele este derivat direct din adresa cerută de vizitator.
Aici apare problema. Așa cum arată advisory-ul GHSA-7hp8-65ch-5whp, această valoare nu era validată corect: o secvență de tip ../ codificată de două ori trecea nestingherită de filtrele inițiale și era decodată abia în momentul în care WordPress căuta fișierul. Rezultatul este un path traversal. Atacatorul iese din directorul temei și poate face WordPress să includă un fișier .php local ales de el, aflat oriunde pe server, cu singura condiție ca fișierul să poată fi citit.
Iar în PHP, a include un fișier înseamnă a-l executa. Dacă pe server există un fișier care poate fi folosit în acest scop, atacatorul ajunge la remote code execution (RCE), adică își rulează propriul cod pe server, cu drepturile aplicației.
Tradus în practică: control asupra site-ului. Și pentru toate acestea nu are nevoie nici de un cont, nici ca cineva din organizație să dea click pe ceva.
Cât de gravă este, de fapt
Pe hârtie, vulnerabilitatea este cât se poate de serioasă: are un scor CVSS 4.0 de 9.2 (Critical) și este clasificată CWE-98. Sunt afectate versiunile 4.7 până la 7.1.1. Fix-ul a venit în 7.1.2 și a fost portat înapoi pe toate branch-urile, până la 4.7 (7.0.6, 6.9.9, 6.8.10 … 4.7.37).
Concret, nu aveți nevoie de un upgrade major, care prezintă riscul de a strica compatibilitatea cu tema sau cu plugin-urile. Este suficient patch-ul pe versiunea pe care o folosiți deja.
Totuși, un scor mare nu înseamnă că orice site vulnerabil poate fi preluat. Exploatarea depinde de două condiții.
Prima ține de temă: tema activă sau tema părinte trebuie să aibă, direct în rădăcina ei, un director al cărui nume începe cu page-, de exemplu page-templates, un nume destul de des întâlnit.
A doua ține de server, unde trebuie să existe un fișier PHP pe care atacatorul îl poate folosi ca să-și scrie și să-și ruleze propriul cod. În demonstrația publică, rolul acesta l-a jucat pearcmd.php, o componentă a managerului de pachete PEAR, pe un server cu setarea PHP register_argc_argv activată. O astfel de configurație apare, de exemplu, în imaginea Docker oficială de PHP și în unele instalări cPanel cu versiuni PHP mai vechi.
Niciuna dintre aceste condiții nu ține de autentificare, așa că, acolo unde sunt îndeplinite, atacul poate veni de oriunde de pe internet. Mai mult, ca să afli dacă un anumit site le îndeplinește, ai nevoie de o analiză pe fiecare instanță în parte, iar analiza durează mai mult decât patch-ul însuși.
De aceea recomandăm ca patch-ul să fie tratat ca prioritate maximă, fără să așteptați o evaluare detaliată a expunerii.
Ce s-a schimbat de la publicare
În primele ore, Patchstack a observat doar request-uri de recunoaștere, prin care atacatorii testau dacă pot include fișiere core inofensive. Încă din aceeași zi au apărut însă și tentative de a scrie fișiere PHP pe server prin pearcmd.php, iar a doua zi traficul malițios a crescut de peste zece ori.
Payload-urile folosite corespund exact modificărilor din patch, semn că atacatorii au pornit chiar de la codul corectat. Între timp, există deja un PoC public și template-uri de scanare automată pentru acest CVE.
Asta nu înseamnă automat compromiteri pe scară largă. Auto-update-ul este activ implicit în WordPress, iar unii analiști estimează că vom vedea multe tentative și relativ puține compromiteri reale.
Riscul se adună acolo unde update-ul nu ajunge singur: în organizațiile cu procese stricte de change management, unde un patch așteaptă aprobări, și în site-urile uitate, cum sunt microsite-urile de campanie vechi, site-urile preluate odată cu alte companii sau paginile construite de agenții.
Ce recomandăm
Patch și verificare. Aplicați update-ul pe branch-ul folosit, apoi verificați versiunea efectiv instalată pe fiecare instanță. Faptul că auto-update-ul este activat nu garantează că update-ul s-a și aplicat: poate fi dezactivat de furnizorul de hosting, de un plugin sau de o politică internă și poate eșua fără ca nimeni să observe.
Inventar complet. Lista trebuie să cuprindă tot ce rulează WordPress și este accesibil din internet, inclusiv mediile de staging (copiile de test ale site-urilor) expuse public, site-urile de campanie și instanțele administrate de terți. Din experiență, tocmai acestea rămân cel mai des fără patch.
Monitorizare până la finalizarea patch-ului. Cât timp mai există instanțe neactualizate, merită un strat suplimentar de detecție. Verificați mai întâi dacă furnizorul de WAF (Web Application Firewall, filtrul care analizează request-urile înainte să ajungă la site) a publicat reguli dedicate.
Pe lângă acestea, configurați în WAF și în SIEM, sistemul care centralizează alertele de securitate, reguli pentru request-urile către WordPress care conțin secvențe de traversare, inclusiv variante encodate, în special în parametrul pagename, precum și pentru orice request care conține pearcmd.
Pentru că detaliile de exploatare sunt acum publice, aceste reguli pot fi destul de precise, dar rămân o măsură temporară.
Pe server, adăugați alerte pentru procesele de sistem pornite de PHP-FPM sau de web server (shell, curl, wget) și pentru fișierele PHP noi sau modificate în instalare.
Hardening. Restrângeți locurile în care user-ul web server-ului poate scrie fișiere și verificați că niciun plugin nu permite upload de fișiere .php. Configurați open_basedir, astfel încât PHP să poată accesa doar directorul aplicației.
Dacă register_argc_argv nu este necesar, dezactivați-l, iar dacă PEAR nu este folosit pe serverele web, eliminați-l. Măsurile acestea nu înlocuiesc patch-ul, dar reduc șansele ca un file inclusion să se transforme în RCE.
Compromise assessment. Pentru instanțele care nu au fost actualizate imediat, patch-ul aplicat acum nu mai este suficient: trebuie verificat și dacă site-ul a fost deja compromis.
Recomandăm verificarea integrității fișierelor (de exemplu cu wp core verify-checksums, plus plugin-uri și teme) și analiza access log-urilor, adică a jurnalelor cu toate request-urile primite de server, pe intervalul de expunere.
Exploatarea poate include un fișier existent fără să scrie nimic pe disk, așa că log-urile pot fi singura sursă de dovezi. Dacă găsiți fișiere .php neașteptate în /tmp sau /var/tmp, tratați serverul ca fiind compromis, nu doar scanat.
Dacă nu ești tehnic: ce poți face tu
Nu trebuie să aplici tu patch-ul, dar poți afla repede dacă subiectul te privește.
Cel mai simplu este să întrebi echipa IT, echipa de marketing sau agenția care a construit site-ul. Poți verifica și singur, în două feluri: deschide site-ul în browser, alege „View page source” din meniul de click dreapta și caută textul wp-content, sau adaugă /wp-admin la finalul adresei.
Dacă apare o pagină de login WordPress, ai răspunsul. De obicei, informația se găsește și în contractul cu agenția sau cu furnizorul de hosting.
Dacă răspunsul este da, câteva întrebări puse azi colegilor sau furnizorului acoperă aproape tot ce contează:
• Câte instanțe WordPress avem, inclusiv medii de staging, site-uri de campanie și site-uri ale unor firme preluate?
• Pe ce versiune rulează fiecare acum? Răspunsul corect este 7.1.2 sau versiunea cu fix de pe branch-ul respectiv.
• Cine răspunde de patch management: noi, agenția sau furnizorul de hosting?
• Când s-a aplicat patch-ul și putem primi o confirmare scrisă?
• Dacă patch-ul nu s-a aplicat imediat, a făcut cineva un compromise assessment?
Păstrează confirmarea primită. Un e-mail cu versiunea și data aplicării este suficient și, așa cum explicăm mai jos, poate conta la un audit.
Din perspectiva NIS2 și DORA
NIS2 include gestionarea vulnerabilităților printre măsurile obligatorii de gestionare a riscurilor, pentru sistemele folosite în operațiuni și în furnizarea serviciilor. În practică, un site public compromis, chiar și unul considerat non-critic, poate deveni punct de intrare în organizație sau îi poate afecta reputația.
Pentru entitățile financiare, cerințele merg mai în detaliu. DORA, aplicabil din ianuarie 2025, cere un inventar al activelor ICT, politici documentate de patch management și mecanisme de detecție a activităților anormale, iar RTS-ul privind cadrul de gestionare a riscurilor ICT detaliază aceste cerințe pentru vulnerability și patch management.
Recomandările de mai sus se suprapun direct pe aceste obligații. Un aspect adesea ignorat este riscul ICT al furnizorilor terți: multe site-uri WordPress sunt găzduite sau administrate de agenții și furnizori externi, dar sub DORA responsabilitatea rămâne la entitatea financiară, care trebuie să poată demonstra că furnizorul a aplicat patch-ul.
În ambele cadre, viteza cu care identifici sistemele afectate și calitatea documentării remedierii cântăresc la fel de mult ca patch-ul în sine. La un audit nu este suficient să spui că problema s-a rezolvat. Trebuie să poți arăta când și cum.
Mulțumiri lui Robert Ressl pentru descoperirea și raportarea responsabilă a vulnerabilității, și echipei WordPress pentru fix și pentru backport-urile pe toate branch-urile, până la 4.7.
