Miért állt le a magyarorszag.hu és sok kormányzati oldal itthon és Európában? Mi történt? Mit tehetünk?

Szerdáról csütörtökre virradó éjjel elővigyázatosságból lekapcsolták a magyarorszag.hu-t, és hasonló lépésre kényszerültek kormányok, intézmények Hollandiától Finnországig. Az ok két súlyos hiba abban a programozási nyelvben, amelyre a weboldalak többsége épül. Összeszedtük, mi történt, kit érint, és mit kell tenni.

Csütörtök hajnal óta áll a magyarorszag.hu, szünetel az ügyintézés. Tanács Zoltán tudományos és technológiai miniszter Facebook-bejegyzésében jelentette be, hogy az éjszaka során

átmenetileg leállították a portált és néhány további kormányzati weboldalt.

magyarorszag.hu

A miniszter hangsúlyozta, hogy támadásra utaló jelet nem találtak, de a hiba javításáig a portálon keresztüli ügyintézés várhatóan 48 órán át szünetel.

A kormányhivatalok tájékoztatása szerint a leállás a kormányablakos időpontfoglalást is érinti:

átmenetileg a Központi Időpontfoglaló Alkalmazás sem érhető el.

A lekapcsolás megelőző lépés, ugyanerre a döntésre jutottak sok más országban is.

Európa-szerte sötétedtek el oldalak

A Reuters összesítése szerint Hollandiában a nemzeti kiberbiztonsági központ a saját honlapját is lekapcsolta, és a példáját sokan követték: a rotterdami kikötő, az Overheid.nl kormányzati portál, a holland labdarúgó-szövetség, az öt legnagyobb párt és több kórház honlapja is elérhetetlenné vált.

Finnországban az állami informatikai szolgáltató a kormány nyilvános webes szolgáltatásait függesztette fel, Dániában az iskolák és a szülők közötti kapcsolattartásra használt országos rendszer állt le, a francia belügyminisztérium pedig összes honlapját megelőző karbantartásra kapcsolta.

A Wikipédiát működtető alapítvány szintén leállította egyes rendszereit, és rövid időre az Internet Archive is elérhetetlenné vált.

Magyarországon a Nemzeti Kiberbiztonsági Intézet (NKI) már a javítás megjelenése előtt riasztást adott ki. Azt javasolta, hogy

ahol a frissítés nem végezhető el azonnal, ott az internet felől elérhető érintett rendszereket különítsék el, vagy szükség esetén ideiglenesen függesszék fel a működésüket.

Mi az a PHP, és miért ekkora a baj?

A PHP a mai napig az internet egyik alappillére. A világ weboldalainak jelentős része PHP-re épül, köztük a legnépszerűbb tartalomkezelő rendszerek, a WordPress, a Drupal és a Joomla is. A W3Techs október 22-i mérése szerint azoknak a weboldalaknak 69,3 százaléka használja, amelyeknél a háttérben futó programnyelv megállapítható.

A PHP nem a mi számítógépünkön vagy telefonunkon fut, hanem a weboldalakat kiszolgáló szervereken: amikor megnyitunk egy hírportált vagy webáruházat, gyakran ez állítja össze másodpercek töredéke alatt a megjelenő tartalmat. A mostani két hiba nem egy-egy honlap saját programjában van, hanem magában a PHP-ban.

Ezért lehet akkor is veszélyes egy weboldal, ha a saját kódja hibátlan.

A PHP2Shell néven ismertté vált hibák egyik felfedezője, a Wiz biztonsági cég szerint egy ügyesen összeállított kéréssel a támadó jelszó nélkül, távolról saját parancsokat futtathat a szerveren, vagyis átveheti fölötte az irányítást. A hibákon keresztül adatok is kiolvashatók a szerver memóriájából, köztük jelszavak és hozzáférési kulcsok. A cég szerint a PHP elmúlt bő évtizedben kiadott valamennyi verziója érintett.

A javítást hónapokig csendben készítették elő, és ma, október 22-én akarták nyilvánosságra hozni.

A PHP Alapítvány beszámolója szerint azonban kedden kiszivárogtak a hibák azonosítói, ezért egy nappal előrehozták a kiadást. Közben az egyik felfedező cég tévedésből közzétett egy videót, amely felgyorsította a támadókódok elkészítését.

A Reuters által idézett Amazon-jelentés szerint az első támadási kísérletet már október 17-én észlelték, négy nappal a nyilvános bejelentés előtt, és a hibákat azóta széles körben próbálják rosszindulatúan kihasználni. A hibákat egyébként mesterséges intelligencia segítségével találták meg, erről cikkünk végén bővebben írunk.

Mit tehetünk?

Ha „csak” internetezünk:

A saját számítógépünkre vagy telefonunkra nincs mit telepítenünk, a hiba a weboldalakat kiszolgáló gépeken van. Minket akkor érinthet, ha egy általunk használt oldalról adatokat lopnak el.

