Teku и Besu исправили риск перехвата наград Ethereum

Разработчики Ethereum выпустили обновления Teku и Besu после обнаружения ошибки в цифровых сертификатах, которая в определённых конфигурациях могла позволить подменить удалённый сервис валидатора и изменить адрес получения комиссий за блок. Besu 26.10.2 вышел 26 октября 2026 года, Teku 26.10.3 - 27 октября. 29 октября история получила широкую огласку в криптовалютных СМИ. При этом, по состоянию на публикацию официального предупреждения Teku от 28 октября, подтверждённых атак не было.

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

Для обычного владельца ETH эта новость не означает, что его кошелёк можно взломать через сертификат eMudhra. Команда Teku прямо уточнила: стандартный узел основной сети, не подключающийся по HTTPS к внешним службам, не затронут. Риск возникал только там, где программное обеспечение валидатора полагалось на уязвимую проверку доверия к удалённому серверу. Подробности приведены в официальном предупреждении Teku.

Как чужая ошибка попала в инфраструктуру Ethereum

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

Такие сертификаты выпускают удостоверяющие центры - Certificate Authorities, или CA. Браузер либо приложение принимает их, если доверяет цепочке подписи. Проблема eMudhra заключалась в том, что приватные ключи восьми промежуточных CA были созданы с недостаточной криптографической случайностью. Исследователь сообщил о находке 17 октября; 18 октября eMudhra отозвала эти сертификаты.

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

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

Как могли перенаправить награды за блок

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

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

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

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

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

Уязвимость затрагивала не каждый узел Teku

Одна из самых важных строк официального предупреждения звучит однозначно: стандартный Teku в Ethereum mainnet не затронут и не требует действий именно из-за этого случая. В стандартном сценарии он не использует внешние HTTPS-адреса из списка рискованных подключений. Обмен данными по одноранговым протоколам Ethereum не основан на сертификатах eMudhra.

Для операторов вопрос стоит конкретнее: присутствуют ли в конфигурации HTTPS-соединения с удалёнными сервисами? Teku перечисляет внешних подписантов, удалённые beacon-узлы, конфигурации proposer, билдеров и MEV-релеев, удалённые execution-клиенты, checkpoint-синхронизацию и некоторые источники начального состояния. На тестовых сетях HTTPS может использоваться автоматически при загрузке состояния в новый узел.

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

Нельзя и заменять HTTPS на обычный HTTP ради устранения ошибки: в последнем случае подтверждение личности удалённого сервера отсутствует изначально. Разработчики рекомендуют исправить доверенное хранилище сертификатов и при необходимости дополнительно закрепить доверие за конкретным сертификатом или собственным CA.

Почему отзыв сертификатов 18 октября не закрыл вопрос

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

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

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

Teku 26.10.3 и Besu 26.10.2: что именно исправили

В релизе Teku 26.10.3 от 27 октября разработчики объявили об исключении из Docker-образов доверия к emSign ECC Root CA - G3, emSign Root CA - G1, emSign Root CA - G2 и AAA Certificate Services. Команда отдельно объяснила, что исходный базовый образ Eclipse Temurin ещё не содержал необходимого изменения.

Аналогичное исправление вошло в Besu 26.10.2, опубликованный 26 октября. Иными словами, две команды не меняли правила начисления ETH и не запускали экстренный хардфорк сети. Они убрали опасные сертификаты из окружения готовых контейнеров, которое устанавливает доверенные HTTPS-соединения.

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

По данным предупреждения Teku, Java 26 к октябрю уже вышла из поддержки и не получит необходимого исправления. Для операторов, использующих эту ветку, разработчики указали переход на поддерживаемую Java 25. Проверять нужно не только номер версии, но и наличие соответствующих исправлений у поставщика сборки: разные дистрибутивы обновляют доверенное хранилище по-разному. Подробные проверки опубликованы в руководстве OpenJDK.

Что проверить оператору валидатора сейчас

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

• Определите окружение. Уточните, работают ли Teku или Besu в Docker, Kubernetes или непосредственно на сервере. Для контейнеров сравните фактические теги и digest образов с исправленными релизами.
• Проверьте внешние HTTPS-адреса. Особенно внимательно рассмотрите подключения к удалённому подписанту, beacon-узлу, конфигурации proposer и builder. Не публикуйте конфигурационные файлы целиком: в URL и переменных окружения могут находиться секреты.
• Проверьте Java отдельно. При самостоятельном запуске используйте официальную диагностику и рекомендации поставщика JDK. На некоторых Linux-дистрибутивах системное хранилище и Java-хранилище обновляются разными способами.
• Усилите границы доверия. По возможности держите критические службы в частной сети, применяйте взаимную TLS-аутентификацию для внешнего подписанта и ограничивайте список допустимых центров сертификации конкретного соединения.
• Проверьте получателя комиссий. У операторов с удалённой конфигурацией предложения блока важно убедиться, что fee recipient и builder-настройки соответствуют ожидаемым. Подозрительное отклонение требует расследования, а не автоматического вывода о краже.

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

Что делать владельцам ETH и клиентам биржевого стейкинга

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

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

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

Почему это не та же уязвимость, что в Glamsterdam

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

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

Что известно о последствиях к 29 октября

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

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

Главный вывод: проблема возникла в сторонней системе доверия к HTTPS-сертификатам, а не в механизме хранения ETH. Операторам специфических конфигураций Teku и Besu нужно обновить контейнеры и проверить Java. Обычным пользователям Ethereum не требуется срочно перемещать монеты: оснований для этого в официальном предупреждении нет. Актуальные данные о сети и рынке доступны в разделе Ethereum на BarbadosNews.

Автор

Barbados