Röviden: A WordPress-frissítés nem segít a PHP2Shell PHP-rés ellen, mert a hiba nem a WordPressben van, hanem a PHP-ban, abban a szoftverben a szerveren, amely a WordPresst futtatja. A Dr. Web szerint a WordPress.org ezért saját frissítést sem tervez. Védeni csak a szerveren végzett PHP-frissítés tud az összes PHP-folyamat újraindításával. Ezt általában a tárhelyszolgáltatója vagy a szerverüzemeltetője telepíti.
A kiindulópont: „Hiszen mindent frissítettünk”
A PHP2Shellről szóló első főcímek után sok üzemeltető azt tette, ami kézenfekvő: megnyitotta a WordPress vezérlőpultját, rákattintott a „Frissítés most” gombra, a bővítményekkel és a témákkal együtt. Utána minden zöld, és az érzés azt súgja: kész.
Ennél a résnél az érzés csal. Ez nem a WordPress miatt van, hanem azért, hogy hol van a hiba. A Cloudflare is rámutat a közleményében, hogy az alkalmazáskód vagy a bővítmények frissítése nem szünteti meg a réseket.
WordPress-frissítés és PHP-rés: a rétegmodell
Egy WordPress-weboldal több, egymásra épülő rétegből áll. Minden rétegnek saját frissítései és gyakran saját felelősei vannak:
| Réteg | Példa | Ki frissíti jellemzően | Érinti a PHP2Shell? |
|---|---|---|---|
| Operációs rendszer | Debian, Ubuntu, AlmaLinux | tárhelyszolgáltató vagy szerveradmin | nem, de gyakran ez szállítja a PHP-csomagot |
| Webszerver | Apache, Nginx, LiteSpeed | tárhelyszolgáltató vagy szerveradmin | az üzemmód befolyásolja a kockázatot |
| PHP-futtatókörnyezet | PHP-FPM, mod_php | tárhelyszolgáltató vagy szerveradmin | igen, itt van a rés |
| WordPress-mag | WordPress | üzemeltető vagy ügynökség | nem |
| Bővítmények és témák | WooCommerce, page builder | üzemeltető vagy ügynökség | nem |
A vezérlőpulton lévő frissítés gomb csak a két alsó sort éri el. A PHP-futtatókörnyezet alattuk van, és a WordPress számára láthatatlan. Hogyan épülnek más rendszerek a PHP-ra, azt a CMS-ek és webshopok PHP-n írás írja le.
Miért nem tudja a WordPress bezárni a rést
Azt gondolhatná az ember, hogy a WordPress „körülprogramozhatja”. Ez a PHP2Shell esetében két okból nem működik.
Először: mindkét hiba abban rejlik, ahogyan a PHP a kéréseket feldolgozza és utána takarít. Ez attól függetlenül történik, hogy melyik program fut a PHP-ban. Másodszor: a PHP-csapat az Apache és mod_php esetében olyan exploitot mutatott be, amely azelőtt hat, hogy egyáltalán alkalmazáskód futna. A WordPress, a bővítményei és bármely biztonsági bővítmény ilyenkor egyáltalán nem kerül sorra.
Ugyanezért nem segít semmilyen „keményítő bővítmény” sem, amely beállításokat módosít ini_set()-tel. A php.net kifejezetten ellenzi, hogy az átmeneti intézkedéseket ezen az úton állítsák be.
És menedzselt WordPressnél?
Menedzselt WordPress-ajánlatoknál a szolgáltató gyakran nemcsak a WordPress-frissítésekkel, hanem az alatta lévő szerverrel is foglalkozik. Ez a PHP2Shell esetében előny, de nem automatizmus. Kérdezzen rá konkrétan, hogy a PHP-frissítést telepítették-e, és az összes PHP-folyamatot újraindították-e. A „Naprakészen tartjuk a WordPressét” kijelentés nem válaszol erre a kérdésre.
Sok weboldal, egy PHP-telepítés
Az ügynökségeknek és a több weboldallal rendelkező vállalatoknak ismerniük kell egy sajátosságot: egy szerveren gyakran sok WordPress-telepítés osztozik ugyanazon a PHP-verzión. Ha ez javítatlan, mind érintett, függetlenül attól, milyen jól gondozott az egyes weboldal. Fordítva, egy PHP-frissítés egyszerre védi az összes telepítést, feltéve hogy utána az összes hozzá tartozó PHP-folyamatot újraindítják. Aki több PHP-verziót üzemeltet párhuzamosan, mindegyiket külön kell frissítenie.
Egy zöld WordPress-vezérlőpult semmit sem mond a PHP2Shellről. A döntő a PHP javítási állapota a szerveren és az összes PHP-folyamat újraindítása.
A PHP-verzió helyes olvasása a WordPressben
A WordPress megjeleníti a PHP-verziót: a vezérlőpulton az Eszközök, Weboldal állapota alatt, a Jelentés részben a Szerver szakasznál. Ez jó első jelzés, de nem bizonyíték.
Ha ott egy 8.1-es vagy régebbi ág áll, az egyértelmű figyelmeztető jel, mert ahhoz már nincsenek hivatalos frissítések. Ha ott 8.2.35, 8.3.36, 8.4.27 vagy 8.5.12 áll, a javított állapot telepítve van. Ha egy támogatott ág régebbi száma áll ott, backport ettől még telepítve lehet. A disztribúciók és a tárhelyszolgáltatók ilyenkor gyakran nem változtatják meg a számot. Egyértelműséget csak a tárhelyszolgáltató megerősítése vagy egy pillantás a csomag changelogjába ad. Hogyan megy ez, azt a PHP-verzió és javítási állapot ellenőrzése tartalmazza.
Mit tegyenek helyette a WordPress-üzemeltetők
- Kérdezze meg a tárhelyszolgáltatót vagy a szerverüzemeltetőt: Javított-e a PHP, mikor, és újraindították-e az összes PHP-folyamatot? A válasz írásban.
- Ellenőrizze a PHP-ágat: Ha a weboldal 8.1-en vagy régebbin fut, tervezze meg az átállást egy támogatott ágra. Hogy a WordPress-verziója melyik verziót támogatja, azt a wordpress.org rendszerkövetelményei között találja. Az átállást az ügyfélmenüben a PHP-verzió módosítása a tárhely ügyfélterületén írja le.
- Nyomok ellenőrzése: új PHP-fájlok a
wp-content/uploadsmappában, ismeretlen rendszergazdai fiókok, idegen bejegyzések amu-pluginsmappában. A tipikus rejtekhelyeket a WordPress és PHP2Shell oldal írja le. - A WordPresst mégis tartsa naprakészen: A mag, a bővítmények és a témák más réseket zárnak be. Ez továbbra is kötelező, csak más.
- Tisztázza a felelősséget: Ha egy ügynökség gondozza a weboldalt, rögzítse, hogy a PHP-ért is felel-e, vagy csak a WordPressért.
Éppen az utolsó pont okoz gyakran réseket. Az ügynökség a WordPresst gondozza, a tárhelyszolgáltató a szervert, és mindenki azt hiszi, hogy a másik tartja szemmel a PHP2Shellt.
Hogyan segít konkrétan a PHP SOS?
- A rétegek tisztázása: Megállapítjuk, hogy a WordPress-weboldalánál ki melyik rétegért felel.
- A PHP frissítése: Saját vagy menedzselt szervereken telepítjük a PHP-frissítést, és újraindítunk minden folyamatot.
- A WordPress ellenőrzése: Egy támadás nyomait keressük fájlokban, adatbázisban és fiókokban.
- Igazolás: A javítási állapotot írásban megkapja, az ügynökségnek vagy az ügyfeleknek való továbbadáshoz is.
A folyamatot a PHP-javítási szolgáltatás írja le.
Összegzés
A WordPress-frissítés jó karbantartás, de a PHP2Shell ellen rossz réteg. A rés egy emelettel lejjebb van, a szerveren lévő PHP-ban. Aki ezt érti, a megfelelő kérdést teszi fel a megfelelő helyen: javított-e a PHP, újraindították-e, és igazolt-e?
Gyakori kérdések
Hoz a WordPress biztonsági frissítést a PHP2Shell ellen?
A Dr. Web szerint a WordPress.org nem tervez frissítést a PHP2Shell ellen, mert a rés a szerveren lévő PHP-értelmezőben van. Megoldást csak a tárhelyszolgáltató vagy a szerverüzemeltető által végzett PHP-frissítés hoz.
Hol látom a WordPressben a PHP-verziót?
A vezérlőpulton az Eszközök, Weboldal állapota alatt, a Jelentés részben a Szerver szakasznál. A kijelzett szám azonban nem mondja meg biztosan, hogy a javítás telepítve van-e, mert a tárhelyszolgáltatók a javításokat gyakran új verziószám nélküli backportként építik be.
Véd egy biztonsági bővítmény a PHP2Shell ellen?
Csak nagyon korlátozottan. Egy bővítmény maga is PHP-ban fut, és csak akkor lesz aktív, ha a WordPress betöltődött. Apache és mod_php esetében a PHP-csapat szerint azelőtt mutattak be egy exploitot, hogy egyáltalán alkalmazáskód futna. Ott egy bővítmény nem tud beavatkozni.
Frissítsem mégis a WordPresst?
Igen. A WordPress, a témák és a bővítmények aktuális verziói más réseket zárnak be, és a jó karbantartás részei. Csak a PHP2Shell problémáját nem oldják meg.