Ezért érdemes figyelni a webáruházak, szolgáltatók esetleges értesítéseit is.

A magyarorszag.hu kiesése miatt nem kell határidő-mulasztástól tartanunk. A kormányhivatalok tájékoztatója szerint, ha az elektronikus ügyintézés egy munkanapnál tovább szünetel, a beadvány papíron is benyújtható, és a kiesés miatt az ügyféllel szemben hátrányos jogkövetkezmény nem alkalmazható.

Ha saját vagy céges weboldalunk van:

A javítás szerda délután 16 órakor megjelent, a PHP 8.5.12-es, 8.4.27-es, 8.3.36-os és 8.2.35-ös verzióiban. A PHP fejlesztői szerint a frissítés az egyetlen teljes megoldás.

magyarorszag.hu

Fontos tudni, hogy a WordPress szokásos frissítése nem javítja a hibát, mert nem a WordPresst, hanem az alatta futó PHP-t kell frissíteni.

Hogy oldalunk melyik PHP-verzión fut, WordPressben így nézhetjük meg: Eszközök menü → Webhely Egészség → Információ fül → Kiszolgáló szakasz.

Ha a PHP régebbi, a verziószám az Állapot fülön, az ajánlott javítások között is megjelenhet. Ott azonban ne a címkére figyeljünk, hanem a számra. A WordPress a régi PHP-t jelenleg csak „Teljesítmény” címkével, ajánlott javításként jelzi, a mostani biztonsági hibát ez a jelzés nem tükrözi.

Az alábbi képernyőképen az látható, hogy az adott weboldalon a 8.2.34-es verzió fut, azaz egy számmal marad el a javított 8.2.35-östől, és mégis, a WordPress csak „teljesítményproblémaként” jeleníti meg. Ilyen esetben minden okunk megvan azonnal megkeresni a tárhelyszolgáltatót.

magyarorszag.hu

A legtöbb kisebb honlap úgynevezett osztott tárhelyen fut, ahol a PHP-t nem a tulajdonos, hanem a szolgáltató kezeli. Épp ezek az oldalak vannak nagyobb veszélyben, mert gazdáiknak kevés informatikai erőforrásuk van. A WordPress.com-ot üzemeltető Automattic közlése szerint a náluk futó oldalak védettek.

Ha ugyanazon a tárhelyen több oldalunk is fut, érdemes mindegyikre egyszerre rákérdezni.

Külön gond, hogy a PHP 8.1-es és régebbi változatai már nem kapnak rendes frissítést. A fejlesztők a súlyosságra tekintettel ezekhez is közzétettek egy minimális javítást, de ezt csak a szervert maguk üzemeltetők tudják beépíteni, ezért a legtöbb tárhelyen a valós megoldás a verzióváltás, amely sok helyen a kezelőfelületen is elvégezhető.

Váltás előtt azonban kérdezzük meg a szolgáltatót, hogy az általa kínált újabb verzió már a javított kiadás-e, mert egy javítatlan újabb verzióra váltás nem véd.

Egyes szolgáltatók saját javítást is kínálnak, erre is érdemes rákérdezni. A Censys adatai szerint a PHP-t futtató 2,6 millió vizsgált szerverből nagyjából 1,5 millió olyan verziót használ, amelyhez nincs javítás.

Utána érdemes ellenőrizni, hogy az oldal rendben működik-e.

Ha a frissítés nem oldható meg azonnal, az NKI tanácsa egyértelmű: az oldalt ideiglenesen érdemes lekapcsolni.

A frissítés után pedig nem árt az óvatosság. Ha valaki már korábban bejutott a szerverre, a javítás nem zárja ki utólag, ezért céges oldal esetén érdemes szakemberrel átnézetni a rendszert.

Hol értesülhetünk a fejleményekről elsőként?

A javításokról a php.net hírei, a hazai teendőkről az NKI honlapjának Riasztások rovata tájékoztat elsőként. A saját oldalunkat érintő lépésekről a tárhelyszolgáltató ad információt, a kormányzati szolgáltatások helyreállításáról pedig a kormányhivatalok és a magyarorszag.hu.

Aki csak a teendőkre volt kíváncsi, itt abbahagyhatja az olvasást. A történet hátterében viszont ott van egy kérdés, amely túlmutat ezen az ügyön:

mit kezdjünk azzal, hogy ugyanaz a mesterséges intelligencia segíti a védekezőket és a támadókat is?

Hogyan került elő a hiba?

Két biztonsági cég, egymástól függetlenül, augusztusban bukkant rá a hibákra, mindkettő AI-modellek segítségével. A Calif augusztus 1-jén, az OpenAI Patch the Planet nevű programjában, általánosan elérhető AI-modellel dolgozva talált rá az elsőre.

A Wiz augusztus 19-én jutott el ugyanide a Wiz Atlas nevű AI-kutatórendszere, a Google Gemini 4 Argon és az OpenAI GPT-5.6 Sol modelljének segítségével. A cég összegzése szerint

