Rendkívül súlyosak a sérülékenységek, amik miatt a magyarorszag.hu-t is lelőtték, de már van megoldás

Tanács Zoltán tudományos és technológiai miniszter csütörtökön reggel bejelentette, hogy elővigyázatosságból lekapcsolták a magyarorszag.hu-t és más kormányzati honlapokat egy több országot érintő, kritikus informatikai biztonsági kockázat miatt. Csütörtök délutánra sikerült elhárítani a fenyegetést, az oldal újraindult, a miniszter pedig arról beszélt, az ilyen esetek miatt is van szükség a magyar kiberbiztonsági képességek fejlesztésére. A fenyegetés, amiről szerdán a Telexen is írtunk, egészen pontosan két sérülékenységet takar, amelyeket a PHP nevű, széles körben elterjedt programozási nyelvben fedeztek fel, és valóban rendkívül komoly problémát jelent. Nagyon röviden összefoglalva ezeket kihasználva

hitelesítés nélkül lehetett beférkőzni egy ezen alapuló weboldal szervereire, ahol aztán bármit lehetett csinálni, és mivel itt maga a programozási nyelv volt kompromittálható, az is teljesen mindegy volt, hogy a honlap mennyire biztonságos.

A két sérülékenység miatt szerdán rengeteg honlapot kapcsoltak le szerte a világon, a BBC-től a Wikipédián át különböző országok állami honlapjaiig, de egyebek mellett egy rakás, Japánban fejlesztett videójáték is elérhetetlen volt emiatt egy ideig. A kibervédelmi szervezetek és állami ügynökségek nem győzik hangsúlyozni, hogy mindenki frissítsen, és addig is lője le az oldalait, a hibát bemutató két vállalat, a Wiz és az OpenAI pedig az elmúlt időszak legsúlyosabb kiberbiztonsági incidenséről ír. Ami azért is különösen durva, mert mesterséges intelligencia segítségével észlelték.

Mi ez az egész?

A PHP egy ingyenes, nyílt forráskódú, elég sokoldalú programozási nyelv, amelyet elsősorban honlapok építéséhez szoktak használni. A PHP nagyon leegyszerűsítve azt tudja, hogy szerveroldalon összeállítja a kódot, ami egy oldal megjelenítéséhez szükséges, és ezt küldi el a felhasználónak, aki bepötyögte, hogy mondjuk wikipedia.com. A W3Techs adatai alapján a PHP a legnépszerűbb szerveroldali programnyelv, a honlapoknál, ahol ez az infó publikus, közel 70 százalékos a használati aránya. A rengeteg weboldalnál használt WordPresst és a Wikipedia alatt futó MediaWikit is ez hajtja.

Ebből már lehet sejteni, hogy ha a PHP-vel baj van, az rengeteg dolgot érint az interneten. A két sérülékenység pedig, amit két kiberbiztonsággal foglalkozó cég, a Calif és a Wiz, plusz az OpenAI is felfedezett, több fejlett mesterségesintelligencia-modellel felvértezve, rendkívül komoly volt. Szerdán a Wiz, a Calif és az OpenAI egy-egy külön blogposztot szentelt a problémának, amelyek alapján elég jól rekonstruálható, hogy mi történt. A Calif egészen 2004-ig ment vissza az időben, hogy elmagyarázza a sztori előzményeit, de mi maradjunk annál, hogy idén augusztusban kiderült,

egy jóval korábban felfedezett, és egy 2024-es auditon megerősített, memóriakezeléssel összefüggő hibát, amiről korábban nem bizonyosodott be, hogy ki is lehet használni, mégiscsak ki lehetett használni.

Ez úgy derült ki, hogy a PHP mögött álló alapítvány idén nyáron csatlakozott az OpenAI által indított, Patch the Planet nevű kezdeményezéshez, amelynek célja, hogy a mesterséges intelligencia segítségével kutassanak kritikus sérülékenységek után. A PHP-val a Calif kezdett el foglalkozni, és a kutatói rövidesen jelezték, hogy az évek óta ismert hibára építve távolról, hitelesítés nélkül lehet kódot futtatni egy PHP-s webszerveren. Tőlük függetlenül az OpenAI is jelentette ugyanezt a problémát, majd később a Wiz és ők is újabb támadási vektort fedeztek fel.

