A céges VPN sok szervezetnél a távoli munka és a beszállítói hozzáférés kapuja. Ha ezen a kapun bejelentkezés nélkül lehet parancsokat futtatni, a peremvédelemből belépési pont lesz. A Nemzeti Kiberbiztonsági Intézet (NKI) október 14-i riasztása pontosan ezt a helyzetet írja le az Ivanti Connect Secure kapcsán.

Mi történt?

Az Ivanti október 13-án biztonsági közleményt adott ki a Connect Secure terméket érintő, CVE-2026-104935 azonosítójú sérülékenységről. A hiba hamisításon alapuló hitelesítésmegkerülést tesz lehetővé. Sikeres kihasználás esetén egy távoli, hitelesítéssel nem rendelkező támadó tetszőleges parancsokat hajthat végre az érintett eszközön.

A gyártó a hibát magas súlyosságúnak sorolja, CVSS-alapértéke 8,6. A CVE-nyilvántartás CWE-290 (hitelesítés megkerülése hamisítással) kategóriába sorolja. Az Ivanti közleménye szerint a hibát a nyilvánosságra hozatalkor már kihasználták, korlátozott számú ügyfélnél.

Az amerikai kiberbiztonsági ügynökség (CISA) ugyanazon a napon felvette a hibát az aktívan kihasznált sérülékenységek katalógusába (KEV). A CISA szerint a támadók a hozzáférést hitelesítő adatok ellopására és adatkiszivárogtatásra használták. A katalógusban szereplő október 16-i javítási határidő az amerikai szövetségi szervekre vonatkozik. A magyar szervezetek számára az NKI riasztása és a gyártói javítás az irányadó.

Az NKI ugyanebben a riasztásban a Microsoft Windows Shell CVE-2026-96951 azonosítójú, szintén aktívan kihasznált hibájára is felhívta a figyelmet. Ez a cikk a VPN-termékre koncentrál.

Mit tudni a támadásokról?

A kihasználást a Volexity amerikai incidenskezelő cég észlelte egy ügyfelénél végzett vizsgálat során, és jelezte a gyártónak. Az alábbiak a Volexity október 13-i elemzéséből származnak, és egyetlen megtámadott szervezet vizsgálatán alapulnak. Független forrás ezeket lapzártánkig, október 15-ig nem erősítette meg.

A Volexity szerint egy általa UTA0576 néven követett, korábban ismeretlen támadó október 3-tól használta ki a hibát egy akkor teljesen frissített, 22.8R2.4-es verziójú eszközön. A támadó három hibát fűzött láncba. Kettőt a CVE-2026-104935 azonosító fed le, a harmadik egy jogosultság-emelési hiba, amellyel rendszergazdai (root) jogot szerzett az eszközön. Erre a harmadik hibára a Volexity szerint az Ivanti egy későbbi kiadásban ad javítást. Lapzártánkig, október 15-ig ezzel kapcsolatban nem találtunk újabb gyártói közleményt.

A támadó a Volexity szerint a VPN-eszközön tárolt címtár-hitelesítő adatokat szerzett meg, majd a cég Active Directory címtárából helyi rendszergazdai jelszavakat és BitLocker-helyreállítási kulcsokat keresett. A nyomait a naplókból törölte, és a parancsai a memóriában futottak, ezért az Ivanti saját integritásellenőrző eszköze ezt a támadást nem jelezte.

Mely verziók érintettek?

Az Ivanti közleménye szerint érintett a 25.1.1.1-es és a korábbi, a 25.1.2.2-es és a korábbi, valamint a 22.8R2.4-es és a korábbi verzió.

A javított kiadások a következők. A 25.1.1.x ágban a 25.1.1.2, amely október 5-én jelent meg. A 22.8-as ágban a 22.8R2.5, amely október 12-én jelent meg. A júliusban megjelent 25.1.3.0 és az azt követő 25.1.3.1 a gyártó szerint nem tartalmazza a hibát, mert az Ivanti a hiba egy részét saját vizsgálata nyomán már ebben a kiadásban javította. A 25.1.3.0 ugyanakkor csak az új hardverplatformon (ISA4500, ISA6500, ISA8500) fut, virtuális és felhős telepítésnél új példányt kell építeni. A 25.1.2.x ágra a közlemény nem ad meg külön javított buildet.

