eMudhra: nyolc gyenge kulcs miatt lépett a Chrome és a Firefox

Mi történt az eMudhra tanúsítványaival?

2026. október 17-én egy független kutató jelezte a böngészőgyártók felé, hogy az indiai eMudhra hitelesítésszolgáltatóhoz kapcsolódó nyolc köztes tanúsítvány magánkulcsa kompromittálódott. A Google Chrome biztonsági csapatának hivatalos közleménye szerint a kulcsok létrehozásakor nem használtak elegendő véletlenszerűséget. Emiatt az eredetileg erősnek szánt elliptikus görbéjű kulcsok rendkívül könnyen rekonstruálhatók voltak.

Ez nem egyszerűen azt jelenti, hogy egy kiszivárgott jelszót vissza lehetett volna használni. A sérülékeny kulcsokkal egy támadó olyan digitális aláírást állíthatott volna elő, amellyel más webhelyek nevében is látszólag hiteles HTTPS-tanúsítványokat bocsáthat ki azokon a rendszereken, amelyek még megbíztak az érintett tanúsítványláncokban. A helyzetet a Chrome, a Firefox, valamint más böngésző- és operációsrendszer-gyártók gyors védelmi lépésekkel kezelték.

Miért veszélyes egy köztes hitelesítésszolgáltatói kulcs?

Amikor valaki megnyit egy HTTPS-címet, a böngésző nemcsak titkosított kapcsolatot hoz létre, hanem azt is ellenőrzi, hogy a felkeresett szerver megfelelő tanúsítvánnyal azonosítja-e magát. A bizalom gyakran több szintből áll: egy gyökér-hitelesítésszolgáltató (root CA), az általa felhatalmazott köztes szolgáltató (intermediate CA) és a konkrét webhely tanúsítványa alkot láncot.

Ha egy köztes szolgáltató aláírókulcsa támadó kezébe kerül, az sokkal több egyetlen weboldal certifikátumának ellopásánál. A támadó elvileg más domainekre is készíthet aláírt tanúsítványokat. A tényleges megtévesztéshez azonban jellemzően a kapcsolat eltérítésének vagy elfogásának lehetősége, és az adott kliensrendszer tanúsítványellenőrzésének megkerülése vagy elavultsága is szükséges. Ezért a lehetséges hamisítás nem azonos bizonyított felhasználói adatlopással.

Nyolc kulcs sérült – de hat tanúsítvány volt közvetlen TLS-kockázat

A teljes incidens nyolc köztes hitelesítésszolgáltatói kulcsot érintett. A Chrome Root Program részletes tájékoztatása szerint ezek közül hat TLS-tanúsítványok kiadására szolgáló köztes CA volt, további kettő pedig kódaláírásra korlátozott környezethez kapcsolódott. A Chrome a hat TLS-kulcshoz tartozó azonosítókat azonnal blokkolta, és hangsúlyozta, hogy a kódaláírásra korlátozott tanúsítványokat a böngésző TLS-ellenőrzése eleve nem fogadja el webhelyhitelesítésre.

A Google szerint az érintett hat TLS-köztes CA alatt a blokkolás előtt nem szerepelt bejegyzett webhelytanúsítvány a Certificate Transparency, azaz CT-nyilvántartásokban. Mivel a Chrome nyilvánosan megbízható tanúsítványoknál megköveteli a megfelelő CT-igazolást, ez további védelmet jelentett a böngésző felhasználóinak. Ez a megállapítás a CT-t érvényesítő kliensekre vonatkozik; az egyedi programok, régi eszközök vagy saját tanúsítványtárat használó API-kliensek kockázata eltérhet.

Hogyan reagált a Chrome, a Firefox és az Android?

A Chrome és Android biztonsági csapatának tájékoztatása szerint a Chrome október 17-én, 19:45 UTC-kor frissítette a CRLSet blokkolási listáját. Ez a sérült köztes CA-k kulcsazonosítóit tiltja, és az általános Chrome-konfigurációban nem igényelt külön böngészőfrissítést vagy újraindítást. Az Androidon a Google Play Services hasonló védelmet terített, bár a készülékek eltérő ütemben kapták meg.

A Mozilla szintén október 17-én reagált: a Firefox OneCRL rendszerén keresztül 22:59 UTC-re eljuttatta az érintett tiltásokat a szabványos beállításokat használó felhasználókhoz. Október 20-án további Firefox- és ESR-kiadásokkal a speciális beállítások miatt kimaradó felhasználókat is védeni kívánta. Ezzel párhuzamosan az NSS tanúsítványtár frissítésével a böngészőn kívüli alkalmazások kockázatát is csökkenti.

A Chrome Root Store-ból az emSign ECC Root CA - G3 gyökértanúsítvány eltávolítását is bejelentették. Ennek széles körű terjesztését október 27-re tervezték, tehát október 21-én ezt még nem szabad már befejezett intézkedésként bemutatni. A root eltávolítása miatt egyes, egyébként legitim tanúsítványokat használó oldalaknak időben új tanúsítványláncra kell átállniuk.

Mit állít maga az eMudhra és az indiai hatóság?