Mennyire volt ez durva, és hogy jön ide az MI?

A sérülékenységeket kritikusnak minősítették, a három cég pedig együtt kezdett el dolgozni a PHP-vel azon, hogy orvosolják őket. Menet közben létrehoztak egy php2shell nevű szkriptet, amely ezeket kombinálva demonstrálta, hogy lehet távolról kódot futtatni egy szerveren anélkül, hogy a támadónak be kéne lépnie a rendszerbe. Ez azért lényeges, mert ezt a lépést általában nem lehet megúszni: vagy biztonsági réseket kihasználva kell beférkőzni a rendszerbe, és ott jogosultságokat szerezni, vagy egy létező fiókot kell ellopni, például adathalászattal.

Itt ez nincs, vagyis az egész folyamat automatizálható, elméletben rá lehetett volna ereszteni egy szkriptet az egész internetre, ami aztán magától feltörhetett volna bármit, ami alatt PHP fut.

Emellett azt is sikerült bizonyítani, hogy érzékeny adatokat, például jelszavakat vagy API-kulcsokat is ki lehet olvasni a memóriából anélkül, hogy ahhoz bármilyen kódot kellene futtatni. A sérülékenységek kihasználása a gyakorlatban így nézett ki:

Ezen a ponton érdemes beszélni arról is, hogy miért kellett ehhez mesterséges intelligencia, pláne ha ezek a kritikus problémák már több mint egy évtizede ismertek voltak, és legutóbb két éve is meg lettek erősítve. Nagyjából azért, mert hiába volt ismert, a kutatók eddig kihasználni nem tudták őket, a memóriával kapcsolatos hibák ugyanis rendkívül összetettek, és ha egy helyen ki is lehet használni őket, az nem garantálja, hogy máshol is működni fognak. Emiatt rengeteg tesztelésre és akár komoly módosításokra is szükség lehet, hogy máshol is bizonyítsák a működést.

Ezt manuálisan megcsinálni nagyon nehéz volt, de a kutatók szerint a nagy nyelvi modellekkel már nem az. A Wiz arról írt, hogy a saját, sérülékenységek keresésére kifejlesztett, Atlas nevű modelljükkel, a Gemini 4 Argonnal és a GPT-5.6 Sollal sikerült megtalálni és kihasználni a sérülékenységeket. Ez jó hír, mert jó esetben még az előtt sikerült orvosolni a problémát, hogy bárki kihasználhatta volna, de ijesztő is, mert megmutatja, hogy a fejlett MI-rendszerekkel a támadók is előnybe kerülhetnek, ami láthatóan aktuálisabb probléma, mint az, hogy az MI elhozza a világvégét.

Mi történt ezután?

A PHP már szeptember óta gőzerővel dolgozott, hogy fixálja ezeket a sérülékenységeket, és értelemszerűen fel is vette a kapcsolatot azokkal az érintettekkel, akiknek ez kulcsfontosságú volt, hogy előre felkészülhessenek a frissítésre. Ez bevett gyakorlat, és ideális esetben az egészről csak akkor hallottak volna az emberek, amikor az eredeti terveknek megfelelően október 22-én, vagyis csütörtökön kijött volna a közlemény, hogy volt egy ilyen hiba, de már minden jó, és a Wiz, a Calif és az OpenAI is közzétették volna a saját elemzéseiket.

A valóságban viszont nem ez történt. Október 20-án különböző online fórumokon elkezdett terjedni, hogy a két sérülékenység létezik, ezért a PHP előrébb hozta az első bejelentését, és a javítócsomag megjelenését is. A Calif erre közzétette a saját videóját a php2shellről, ami bemutatta a szkript működését, illetve bizonyos részleteket is bemutatott a sérülékenységekről. A cég gyorsan kapcsolt, és törölte a videót, de ekkor már mindegy volt, az elkezdett terjedni, és hozzájárult ahhoz, hogy mások is képesek voltak igazolni: a dolog tényleg működik.

