Инсталирањето на поправката за ранливост во WordPress може уште еднаш да ги изложи одредени веб-страници на напади

Одредени веб-страници базирани на WordPress и понатаму можат да бидат нападнати додека ја инсталираат поправката за активно експлоатирана ранливост, предупредува Умут Бајрам (Umut Bayram), истражувач во компанијата Picus Security, кој ја открил ранливоста.

Ажурирањето што ја инсталира поправката сè уште ги распакува своите датотеки користејќи го стариот, непоправен код на веб-страницата. Тоа значи дека напаѓачот кој ќе го избере вистинскиот момент може да изврши код на серверот. Истражувачот препорачува блокирање на веб-пристапот до папката wp-content/upgrade пред да се започне со ажурирањето.

Ранливоста, означена како CVE-2026-119977, ги засега верзиите на WordPress од 4.7 до 7.1.3. За време на ажурирањето на основниот систем (core update) со користење на целосен пакет, WordPress распакува копија од новата верзија во привремена папка во рамките на wp-content/upgrade. Таа копија ги содржи и датотеките на инсталерот на WordPress, до кои веб-серверот вообичаено може да пристапи.

Напаѓач без корисничка сметка, кој може да го открие името на папката и да пристапи до инсталерот пред WordPress да ја избрише копијата, може да успее да изврши код на серверот. Американската Агенција за сајбер-безбедност и безбедност на инфраструктурата (CISA) ја додаде ранливоста во својот каталог на познати експлоатирани ранливости претходно оваа недела.

WordPress ја објави поправката минатата недела, во верзијата 7.1.4, како и во соодветните ажурирања за постарите гранки, сè до верзијата 4.7. Сите ажурирања се наведени во неговото безбедносно известување.

Поправката ѝ доделува случајно име на привремената папка. Но, ажурирањето што ја инсталира поправката ги распакува датотеките користејќи го стариот код кој веќе се наоѓа на веб-страницата, како што покажува кодот на механизмот за ажурирање на WordPress. Кај веб-страниците што користат верзија 5.9 или понова, стариот код го именува папката според преземената датотека, па нејзиното име може да се предвиди уште еден последен пат.

Пред објавувањето на поправката, напаѓачот можел да го искористи инсталерот за да запише нова конфигурациска датотека wp-config.php во привремената копија. Ажурирањето потоа би ја заменило вистинската датотека на веб-страницата со таа датотека. Делот од поправката што го спречува ова веќе функционира за време на ажурирањето со кое се инсталира поправката, бидејќи WordPress ги копира датотеките на нивните места користејќи го новиот код.

Сепак, напаѓачот кој ќе го искористи временскиот прозорец за време на ажурирањето сè уште може да ја конфигурира привремената копија на WordPress со сопствена база на податоци, да се најави во неа и да извршува PHP-код со дозволите на веб-серверот пред копијата да биде избришана, објаснува Бајрам во својата техничка анализа. На тој начин, напаѓачот може да чита или менува датотеки во активната WordPress-веб-страница.

Кои веб-страници се изложени на ризик за време на ажурирањето

Според истражувачот, не секое ажурирање овозможува пристап до инсталерот. Целосните пакети секогаш ги содржат датотеките на инсталерот. Помалите, делумни пакети, создадени за одредена почетна верзија, ја изложуваат веб-страницата на ризик само доколку ги содржат тие датотеки.

Кај веб-страниците на кои им е овозможено автоматско ажурирање во заднина, WordPress автоматски ја инсталира поправката преку истиот механизам за ажурирање и со истите чекори.

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 директно работи со оваа папка на дискот, па блокирањето на веб-пристапот не го попречува процесот на ажурирање.

1. Блокирајте ја папката преку конфигурацијата на веб-серверот. Кај Nginx, додадете ја следнава директива:location ^~ /wp-content/upgrade/ { deny all; }Кај Apache, додадете Require all denied во рамките на блокот Directory за оваа папка, во конфигурацијата на виртуелниот хост.
2. Ако можете да ја уредувате само датотеката .htaccess, додадете ја следнава директива во .htaccess датотеката во основната WordPress-папка, пред правилата за пренасочување на WordPress:RedirectMatch 403 ^/wp-content/upgrade/
3. Не поставувајте .htaccess датотека во самата папка wp-content/upgrade. Стариот механизам за ажурирање ги брише сите датотеки во таа папка пред да го распакува ажурирањето, па датотеката би била избришана токму кога е најпотребна.
4. Проверете дали блокирањето функционира. Барањето до /wp-content/upgrade/ треба да врати HTTP-статус 403 (Forbidden).
5. Ажурирајте на верзијата 7.1.4 или на соодветната верзија во која е отстранета ранливоста за вашата гранка.

