Клиенты Ethereum закрыли уязвимость, позволявшую перенаправлять вознаграждения в ETH
Криптографическая ошибка индийской сертификационной компании проникла в Ethereum и могла позволить злоумышленникам незаметно перенаправлять себе вознаграждения за блоки некоторых валидаторов. Teku — консенсус-клиент, который многие валидаторы используют для работы Ethereum на proof-of-stake, — во вторник выпустил версию 26.10.3. Клиент исполнения Besu, обрабатывающий транзакции Ethereum, в понедельник выпустил версию 26.10.2. Оба обновления перестают доверять сертификатам, связанным с индийской eMudhra, в Docker-образах — готовых пакетах, которые использует многие операторы.
Валидаторы — это компьютеры, которые стейкают ETH для защиты Ethereum и получают комиссии за предложение блоков. Некоторые из них связываются с другими сервисами через интернет и полагаются на цифровые сертификаты, чтобы убедиться, что подключение идет к нужному сервису.
17 октября исследователи выяснили, что закрытые ключи восьми промежуточных центров сертификации eMudhra были сгенерированы с недостаточной энтропией. Это означало, что ключи можно было восстановить по самим сертификатам, которые находятся в открытом доступе. Любой владелец таких ключей мог выпускать сертификаты, которые непропатченное ПО принимало бы за подлинные. Браузеры заблокировали такие сертификаты, eMudhra отозвала их на следующий день, а компания затем заявила, что уйдет из сертификационного бизнеса.
Java, на которой работают Teku и Besu, по умолчанию не проверяет отзыв сертификата. Docker-образы Teku продолжали доверять плохим сертификатам даже после того, как браузеры перестали их принимать. Злоумышленник, находящийся между валидатором и сервисом, к которому тот подключается, мог выдавать себя за этот сервис. В рекомендации по безопасности Teku говорится, что обманутый таким образом валидатор мог предложить блок, который направляет комиссии на адрес атакующего. Фальшивый внешний сервис подписи — отдельный сервис, хранящий ключи валидатора, — мог выдать подписи для изменения получателя вознаграждений; Teku оценил такую конфигурацию как наиболее рискованную.
«Узел Teku с настройками по умолчанию в основной сети не затронут и не требует действий», — написала команда, добавив, что «сообщений об эксплуатации уязвимости не поступало».
Партнер Teku по безопасности Consensys Diligence первым указал на проблему. Операторам, которые запускают Teku или Besu напрямую на своих машинах, без Docker, придется самостоятельно обновить Java: обновление ПО Ethereum не затрагивает список доверенных сертификатов Java. Новые Docker-образы также не исправляют Java, установленную на хосте. Тем, кто все еще использует Java 26, исправление потребует больше усилий. Teku сообщила, что эта версия больше не поддерживается и пропатченной сборки не будет; таким операторам нужно перейти на Java 25.
