
PHP2Shell kritikus PHP-hiba – érinti az Ön weboldalát?
Lekapcsolták a magyarorszag.hu-t is: mi ez a PHP2Shell, és kire tartozik?
Szerdán két kritikus PHP-hibára adtak ki javítást, és a szerdáról csütörtökre virradó éjszaka már a magyarorszag.hu is elérhetetlenné vált. Ha Ön is üzemeltet weboldalt, érdemes tíz percet szánni arra, hogy kiderítse, érinti-e a dolog.
Röviden: mi történt?
- Október 21-én, szerdán a PHP fejlesztői javítóverziókat adtak ki két súlyos sebezhetőségre, amelyeket a szakma PHP2Shell néven emleget.
- Mindkét hiba a lehető legsúlyosabb sávba esik (9,2 pont a 10-ből, CVSS v4.0), mert a támadó hitelesítés nélkül, az interneten keresztül futtathat kódot az érintett szerveren.
- Elővigyázatosságból Hollandiában, Finnországban, Dániában és Franciaországban is lekapcsoltak kormányzati oldalakat, Ausztráliában szintén. Nálunk a Nemzeti Kiberbiztonsági Intézet adott ki kritikus riasztást, a kormány pedig átmenetileg leállította a magyarorszag.hu-t és néhány további kormányzati weboldalt.
- A javítások nem települnek maguktól: az üzemeltetőknek kell feltenniük őket.
Mit jelent ez a gyakorlatban?
Képzelje el, hogy a bejárati ajtó zára nem kér kulcsot attól, aki jól nyomja le a kilincset. A támadónak nem kell jelszót kitalálnia és fiókot feltörnie: a szerver maga hajtja végre a parancsait. A név is erre utal, a támadó a szerver parancssorához juthat hozzá.
Mit lehet kezdeni egy ilyen hozzáféréssel? Adatot lehet lopni, át lehet írni az oldalt, kártevőt lehet elhelyezni rajta, vagy használhatatlanná lehet tenni. Biztonsági szakemberek szerint a hibákat támadók már ki is próbálták használni, ezért nincs idő várni a frissítéssel.
Érdekesség, hogy a Wiz biztonsági cég közlése szerint a hibákat mesterséges intelligencia segítségével találták meg, és több mint tíz éve ott lapultak a kódban.
Miért a kisvállalkozások járnak a legrosszabbul?
Egy kormányzati portálnak van biztonsági csapata, amely a hírt még aznap látja. Egy kisvállalkozás weboldalánál ez ritkán van így:
- osztott tárhelyen nem Ön kezeli a szervert, így azt sem Ön dönti el, mikor frissül a PHP,
- sok helyen senki sem tudja pontosan, melyik PHP-verzió fut, és kinek a dolga frissíteni,
- a weboldalt készítő szakember már rég másik munkán dolgozik.
A legtöbb ember itt hibázik: azt hiszi, ha a WordPress és a bővítmények naprakészek, akkor minden rendben van. A hiba viszont nem a WordPressben van, hanem a szerveren futó PHP-ban. A WordPress-frissítés tehát nem pótolja a PHP-javítást.
Tízperces ellenőrzőlista
- Írjon a tárhelyszolgáltatójának, és kérdezze meg, felkerültek-e a javított PHP-verziók az Ön szerverére. Osztott tárhelyen ez az ő dolguk, de érdemes írásban rákérdezni.
- Nézze meg a PHP-verziót. WordPressben az Eszközök → Webhely állapota → Infó → Szerver menüben látja. A javított verziók listáját a php.net oldalán találja.
- Frissítse a WordPresst, a sablont és a bővítményeket is. Ez nem védi meg a PHP-hibától, de a többi ismert rést bezárja.
- Mentsen, mielőtt bármihez nyúl: a fájlokról és az adatbázisról is.
- Figyelje a jeleket: ismeretlen adminisztrátori fiók, olyan fájl, amit nem Ön tett fel, szokatlan lassulás, váratlan átirányítás.
- Ha a javítás nem telepíthető azonnal, mérlegelje az oldal ideiglenes lekapcsolását. Az európai, ausztrál, japán és brit hatóságok is azt kérték az érintettektől, hogy vagy telepítsék a frissítést, vagy a javításig állítsák le az oldalaikat.
Ha a weboldalon személyes adatokat is kezel (például űrlapon beküldött megkereséseket), egy feltörés adatvédelmi kérdéseket is felvethet. Erről a GDPR-hibákról szóló cikkünkben is olvashat.
Hogyan lehet elkerülni a hasonló helyzeteket?
Szegedről dolgozunk, de ez a kockázat nem ismer megyehatárokat. A tanulság egyszerű: minél több réteg van egy weboldal alatt, annál több helyen romolhat el valami, és annál kevésbé Ön dönti el, mikor.
A Sun City Web ezért nem WordPressre és nem PHP-alapú tartalomkezelőre épít. Weboldalainkat egyedi, kézzel írt kóddal készítjük, sablonok nélkül. A működésükhöz nincs szükség PHP-ra, ezért nincs mit kihasználni az ilyen hibaosztályban. Ez a gyakorlatban azt jelenti:
- Nincs PHP-s tartalomkezelő, amely a szerveren futva célpont lehetne.
- Nincs bővítményrengeteg, amelynek folyamatosan frissülnie kellene, és amelynek egyike egy szép napon sebezhetővé válik.
- Nincs „azonnal frissítsünk, mert baj van" helyzet, amikor szerdán este a tárhelycégeket kell hívogatni.
- Gyors az oldal, mert kész fájlokat szolgál ki, nem építi fel az oldalt minden látogatásnál.
Őszintén hozzátesszük: ez sem jelent teljes biztonságot. A tárhelyfiók, a domain és a céges e-mail védelme itt is fontos, ezekre mi is figyelünk. De a támadási felület lényegesen kisebb, és pont az a réteg hiányzik, amelyben most a gondot találták.
A munka nálunk nem ér véget az átadással. Mi nem tűnünk el a kész weboldallal: frissítés vagy hibajavítás esetén plusz költség nélkül számíthat ránk. Ha ma még WordPress-es oldala van, megnézzük, érdemes-e váltani, és hogy mi vihető át belőle. Az árainkról itt tájékozódhat.
Gyakori kérdések
Érinti a PHP-hiba az én weboldalamat? Ha az oldala PHP-t használ (WordPress, Drupal, Joomla, PHP-alapú webáruház vagy egyedi PHP-s rendszer), akkor érintett lehet. A pontos kitettség a szerver PHP-verziójától és beállításaitól függ, ezt a tárhelyszolgáltató vagy egy szakember tudja megmondani.
Elég, ha frissítem a WordPresst? Nem. A hiba a szerveren futó PHP-ban van, nem a WordPressben. A javítást a szerveren kell telepíteni.
Miért kapcsoltak le kormányzati oldalakat? Mert a javítások kiadásakor a hibák már ismertek voltak, és nem lehetett mindenhol azonnal telepíteni őket. A lekapcsolás elővigyázatosság volt, az állampolgárok adatainak védelmében, nem feltörés következménye.
Biztonságosabb az egyedi kódú oldal, mint a WordPress? Az ilyen szerveroldali PHP-hibák szempontjából igen, ha az oldal működéséhez nincs szükség PHP-ra. Teljes biztonságot persze semmi sem ad, a tárhely- és domainfiókok védelme itt is számít.
Mit tegyek, ha nem értek hozzá? Írjon nekünk. Röviden megnézzük, mi fut most az oldalán, és megmondjuk, hol érdemes kezdeni.
Összegzés
A PHP2Shell megmutatta, hogy egy weboldal biztonsága nem csak a tulajdonos körültekintésén múlik, hanem azon a technológián is, amire az oldal épül. Ha PHP-s rendszert használ, ellenőrizze most a szerver állapotát. Ha hosszú távon nyugodtan szeretne dolgozni, érdemes olyan megoldásban gondolkodni, ahol ez a kockázat eleve nincs jelen.
Szeretné, ha megnéznénk, hol tart most a weboldala, vagy kíváncsi egy gyors, egyedi kódú megoldásra? Kérjen ingyenes konzultációt még ma, és 48 órán belül felvesszük Önnel a kapcsolatot.



