Rossz címre kerülhetett volna az ETH: biztonsági rést zártak be az Ethereum kliensei

A Teku alapértelmezett főhálózati konfigurációját ugyanakkor nem érintette a probléma, és a fejlesztők nem kaptak jelentést a hiba kihasználásáról.

Az Ethereumon kívül kezdődött a probléma

A biztonsági ügy kiindulópontja az indiai eMudhra digitálistanúsítvány-szolgáltatóhoz vezetett. A vállalat nyolc köztes hitelesítésszolgáltatójánál olyan kriptográfiai hibát tártak fel, amely miatt a privát kulcsok nem tekinthetők biztonságosnak. Ezeket a kulcsokat elégtelen véletlenszerűséggel állították elő, így a nyilvánosan elérhető tanúsítványok adataiból matematikai úton vissza lehetett állítani őket.

Ez azért súlyos probléma, mert a digitális tanúsítványok segítenek igazolni, hogy egy titkosított internetes kapcsolat másik végén valóban a keresett szolgáltatás található. Ha egy támadó hozzájut egy megbízhatónak elfogadott hitelesítésszolgáltató privát kulcsához, hamis tanúsítványokat készíthet. Az érintett szoftverek ezeket hitelesnek fogadhatják el, miközben valójában egy megszemélyesített szolgáltatáshoz kapcsolódnak.

A mostani eset tehát nem az Ethereum blokkláncának közvetlen feltöréséről szól. A kockázat a csomópontok és az általuk használt külső szolgáltatások közötti egyes HTTPS-kapcsolatok hitelesítésében jelentkezett. A támadás sikeréhez ráadásul arra is szükség lett volna, hogy az elkövető be tudjon avatkozni az érintett hálózati kommunikációba.

A visszavonás önmagában nem oldott meg mindent

A kutatók október 17-én azonosították a problémát, az eMudhra pedig október 18-án visszavonta az érintett köztes tanúsítványokat. A technológiai szolgáltatók ezt követően megkezdték a veszélyessé vált tanúsítványláncok kizárását saját rendszereikből. A Microsoft október 26-i biztonsági tájékoztatása szerint az érintett tanúsítványok közül hat internetes kapcsolatok hitelesítéséhez, kettő pedig kódaláíráshoz kapcsolódott.

A Microsoft október 20-án Windows-frissítéssel blokkolta az érintett hitelesítésszolgáltatókat. Október 26-án újabb frissítés következett, amely hét kapcsolódó tanúsítványt távolított el a megbízhatónak minősített tanúsítványok listájáról. A probléma kezelése azonban nem minden szoftverkörnyezetben működik ugyanúgy.

Az Ethereum-kliensek szempontjából a Java működése volt meghatározó. A Teku és a Besu is Java-alapú szoftver, a Java tanúsítvány-ellenőrzése pedig alapértelmezés szerint nem vizsgálja a visszavonási állapotot. Emiatt bizonyos futtatókörnyezetek a visszavonás után is elfogadhattak olyan tanúsítványokat, amelyek a kompromittálódott hitelesítésszolgáltatókhoz kapcsolódtak.

Hogyan téríthették volna el az ETH-bevételeket?

A Teku biztonsági elemzése több lehetséges támadási helyzetet is bemutatott. Az egyik egy távoli beacon node-hoz, vagyis az Ethereum konszenzusfolyamataiban részt vevő csomóponthoz kapcsolódó validátorkliens esetét írta le. Ha a támadó megszemélyesíti ezt a szolgáltatást, manipulált adatokat továbbíthat a validátornak az előterjesztésre váró blokkról.

A következmény az lehetett volna, hogy a validátor olyan blokkot ír alá és terjeszt elő, amelynek díjbevétele egy támadó által ellenőrzött címre kerül. Ez a blokkjavaslathoz kapcsolódó díjbevétel eltérítését jelenti, nem automatikusan a validátor teljes lekötött ETH-állományának ellopását. A különbség lényeges, mert a támadás hatóköre az érintett kapcsolattól és a konfigurációtól függött.

