Коротко
- Teku 26.10.3 и Besu 26.10.2 отменяют доверие к корневым сертификатам, связанным с eMudhra, после того как скомпрометированные промежуточные ключи подвергли риску подделки некоторые конфигурации валидаторов на основе HTTPS.
- Стандартные ноды Teku мейннета не пострадали, и случаи эксплуатации не сообщались, при этом риск зависел от валидаторов, подключавшихся к внешним сервисам через HTTPS.
- Пользователи Docker должны обновить образы клиентов, в то время как операторы в автономном режиме должны отдельно применить патчи для 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 и операционная безопасность выходят за рамки кода консенсуса.
Наиболее рискованные сценарии включали валидаторы, подключающиеся к внешним сервисам через 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 validator infrastructure incidents, которые показали, как зависимости вне протокола могут влиять на операции стейкинга.
Java 26 создает сложность, поскольку достиг конца срока поддержки и не будет получать необходимые исправленные сборки, что означает, что затронутым операторам необходимо перейти на Java 25. Сетевое взаимодействие Ethereum типа «точка-точка» не было открыто, поскольку оно не зависит от этих центров сертификации. Исправления снижают риск, связанный с доверенным хранилищем сторонних разработчиков, но не устраняют эксплуатацию на живом мейннете и не изменяют протокол Ethereum. Этот инцидент следует за другими мерами по безопасности, включая Glamsterdam deposit-routing correction, что подчеркивает, как безопасность валидаторов зависит от кода протокола и вспомогательной инфраструктуры.