Az eMudhra október 20-i közleménye szerint a probléma a 2025 áprilisában tartott tanúsítványkulcs-létrehozási folyamat egy meghatározott részéhez kapcsolódott. A társaság azt közölte, hogy a kompromittálódás nem érintette a gyökérkulcsait, valamint a nyolc vizsgált köztes tanúsítvány – egyetlen kivétellel – nem került termelési használatba; állításuk szerint az érintettek egyike sem bocsátott ki végfelhasználói tanúsítványt. Ez a vállalat előzetes vizsgálati eredménye, a teljes okfeltárás még folyamatban van.

Az indiai CERT-In hatóság október 21-én külön figyelmeztetést adott ki. Eszerint a P-384 típusú kulcsokhoz rendkívül kicsi privát kulcsértékek tartoztak, ezért a kulcsok a nyilvános információkból rövid idő alatt visszaállíthatók voltak. A hatóság különválasztotta a nemzetközi webes TLS-bizalmi infrastruktúrát az eMudhra indiai digitális aláírási és eSign-üzletágától: az utóbbit a közlemény szerint nem érintette a vizsgált incidens.

Mi köze ennek az online bankoláshoz és a fizetési API-khoz?

A böngésző címsorában megjelenő lakat nem azt bizonyítja, hogy a weboldal minden szempontból megbízható, hanem azt, hogy a böngésző ellenőrzése alapján a kapcsolat megfelelően titkosított és hitelesített. A banki weboldalak, az internetes fizetési kapuk és az API-végpontok ezt a bizalmi infrastruktúrát használhatják. Egy köztes CA hibája ezért nemcsak az adott szolgáltató ügyfeleit, hanem a szélesebb webes ökoszisztémát is érintheti.

Képzeljünk el egy feltételezett példát: egy pénzügyi szolgáltató háttéralkalmazása külső fizetési API-t hív meg. Ha az alkalmazás saját, régóta nem frissített tanúsítványtárból dolgozik, és még elfogadja az érintett tanúsítványláncot, a böngésző felhasználóinál már működő védelmek nem feltétlenül vonatkoznak rá. Ezért a szerveroldali API-kliens hitelesítésének frissítése külön feladat lehet.

Nem találtunk hiteles forrást arra, hogy az eMudhra-ügy miatt konkrét magyar banki felhasználók adatait ellopták vagy pénzt utaltak volna el. A kockázat technikai lehetőségként valós, a megvalósult pénzügyi incidensre vonatkozó állítást azonban külön bizonyítani kell.

Mit tett a Cloudflare, és miért nem elég csak a böngészőt frissíteni?

A Cloudflare október 20-i biztonsági beszámolója szerint frissítette a saját szolgáltatásait, tanúsítványtárait és több kliensalkalmazását, például a WARP és a Cloudflare Tunnel kapcsolódó részeit. A vállalat nem azonosított aktív kihasználást a saját szolgáltatásaiban. Külön kiemelte, hogy a böngészők gyors visszavonási mechanizmusai nem automatikusan védik meg az összes, HTTPS-kapcsolatot nyitó kiszolgálót és mobilalkalmazást.

A banki és fintech üzemeltetőknek ezért célszerű ellenőrizniük, hogy szolgáltatásaik mely tanúsítványtárakat használják. Az operációs rendszer által kezelt, naprakész megbízható gyökérlista, az alkalmazásba beépített saját CA-csomag és a konténerképek tanúsítványkészlete eltérhet. A szokásos böngészőteszt nem igazolja automatikusan egy háttérben futó fizetési API-kliens védettségét.

Mit tegyen a felhasználó, és mit az üzemeltető?

A mindennapi felhasználók számára a legfontosabb, hogy a böngészőt és a készülék operációs rendszerét naprakészen tartsák. A böngésző által jelzett tanúsítványhibát, különösen banki belépés vagy fizetés előtt, nem szabad figyelmeztetés nélkül átugrani. Az incidens miatt nincs szükség általános pánikra vagy az összes HTTPS-oldal elkerülésére: a nagy böngészőgyártók gyors védelmi intézkedései már életbe léptek.

Az üzemeltetőknek az érintett eMudhra/​emSign tanúsítványláncokat azonosítaniuk kell, a szolgáltatótól kapott gyártói útmutató alapján szükség esetén alternatív, megbízható CA-láncra váltaniuk, és frissíteniük kell az érintett tanúsítványtárakat. Az október 27-re tervezett Chrome root-store változás előtt különösen fontos megvizsgálni a G3 gyökértanúsítványhoz láncolt, legitim webhelytanúsítványok cseréjét.

Az eMudhra-eset azt mutatja meg, hogy a digitális pénzügyek biztonsága nem ér véget a bank által írt alkalmazásnál. Az aláírókulcsok keletkezése, a tanúsítványláncok ellenőrzése és a harmadik féltől származó bizalmi adatok gyors frissítése ugyanolyan lényeges.

Amit még nem tudunk

A kutató felfedezése és a böngészőgyártók intézkedése ellenőrizhető, de a kulcsgenerálási folyamat teljes műszaki okának feltárása az eMudhra szerint még tart. Az október 27-re tervezett további Chrome-változtatás jelenleg jövőbeni közzétételi terv, nem lezárt esemény. Nincs hitelesen dokumentált, ezekhez a gyenge kulcsokhoz köthető magyar banki adatlopás sem.

A felhasználók számára az azonnali tanács a naprakész rendszer és az érvényes tanúsítvány figyelése; a pénzügyi intézmények és fejlesztők számára pedig a háttéralkalmazások tanúsítványláncainak átfogó ellenőrzése a legfontosabb.