Na kratko: Posodobitev WordPressa ne pomaga proti ranljivosti PHP2Shell, ker napaka ni v WordPressu, ampak v PHP, programski opremi na strežniku, ki WordPress izvaja. Po Dr. Web WordPress.org zato tudi ne načrtuje lastne posodobitve. Zaščiti lahko samo posodobitev PHP na strežniku s ponovnim zagonom vseh procesov PHP. To praviloma namesti vaš ponudnik gostovanja ali upravljavec strežnika.
Povod: „Saj smo vse posodobili“
Po prvih naslovih o PHP2Shell so mnogi upravljavci storili očitno: odprli nadzorno ploščo WordPressa, kliknili „Posodobi zdaj“, vtičnike in teme pa kar zraven. Potem je vse zeleno in občutek pravi: opravljeno.
Pri tej ranljivosti občutek vara. Ni krivda WordPressa, ampak mesto, kjer je napaka. Tudi Cloudflare v svojem obvestilu opozarja, da posodobitev kode aplikacije ali vtičnikov ranljivosti ne odpravi.
Posodobitev WordPressa in ranljivost PHP: model plasti
Spletna stran WordPress je sestavljena iz več plasti, ki se gradijo ena na drugi. Vsaka plast ima lastne posodobitve in pogosto lastne odgovorne osebe:
| Plast | Primer | Kdo običajno posodablja | Ali jo PHP2Shell zadene? |
|---|---|---|---|
| Operacijski sistem | Debian, Ubuntu, AlmaLinux | ponudnik gostovanja ali skrbnik strežnika | ne, a pogosto dobavlja paket PHP |
| Spletni strežnik | Apache, Nginx, LiteSpeed | ponudnik gostovanja ali skrbnik strežnika | način delovanja vpliva na tveganje |
| Izvajalno okolje PHP | PHP-FPM, mod_php | ponudnik gostovanja ali skrbnik strežnika | da, tukaj je ranljivost |
| Jedro WordPressa | WordPress | upravljavec ali agencija | ne |
| Vtičniki in teme | WooCommerce, page builder | upravljavec ali agencija | ne |
Gumb za posodobitev v nadzorni plošči doseže samo spodnji dve vrstici. Izvajalno okolje PHP leži pod njima in je za WordPress nevidno. Kako se drugi sistemi gradijo na PHP, opisuje prispevek CMS in spletne trgovine na PHP.
Zakaj WordPress ranljivosti ne more zapreti
Lahko bi mislili, da WordPress lahko „programira okoli“. Pri PHP2Shell to ne deluje iz dveh razlogov.
Prvič, obe napaki sta v načinu, kako PHP obdeluje zahteve in nato pospravlja. To se zgodi neodvisno od tega, kateri program teče v PHP. Drugič, ekipa PHP je za Apache z mod_php prikazala exploit, ki deluje, še preden se sploh izvede koda aplikacije. WordPress, njegovi vtičniki in vsak varnostni vtičnik potem sploh ne pridejo na vrsto.
Iz istega razloga ne pomaga niti „vtičnik za utrjevanje“, ki nastavitve spreminja prek ini_set(). php.net izrecno odsvetuje, da bi prehodne ukrepe nastavljali na ta način.
In pri upravljanem WordPressu?
Pri ponudbah upravljanega WordPressa ponudnik pogosto skrbi ne le za posodobitve WordPressa, ampak tudi za strežnik pod njim. To je za PHP2Shell prednost, a ne avtomatizem. Vprašajte konkretno, ali je bila posodobitev PHP nameščena in so bili vsi procesi PHP znova zagnani. Izjava „Vaš WordPress ohranjamo aktualen“ na to vprašanje ne odgovarja.
Veliko spletnih strani, ena namestitev PHP
Agencije in podjetja z več spletnimi stranmi naj poznajo eno posebnost: na strežniku si pogosto veliko namestitev WordPressa deli isto različico PHP. Če ta ni popravljena, so prizadete vse, ne glede na to, kako dobro je vzdrževana vsaka posamezna spletna stran. Obratno posodobitev PHP zaščiti vse namestitve naenkrat, če se potem znova zaženejo vsi pripadajoči procesi PHP. Kdor vzporedno upravlja več različic PHP, mora vsako posodobiti posebej.
Zelena nadzorna plošča WordPressa o PHP2Shell ne pove nič. Odločilno je stanje popravkov PHP na strežniku in ponovni zagon vseh procesov PHP.
Različico PHP v WordPressu pravilno brati
WordPress prikazuje različico PHP: v nadzorni plošči pod Orodja, Zdravje strani, v razdelku Info pri odseku Strežnik. To je dober prvi namig, a ne dokaz.
Če tam stoji veja, kot je 8.1 ali starejša, je to jasen opozorilni znak, saj zanjo uradnih posodobitev ni več. Če tam stoji 8.2.35, 8.3.36, 8.4.27 ali 8.5.12, je nameščeno odpravljeno stanje. Če tam stoji starejša številka podprte veje, je kljub temu lahko nameščen backport. Distribucije in ponudniki gostovanja pri tem številke pogosto ne spremenijo. Jasnost prinese samo potrdilo ponudnika gostovanja ali pogled v changelog paketa. Kako to storiti, je opisano pod Preverjanje različice PHP in stanja popravkov.
Kaj naj upravljavci WordPressa storijo namesto tega
- Vprašajte ponudnika gostovanja ali upravljavca strežnika: Ali je PHP popravljen, kdaj in ali so bili vsi procesi PHP znova zagnani? Odgovor pisno.
- Preverite vejo PHP: Če spletna stran teče na 8.1 ali starejšem, načrtujte prehod na podprto vejo. Katero različico podpira vaša različica WordPressa, je v sistemskih zahtevah na wordpress.org. Preklop v meniju za stranke opisuje Sprememba različice PHP v območju za stranke pri gostovanju.
- Preglejte sledi: nove datoteke PHP v
wp-content/uploads, neznani skrbniški računi, tuji vnosi vmu-plugins. Tipična skrivališča opisuje stran WordPress in PHP2Shell. - WordPress kljub temu ohranjajte aktualen: Jedro, vtičniki in teme zapirajo druge ranljivosti. To ostane dolžnost, le druga.
- Razjasnite odgovornost: Če spletno stran vzdržuje agencija, zapišite, ali je odgovorna tudi za PHP ali samo za WordPress.
Prav zadnja točka pogosto povzroča vrzeli. Agencija vzdržuje WordPress, ponudnik gostovanja strežnik in vsak misli, da ima drugi PHP2Shell na očeh.
Kako konkretno pomaga PHP SOS?
- Razjasniti plasti: Ugotovimo, kdo je pri vaši spletni strani WordPress odgovoren za katero plast.
- Posodobiti PHP: Na lastnih ali upravljanih strežnikih namestimo posodobitev PHP in znova zaženemo vse procese.
- Preveriti WordPress: Iščemo sledi napada v datotekah, podatkovni bazi in računih.
- Dokazilo: Stanje popravkov prejmete pisno, tudi za posredovanje agenciji ali strankam.
Potek opisuje storitev popravkov PHP.
Sklep
Posodobitev WordPressa je dobro vzdrževanje, a proti PHP2Shell napačna plast. Ranljivost sedi nadstropje nižje, v PHP na strežniku. Kdor to razume, postavi pravo vprašanje na pravem mestu: Je PHP popravljen, znova zagnan in dokazan?
Pogosta vprašanja
Ali WordPress izda varnostno posodobitev proti PHP2Shell?
Po Dr. Web WordPress.org ne načrtuje posodobitve proti PHP2Shell, ker je ranljivost v interpreterju PHP na strežniku. Pomaga samo posodobitev PHP, ki jo opravi ponudnik gostovanja ali upravljavec strežnika.
Kje v WordPressu vidim različico PHP?
V nadzorni plošči pod Orodja, Zdravje strani, v razdelku Info pri odseku Strežnik. Prikazana številka pa ne pove zanesljivo, ali je popravek nameščen, ker ponudniki gostovanja popravke pogosto vgradijo kot backport brez nove številke različice.
Ali varnostni vtičnik ščiti pred PHP2Shell?
Le zelo omejeno. Vtičnik sam teče v PHP in postane aktiven šele, ko je WordPress naložen. Pri Apache z mod_php je bil po ekipi PHP exploit prikazan, še preden se sploh izvede koda aplikacije. Tam vtičnik ne more posredovati.
Ali naj WordPress kljub temu posodobim?
Da. Aktualne različice WordPressa, tem in vtičnikov zapirajo druge ranljivosti in so del dobrega vzdrževanja. Težave PHP2Shell pa ne rešijo.