WordPress login XSS u rregullua pas zinxhirit të ekzekutimit të kodit PHP

Një dobësi XSS në loginin e WordPress që nuk kërkon llogari, fjalëkalim ose privilegj për t'u aktivizuar është rregulluar në WordPress 7.0.3, pasi studiuesit në pwn.ai treguan se bug-u mund të zinxhirohet në ekzekutim kodi PHP në server. Dobësia gjurmohet si CVE-2026-64638 dhe ka një vlerësim CVSS prej 8.9, duke e vendosur në intervalin e rrezikshmërisë së lartë. Rregullimi u publikua më 6 gusht dhe është bartur prapa përmes degës 4.7 të sistemit të menaxhimit të përmbajtjes, kështu që rregullimi arrin faqet që ekzekutojnë versione aq të vjetra sa ajo degë. Versionet më të vjetra se 4.7 mbeten të prekura, por bien jashtë intervalit aktual të bartjes prapa të projektit.

Cross-site scripting, zakonisht i shkurtuar si XSS, nënkupton bërjen e JavaScript-it të një sulmuesi të ekzekutohet brenda shfletuesit të dikujt tjetër ndërsa ai person viziton një faqe interneti. Quhet i reflektuar kur inputi keqdashës dërgohet në një kërkesë dhe më pas kthehet në faqen që viktima ngarkon. Këtu dobësia ndodhet në ekranin e login-it të WordPress dhe, sipas pwn.ai, që e zbuloi dhe ndau detaje teknike me The Hacker News, nuk kërkohet autentikim. Një emër përdoruesi i ndërtuar me kujdes i dërguar në faqen e login-it përfundon në faqen e gabimit të login-it të dështuar, dhe JavaScript-i që rezulton ekzekutohet në shfletuesin e vizitorit. Ajo faqe nuk kërkon ndërveprim të mëtejshëm nga viktima: mjafton vizita.

Shndërrimi i atij injektimi skripti në kod që ekzekutohet në server është një rrugë shumë më e gjatë. Kërkon një viktimë që është tashmë e identifikuar si Administrator dhe që ndërvepron me një faqe që sulmuesi kontrollon. Në demonstrimin e pwn.ai, ai ndërveprim ishte një klikim i zakonshëm, pikërisht lloji i hapit që inxhinieria sociale synon të prodhojë. Studiuesit i thanë The Hacker News se sulmi funksionon kundër instalimeve standarde të WordPress dhe nuk kërkon cilësime të pazakonta hostimi ose vendosjeje, dhe se ata kanë rrugë të shumta nga XSS në ekzekutim kodi, duke përfshirë variante që instalojnë një plugin ose ngarkojnë një arkivë ZIP arbitrare.

Këshilla e vetë WordPress merr një qëndrim më të kujdesshëm për shfrytëzueshmërinë. Ajo vëren se përshkallëzimi në ekzekutim kodi në distancë, që nënkupton aftësinë për të ekzekutuar komanda në server, përfshin kushte jashtë kontrollit të sulmuesit dhe kërkon inxhinieri sociale të suksesshme plus ndërveprim të qartë nga viktima. Dy pozicionet nuk janë kontradiktore. Injeksioni i skriptit në vetvete nuk kërkon asgjë nga objektivi, ndërsa kërcimi në ekzekutim kodi varet nga mashtrimi i një administratori të identifikuar për të klikuar.

pwn.ai e gjurmon dobësinë te mënyra se si WordPress trajton emrin e përdoruesit nga një përpjekje e dështuar për login. Vlera kalon përmes sanitize_user() dhe wp_strip_all_tags(), e dyta prej të cilave mbështetet në funksionin strip_tags() të PHP. Një varg i ngjashëm me etiketë që përmban hapësirë pas kllapës së hapjes mund t'i mbijetojë atij parseri dhe të trajtohet si tekst i zakonshëm. Më vonë, WordPress e kalon të njëjtën vlerë përmes wp_kses_post(), një funksion që filtron përmbajtjen kundrejt një liste HTML të lejuar, dhe ky parser i veçantë e lexon të njëjtin input si HTML të lejuar. Dy parserët nuk pajtohen për të njëjtat karaktere, dhe rezultati është elementë DOM të gjallë të kontrolluar nga sulmuesi në faqen e login-it të dështuar. Elementët DOM janë pjesët që një shfletues monton në një faqe, kështu që sulmuesi në mënyrë efektive ka vendosur pjesët e veta në faqen që WordPress po shfaq.