A 22.7R2.14-es és a korábbi verziókat a hiba nem érinti. A 22.7-es és a 22.8-as termékvonal támogatása egyaránt 2027. január 31-én megszűnik, ezért az Ivanti a 25.1-es vonalra való átállást javasolja. A 22.8-as vonalat a gyártó csak átmeneti hídnak tekinti.

Az NKI riasztása a „25.1.3.0, 25.1.3.1, 22.8R2.5 előtti” verziókat nevezi érintettnek. Ez a felsorolás a javított kiadásokat sorolja fel, de nem tér ki arra, hogy a 25.1.1.2 is javított. A gyártói táblázat egyértelmű: ha az eszközén 25.1.1.2, 25.1.3.0, 25.1.3.1 vagy 22.8R2.5 fut, ez a hiba már javítva van.

Céges ellenőrzőlista

Az alábbi lépések az NKI javasolt intézkedéseiből, az Ivanti közleményéből és a CISA helyreállítási ajánlásaiból következnek. A sorrend a gyakorlatban párhuzamosítható, de a verzióazonosítás és a naplók mentése ne maradjon el a frissítés előtt.

  1. Írja össze az összes Ivanti Connect Secure hardver-, virtuális és felhős példányt, a magas rendelkezésre állású klaszterek minden csomópontjával együtt.
  2. Állapítsa meg, melyik verzió fut rajtuk. Érintett a 25.1.1.1-es, a 25.1.2.2-es, a 22.8R2.4-es és bármelyik korábbi verzió, kivéve a 22.7R2.14-es és korábbi vonalat.
  3. Telepítse a javított verziót minden érintett példányon: 25.1.1.2, 25.1.3.0 vagy 25.1.3.1, átmenetileg 22.8R2.5. A frissítés után ellenőrizze a futó verziót és a rendszer integritását.
  4. Futtassa az Ivanti Integrity Checker Toolt, de tiszta eredményt ne tekintsen felmentésnek. A CISA és a Volexity szerint a memóriában futó támadói parancsokat ez az eszköz nem feltétlenül észleli, ezért gyanú esetén hálózati és memóriakép-alapú vizsgálat kell.
  5. Nézze át a naplókat, a szokatlan hitelesítéseket, a konfigurációmódosításokat és a VPN-eszközről induló kimenő kapcsolatokat. A Volexity a nagy számú, a /dana-na/auth/url_default/welcome.cgi címre érkező kérés figyelését javasolja, és a kapcsolódó indikátorokat a GitHubon közzétette.
  6. Kompromittálódás gyanúja esetén mentse a releváns naplókat és bizonyítékokat, mielőtt az eszközt leválasztaná vagy újratelepítené.
  7. Igazolt kompromittálódásnál az NKI szerint az eszközt le kell választani, majd tiszta állapotból helyre kell állítani. A CISA ehhez a konfiguráció mentését, gyári visszaállítást (virtuális és felhős példánynál újraépítést), a legújabb verzióra frissítést, majd a mentett konfiguráció visszatöltését ajánlja.
  8. Ezután cseréljen jelszót minden fióknál, a tartományi, a rendszergazdai és a helyi fiókoknál is. Vonja vissza és bocsássa ki újra a tárolt tanúsítványokat, cserélje az API-kulcsokat és a licenckiszolgáló hitelesítő adatait. Kiemelten kezelje azt a szolgáltatásfiókot, amellyel a VPN a címtárhoz kapcsolódik.
  9. Ha a szervezete a Kibertv. hatálya alá tartozik, mérje fel, hogy bejelentésköteles incidensről van-e szó, és ha igen, tartsa a lenti határidőket.

Mit ír elő a Kibertv. a bejelentésről?

A bejelentési kötelezettséget a Magyarország kiberbiztonságáról szóló 2024. évi LXIX. törvény (Kibertv.) 66. §-a írja elő, a részleteket a 418/2024. (XII. 23.) Korm. rendelet 77. §-a határozza meg. A bejelentés címzettje a nemzeti kiberbiztonsági incidenskezelő központ, amely a rendelet 65. §-a szerint a Nemzetbiztonsági Szakszolgálat. A gyakorlatban ez az NKI.

