НовостиКриптовалютыКлиенты Ethereum Teku и Besu экстренно исправляют уязвимость из-за сбоя сертификатов eMudhra

Клиенты Ethereum Teku и Besu экстренно исправляют уязвимость из-за сбоя сертификатов eMudhra

Автор: CryptoMeter io·

Ключевые выводы

  • •Криптографическая ошибка в апреле 2025 года привела к тому, что eMudhra сгенерировала восемь промежуточных ключей удостоверяющего центра с восстанавливаемыми закрытыми ключами; эта слабость оставалась незамеченной около 18 месяцев, пока независимый исследователь не обнаружил её 17 октября 2026 года.
  • •Teku выпустил версию 26.10.3 27 октября, а Besu — версию 26.10.2 26 октября, удалив доверие к затронутым удостоверяющим центрам из дистрибутивов Docker.
  • •При определённых конфигурациях злоумышленники при атаках типа «человек посередине» теоретически могли вмешиваться в коммуникации между валидаторами и внешними сервисами подписания, потенциально перенаправляя комиссии за блоки на подконтрольные им адреса.
  • •Конфигурации основной сети Ethereum по умолчанию не пострадали, и разработчики не зафиксировали подтверждённых случаев эксплуатации затронутых установок Teku.
  • •Администраторам, запускающим Teku или Besu напрямую на серверах, необходимо отдельно проверить установки Java и хранилища доверенных сертификатов, поскольку одно лишь обновление клиента Ethereum может не устранить уязвимость.
Клиенты Ethereum Teku и Besu экстренно исправляют уязвимость из-за сбоя сертификатов eMudhra

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

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

Как сбой сертификатов eMudhra создал риски безопасности

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

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

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

Teku и Besu выпускают экстренные обновления безопасности

В ответ разработчики клиентов Ethereum удалили доверие к затронутым удостоверяющим центрам из своих дистрибутивов Docker. Teku выпустил версию 26.10.3 27 октября, а Besu — версию 26.10.2 26 октября.

Исправления направлены на устранение рисков, связанных с HTTPS-соединениями, зависящими от скомпрометированных цепочек сертификатов. При определённых конфигурациях злоумышленники, проводящие атаки типа «человек посередине» — незаметно ретранслирующие и изменяющие трафик между двумя сторонами, — потенциально могли вмешиваться в коммуникации между валидаторами и внешними сервисами подписания. Теоретически такие атаки могли перенаправлять комиссии за блоки на адреса, контролируемые злоумышленниками.

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

Дополнительные проверки Java для операторов Ethereum

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

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