Nyolc köztes CA privát kulcsának kompromittálódását erősítették meg
2026. október 20-án a Google és a Mozilla is nyilvánosan megerősítette: kompromittálódtak az eMudhra tanúsítványkiadó hitelesítésszolgáltató nyolc köztes CA-jának privát kulcsai. A CA a Certificate Authority rövidítése: az a hitelesítő, amely a tanúsítványokat aláírja. Az érintett TLS CA-k kulcsaival illetéktelenek más webhelyek nevére állíthatnak ki hamis tanúsítványt. Egy ilyen igazolást a még érintett alkalmazás éppúgy hitelesnek fogadhat el, mint a valódi szolgáltatóét.
A kulcsokat elégtelen véletlenszerűséggel hozták létre, ezért a nyilvános tanúsítványokból vissza lehetett állítani őket. A Mozilla ezt az eredeti bejelentőtől függetlenül is megtette. Az aláírásra használt titok így illetéktelenek számára is hozzáférhető: a bizalom alapja sérült meg annál a hitelesítőnél, amely mások személyazonosságát igazolja.
Scott Helme biztonsági kutató saját ellenőrzésében az egyik privát kulcs értéke a 4-es szám volt. Ez jelzi, mennyire kevés számítással visszaállítható kulcsokról van szó. Aki visszaállítja valamelyik érintett TLS-hitelesítő kulcsát, annak már rendelkezésére áll a hamis tanúsítvány aláírásához szükséges titok.
Az első bejelentés október 17-én érkezett a böngészőgyártókhoz. A Chrome és a Firefox még aznap tiltással reagált. A szerveres alkalmazások és konténerek viszont eltérő tanúsítványkészletből dolgozhatnak, ezért náluk külön ellenőrzés és frissítés kellhet. Ha céges rendszert üzemeltetsz, most azt kell tisztázni, melyik programod bízik még ezekben a kulcsokban.
A hamis SSL/TLS-tanúsítvánnyal a támadó más szolgáltatás nevében mutatkozhat be
A webes tanúsítványokra ma is gyakran SSL-tanúsítványként hivatkozunk; a HTTPS-kapcsolatok védelmét a TLS protokoll adja. Amikor a szervered ilyen kapcsolatot nyit, a távoli szolgáltatás tanúsítvánnyal igazolja magát. A kliens ellenőrzi a nevet, az érvényességet és az aláírási láncot. A köztes CA további tanúsítványokat írhat alá; ezért a privát kulcsának kompromittálódása sok szolgáltatás megszemélyesítésére adhat lehetőséget.
A támadónak ehhez nem kell ellopnia a te weboldalad vagy a partnered eredeti tanúsítványát. A kompromittált hitelesítőkulccsal másik igazolást készíthet ugyanarra a névre. Emiatt az érintettséget akkor is vizsgálni kell, ha a saját tanúsítványodat másik szolgáltatótól vásároltad. A kimenő kapcsolatot indító alkalmazás bizalmi listája dönti el, elfogadja-e a hamis láncot.
A kihasználáshoz a támadónak a kapcsolatba is közbe kell ékelődnie, vagy a klienst a saját szerveréhez kell irányítania. Ha a kliens elfogadja a hamis tanúsítványt, a kapcsolat titkosítva, de a támadó szerverével épülhet fel. Az alkalmazás ide küldheti el az adatot, és innen kaphat módosított választ. Ez teszi súlyossá a hibát: a titkosítás látható működése mellett a másik fél hitelesítése vallhat kudarcot.
A böngészők gyorsan reagáltak; a szervereknél az üzemeltetőnek kell lezárnia a hibát
A Mozilla október 17-én a Firefox OneCRL mechanizmusával tiltotta az érintett tanúsítványokat a szokásos beállítást használóknál. A Google ugyanazon a napon CRLSet-frissítéssel lépett. Ezekkel a böngészők gyorsan megkaphatták a tiltást. Egy céges szerveren működő háttérprogram ettől még tovább használhatja a korábban betöltött bizalmi készletet.
A céges szerveren futó program más utat követhet. A curl beállítástól és TLS-háttértől függően a rendszer tanúsítványtárát vagy egy fájlban tárolt készletet használ. A Node.js saját, a kiadásakor rögzített tanúsítványkészlettel is működhet. Egy alkalmazás külön megadott tanúsítványfájlt is betölthet. Így ugyanazon a gépen a böngésző, a parancssori eszköz és az alkalmazás eltérő eredményre juthat.
Ezért az üzemeltetőnek az alkalmazás tényleges hitelesítési útját kell azonosítania. Melyik könyvtár nyitja a kapcsolatot? Melyik tanúsítványkészletet tölti be? Mikor frissült az a futó példányban? A gépen telepített csomag neve hasznos kiindulópont, de a vizsgálat azzal válik teljessé, hogy a kimenő kapcsolatot létrehozó program viselkedését is ellenőrzik.
Ügyféladatok, hozzáférési tokenek és szoftverletöltések kerülhetnek veszélybe
Egy webáruház rendelési adatot küld a számlázónak, a háttérfeladat levelet indít egy külső szolgáltatónál, a telepítési automatika pedig szoftvert tölt le. Ezekben a hétköznapi kapcsolatokban az alkalmazás ügyféladatot, üzleti dokumentumot vagy hozzáférési tokent is továbbíthat. Az eMudhra-incidens után elsőként az ilyen érzékeny kimenő kapcsolatok hitelesítését kell ellenőrizni.
A másik fontos terület a szoftverek és frissítések letöltése. Ha egy letöltőprogram tévesen hitelesnek fogad el egy közbeékelődő szervert, a letöltött tartalom eredete is kérdésessé válhat. A kiadó ellenőrzött aláírása további védelmet adhat; ugyanarról a megtámadott kapcsolatról letöltött fájl és ellenőrzőösszeg egyezése viszont önmagában nem független eredetigazolás.
A vizsgálatból a ritkán futó háttérfeladatok és a telepítési automatizmusok sem maradhatnak ki. Egy naponta vagy havonta kapcsolódó program ma még nem feltétlenül mutat tünetet, de a következő futásnál ugyanabból az elavult bizalmi készletből dönthet. A szolgáltatások listájához ezért a futó alkalmazást, a tanúsítványok forrását és a felelős üzemeltetőt is hozzá kell rendelni.
A host frissítésével még régi tanúsítványok maradhatnak a konténerekben
A konténerkép az elkészítésekor használt alapképet, csomagokat és függőségeket rögzíti. Ha a host operációs rendszerét frissíted, attól a konténer fájlrendszerében lévő tanúsítványkészlet vagy a futtatókörnyezetbe épített lista még nem változik meg. A konténer újraindítása is ugyanazt a régi képet indíthatja el.
A tartós javításhoz ellenőrzött, javított alap és szükség szerint frissített alkalmazásfüggőség kell, majd új kép készítése és a futó példány cseréje. A Docker dokumentációja külön kezeli az alapképet frissítő letöltést és a buildgyorsítótár kihagyását. A javítás eredményét a telepített példányban kell visszamérni, mert a sikeres build még nem jelenti a futó szolgáltatás cseréjét.
A frissítés után a fontos kapcsolatok működését is próbáljuk ki. Egy bizalmi lánc kivezetése szabályos szolgáltatásnál is okozhat tanúsítványhibát, amelyet a szolgáltatóval kell rendezni. Az általános tanúsítvány-ellenőrzés kikapcsolása ilyenkor újabb védelmi réteget bontana le. A működő, ellenőrzött kapcsolat legyen az elfogadás feltétele.
Az ellenőrzést most indítsd el, a javítást pedig a futó alkalmazásban igazold
A nyilvános közzététel után a hibás kulcsokra épülő visszaélés lehetősége széles körben ismert. A következő tervezett karbantartásig várás helyett az első érintettségi vizsgálatot most érdemes elindítani. A javítás sorrendjében az érzékeny adatot és hozzáférési tokent küldő alkalmazások kapjanak elsőbbséget.
Az incidens közzétételi oldala több érintett tanúsítványlánchoz ad tesztet és offline ellenőrizhető anyagot. A vizsgálatban az alkalmazás saját TLS-kezelését használjuk, érzékeny adatok küldése nélkül. Egyetlen lánc elutasítása csak arról a próbáról ad eredményt. Egy időtúllépés, DNS-hiba vagy tűzfaltiltás pedig nem bizonyítja a tanúsítvány elutasítását.
- Térképezd fel a kimenő kapcsolatokat és a hozzájuk tartozó futó alkalmazásokat, konténereket, tanúsítványtárakat.
- A vizsgált hibás láncokat a valódi TLS-ellenőrzés utasítsa el; külön igazold, hogy egy jogos kapcsolat továbbra is működik.
- A szolgáltatói és disztribúciós útmutató alapján frissíts, majd a futó példány cseréje vagy újratöltése után ismételj ellenőrzést.
- Rögzítsd a vizsgált környezetet, az időpontot, az eredményt és a még nyitott kivételek felelősét.
A vizsgálat eredménye alapján lehet eldönteni, hol kell tanúsítványkészletet vagy futtatókörnyezetet frissíteni, konténerképet cserélni, illetve szolgáltatói tanúsítványláncot javítani. Ha visszaélésre utaló jel is előkerül, őrizd meg a naplókat, és indíts incidensvizsgálatot. Az érintett hozzáférések cseréjéről és a további korlátozásokról a feltárt események alapján kell dönteni.
Az átvizsgálás zárja le a mostani rést, a hardening készítsen fel a következő incidensre
Az eMudhra-incidensre adott válasz akkor teljes, ha a fontos alkalmazások már elutasítják a hibás láncokat, és a jogos kapcsolataik továbbra is működnek. A hardening a biztonsági beállítások megerősítése: a tanúsítvány-ellenőrzés következetes bekapcsolása, a veszélyes kivételek megszüntetése és a frissítések ellenőrizhető eljuttatása a futó példányokhoz. Így a következő hitelesítésszolgáltatói incidensnél már megvan a kapcsolatok listája és a beavatkozás felelőse.