Këta elementë më pas ndërveprojnë me user-profile.js të vetë WordPress, një skript për menaxhimin e profilit që ngarkohet gjithashtu në faqen e login-it, sepse ajo faqe trajton rivendosjen e fjalëkalimit. Disa nga elementët e profilit që skripti pret mungojnë atje. Dy inpute që mungojnë zgjidhen të dy si undefined, gjë që lejon që një kontroll barazie të kalojë, dhe ndryshorja ajaxurl, ndryshe undefined, adresa që skripti përdor për të komunikuar me faqen, mund të mbishkruhet me një element DOM të injektuar. Efekti është të drejtohet JavaScript-i i vetë WordPress drejt një kërkese REST me të njëjtin origjinë të zgjedhur nga sulmuesi, ku me të njëjtin origjinë do të thotë që kërkesa duket se vjen nga vetë faqja. Studiuesit përdorin mbështetjen JSONP të REST-it të WordPress për ta kthyer atë kërkesë në JavaScript që ekzekutohet në origjinën e faqes. Për vendosjet ku kërkesat anonime REST kthejnë HTTP 401, kodi i përgjigjes së paautorizuar, parametri _envelope=1 mund ta mbështjellë mohimin në një përgjigje të jashtme HTTP 200, gjë që lejon jQuery, bibliotekën JavaScript të përfshirë, të vazhdojë ta përpunojë si skript. Studiuesit gjithashtu zbuluan në testimin e tyre se një Content Security Policy e bazuar në nonce që përdor strict-dynamic nuk bllokoi rrugën që ata demonstruan. Një Content Security Policy është një listë rregullash që një faqe dërgon në shfletues duke thënë se cilat skripte mund të ekzekutohen, dhe një nonce është një kod një-herësh që shënon një skript si të besuar.

Një rrugë e demonstruar nga pwn.ai përdor XSS-in në origjinën e WordPress për të thirrur kontrollin nativ të miratimit të Application Password brenda një sesioni të identifikuar Administratori. Application Passwords janë kredenciale të revokueshme të destinuara për akses API, kështu që kjo rrugë nuk ka nevojë që fjalëkalimi kryesor i administratorit të vidhet. WordPress më pas krijon një kredencial API dhe e ridrejton në një success_url HTTPS të zgjedhur nga sulmuesi. Studiuesit përdorën atë kredencial për akses REST të autentikuar për të publikuar një faqe WordPress që përmban JavaScript me të njëjtën origjinë. Kur sesioni i mbajtur i administratorit hapi atë faqe, skripti i saj mori nonce-in e ngarkimit të plugin-it të WordPress dhe ngarkoi një arkivë ZIP të furnizuar nga sulmuesi. PHP më pas mund të kërkohej drejtpërdrejt nga plugin-i i nxjerrë, dhe plugin-i nuk kishte nevojë të aktivizohej. Kjo fazë ndërtohet mbi kërkimin e Paulos Yibelo të vitit 2022 mbi Same Origin Method Execution, një teknikë që përdor një zinxhir të lejuar të vetive JSONP për të thirrur një metodë në një dritare tjetër të shfletuesit.

Studiuesit e quajnë zinxhirin e sulmit XSS2Shell. Ata thonë se sistemi i tyre autonom zbuloi dhe riprodhoi zinxhirin e dobësisë pasi iu dha kërkimi SOME i Yibelo të vitit 2022 si pikënisje, se puna zgjati pothuajse katër ditë duke përdorur modele me burim të hapur dhe një rrjedhë pune me shumë agjentë, dhe se zinxhiri u riprodhua më 26 korrik dhe u raportua në WordPress të nesërmen. Ka rëndësi se ku u provua çdo hallkë. Provat e prodhimit të furnizuara The Hacker News ndalen te XSS. Studiuesit riprodhuar veçmas XSS-in e faqes së login-it pa cookie kundër dy vendosjeve WordPress 7.0.2 në profile të reja Chrome pa cookie ose kredenciale WordPress. Ata nuk u përpoqën të krijonin Application Password, të ngarkonin skedarë, të ruajnë qëndrueshmëri ose të ekzekutojnë PHP në ato sisteme. Zinxhiri i plotë i ekzekutimit të PHP u demonstrua veçmas në një instalim të pastër lokal WordPress 7.0.2. WordPress vlerësoi ekipin në pwn.ai për zbulimin dhe zbulimin e përgjegjshëm të dobësisë, dhe deri më 7 gusht këshilla e projektit nuk raporton shfrytëzim në natyrë.

Çfarë do të thoshte në praktikë një ekzekutim i suksesshëm i PHP? Do të ekspozonte kredencialet e bazës së të dhënave të WordPress të ruajtura në wp-config.php, do të lejonte krijimin e llogarive të përhershme administratori dhe ndryshimin e përmbajtjes, do të ekspozonte skedarë dhe sekrete të lexueshme nga punëtori PHP, dhe do të lejonte komanda të sistemit operativ me privilegjet e atij punëtori. Studiuesit thonë se masat e njohura të forcimit të WordPress nuk duhet të trajtohen si një zbutje e plotë për XSS-in themelor, dhe se aplikimi i përditësimit të sigurisë është i nevojshëm. WordPress rekomandon përditësimin menjëherë, dhe faqet që mbështesin përditësimet automatike në sfond duhet ta marrin publikimin e sigurisë vetë. Pronarët e faqeve në versione më të vjetra se 4.7 duhet të kalojnë në një publikim të mbështetur në vend që të presin, sepse nuk planifikohet asnjë bartje prapa për ta. Kontrollimi i numrit të versionit në panelin e WordPress dhe aplikimi i çdo përditësimi të disponueshëm prej andej është hapi i parë praktik.

Për lexuesit që nuk duan t'i ndjekin vetë publikimet e WordPress, AEU Hosting (albhosting.eu) është një shërbim i menaxhuar hostimi WordPress, që do të thotë se përditësimet bazë dhe siguria e faqes trajtohen si pjesë e konfigurimit, dhe faqja për secilin plan përcakton saktësisht se çfarë përfshihet.