A kötelezettség köre szervezettípusonként eltér. A közigazgatási szervek, a nagyobb állami cégek, a hatóság által azonosított szervezetek és a honvédelmi célú gazdasági társaságok minden kiberbiztonsági incidenst kötelesek bejelenteni. A 2. és 3. melléklet szerinti ágazatokban működő, a törvény hatálya alá tartozó cégeknek azokat az incidenseket kell bejelenteniük, amelyek súlyos zavart vagy vagyoni hátrányt okoznak a működésükben, vagy jelentős kárt okoznak másoknak. A többi incidens önkéntesen jelenthető.

A rendelet szerint a határidők a tudomásszerzéstől számítanak. Indokolatlan késedelem nélkül, de legkésőbb 24 órán belül első bejelentést kell tenni a rendelkezésre álló alapadatokkal. Legkésőbb 72 órán belül eseménybejelentés következik, amely frissíti az első bejelentést, és tartalmazza az incidens súlyosságának és hatásának első értékelését. A zárójelentés az eseménybejelentést követő egy hónapon belül esedékes. Ha az incidens ekkor még tart, előrehaladási jelentést kell adni, a zárójelentést pedig a kezelés lezárását követő egy hónapon belül.

Mit jelent ez egy KKV-nak?

A döntő kérdés az, hogy van-e a cégnél internet felől elérhető Ivanti Connect Secure, és milyen verzió fut rajta. Egy KKV-nál a VPN gyakran az egyetlen távoli belépési út, ráadásul sokszor ugyanahhoz a címtárhoz kapcsolódik, amelyben a munkatársak összes fiókja van. Ha az eszköz érintett, a gyors frissítés és a naplók átnézése sokkal olcsóbb, mint egy utólagos, teljes körű vizsgálat.

A Kibertv. a mellékletekben felsorolt ágazatokban jellemzően a középvállalkozásokra és a nagyobb szervezetekre vonatkozik. A kisvállalkozások közül főként az elektronikus hírközlési, bizalmi és domainszolgáltatók tartoznak alá méretüktől függetlenül. A bejelentési kötelezettség hiánya azonban nem jelenti azt, hogy a frissítés várhat.

Ha nincs Ivanti Connect Secure a leltárban, a riasztás akkor is hasznos emlékeztető. A peremeszközök, vagyis a VPN, a tűzfal és az SSL-átjáró legyenek verziókövetettek, és a kezelőfelületük ne legyen korlátozás nélkül elérhető az internetről.

Gyakori kérdések

Elég a frissítés, vagy vizsgálat is kell?

A frissítés az érintett példányokon kötelező lépés, de önmagában nem elég. Az NKI és a CISA is vizsgálatot javasol, mert a hibát a közlemény megjelenésekor már kihasználták, és a memóriában futó támadói tevékenységet az integritásellenőrző eszköz nem mindig mutatja ki.

Van nyilvános lista a támadás nyomairól?

Az Ivanti közleménye maga nem tartalmaz IP-cím-, domain-, hash- vagy fájlnév-alapú listát, a gyártó szerint kevés ilyen jel áll rendelkezésre. A közlemény a Volexity elemzésére utal, amely a kapcsolódó indikátorokat a GitHubon tette közzé.

Biztonságos a 22.7-es vonal?

A gyártó szerint a 22.7R2.14-es és a korábbi verziókat ez a hiba nem érinti. A 22.7-es vonal támogatása azonban 2027. január 31-én megszűnik, ezért az átállást a 25.1-es vonalra érdemes már most megtervezni.

Mikor kell az NKI-nek jelenteni?

A Kibertv. hatálya alá tartozó szervezetnek a bejelentésköteles incidensről való tudomásszerzéstől számítva legkésőbb 24 órán belül első bejelentést, 72 órán belül eseménybejelentést, majd az eseménybejelentést követő egy hónapon belül zárójelentést kell benyújtania. A határidőket a 418/2024. (XII. 23.) Korm. rendelet 77. §-a rögzíti.

Döntési szabály

Ha van Ivanti Connect Secure a szervezeténél, haladéktalanul állapítsa meg a verziót. Ha az eszközön nem 25.1.1.2, 25.1.3.0, 25.1.3.1 vagy 22.8R2.5 fut, és nem is a 22.7R2.14-es vagy korábbi vonal, telepítse a javítást, mentse a naplókat, és indítson vizsgálatot. Ha a Kibertv. hatálya alá tartozik, és kompromittálódás vagy jelentős szolgáltatászavar merül fel, a tudomásszerzéstől számított 24 órán belül tegye meg az első bejelentést.

Források