Klienci Ethereum naprawiają lukę, która może przekierować nagrody ETH

Deweloperzy klientów Ethereum, Teku i Besu, wydali aktualizacje zabezpieczeń, aby rozwiązać problem z certyfikatem, który mógłby pozwolić atakującym na podszywanie się pod usługi używane przez walidatorów i potencjalnie przekierować ich nagrody blokowe.

Podsumowanie

• Klienci Ethereum, Teku i Besu, wydali aktualizacje zabezpieczeń po odkryciu luki w certyfikacie, która mogła pozwolić atakującym na przekierowanie nagród blokowych walidatorów na ich własne adresy.
• Luka pochodziła z słabych kluczy kryptograficznych związanych z ośmioma urzędami certyfikacyjnymi prowadzonymi przez indyjską firmę eMudhra, co mogło pozwolić atakującym na tworzenie fałszywych certyfikatów.
• Teku ostrzegło, że atakujący mogą podszywać się pod zewnętrzne usługi używane przez walidatorów Ethereum i manipulować propozycjami bloków lub uzyskiwać wrażliwe podpisy walidatorów w określonych konfiguracjach.
• Domyślne konfiguracje mainnet Teku nie były dotknięte, a deweloperzy potwierdzili, że nie zgłoszono wykorzystania tej luki.
• Operatorzy korzystający z samodzielnych instalacji Teku lub Besu muszą oddzielnie zaktualizować swoje środowiska Java, ponieważ najnowsze poprawki obrazu Docker nie aktualizują automatycznie lokalnie zainstalowanych certyfikatów Java.

Zgodnie z poradnikami bezpieczeństwa towarzyszącymi wydaniom, problem wynikał z skompromitowanych kluczy urzędów certyfikacyjnych należących do indyjskiego dostawcy certyfikatów cyfrowych eMudhra, co pozostawiło niektóre konfiguracje węzłów Ethereum narażone na fałszywe połączenia HTTPS.

Teku wydało wersję 26.10.3 27 października, podczas gdy Besu wprowadziło wersję 26.10.2 dzień wcześniej. Obie aktualizacje usuwają zaufanie do dotkniętych certyfikatów eMudhra z ich obrazów Docker, które operatorzy używają do wdrażania i uruchamiania oprogramowania węzła Ethereum.

Luka mogła wpłynąć na walidatorów, którzy polegają na zewnętrznych usługach do podpisywania transakcji, komunikacji z węzłami beacon lub otrzymywania informacji o budowaniu bloków. Atakujący musiałby przechwycić dotknięte połączenie i przedstawić fałszywy certyfikat, który oprogramowanie walidatora zaakceptuje jako autentyczny.

Deweloperzy Teku potwierdzili, że domyślne konfiguracje mainnet nie były dotknięte i powiedzieli, że nie zgłoszono wykorzystania tej luki.

Luka w zabezpieczeniach Ethereum związana z skompromitowanymi certyfikatami eMudhra

Problem z zabezpieczeniami rozpoczął się od błędu kryptograficznego dotyczącego ośmiu pośrednich urzędów certyfikacyjnych prowadzonych przez eMudhra, których klucze prywatne okazały się być generowane przy użyciu niewystarczającej losowości.

Badacze zidentyfikowali problem 17 października, odkrywając, że klucze prywatne można matematycznie odzyskać z informacji dostępnych w publicznych certyfikatach.

Zgodnie z poradnikiem bezpieczeństwa z 26 października od Microsoftu, sześć z dotkniętych certyfikatów było używanych do zabezpieczania połączeń internetowych, podczas gdy pozostałe dwa były związane z podpisywaniem kodu.

Skompromitowane klucze mogły pozwolić komuś na tworzenie certyfikatów, które wydawały się autentyczne dla aplikacji, które nadal ufały dotkniętym urzędom certyfikacyjnym.

eMudhra unieważniła dotknięte pośrednie certyfikaty 18 października, podczas gdy dostawcy technologii zaczęli usuwać zaufanie do skompromitowanych łańcuchów certyfikatów z ich oprogramowania.

Microsoft następnie zablokował dotknięte urzędy certyfikacyjne poprzez aktualizację zabezpieczeń Windows 20 października i wydał kolejną aktualizację 26 października, aby usunąć siedem powiązanych certyfikatów z listy zaufanych.

Jednak problem pozostał istotny dla Ethereum, ponieważ Teku i Besu używają Javy, której walidacja certyfikatów domyślnie nie sprawdza statusu unieważnienia.

