Ethereum client timovi Teku i Besu objavili su bezbednosne zakrpe nakon otkrivanja problema sa digitalnim sertifikatima koji je, u određenim konfiguracijama, mogao omogućiti napadaču da se predstavi kao pouzdani servis i potencijalno preusmeri nagrade validatora.
Propust nije bio direktno u Ethereum protokolu, već u lancu poverenja HTTPS sertifikata koje koriste određene Java instalacije i spoljni servisi povezani sa validatorima.
Prema dostupnim informacijama, nije zabeležen nijedan potvrđen slučaj iskorišćavanja ove ranjivosti, a podrazumevane Teku mainnet konfiguracije nisu bile pogođene.
Problem potiče od kompromitovanih eMudhra sertifikata
Ranjivost je povezana sa indijskim pružaocem digitalnih sertifikata eMudhra.
Istraživači su otkrili problem sa osam intermediate certificate authority sertifikata čiji su privatni ključevi generisani sa nedovoljno kvalitetnom nasumičnošću.
To je ozbiljan kriptografski propust.
Ako je privatni ključ certificate authorityja moguće matematički rekonstruisati iz javno dostupnih informacija, napadač potencijalno može da napravi lažni sertifikat koji izgleda kao legitiman.
U određenim uslovima softver bi takav sertifikat mogao da prihvati kao autentičan.
Problem otkriven 17. oktobra
Istraživači su 17. oktobra identifikovali da se privatni ključevi pogođenih certificate authorityja mogu rekonstruisati.
Od osam pogođenih sertifikata, šest je korišćeno za zaštitu internet konekcija, dok su dva bila povezana sa code-signing sistemima.
eMudhra je pogođene intermediate sertifikate opozvala već 18. oktobra.
Nakon toga su različiti tehnološki provajderi počeli da uklanjaju poverenje u kompromitovane certificate chains.
Microsoft brzo reagovao
Microsoft je 20. oktobra objavio Windows bezbednosno ažuriranje kojim su pogođeni certificate authorityji blokirani.
Dodatno ažuriranje stiglo je 26. oktobra i uklonilo sedam povezanih sertifikata iz trusted liste.
Međutim, problem kod Ethereum infrastrukture ostao je relevantan zbog načina na koji Java proverava sertifikate.
Teku i Besu su Java aplikacije, a Java po podrazumevanim podešavanjima ne proverava uvek revocation status sertifikata na način koji bi automatski rešio ovakav problem.
Zbog toga određene Java instalacije mogu nastaviti da veruju kompromitovanom sertifikatu čak i nakon formalnog opoziva.
Kako je napadač mogao da preusmeri ETH nagrade?
Najzanimljiviji scenario odnosi se na validatora koji koristi udaljeni beacon node ili drugi eksterni servis preko HTTPS konekcije.
Napadač bi prvo morao da presretne komunikaciju.
Zatim bi mogao da predstavi falsifikovani HTTPS sertifikat napravljen pomoću kompromitovanog certificate authority ključa.
Ako validator prihvati taj sertifikat kao validan, napadač bi mogao da se predstavi kao servis kojem validator veruje.
U jednom od scenarija validator bi mogao da dobije manipulisane informacije o bloku koji treba da predloži.
Rezultat bi mogao biti blok u kojem se transaction fee prihod šalje na adresu koju kontroliše napadač, umesto na adresu validatora.
Nije bilo moguće jednostavno ukrasti sav stakovani ETH
Važno je razlikovati preusmeravanje nagrade od potpunog preuzimanja validatora.
Ranjivost nije značila da bilo ko može jednostavno da ukrade svih 32 ETH koliko standardni validator ima u stakingu.
Napad bi zahtevao specifičnu konfiguraciju i mogućnost presretanja mrežne komunikacije.
Najdirektniji scenario odnosio se na manipulaciju servisima koje validator koristi tokom predlaganja blokova i time na preusmeravanje određenih prihoda.
Ipak, drugi scenariji mogli su biti ozbiljniji u zavisnosti od infrastrukture validatora.
External signer predstavljao dodatni rizik
Teku je posebno upozorio na konfiguracije koje koriste external signing servise.
Kod takvog sistema validator privatne ključeve ne čuva direktno u glavnoj node aplikaciji.
Umesto toga, poseban servis čuva ključeve i potpisuje poruke kada validator to zatraži.
To je čest bezbednosni model jer omogućava bolju izolaciju privatnih ključeva.
Međutim, ako napadač uspe da se predstavi kao legitiman external signer ili da manipuliše komunikacijom sa njim, mogao bi pokušati da dobije osetljive potpise.
Potencijalno su mogli biti pogođeni validator exit potpisi
U određenim konfiguracijama napadač bi potencijalno mogao da dobije potpise povezane sa validator exit operacijama.
Teku je ovaj scenario ocenio kao posebno ozbiljan.
Koliko bi napad bio uspešan zavisilo bi od konkretne infrastrukture, dozvoljenih operacija i dodatnih zaštitnih mehanizama.
Konfiguracije koje koriste mutual TLS autentifikaciju bile su bolje zaštićene.
Kod njih bi napadač u pojedinim slučajevima mogao da izazove samo prekid usluge, umesto da dobije mogućnost da se uspešno predstavi kao druga strana.
Mogli su biti pogođeni i drugi servisi
Problem nije bio ograničen samo na beacon nodeove i external signere.
Potencijalno pogođene HTTPS konekcije uključivale su i:
execution cliente,
block buildere,
MEV relay servise,
i servise sa kojih validator preuzima određene konfiguracione informacije.
Zajednički faktor jeste korišćenje HTTPS sertifikata iz kompromitovanog trust chaina.
Ethereum P2P mreža nije bila pogođena
Veoma važna stvar je da ranjivost nije uticala na osnovni Ethereum peer-to-peer protokol.
Ethereum nodeovi za međusobnu P2P komunikaciju ne oslanjaju se na iste kompromitovane certificate authorityje.
To znači da sam Ethereum consensus ili P2P networking nije bio kompromitovan.
Problem se odnosio na dodatne HTTPS veze između validator infrastrukture i spoljnih servisa.
Teku objavio verziju 26.10.3
Teku je 27. oktobra objavio novu verziju 26.10.3.
Update uklanja poverenje prema nekoliko pogođenih certificate roots iz Docker imagea koji se koristi za pokretanje Teku softvera.
Uklonjeni su:
emSign ECC Root CA G3,
emSign Root CA G1,
emSign Root CA G2,
i AAA Certificate Services.
Operatori koji koriste novi Teku Docker image time automatski dobijaju izmenjenu trust konfiguraciju.
Besu zakrpu objavio dan ranije
Besu je odgovarajuću ispravku objavio u verziji 26.10.2, dan pre Tekua.
I Besu update uklanja iste problematične certificate authorities iz svog Docker okruženja.
Za korisnike koji nodeove pokreću pomoću zvaničnih Docker imageova, prelazak na novu verziju predstavlja glavni korak zaštite.
Ali kod standalone instalacija situacija je nešto komplikovanija.
Standalone korisnici moraju posebno da provere Javu
Operator koji Teku ili Besu pokreće kao samostalnu binarnu aplikaciju može imati sopstvenu Java instalaciju.
U tom slučaju update Tekua ili Besua ne mora automatski promeniti sertifikate kojima Java veruje.
Zbog toga operator mora da proveri verziju Java runtimea i njegov trust store.
Ako Java i dalje veruje kompromitovanim sertifikatima, sama nadogradnja Ethereum clienta možda nije dovoljna.
Korisnicima Java 26 savetovan prelazak na Java 25
Teku je posebno upozorio korisnike koji i dalje koriste Java 26.
Ta verzija je stigla do kraja svog životnog ciklusa i neće dobiti potrebnu zakrpu.
Operatorima je zato savetovan prelazak na podržanu Java 25 verziju sa odgovarajućim bezbednosnim ažuriranjima.
Ovo je važan detalj jer pokazuje da sigurnost nodea ne zavisi samo od Ethereum client softvera.
Operativni sistem, Java runtime, Docker image i drugi infrastrukturni delovi takođe mogu predstavljati bezbednosni rizik.
Podrazumevana Teku mainnet konfiguracija nije bila pogođena
Teku developeri naveli su da default mainnet konfiguracije nisu bile ranjive na opisani scenario.
To značajno smanjuje potencijalni obim problema.
Najveći rizik postojao je kod operatora koji koriste specifične eksterne HTTPS servise i konfiguracije.
Takođe nije prijavljen nijedan slučaj u kojem je ranjivost zaista iskorišćena protiv Ethereum validatora.
Zakrpe su zato prvenstveno preventivna mera.
Testnet konfiguracije mogle su biti izložene
Određene testnet konfiguracije ipak su mogle biti pogođene.
Posebno se navode setupi koji inicijalno blockchain stanje preuzimaju preko HTTPS konekcije.
Ako bi se takva konekcija oslanjala na kompromitovani certificate chain, napadač bi teoretski mogao da manipuliše podacima koje node preuzima.
Zato update treba primeniti i na testne sisteme, a ne samo na mainnet infrastrukturu.
Ovo nije prvi bezbednosni problem Ethereum validator infrastrukture ovog meseca
Najnovije zakrpe dolaze nakon još nekoliko bezbednosnih događaja povezanih sa Ethereum validatorima.
MetaMask je ranije počeo da povlači određene validatore nakon zasebnog sigurnosnog incidenta koji je objavljen krajem septembra.
Takođe je tokom razvoja predstojeće Glamsterdam nadogradnje ispravljen propust vezan za validator depozite.
U tom scenariju određeni builder nalozi mogli su da dobiju ETH namenjen validatorima.
To je odvojena ranjivost i nema direktnu vezu sa problemom eMudhra sertifikata.
Glamsterdam testiranje takođe odloženo
Ethereum developeri su dodatno odložili planiranu Hoodi testnet aktivaciju za Glamsterdam upgrade.
Razlog je istraga problema kompatibilnosti smart contracta povezanih sa EIP-8037.
Planirana aktivacija Amsterdam execution promena i Gloas consensus promena zato nije izvršena po prvobitnom rasporedu.
Istovremeno je odloženo i planirano povećanje Hoodi gas limita na 200 miliona.
Novi datum aktivacije još nije objavljen.
Šta validator operatori treba da urade?
Najvažnija preporuka je jednostavna: ažurirati Teku i Besu na najnovije bezbednosne verzije.
Teku operatori treba da koriste najmanje verziju 26.10.3, dok Besu korisnici treba da pređu na 26.10.2 ili noviju verziju koja uključuje iste izmene.
Docker korisnici treba da povuku nove imageove.
Standalone korisnici dodatno moraju proveriti Java runtime i listu trusted sertifikata.
Posebno je važno proveriti infrastrukturu ako validator koristi remote beacon node, external signer, builder, relay ili druge udaljene HTTPS servise.
Nema razloga za paniku među običnim ETH vlasnicima
Za prosečnog korisnika koji samo drži ETH u walletu ovaj problem nema direktan uticaj.
Ranjivost nije povezana sa MetaMask seed frazama, običnim Ethereum adresama ili standardnim transferom ETH-a.
Ona se odnosi na specifičnu validatorsku infrastrukturu i način na koji određeni nodeovi proveravaju HTTPS sertifikate spoljnih servisa.
Zato obični ETH holderi ne moraju da menjaju wallet ili prebacuju sredstva zbog ove konkretne ranjivosti.
Incident pokazuje koliko je validatorska infrastruktura složena
Ethereum validator danas često ne koristi samo jedan program.
Tipičan setup može uključivati consensus client, execution client, validator client, MEV relay, block builder infrastrukturu, external signer, monitoring i različite cloud servise.
Svaka dodatna komponenta povećava fleksibilnost sistema, ali istovremeno uvodi novu tačku potencijalnog napada.
Najnovija ranjivost dobar je primer problema koji nije nastao u Ethereum kriptografiji niti consensus protokolu, već u potpuno spoljašnjem certificate authority sistemu.
Ipak, posledice su mogle da se prenesu sve do Ethereum validator nagrada.
Zaključak
Ethereum client timovi Teku i Besu zakrpili su bezbednosni propust koji je u određenim konfiguracijama mogao omogućiti napadaču da se predstavi kao pouzdani servis i potencijalno preusmeri validator block rewards.
Problem je nastao zbog osam kompromitovanih certificate authority sertifikata kompanije eMudhra, čiji su privatni ključevi bili generisani sa nedovoljno kvalitetnom nasumičnošću.
Teku je objavio verziju 26.10.3, dok je Besu objavio 26.10.2.
Podrazumevane Teku mainnet konfiguracije nisu bile pogođene, a do sada nije prijavljen nijedan potvrđen slučaj iskorišćavanja ranjivosti.
Najveću pažnju treba da obrate validator operatori koji koriste udaljene beacon nodeove, external signere, block buildere, relaye i druge HTTPS servise.
Docker korisnici mogu da reše problem prelaskom na nove imageove, dok standalone instalacije zahtevaju i proveru Java certificate trust storea.
Za obične vlasnike ETH-a nema neposredne opasnosti.
