WordPress-ի շահագործված թերության շտկումը կարող է թարմացման ժամանակ կարճ ժամանակով բացահայտել որոշ կայքեր

Ըստ Picus Security-ի հետազոտող Ումութ Բայրամի, ով հայտնաբերել է այն, որոշ WordPress կայքեր դեռ կարող են հարձակման ենթարկվել, երբ տեղադրում են ակտիվորեն շահագործվող թերության շտկումը։ Շտկումը տեղադրող թարմացումը դեռ բացում է ֆայլերը՝ օգտագործելով կայքի հին, չշտկված կոդը, ուստի ճիշտ պահին հարձակվողը կարող է կոդ գործարկել սերվերում։ Թերությունը գրանցված է CVE-2026-119977 նույնացուցիչով և ազդում է WordPress 4.7-ից մինչև 7.1.3 տարբերակների վրա։

Ինչու է կարևոր թարմացման պատուհանը

WordPress-ը շտկումը թողարկել է անցած շաբաթ՝ 7.1.4 տարբերակում, և ինչպես նաև հին ճյուղերի համար համապատասխան թարմացումներ՝ 4.7-ը ներառյալ։ CISA-ն այս շաբաթ վաղ շրջանում թերությունը ավելացրել է իր հայտնի շահագործված խոցելիությունների կատալոգում։ Միջուկի ամբողջական փաթեթով թարմացման ժամանակ WordPress-ը նոր տարբերակի պատճենը բացում է wp-content/upgrade պանակում գտնվող ժամանակավոր պանակում, ներառյալ տեղադրիչը, և վեբ սերվերը սովորաբար կարող է հասնել դրան։ Հաշիվ չունեցող հարձակվողը, եթե կարողանում է որոշել պանակի անունը և մինչև ջնջումը հասնել տեղադրիչին, կարող է կոդ գործարկել։ Շտկումը պանակի անունը պատահականացնում է, սակայն այն տեղադրող թարմացումը օգտագործում է հին կոդը։ 5.9 և ավելի նոր տարբերակներում այդ հին կոդը պանակին անուն է տալիս՝ ըստ ներբեռնված ֆայլի, ուստի անունը կարելի է կանխատեսել վերջին անգամ։ Մինչև շտկումը հարձակվողը կարող էր տեղադրիչի միջոցով ժամանակավոր պատճենի մեջ գրել նոր կարգավորման ֆայլ՝ wp-config.php, և թարմացումը հետո այդ ֆայլով կվերագրեր կայքի իրական ֆայլը. շտկման այն մասը, որը դա կանգնեցնում է, արդեն աշխատում է հենց այդ թարմացման ընթացքում, որովհետև WordPress-ը ֆայլերը տեղափոխում է նոր կոդով։ Այդ պատուհանի ընթացքում հարձակվողը կարող է ժամանակավոր պատճենը կարգավորել իր սեփական տվյալների բազայով, մուտք գործել դրա մեջ և վեբ սերվերի թույլտվություններով PHP գործարկել մինչև ջնջումը, ապա կարդալ կամ գրել կենդանի կայքի ֆայլերը։

Ով է ենթարկվում ռիսկի