W rezultacie dotknięte instalacje Javy mogły nadal akceptować certyfikaty związane z skompromitowanymi urzędami, nawet po ich unieważnieniu.

Jak atakujący mogą przekierować nagrody walidatorów Ethereum

Poradnik bezpieczeństwa Teku zidentyfikował kilka możliwych scenariuszy ataku dotyczących walidatorów, którzy komunikują się z zewnętrznymi usługami za pośrednictwem połączeń HTTPS.

Jednym ze scenariuszy jest atakujący podszywający się pod zdalny węzeł sygnalizacyjny używany przez walidatora do koordynacji jego obowiązków na Ethereum.

Jeśli atakujący skutecznie przechwyci połączenie i przedstawi sfałszowany certyfikat, walidator może otrzymać zmanipulowane informacje o bloku, który przygotowuje do zaproponowania.

Według Teku, taki atak mógłby spowodować, że walidator zaproponuje blok, który kieruje opłaty transakcyjne na adres kontrolowany przez atakującego.

W zaleceniu zidentyfikowano zewnętrzne usługi podpisywania jako kolejny potencjalnie narażony komponent. Usługi te przechowują klucze podpisywania walidatora oddzielnie od głównego oprogramowania węzła i dostarczają podpisy na żądanie.

Atakujący podszywający się pod zewnętrznego sygnatariusza mógłby potencjalnie uzyskać podpisy związane z wyjściami walidatora, w zależności od konfiguracji i dostępnych zabezpieczeń.

Teku sklasyfikowało ten scenariusz jako szczególnie poważny, chociaż konfiguracje wykorzystujące wzajemną autoryzację TLS mogłyby ograniczyć konsekwencje do odmowy usługi.

Inne potencjalnie dotknięte połączenia obejmują klientów wykonawczych, budowniczych bloków, przekaźniki i usługi używane do pobierania informacji o konfiguracji walidatora.

Luka ta nie wpłynęła na podstawowe protokoły sieciowe Ethereum, które nie polegają na skompromitowanych organach certyfikacyjnych.

Teku i Besu wydają poprawki dla dotkniętych węzłów Ethereum

Po ujawnieniu, Teku wydało wersję 26.10.3, aby usunąć cztery korzenie certyfikatów ze swoich obrazów Docker, w tym emSign ECC Root CA G3, emSign Root CA G1, emSign Root CA G2 i AAA Certificate Services.

Besu wprowadziło te same usunięcia certyfikatów w wersji 26.10.2, rozwiązując ryzyko dla operatorów korzystających z jego zaktualizowanych obrazów Docker.

Jednak wydania te nie aktualizują automatycznie instalacji Java utrzymywanych oddzielnie przez operatorów węzłów.

Użytkownicy uruchamiający Teku lub Besu za pomocą samodzielnych dystrybucji binarnych muszą sprawdzić swoją zainstalowaną wersję Java i zaktualizować jej zaufane certyfikaty w razie potrzeby.

Teku ostrzegło, że operatorzy wciąż używający Java 26 będą musieli przejść na Java 25, ponieważ wcześniejsza wersja osiągnęła koniec życia i nie otrzyma wymaganego poprawionego buildu.

Zalecenie dodatkowo zidentyfikowało pewne konfiguracje testnet jako potencjalnie narażone, w tym ustawienia, które pobierają swój początkowy stan blockchainu przez HTTPS.

Aktualizacje zabezpieczeń następują po innych niedawnych obawach dotyczących infrastruktury walidatorów Ethereum. Na początku tego miesiąca, crypto.news doniosło, że MetaMask rozpoczął wycofywanie dotkniętych walidatorów po oddzielnym incydencie związanym z bezpieczeństwem infrastruktury ujawnionym 30 września.

Ostatnio deweloperzy Ethereum poprawili błąd wpłaty walidatora w nadchodzącej aktualizacji Glamsterdam po tym, jak badacze zidentyfikowali scenariusz, w którym konta budownicze mogłyby otrzymać ETH przeznaczone dla walidatorów.

Aktualizacja Glamsterdam napotkała osobne opóźnienia po tym, jak deweloperzy odłożyli aktywację testnetu Hoodi, aby zbadać problemy z kompatybilnością kontraktów inteligentnych związane z EIP-8037.

Opóźnienie z 26 października usunęło zaplanowaną aktywację zarówno zmian wykonawczych Amsterdamu, jak i zmian konsensusu Gloas, wraz z proponowanym zwiększeniem limitu gazu Hoodi do 200 milionów. Deweloperzy Ethereum nie ogłosili daty zastępczej aktywacji.