A hamis tanúsítvány önmagában még nem lett volna elegendő. A támadónak a validátor és a külső szolgáltatás közötti adatforgalomba is be kellett volna avatkoznia, miközben a kliensnek el kellett fogadnia a hamis hitelesítést. A fejlesztők tájékoztatása szerint a sérülékenység tényleges kihasználásáról nem érkezett jelentés. 

A külső aláíró szolgáltatásoknál nagyobb lehetett a tét

A figyelmeztetés külön kitért a külső aláíró szolgáltatásokra. Ezek a validátori aláírókulcsokat a fő csomópontszoftvertől elkülönítve kezelik, és a megfelelő kérésekre digitális aláírásokat biztosítanak. Az elkülönítés hasznos biztonsági megoldás, de a két rendszer közötti kommunikáció hitelessége továbbra is alapvető követelmény.

Bizonyos konfigurációkban a kapcsolat manipulálásával a támadó a validátor önkéntes kilépéséhez kapcsolódó aláírásokhoz is hozzájuthatott volna. A Teku ezt különösen súlyos lehetséges következményként kezelte, mivel az érvényesen kezdeményezett kilépés visszafordíthatatlan. Ez nem azonos a lekötött eszközök támadói címre történő közvetlen átutalásával, de megszakíthatja a validátor működését és jövőbeli jutalomszerzését.

A meglévő védelmi intézkedések jelentősen módosíthatták a kockázatot. Kölcsönös TLS-hitelesítés esetén mindkét kommunikáló fél igazolja magát, így egy hamis szervertanúsítvány nem ad automatikusan hozzáférést a valódi aláíró szolgáltatáshoz. A fejlesztői tájékoztatás szerint ilyen beállítás mellett a következmény szolgáltatásmegtagadásra, vagyis a működés akadályozására korlátozódhatott.

Nem minden Ethereum-csomópont volt érintett

A lehetségesen veszélyeztetett kapcsolatok között a távoli végrehajtási kliensek, a blokképítők, a relay szolgáltatások és a validátori konfigurációt továbbító külső végpontok is szerepeltek. Ezek különböző feladatokat látnak el, de közös bennük, hogy egyes telepítéseknél HTTPS-en keresztül kommunikálnak a csomóponttal. A sérülékenység akkor válhatott relevánssá, ha a kapcsolat hitelesítése továbbra is megbízott az érintett tanúsítványláncokban.

A Teku alapértelmezett mainnet-konfigurációját a fejlesztők szerint nem érintette a hiba. Ezt azonban nem szabad úgy értelmezni, hogy minden főhálózati Teku-telepítés védett volt: a külső HTTPS-végpontokat használó egyedi beállítások külön ellenőrzést igényelhetnek. Az érintettséget tehát a tényleges konfiguráció határozza meg.

Az Ethereum csomópontjai közötti alapvető, peer-to-peer hálózati protokollokat nem érintette ez a tanúsítványprobléma. Ezek nem a kompromittálódott hitelesítésszolgáltatókra támaszkodnak. A kockázat így a kapcsolódó szolgáltatásokkal folytatott kommunikáció meghatározott részére korlátozódott.

Megérkeztek a Teku és a Besu javításai

A Teku október 27-én adta ki a 26.10.3-as verziót, a Besu pedig egy nappal korábban jelentette meg a 26.10.2-es kiadást. A frissítések a Docker-képekben megszüntették a bizalmat a problémás tanúsítványláncokhoz kapcsolódó gyökértanúsítványok iránt. Ezek a konténerképek a csomópontszoftver mellett a futtatásához szükséges környezetet is tartalmazzák. 

A módosítás az emSign ECC Root CA – G3, az emSign Root CA – G1, az emSign Root CA – G2 és az AAA Certificate Services gyökértanúsítványokat érintette. A bizalmi listából való eltávolítás célja, hogy a szoftver többé ne fogadjon el az érintett láncokra támaszkodó hitelesítést. A gyökértanúsítványok kizárása ugyanakkor nem jelenti azt, hogy mindegyik gyökér privát kulcsa kompromittálódott: a feltárt probléma a köztes hitelesítésszolgáltatók kulcsaihoz kapcsolódott.