egy kutató egyetlen hét alatt elvégezte azt, amihez korábban egy világszínvonalú csapatnak hónapokra lett volna szüksége.

A PHP Alapítvány beszámolójából kiderül, hogy a probléma első jelei már egy 2024-es biztonsági átvilágításkor felbukkantak. Akkor azonban senki sem talált módot arra, hogy a hibát valóban ki lehessen használni, a javítás pedig a nehéz műszaki döntések és a kevés erőforrás miatt hónapokig elakadt.

Az alapítvány maga is szervezeti kudarcnak nevezi a késlekedést: AI-jal dolgozó kutatók jelentései tették világossá, mekkora a valódi veszély.

Az OpenAI szerint „tudomásunk szerint a mesterséges intelligencia a támadók előtt találta meg ezeket a hibákat”, így a védekezők felkészülhettek. Az előny azonban nem tartott ki a javításig: az Amazon által észlelt korai támadási kísérlet azt mutatja, hogy a titok néhány nappal a bejelentés előtt már kiszivároghatott.

Védő vagy támadó: kinek dolgozik az AI?

Aki próbált már kényes kérést intézni egy AI-csevegőhöz, tudja, hogy a modellek sok mindent megtagadnak. Felmerül a kérdés: ha egy ártalmatlan, de pikáns témájú szöveg megírását, kép elkészítését is visszautasítják, mégis, hogyan használhatják őket hackerek?

magyarorszag.hu

Ugyanazon a napon, amikor a PHP-hibák nyilvánosságra kerültek, a Straiker biztonsági cég jelentést tett közzé egy latin-amerikai, a CyberCartel nevű bűnözői hálózathoz köthető csoportról.

A jelentés szerint a csoport néhány hónap alatt több mint négyszáz pénzügyi célpontot támadott egy olyan rendszerrel, amelyben több AI-modell osztozott a munkán.

A hackerek olyan szoftvert használtak, amely több AI-modell munkáját hangolja össze, és webböngészőt, más alkalmazásokat is kezeltet velük. Ebben az esetben egy csapat Grok-ügynököt küldtek ki, hogy kémkedjenek a célpontjaik után, és megpróbáljanak titkokat feltárni, miközben több Claude-ügynök maga tervezte meg és hajtotta végre a hackeket.

A bűnözők speciális utasításokat használtak, hogy becsapják Claude-ot, és

elhitessék vele, hogy nem csinál semmi rosszat, egyetemi gyakorlaton, biztonsági teszten vagy hibavadász-feladaton vesz részt.

Ha a rendszer másodlagos modelljei, köztük a kínai Kimi, megtagadták a kérést, a program előre megírt támadókódot vett elő.

Míg mondjuk egy szexuális tartalmú kérés a szövegből felismerhető, az a kérés viszont, hogy „vizsgáld meg a saját rendszerünk gyenge pontjait”, szóról szóra ugyanúgy hangzik, akár egy bank biztonsági csapata írja, akár egy bűnbanda:

a modell a szándékot nem látja, és a hamis kontextust nem tudja ellenőrizni.

Az OpenAI a PHP-ügyről írt bejegyzésében arra figyelmeztet, hogy ugyanazok a képességek, amelyek az egész internetet érintő hibákat tárnak fel, a támadóknak is segíthetnek gyorsan támadóeszközöket fejleszteni. A cég további szűrőket hangol a visszaélések ellen, de elismeri, hogy ezek a jogos biztonsági munkát is akadályozhatják.

Kié lesz az előny?

A PHP Alapítvány adatai jól mutatják a változás ütemét: július 1. óta 15 biztonsági hibát tettek közzé, és több mint száz olyan bejelentést dolgoztak fel, amely érvénytelennek, ismétlődőnek vagy reprodukálhatatlannak bizonyult. Az alapítvány szerint az eszközök

gyorsabban találnak hibákat, mint valaha – védekezőknek és támadóknak egyaránt.

A helyes javításról viszont továbbra is tapasztalt mérnököknek kell dönteniük, és belőlük kevés van.

Az OpenAI szerint a PHP-hibák csak néhányak a már megtalált súlyos sérülékenységek közül, és a hasonló leletek száma a következő hónapokban meredeken nőni fog. Ezúttal a védekezők értek oda előbb, a titok azonban néhány nappal a javítás előtt kikerült. Nagy kérdés, hogy legközelebb meddig tart ki a védekezők előnye.

AI Radar heti hírlevél
Iratkozzon fel, és hetente egyszer elküldjük Önnek a hét legjobb AI-történeteit
3 perc alatt elolvasható. Nem küldünk spamet, és bármikor leiratkozhat egy kattintással.
Köszönjük!
Feliratkozott. A következő hírlevelet már Önnek is elküldjük.
Ha a LinkedInt is használja, ott is követheti az AI Radart: AI Radar – Heti Hírlevél