Még tovább kavarta a dolgokat, hogy a Chainguard nevű kiberbiztonsági cég, amely szintén megkapta előre a javítócsomagot, órákkal az embargó előtt közzétette azt, így gyakorlatilag minden kiberbűnöző és hekker elkezdhette tanulmányozni, hogy pontosan mi van benne, és azt hogyan fordíthatják a maguk javára, még azelőtt, hogy a javítás hivatalosan megjelent volna. Ezt a PHP is kiemelte a saját blogposztjában, amire Dan Lorenc, a Chainguard vezérigazgatója reagált is, mégpedig azt, hogy azért döntött a korábbi közlés mellett, mert állítása szerint múlt pénteken

ők maguk is képesek voltak a korábbi felfedezéstől függetlenül, teljesen önállóan felfedezni a hibát egy fejlett MI-modellel, aminek csak annyit mondtak, hogy „keress durva sérülékenységeket a PHP-ban”.

Hogy ez tényleg így volt-e, azt nehéz megmondani, ahogy azt is, hogy megáll-e a Chainguard indoklása, miszerint többen is arról számoltak be, hogy aktívan kihasználják a sérülékenységeket. Az Amazon 21-én valóban azt közölte, hogy szerintük valaki már október 17-én megpróbálkozott ezzel, 20-án pedig több aktív kísérletet is észleltek, a PHP Alapítvány viszont azt állítja, hogy az interneten keringő demonstrációk a gyakorlatban nem működtek, és a javítások hivatalos megjelenéséig nem is találtak olyan online elérhető megoldást, amely működött volna.

Mi lesz most?

Az a szerdai őrületből jól látszott, hogy alaposan megkavarta a dolgokat, hogy a hivatalos megjelenés előtt elkezdtek csepegni az infók a sérülékenységekről, aztán végül az egész javítócsomag is még az előtt elérhető lett, hogy hivatalosan bejelentették volna. Ha minden a tervezett mederben zajlik, valószínűleg jóval kisebb visszhangja lett volna az egésznek, mint így. Az érintetteknek – akikből, ugye, elég sok van –, kevésbé kellett volna kapkodniuk, és talán Magyarországon, meg máshol sem kellett volna lekapcsolni kormányzati oldalakat és a Wikipedia meg a BBC is állva maradt volna.

A PHP Alapítványnál így is optimisták, hiszen a javítások megjelentek, tényleg működnek, és mivel rengeteg disztribútor előre megkapta őket, sok esetben még így sem okozott problémát az, hogy időben meg is kapják őket a rendszerek, amelyeknek szüksége volt rájuk. Az AWS és a Cloudflare már a hivatalos megjelenés előtt közzétett olyan megoldásokat, amelyekkel mérsékelni lehetett a sérülékenységnek való kitettséget, így a kockázat már az előtt enyhítve volt valamelyest, hogy az érintettek telepítették volna a javítócsomagot.

Azt viszont érdemes kiemelni, hogy a frissítések csak PHP 8.2-re, és az azt követő verziókra jöttek ki, miközben a W3Techs adatai szerint az ismert honlapok durván 31 százaléka alatt 7-es, vagy annál régebbi verzió fut. A PHP Alapítvány természetesen felhívta erre a figyelmet, és a lehetőségekhez mérten a korábbi verziókat használóknak is igyekszik segítséget nyújtani, de azt hangsúlyozták, hogy kizárólag az új verzióra való átállás jelent végleges, mindenre kiterjedő megoldást. Ez persze sokszor nem egyszerű, ezért is lehet az, hogy bizonyos oldalakat akár több napra is lelőttek szerdán.

Az mindenesetre biztos, hogy ha valakinek van egy honlapja, ami alatt PHP fut, annak most mindenképpen ajánlott megnéznie, hogy milyen verzióról van szó – ha fel lehet rá tenni a javítócsomagot, akkor minél hamarabb tegyen is így, ha pedig nem, akkor kapcsolja le az oldalt, és frissítsen újabb verzióra, vagy legalábbis tegye meg azokat az óvintézkedéseket, amelyeket a PHP Alapítvány javasolt a régebbi verziókon ragadtaknak. Pláne, mert most, hogy a javítások nyilvánosan elérhetőek, már egészen biztos, hogy hamarosan lesznek működő módszerek arra, hogy a sérülékenységeket élesben is ki lehessen használni.