Ոչ բոլոր թարմացումներն են բացահայտում տեղադրիչը։ Ամբողջական փաթեթները միշտ ներառում են այն, իսկ մասնակի փաթեթը կայքը բացահայտում է միայն այն դեպքում, եթե պարունակում է տեղադրիչի ֆայլերը։ Ավտոմատ թարմացումները օգտագործում են նույն թարմացնողը։ The Hacker News-ը ստուգել է WordPress.org-ի թարմացման ծառայությունը. ճյուղի ներսում, օրինակ՝ 7.1.3-ից 7.1.4, իսկ միայն ամբողջական փաթեթներ՝ ավելի հին ճյուղից, օրինակ՝ 7.0.7-ից 7.1.4։ 4.4-ից մինչև 5.8 տարբերակներում հին կոդը պատահական նիշեր է ավելացնում, որոնք թաքցնում են պանակի անունը, եթե այն չի արտահոսել։ 7.1.4-ը կամ ճյուղի շտկումը տեղադրելուց հետո հետագա թարմացումները օգտագործում են պատահական անուն, և ժամանակավոր պատճենի wp-config.php ֆայլը երբեք չի վերագրվում իրական ֆայլի վրա։ Բայրամը ասել է, որ մասնակի բացահայտումը կախված է նրանից, թե ինչ է պարունակում կոնկրետ փաթեթը, իսկ կայքը վերադառնում է ամբողջական փաթեթին, եթե ստուգիչ գումարները չեն համընկնում կամ վերատեղադրման ժամանակ։ Որոշիչ գործոնը այն է, թե արդյոք տեղադրված թարմացնողը արդեն շտկված է։

Ինչ պետք է անեն ադմինիստրատորները

Բայրամը խորհուրդ է տալիս թարմացումից առաջ արգելափակել վեբ հասանելիությունը wp-content/upgrade պանակի համար։ WordPress-ը պանակն օգտագործում է անմիջապես սկավառակի վրա, ուստի վեբ հասանելիության արգելափակումը չի խաթարում թարմացումները։ Nginx-ում ավելացրեք location ^~ /wp-content/upgrade/ { deny all; }։ Apache-ում ավելացրեք Require all denied պանակի բլոկում։ .htaccess-ում ավելացրեք RedirectMatch 403 ^/wp-content/upgrade/ վերագրման կանոններից վեր, բայց .htaccess մի դրեք պանակի ներսում, քանի որ հին թարմացնողը այն ջնջում է։ Հաստատեք, որ հարցումը վերադարձնում է 403։ Թարմացրեք մինչև 7.1.4 կամ ճյուղի համար շտկված թողարկում։ Վեբ արմատից դուրս ձեռքով թարմացումը ևս անվտանգ ճանապարհ է։ WP-CLI wp core update-ը փոխարինող չէ։ WordPress 4.6 և ավելի հին տարբերակները անվտանգության թարմացումներ չեն ստանում, իսկ թերությունը սկիզբ է առնում 2.7 տարբերակից, որը թողարկվել է 2008 թվականին։

Շահագործում և ստուգումներ

CISA-ն իր կատալոգում ավելացումը հիմնել է ակտիվ շահագործման ապացույցների վրա, բայց հարձակումները չի նկարագրել։ Wordfence-ը՝ WordPress-ի անվտանգության ընկերությունը, որը նշանակել է CVE նույնացուցիչը, տեսել է, որ փորձերը սկսվել են թողարկման օրը ֆայրվոլի կանոնը տեղադրելուց ինը րոպե անց, իսկ երկու ամենածանրաբեռնված աղբյուրները մոտ 14,5 ժամ փոքր խմբեր են ստուգել, ինչը, ըստ ընկերության, համապատասխանում է կայքի թարմացման պահը որսալու փորձերին։ CVE գրառման գնահատականը CVSS սանդղակով 10-ից 8,1 է, մինչդեռ WordPress-ը թերությունը գնահատում է ցածր։ Հանրային GitHub պահոցներում հայտնվել է կոդ, որը հեղինակները նկարագրում են որպես թերության շահագործման միջոց. նրանցից մեկը պնդում է, որ իր կոդն աշխատում է նաև այն կայքերում, որոնք ամբողջական փաթեթով թարմացման ժամանակ դեռ օգտագործում են կանխատեսելի պանակ։ Արդյոք այդ կոդը աշխատում է, հաստատված չէ։ Ստուգեք wp-content/upgrade պանակում անսպասելի PHP հարցումները, ոչ ոքի անծանոթ ադմինիստրատորական հաշիվները, ոչ ոքի կողմից չտեղադրված փլագինները և այնտեղ ոչ ոքի կողմից չդրված PHP ֆայլերը։

Աղբյուրներ՝ The Hacker News