A frissítésnél különösen fontos a telepítési mód. A javított Docker-kép használata a konténerben található környezetet kezeli, a külön telepített Java-rendszert viszont nem frissíti automatikusan. Fordítva is igaz: a gazdagépen végrehajtott Java-frissítés önmagában nem cseréli le a konténeren belüli futtatókörnyezetet.

A külön telepített Java további figyelmet igényel

Az önálló bináris csomagból futtatott Teku vagy Besu a csomópont üzemeltetője által telepített Java-környezetre támaszkodik. Ezeknél a rendszereknél külön kell ellenőrizni, hogy a használt Java-kiadás és annak tanúsítványtára tartalmazza-e a szükséges javításokat. A kliens verziószámának frissítése önmagában nem feltétlenül szünteti meg a tanúsítványokból eredő kockázatot.

A Teku tájékoztatója a Java 26 használóinak a Java 25-re történő átállást javasolta. A megadott indok szerint a Java 26 rövid támogatású kiadásként már elérte támogatási életciklusának végét, ezért nem kapja meg a szükséges javított változatot. A megfelelő környezet kiválasztásánál így a támogatási állapotot és a ténylegesen alkalmazott biztonsági javításokat is figyelembe kell venni.

Bizonyos teszthálózati konfigurációk szintén érintettek lehettek. Ilyenek azok a telepítések, amelyek induláskor HTTPS-en keresztül töltik le a kezdeti blokkláncállapotot. Ez jól mutatja, hogy a tanúsítványok biztonsága a csomópont első indításakor is számíthat, nem kizárólag a folyamatos validátori működés során.

Más biztonsági ügyek is foglalkoztatják az Ethereum fejlesztőit

A frissítések olyan időszakban érkeztek, amikor a validátori infrastruktúra más problémái is figyelmet kaptak. Egy szeptember 30-án nyilvánosságra hozott, különálló infrastruktúra-biztonsági incidens után a MetaMask megkezdte az érintett validátorok kiléptetését. Ezt az esetet azonban nem szabad összemosni az eMudhra tanúsítványhibájával.

A készülő Glamsterdam-frissítés fejlesztése során egy más jellegű validátori befizetési hibát is korrigáltak. A feltárt helyzetben a validátoroknak szánt ETH blokképítői számlákra kerülhetett volna. Ez eltérő technikai probléma, nem a most javított HTTPS-hitelesítési sérülékenység következménye.

A Glamsterdam Hoodi teszthálózati aktiválását október 26-án külön okból, az EIP-8037-hez kapcsolódó okosszerződés-kompatibilitási aggályok vizsgálata miatt halasztották el. A halasztás az Amsterdam végrehajtási és a Gloas konszenzusoldali változtatásainak ütemezését, valamint a Hoodi gas limitjének tervezett, 200 millióra emelését is érintette. Az ismertetett fejlemények idején új aktiválási időpontot még nem jelentettek be.

A biztonság a futtatókörnyezeten is múlik

A mostani eset arra világít rá, hogy egy Ethereum-validátor biztonságát a kliens mellett a Java-környezet, a tanúsítványtár és a külső szolgáltatásokhoz vezető kapcsolatok együtt határozzák meg. Egy más területen feltárt kriptográfiai hiba így a blokkláncos infrastruktúrában is kockázatot teremthet. A pontos érintettség megállapításához ezért a teljes telepítést kell áttekinteni.

A lényeg: a Teku és a Besu javított Docker-kiadásai már elérhetők, a külön kezelt Java-telepítések viszont önálló ellenőrzést igényelnek. A Teku alapértelmezett főhálózati beállítását nem érintette a hiba, és a fejlesztők nem számoltak be ismert visszaélésről. A bejelentés tehát egy komoly, bizonyos konfigurációkban fennálló támadási lehetőség lezárásáról szól, nem igazolt, tömeges ETH-lopásról.