Teku и Besu обновили свои Docker-образы, поскольку слабые ключи сертификатов создали риск для программ, подключающихся к внешним сервисам, включая некоторые системы валидаторов Ethereum.

Непосредственный вопрос для операторов: может ли их программное обеспечение принять поддельный сертификат при подключении к другому сервису? Ответ зависит от используемых подключений и установки Java, поэтому обновления клиента не означают, что каждый валидатор подвергался одинаковому риску.

СРОЧНО: Клиенты Ethereum Teku и Besu устранили уязвимость, которая могла поставить под угрозу вознаграждения валидаторов.

Обновления устраняют доверие к скомпрометированным сертификатам eMudhra, которые могли позволить злоумышленникам имитировать внешние сервисы и перенаправлять комиссии за блоки в определенных конфигурациях, хотя по умолчанию… pic.twitter.com/CQ0GYM66d2

— crypto.news (@cryptodotnews) [29 октября 2026 г.] (https://x.com/cryptodotnews/status/2115761009088450632?ref_src=twsrc%5Etfw)

Teku и Besu обновили свои Docker-образы

Команды разработчиков клиентов Ethereum выпустили обновления для устранения проблемы с сертификатами, которая возникла за пределами блокчейна. Изменения касаются того, как программное обеспечение определяет, является ли удаленный сервис подлинным.

Teku 26.10.3 и Besu 26.10.2 удаляют доверие к затронутым корневым сертификатам из своих Docker-образов. Эти выпуски последовали за обнаружением слабых ключей, связанных с центром сертификации eMudhra.

Для операторов валидаторов проблема заключается в том, что злоумышленник может выдавать себя за сервис, к которому подключается их программное обеспечение. В зависимости от роли этого сервиса, ложный ответ может нарушить работу или повлиять на то, куда выплачиваются определенные комиссии за блоки.

Это не означает, что каждый валидатор Ethereum подвергся риску. Уведомление о безопасности Teku указывает на то, что стандартный узел основной сети не затронут, и что о случаях эксплуатации не сообщалось.

Разница заключается в установке. Оператор, использующий внешние HTTPS-сервисы, имеет подключения, которые необходимо проверять, в отличие от того, кто использует только локальные компоненты.

Обновления применяются к определенным установкам. В обновленном Docker-образе содержатся изменения в среде выполнения, включенной в него, в то время как программное обеспечение, установленное из архива, может использовать Java, предоставленную отдельно оператором.

Этот инцидент касается инфраструктуры, связанной с валидаторами, в то время как правила консенсуса Ethereum остаются неизменными.

Как проблема с сертификатом стала угрозой безопасности?

Сертификаты помогают программному обеспечению определить, достигло ли оно сервиса, с которым намеревалось связаться. Доверенный центр сертификации подтверждает личность, связанную с сертификатом сервера.

Эта схема хорошо знакома по HTTPS-сайтам, но она также используется в приложениях, которые общаются без браузера. Фоновый сервис может полагаться на те же проверки идентификации.

Центр сертификации может использовать промежуточные сертификаты, находящиеся под доверенным корневым сертификатом. Приватные ключи, связанные с этими промежуточными сертификатами, должны оставаться в безопасности, поскольку они могут быть использованы для подписи других сертификатов.

В данном случае проблема заключалась не просто в том, что кто-то получил обычные учетные данные сервера. Затронутые промежуточные ключи могли быть восстановлены из информации, которая уже была общедоступной.

В сообщении команды безопасности Go говорится, что эта уязвимость позволяла восстанавливать приватные ключи за микросекунды. В нем описывается, как злоумышленник мог создать сертификат для домена, которым он не контролировал.

Уязвимое приложение могло принять этот сертификат, поскольку он, казалось бы, вел к авторитетному центру, которому приложение доверяло. Таким образом, поддельная личность могла пройти проверку, предназначенную для отклонения поддельных сертификатов.

Злоумышленнику все равно нужен был способ перехватить или перенаправить соединение жертвы. Слабый ключ не автоматически помещает его между каждым пользователем и каждым сервером.

Это условие сужает круг возможных способов атаки, но не делает отказ в сертификате безвредным. Перехват сетевого трафика становится более опасным, когда программное обеспечение принимает поддельный сертификат как настоящий.

В исследовании компании Kudelski Security рассматривается структура затронутых сертификатов. Проблема заключается в том, что программное обеспечение могло принимать сертификат, подписанный ключом, который злоумышленник мог воспроизвести.

Компания eMudhra связывает слабые ключи с ошибкой обработки

В заявлении компании eMudhra об инциденте говорится, что исследователь 17 октября сообщил о восьми слабых промежуточных ключах. На следующий день компания отозвала все восемь.

В заявлении говорится, что эти промежуточные сертификаты были созданы во время церемонии генерации ключей 30 апреля 2025 года. По словам компании, из-за ошибки в процессе шифрования и дешифрования были созданы слабые копии ключей вместе с оригинальными, сильными ключами.

Компания утверждает, что использовались сертифицированные аппаратные модули безопасности. Объяснение компании связывает сбой с этапом в процедуре, а не с отсутствием этого оборудования.

Также компания сообщает, что 7 промежуточных сертификатов никогда не использовались в производственной среде, а оставшийся один не выдавал сертификаты. Компания заявляет, что в результате инцидента не произошло компрометации инфраструктуры или утечки данных.

Эти заявления объясняют, что, по словам компании eMudhra, произошло внутри ее собственной инфраструктуры. Поставщикам программного обеспечения все равно пришлось отреагировать на отдельную возможность того, что другая сторона может использовать восстанавливаемые ключи.

Система сертификации не может полагаться только на обещание первоначального оператора не выдавать больше никаких сертификатов. Как только кто-то другой может воспроизвести ключ подписи, эта гарантия больше не контролирует каждый сертификат, который может быть создан.

Поэтому реакция вышла за рамки компании, которая генерировала ключи. Производители браузеров, поставщики операционных систем и команды разработчиков языков программирования должны были рассмотреть, какие сертификаты будет принимать программное обеспечение их пользователей.

Эти исправления доходят до пользователей через различные обновления. Браузер может получить список заблокированных сайтов, в то время как несвязанное Java-приложение продолжает использовать устаревший набор доверенных сертификатов.

Слабый ключ и приложение, которое его использует, – это отдельные части одной и той же проблемы. Отзыв сертификата влияет на записи органа, выдающего сертификаты, в то время как клиенту также необходим надежный способ узнать, что ему следует отклонить этот путь доверия.

Внешние сервисы создают различные риски для валидаторов

Узел Ethereum сочетает в себе программное обеспечение с различными функциями. Документация Ethereum-клиента разделяет клиент выполнения, который обрабатывает выполнение транзакций и состояние, и клиент консенсуса, который следует принципу proof of stake.

Программное обеспечение валидатора добавляет функции, связанные с предложением блоков и подтверждением цепочки. Операторы могут запускать эти компоненты локально или подключать некоторые из них через внешние сервисы.

Teku – это клиент консенсуса, а Besu – клиент выполнения. Оба используют Java, поэтому доверие к сертификатам среды выполнения стало актуальным для их версий.

Внешний сервис может добавить проверку идентификации в эту схему. Программное обеспечение должно знать, что конечная точка, отвечающая на его запросы, является предполагаемым поставщиком.

Например, оператор может использовать уданный сервис для подписи транзакций, а не выполнять операции подписи в том же процессе. Другой может полагаться на внешнюю конечную точку для получения данных или создания блоков.

Ущерб, который может нанести злоумышленник, зависит от того, какие действия разрешены сервису. Сервис, который только получает данные мониторинга, отличается от сервиса, который предоставляет информацию, используемую при принятии решения о подписи.

Вам также может быть интересно: Почему цена Ethereum падает сегодня, 29 октября?

Важен также сетевой путь. Соединение, проходящее через общедоступную инфраструктуру, предоставляет различные возможности для перехвата данных по сравнению с компонентами, ограниченными одним хостом или тщательно контролируемой частной сетью.

Частная сеть не делает каждую ошибку невозможной. Она может уменьшить количество мест, где злоумышленник может получить позицию, необходимую для вмешательства в трафик.

Именно поэтому только название клиента не определяет уровень подверженности риску. Одно и то же программное обеспечение может использоваться в развертываниях с разными конечными точками, хранилищами доверия и средствами контроля доступа.

Важный вопрос заключается в том, какое соединение использовало сертификаты, прошедшие через этот путь. Как только это станет известно, оператор сможет оценить, какие полномочия имел бы поддельный сервис в работе валидатора.

Почему образы Docker и архивные установки отличаются?

Образы Docker упаковывают приложение вместе со средой, необходимой для его работы. Это может включать среду выполнения Java и сертификаты, которым доверяет эта среда выполнения.

Обновление Java на основном компьютере не приводит к автоматической замене Java внутри существующего образа. Контейнер может продолжать использовать свои собственные файлы.

Именно поэтому в описаниях версий клиента указываются изменения, внесенные в Docker. В заметках Teku говорится, что базовый образ Eclipse Temurin еще не содержал соответствующее удаление, поэтому изменения были внесены непосредственно в образ клиента.

В описании версии Besu также говорится, что удаление сертификатов применяется к образам Docker. Там прямо указано, что пользователи должны проверять используемую ими версию Java.

Установка из архива может возложить эту ответственность на оператора. Клиент Ethereum может быть новым, в то время как его отдельная среда выполнения по-прежнему содержит более старый набор сертификатов.

Обратная ситуация также может иметь значение во время обслуживания. Замена среды выполнения на основном компьютере помогает процессам, использующим эту среду выполнения, но не другой установке, которая запускается с другим путем к Java.

Рекомендации Oracle по устранению неполадок рекомендуют пользователям обновить затронутую среду выполнения или следовать описанным альтернативным решениям. Также рекомендуется перезапустить работающие среды выполнения и рассматривать отдельные установки по отдельности.

Это означает, что работающий процесс важнее, чем наличие загруженного обновления. Сервер может содержать обновленные файлы, в то время как более старый процесс продолжает работать до тех пор, пока он не будет заменен или перезапущен.

Настраиваемые хранилища сертификатов добавляют еще один вариант. Организация может использовать хранилище, предназначенное для ее собственных служб, а не только стандартное хранилище, поставляемое с Java.

Практическая задача заключается в том, чтобы определить, что именно использует клиент. Метод установки, расположение среды выполнения и конфигурация доверия вместе определяют, достигло ли опубликованное исправление соединения, которое в нем нуждается.

Проверки отзыва различаются для разных приложений

Отзыв означает, что сертификат больше не должен приниматься. Это не гарантирует, что каждое приложение проверяет самую свежую информацию об отзыве перед установлением соединения.

Приложения могут получать эту информацию различными способами. Некоторые обращаются к онлайн-сервисам, некоторые используют предоставленные поставщиком черные списки, а другие в основном полагаются на сертификаты в локальном хранилище доверия.

Реакция команды Go иллюстрирует, почему поставщик среды выполнения может вмешаться напрямую. Они выпустили срочное обновление безопасности 19 октября и заявили, что обновленные версии были доступны примерно через 7,5 часов после уведомления.

Это действие заблокировало затронутые пути к сертификатам для приложений, использующих соответствующее поведение проверки Go. Пользователям Java требовалась защита через собственные настройки среды выполнения и хранилища доверия.

В уведомлении Teku говорится, что Java по умолчанию не проверяет отзыв. Это дало причину для локального удаления доверия, даже несмотря на то, что eMudhra уже отозвала промежуточные сертификаты.

Удаление корневого сертификата и блокировка промежуточного сертификата также могут работать на разных уровнях. Один отклоняет конкретный скомпрометированный путь, а другой может отклонять более широкий набор цепочек, ведущих к удаленному корневому сертификату.

Правильная реализация принадлежит поставщику и организации, поддерживающей приложение. Несанкционированное изменение, которое отключает проверку подлинности, скорее снизит уровень защиты, чем решит проблему доверия.

Даже легитимные сервисы могут требовать доработки. Если их сертификаты зависят от пути, который клиенты теперь отклоняют, сервис должен предоставить приемлемую замену, а не ожидать, что пользователи восстанавливают небезопасное доверие.

Это объясняет, почему инцидент, связанный с сертификатом, может развиваться в течение нескольких дней. Обнаружение может произойти немедленно, но защита распространяется на браузеры, приложения и частную инфраструктуру через отдельные процессы выпуска и обслуживания.

Для оператора валидатора важным является то, отклоняет ли соответствующее соединение теперь недоверенную подлинность. Объявление об отзыве в другой части программной экосистемы не гарантирует этого результата для процесса, работающего на его узле.

Оказываются ли вознаграждения и доля валидатора под угрозой в равной степени?

Доля валидатора, обязанности по подписи и платежи за услуги связаны, но они регулируются разными механизмами. Проблема, затрагивающая один из них, не должна автоматически означать контроль над всеми.

Документация Ethereum по стейкингу объясняет, что валидаторы получают вознаграждения за выполнение задач и подвергаются штрафам за отключение или совершение доказанных нарушений. Функции подписи и вывода средств имеют разные роли в этой системе.

Ключ сертификата принадлежит системе идентификации, используемой для соединения. Это не является личным ключом подписи валидатора и не раскрывает напрямую учетные данные, необходимые для вывода застейканного ETH.

Тем не менее, поддельный сервис может повлиять на действия валидатора. Эффект зависит от того, какие запросы или ответы обрабатывает сервис, и какие дополнительные проверки остаются в силе.

Предложения блоков включают получателя комиссии для платежей, связанных с выполнением. Следовательно, путь, который может изменить предложение или конфигурацию, может иметь последствия, не давая при этом контроля над всей долей.

Сервис подписи поднимает еще один ряд вопросов, поскольку он участвует в авторизации действий валидатора. Собственные механизмы защиты, включая ограничения на запросы и средства защиты от конфликтующих подписей, могут повлиять на то, чего может достичь злоумышленник.

Пропущенные задачи являются еще одним возможным последствием сбоев в инфраструктуре. Злоумышленник, который предотвращает правильный ответ, может снизить вознаграждения, даже если ни один платеж не был успешно перенаправлен.

Эти результаты имеют разные финансовые последствия. Упущенные возможности для создания блоков, обычные штрафы за неактивность и "слэшинг" – это не взаимозаменяемые описания потерь.

Рекомендации для клиентов описывают возможные последствия в зависимости от затронутых конфигураций. Они не утверждают, что каждый оператор столкнулся с этими последствиями или что соответствующая сумма ETH была украдена.

Для пользователей, использующих сервисы стейкинга, актуальность определяется фактической конфигурацией, используемой этим сервисом. Объем управляемого ETH не позволяет определить, какие удаленные сервисы или хранилища сертификатов используются операторами.

Валидаторы также зависят от программного обеспечения, находящегося за пределами Ethereum

Правила сети Ethereum — это лишь часть того, на чем полагается оператор. Аппаратное обеспечение, среды выполнения, хостинг, конфигурация и внешние сервисы — все это влияет на то, насколько правильно валидатор выполняет свои функции.

Авторитетный центр сертификации находится за пределами протокола Ethereum, но его сбой может стать важным, если программное обеспечение валидатора доверяет ему идентификацию сервиса. Эта связь достаточна, чтобы привести проблему безопасности в интернете к инфраструктуре стейкинга.

Разнообразие клиентских решений остается полезным, поскольку отдельные реализации снижают зависимость от одного и того же кода. Это не делает каждую зависимость независимой.

Два клиента могут использовать одну и ту же среду выполнения языка программирования. Разные операторы также могут использовать одного и того же поставщика услуг хостинга, сервиса подписи или инфраструктуры сборки.

Эти общие компоненты могут создавать общие уязвимости, даже если само программное обеспечение Ethereum отличается. Поэтому понимание конфигурации требует большего, чем просто подсчет количества используемых клиентских решений.

Аутсорсинг также может вносить свои компромиссы. Специализированный сервис подписи может улучшить защиту ключей, но при этом делает аутентифицированное подключение к этому сервису более важным.

Локальная работа требует собственного обслуживания. Размещение компонентов на одном компьютере может снизить некоторые сетевые риски, но оператор все равно должен управлять обновлениями программного обеспечения и доступом к этому компьютеру.

Этот инцидент не указывает на какую-либо архитектуру, которая автоматически является самой безопасной в любой ситуации. Он показывает, почему важно понимать и поддерживать ответственность, связанную с каждым подключением.

Это различие также важно для обычных пользователей ETH. Обновление сертификата в инфраструктуре узла не означает, что каждый кошелек должен переводить средства или что балансы учетных записей Ethereum изменились.

Действия должны быть предприняты операторами программного обеспечения, на которые это повлияло. Они являются теми, кто может определить используемую среду выполнения, конечную точку и настройки доверия, а затем применить соответствующие рекомендации поставщика к системам, которые устанавливают эти соединения.

Операторам необходимо применять и проверять обновления

Выпущенные обновления предоставляют операторам возможность удалить затронутые пути доверия из поддерживаемых образов Docker. Пользователи устаревших версий должны учитывать отдельные требования к среде выполнения в соответствии с рекомендациями поставщика Java.

Доступность обновлений — это лишь первый этап этого процесса. Также необходимо, чтобы обновленная среда работала, а запланированные конфигурации и сервисы продолжали функционировать.

Для поставщиков услуг сбой, вызванный отклоненным сертификатом, может потребовать изменения сертификата на конечной точке. Восстановление сервиса должно сохранять проверки подлинности, а не обходить их.

Дополнительная информация может уточнить степень влияния. Оператор может обнаружить конфигурацию, которая допускает использование уязвимой цепочки, или сообщить об инциденте, связанном с конкретной службой.

На данный момент уведомление Teku не содержит информации об эксплуатации уязвимости и различает использование основной сети по умолчанию и затронутые внешние подключения. Это является наиболее четкой основой для описания текущей уязвимости в сети Ethereum.

Затронутые операторы имеют основания для обновления. Любые финансовые потери будут зависеть от того, какую службу злоумышленник пытался имитировать, перехватывал ли он трафик и какие действия эта служба могла выполнять.

Что следует отслеживать

• Обновления клиентов: Следите за выпусками Teku и Besu и убедитесь, что установлены обновленные версии.
• Сертификаты Java: Проверьте рекомендации поставщиков для используемой среды выполнения Java и хранилища сертификатов в каждой установке.
• Внешние подключения: Проверьте HTTPS-ссылки на удаленные сервисы подписи, обработки данных и создания блоков.
• Уведомления о безопасности: Следите за подтвержденными атаками или дальнейшими инструкциями от команд разработчиков клиентов и поставщиков Java.

Часто задаваемые вопросы

В чем заключалась проблема с eMudhra?

Инцидент связан со слабыми закрытыми ключами, используемыми в промежуточных сертификатах от удостоверяющего центра eMudhra. Исследователи обнаружили, что эти ключи можно восстановить из общедоступной информации, что позволяет злоумышленнику создавать сертификаты для доменов, которыми он не владеет. Программное обеспечение, которое доверяет затронутой цепочке сертификатов, может принять эту поддельную идентификацию. Злоумышленнику все равно потребуется способ перехвата или перенаправления соединения, прежде чем он сможет имитировать целевую службу.

Сработал ли механизм консенсуса Ethereum?

Нет. Описанная проблема касается того, как программное обеспечение проверяет идентификацию внешних служб, а не правил Ethereum, определяющих достижение консенсуса в блокчейне. Обновления клиентов изменяют механизм проверки сертификатов в затронутой программной среде. Некоторые конфигурации валидаторов все еще могут подвергаться операционным рискам, если внешняя служба будет замаскирована под другую. Эта возможность зависит от подключения и роли службы и не означает, что правила консенсуса Ethereum были нарушены.

Какие клиенты были обновлены?

Teku 26.10.3 и Besu 26.10.2 изменили свои Docker-образы, чтобы удалить затронутую цепочку сертификатов. Teku является клиентом консенсуса, а Besu — клиентом выполнения, и оба используют Java. Метод установки важен, поскольку изменение применяется к среде, предоставляемой в этих образах. Операторам, которые устанавливают клиентские архивы и предоставляют собственную среду выполнения Java, необходимо отдельно проверить рекомендации для этой среды.

Все ли валидаторы подвержены риску?

Нет. В уведомлении Teku указано, что стандартный узел основной сети не подвержен риску. Риск зависит от того, использует ли конфигурация соответствующие внешние HTTPS-соединения и принимает ли проверка сертификатов затронутую цепочку. Разные операторы могут использовать один и тот же клиент с разными сервисами, версиями Java и хранилищами сертификатов. Поэтому название клиента или количество ETH, заложенного валидатором, не позволяет определить, подвержен ли конкретный валидатор риску.

Охватывает ли обновление Docker все установки?

Нет. Обновленное Docker-ображение обновляет среду, упакованную внутри этого образа, но установка из архива может использовать Java, поставляемую отдельно оператором. Другие контейнеры или сервисы также могут иметь свои собственные среды выполнения. Операторам необходимо определить, какую установку использует запущенный процесс, и следовать инструкциям поставщика. Обновленные файлы на сервере не защищают процесс, который продолжает работать со старой средой.

Было ли подтверждено использование уязвимости?

В уведомлении компании Teku не сообщалось об использовании уязвимости на момент публикации этой статьи. Описания содержат информацию об уязвимости и возможных последствиях, но не подтверждают, что злоумышленник использовал ее против валидатора. Это различие важно при обсуждении возможных убытков. Возможность подмены сервиса не является доказательством того, что были скомпрометированы функции подписи, перенаправлены платежи за комиссии или украден ETH, находящийся в залоге.

Автоматически ли становятся доступны данные о депозитах валидаторов?

Нет. Ключ для подписи сертификатов отличается от ключа подписи валидатора или учетных данных, контролирующих вывод средств. Восстановление скомпрометированного ключа сертификата не раскрывает автоматически ключи, необходимые для вывода заложенного ETH. Подмененный сервис все равно может нарушить работу или повлиять на информацию, используемую валидатором, в зависимости от конфигурации. Возможные последствия необходимо учитывать для этого конкретного сервиса, а не рассматривать как автоматический доступ ко всему депозиту.

Что должен сделать оператор?

Операторы должны следовать соответствующим рекомендациям по обновлению от Teku или Besu и инструкциям для своей версии Java. Им необходимо определить среду выполнения и хранилище сертификатов, используемые каждым затронутым процессом, включая те, которые поставляются внутри контейнеров. После применения рекомендованного обновления они должны убедиться, что обновленный сервис работает и что необходимые соединения все еще функционируют. Отключение проверок сертификатов для восстановления неработающего соединения лишит защиту, которую эти проверки обеспечивают.

Отказ от ответственности: Эта статья предназначена только для информационных и образовательных целей и не является финансовым или инвестиционным советом. Приведенные данные отражают информацию, содержащуюся в регуляторных документах и отчетах, доступных на момент написания, и могут меняться с каждой новой публикацией. Ничто из представленного здесь не является рекомендацией к покупке, продаже или хранению каких-либо ценных бумаг или активов. Всегда проводите собственное исследование. Информация актуальна по состоянию на 29 октября 2026 года.