Другата безбедна опција, според истражувачот, е рачно ажурирање надвор од веб-коренската папка (web root), односно папката од која веб-серверот ги доставува содржините.

Постапката вклучува правење резервна копија на датотеките и базата на податоци на веб-страницата, распакување на новата верзија во папка до која веб-серверот нема пристап, копирање на основните системски датотеки без менување на wp-config.php и wp-content, а потоа извршување на ажурирањето на базата на податоци на WordPress.

На овој начин никогаш не се создава привремен инсталер во папка до која може да пристапи веб-прелистувач.

Командата wp core update во WP-CLI не претставува алтернатива, бидејќи го користи истиот механизам за ажурирање и го распакува пакетот во истата папка.

WordPress 4.6 и постарите верзии повеќе не добиваат безбедносни ажурирања, па затоа за нив не постои поправка. Истражувачот наведува дека ранливоста постои уште од WordPress 2.7, објавен во 2008 година, и дека веб-страниците што ги користат овие верзии треба да преминат на поддржана верзија.

Напади и што треба да се провери

Додавањето на ранливоста во каталогот на CISA претходно оваа недела се засновало на докази за активна експлоатација, но агенцијата не објавила детали за нападите.

Wordfence, компанија за безбедност на WordPress која го доделила CVE-идентификаторот на ранливоста, забележала дека обидите за напади започнале само девет минути откако компанијата имплементирала правило за заштита во својот firewall, на денот на објавувањето на поправката.

Два од најактивните извори на напади продолжиле да проверуваат мали групи веб-страници во период од околу 14,5 часа. Според компанијата, ваквото однесување е во согласност со обидите да се искористи моментот кога веб-страницата го извршува ажурирањето, како што е наведено во нејзината анализа на нападите.

Ранливоста има оцена 8,1 од 10 според CVSS-скалата во нејзиниот CVE-запис. Во лабораториските тестирања на Wordfence, временскиот прозорец за напад траел само неколку секунди. Сопственото безбедносно известување на WordPress, пак, ја оценува ранливоста како нискоризична.

Код за кој неговите автори тврдат дека претставува експлоатација на оваа ранливост се појавил во јавни GitHub-репозиториуми претходно оваа недела. Во еден од нив се наведува дека кодот функционира и на веб-страници кои сè уште користат предвидливо име на папката при ажурирање со целосен пакет. Сепак, неговата функционалност сè уште не е потврдена.

За веб-страниците што останале на засегната верзија по објавувањето на поправката, Wordfence препорачува проверка за следниве знаци на компромитирање:

• Неочекувани барања до PHP-датотеки во рамките на wp-content/upgrade.
• Администраторски сметки кои не им се познати на сопствениците или администраторите на веб-страницата.
• Додатоци (plugins) кои никој не ги инсталирал.
• PHP-датотеки во wp-content/upgrade кои не биле поставени од овластени лица.

Дополнување

Бајрам на 6 ноември за The Hacker News изјавил дека тоа дали делумното ажурирање е изложено на ризик зависи од содржината на конкретниот пакет. Делумниот пакет ги содржи само датотеките што се промениле помеѓу две изданија. Ако тие не ги вклучуваат датотеките на инсталерот, привремената копија не може да функционира како WordPress-инсталација, па инсталерот никогаш не станува достапен.

Веб-страницата исто така не добива секогаш делумен пакет, дури и кога таков постои. WordPress преминува на целосен пакет доколку основните системски датотеки на веб-страницата не се совпаѓаат со официјалните контролни суми (checksums) или ако ажурирањето претставува повторна инсталација.

Клучниот фактор, според истражувачот, „не е дали пакетот е делумен или целосен, туку дали механизмот за ажурирање што веќе е инсталиран на веб-страницата е поправен“.

Извори:

• The Hacker News – Installing the Fix for an Exploited WordPress Flaw Can Expose Some Sites One Last Time The Hacker News