Коротко
- Teku 26.10.3 і Besu 26.10.2 відміняють довіру до кореневих сертифікатів, пов’язаних з eMudhra, після того як скомпрометовані проміжні ключі виставили під загрозу деякі конфігурації валідаторів на основі HTTPS.
- За замовчуванням ноди Teku мейннету не були вплинуті, і жодних випадків експлуатації не повідомлялося, тоді як ризик залежав від валідаторів, які підключалися до зовнішніх сервісів через HTTPS.
- Користувачі Docker повинні оновити образи клієнта, тоді як оператори у standalone-режимі повинні окремо застосувати патчі для Java; користувачі Java 26 повинні перейти на підтримувані збірки Java 25.
Teku та Besu випустили оновлення безпеки після того, як скомпрометовані ключі центру сертифікації eMudhra відкрили конфігурації нод ethereum можливості для підроблених HTTPS-з’єднань. Примітки до випуску Teku рекомендують версію 26.10.3, яка видаляє довіру до чотирьох пошкоджених кореневих сертифікатів із Docker-образів, тоді як Besu випустила версію 26.10.2. Оновлення вирішують питання довіри до сертифікатів на рівні розповсюдження програмного забезпечення, а не виявляють недолік у правилах консенсусу ethereum. За замовчуванням ноди mainnet Teku не були вплинуті, що робить цей інцидент окремим від уразливостей у протоколі Ethereum.
Скомпрометовані ключі сертифікатів створили ризик підробки
Дослідники виявили, що приватні ключі восьми проміжних центрів сертифікації eMudhra можна відновити, оскільки вони були згенеровані з недостатньою випадковістю. Хоча сертифікати були відкликані, Java за замовчуванням не перевіряє відкликання, що залишає середовища виконання здатними приймати підроблені сертифікати. Зловмисник, розташований між нодою та HTTPS-сервісом, може таким чином імітувати цей кінцевий пункт у вразливих конфігураціях. Цей випадок підкреслює, чому Ethereum client diversity and operational security поширюються далі за код консенсусу.
Найбільш ризикованими сценаріями були випадки, коли валідатори підключалися до зовнішніх служб через HTTPS. Підроблений ендпоінт міг маніпулювати інформацією про побудову блоків, перенаправляти отримувачів комісій або отримувати підписи через імітованого зовнішнього підписувача. Teku зазначила, що зловмисник міг спричинити те, що клієнт валідатора, що використовує віддалену beacon-ноду, запропонує блок, у якому комісії сплачуються на адресу зловмисника. Ризик залежав від положення в мережі та конфігурацій віддалених служб, а не просто від використання Teku чи Besu. Жодних випадків експлуатації не було повідомлено.
Teku 26.10.3 видаляє довіру до emSign ECC Root CA G3, emSign Root CA G1, emSign Root CA G2 та AAA Certificate Services у Docker-образах. Оновлення Besu застосовує той самий підхід. Оператори, які запускають бінарні файли безпосередньо, повинні оновити Java окремо, оскільки оновлення клієнта не замінює сховище сертифікатів хост-середовища. Тому для Docker-розгортань і автономних розгортань потрібні різні шляхи виправлення. Ця різниця має значення після инцидентів інфраструктури Ethereum-валідатора, які показали, як залежності поза протоколом можуть впливати на операції стейкінгу.
Java 26 створює складність, оскільки він досяг кінця життєвого циклу і не отримуватиме необхідних виправлень, що означає, що вплинутий оператори повинні перейти на Java 25. Однорівневе Ethereum-мережеве взаємодія не була відкрита, оскільки вона не залежить від цих центрів сертифікації. Виправлення зменшують ризик довіри до стороннього сховища сертифікатів, не виправляючи активного експлойту на мейннеті чи не змінюючи протокол Ethereum. Цей випадок є продовженням інших робіт з безпеки, включаючи Glamsterdam deposit-routing correction, що підкреслює, як безпека валідаторів залежить від коду протоколу та супутньої інфраструктури.