Teku и Besu обновили свои Docker-образы после инцидента с eMudhra, поскольку слабый ключ сертификата создавал риски для программного обеспечения, подключающегося к внешним сервисам, включая некоторые развертывания валидаторов Ethereum.
- Teku 26.10.3 и Besu 26.10.2 удалили доверие к затронутым сертификатам в Docker-образах из-за инцидента eMudhra.
- Teku сообщает, что по умолчанию узлы основной сети не затронуты, и фактический уровень экспозиции зависит от HTTPS-соединения и Java-среды выполнения, используемой оператором.
- Раскрытые риски связаны с поддельными сервисами и операциями валидаторов; в уведомлении Teku не сообщалось о случаях эксплуатации.
Для операторов самым прямым вопросом сейчас является: будет ли их программное обеспечение принимать поддельные сертификаты при подключении к другим сервисам. Ответ зависит от используемого соединения и установки Java, поэтому обновление клиента не означает, что каждый валидатор сталкивается с одинаковым риском.
Обновление Docker-образов Teku и Besu
Команда клиентов Ethereum выпустила обновление для устранения проблемы с сертификатом, возникшей вне блокчейна. Соответствующие изменения касаются того, как программное обеспечение определяет подлинность удаленных сервисов.
Teku 26.10.3 и Besu 26.10.2 удалили доверие к корневым сертификатам, затронутым их Docker-образами. Этот выпуск связан с обнаружением слабых ключей, связанных с центром сертификации eMudhra.
Для операторов валидаторов проблема заключается в том, что злоумышленник выдает себя за сервис, к которому подключено программное обеспечение. В зависимости от роли этого сервиса, поддельные ответы могут нарушить распределение обязанностей или повлиять на направление платежей за блоки.
Это не означает, что каждый валидатор Ethereum подвержен риску. Согласно уведомлению о безопасности Teku, стандартные узлы главной сети не затронуты, и на данный момент не сообщалось о случаях эксплуатации.
Разница заключается в способе установки. Операторы, использующие внешний HTTPS-сервис, должны проверять соединения, которые могут отсутствовать при полностью локальном развертывании компонентов.
Эти обновления применяются к конкретной среде установки. Исправленный образ Docker содержит модифицированные среды выполнения, упакованные внутри контейнера, тогда как программное обеспечение, установленное из архивного файла, может использовать Java, предоставленную оператором отдельно.
Это событие затронуло инфраструктуру вокруг валидаторов, но правила консенсуса Ethereum остались неизменными.
Почему проблемы с сертификатами могут превратиться в риск безопасности?
Сертификаты помогают программному обеспечению определить, подключено ли оно к ожидаемому сервису. Доверенные центры выдачи сертификатов обеспечивают подтверждение личности, соответствующей серверному сертификату.
Этот механизм часто используется на веб-сайтах HTTPS, но также применим и к приложениям, не использующим браузер для связи. Фоновые службы также могут зависеть от этих проверок подлинности.
Центры сертификации могут использовать промежуточные сертификаты под доверенными корневыми сертификатами. Приватные ключи, связанные с этими промежуточными сертификатами, должны оставаться в безопасности, так как они могут быть использованы для выдачи дополнительных сертификатов.
В этом инциденте проблема заключалась не только в том, что кто-то получил обычные данные для входа на сервер. Затронутые промежуточные ключи можно восстановить из уже опубликованной информации.
Группа безопасности Go заявила, что эта уязвимость позволяет восстановить закрытый ключ на уровне микросекунд. В описании также указано, что злоумышленник может затем создавать сертификаты для доменов, которыми он не управляет.
Если уязвимое приложение считает, что сертификат в конечном итоге можно проследить до доверенного им учреждения, оно может принять его. Таким образом, подделка личности может пройти через проверки, предназначенные для отказа в доступе мошенникам.
Однако злоумышленнику все еще нужен какой-либо способ перехватить или перенаправить соединение жертвы. Слабые ключи не позволяют им автоматически оказываться между каждым пользователем и каждым сервером.
Это условие ограничивает способы, которыми может произойти атака, но не делает отзыв сертификата безвредным. Пока программное обеспечение воспринимает поддельный объект как настоящую конечную точку, перехват сети становится более опасным.
Исследование Kudelski Security изучило затронутые уровни сертификатов. Проблема заключается в том, что программное обеспечение может принимать сертификаты, подписанные ключами, которые злоумышленник может воспроизвести.
eMudhra приписывает слабые ключи ошибкам обработки
Заявление eMudhra гласит, что исследователь сообщил о 8 слабых промежуточных ключах 17 октября. Компания отозвала эти 8 ключей на следующий день.
Компания заявила, что эти промежуточные сертификаты были сгенерированы во время церемонии ключей 30 апреля 2025 года. Согласно компании, дефектные шаги wrap и unwrap создали слабые копии помимо исходных надежных ключей.
Компания заявила, что использует сертифицированный аппаратный модуль безопасности. Она объяснила, что сбой произошел из-за одного из этапов вспомогательных процессов, а не из-за отсутствия такого оборудования.
Компания также сообщила, что семь промежуточных сертификатов никогда не использовались в производственной среде, а оставшийся один еще не выдавался для подписания сертификатов. Компания заявила, что инцидент не привел к компрометации инфраструктуры или утечке данных.
Эти утверждения объясняют описание eMudhra своих внутренних процессов. Однако поставщику программного обеспечения все еще необходимо учитывать другую возможность: другие стороны могут использовать восстанавливаемые ключи.
Система сертификации не может полагаться только на обещание первоначального оператора больше не выдавать никакие сертификаты. Как только кто-то другой сможет воспроизвести тот же ключ подписи, такое обещание больше не сможет контролировать все возможные сертификаты, которые могут быть созданы.
Следовательно, меры реагирования вышли за рамки компании, создавшей ключ. Производители браузеров, поставщики операционных систем и команды языков программирования должны учитывать, какое программное обеспечение будет принимать их пользователи.
Эти исправления будут переданы пользователям через различные обновления. Браузер может получить список блокировок, в то время как другое независимое Java-приложение может продолжать использовать старый набор доверенных сертификатов.
Слабые ключи и приложения, принимающие эти ключи, — это две разные части одной и той же проблемы. Отзыв сертификата решает проблему на уровне записей организации, но клиентам также необходим надежный способ определить, какие пути доверия следует отклонить.
Внешние сервисы создают различные риски для валидаторов
Эфириум-ноды состоят из программного обеспечения, выполняющего различные функции. Документация по клиентам Эфириума различает исполнительные клиенты и консенсусные клиенты: первые обрабатывают выполнение транзакций и состояние, а вторые следуют консенсусу на основе доказательства участия.
Программное обеспечение валидатора добавило обязанности по предложению блоков и подтверждению цепочки. Операторы могут запускать эти компоненты локально или подключать часть из них через внешние сервисы.
Teku — это консенсус-клиент, Besu — это исполнительный клиент. Оба используют Java, что объясняет, почему доверие к сертификатам во время выполнения связано с их выпуском.
Сервисы за пределами локального компьютера добавляют дополнительную проверку подлинности для такого соглашения. Программа должна подтвердить, что endpoint, ответивший на запрос, является ожидаемым поставщиком.
Например, операторы могут использовать удаленные сервисы подписи, а не выполнять операции подписи в одном процессе. Некоторые могут полагаться на внешние точки для получения данных или услуг по построению блоков.
Вред, который могут причинить подделки, зависит от того, какие действия разрешены для этого сервиса. Сервис, который только получает мониторинговые данные, и сервис, участвующий в принятии решений о подписи, имеют разный уровень риска.
Сетевой путь также важен. Соединения, проходящие через общую инфраструктуру, имеют иные возможности перехвата по сравнению с компонентами, ограниченными одной хост-системой или строго контролируемой частной сетью.
Частная сеть не может исключить все возможные сбои, но она снижает вероятность того, что злоумышленник получит доступ к местоположению, необходимому для вмешательства в трафик.
Таким образом, по одному только имени клиента нельзя определить, подвержен ли он риску. Одно и то же программное обеспечение может быть развернуто в средах с различными конечными точками, хранилищами доверия и системами контроля доступа.
Фактически нуждающийся в ответе вопрос: какой соединение прошло через затронутый путь и приняло сертификат. Как только это будет установлено, операторы смогут оценить, какие права должны были быть у поддельного сервиса в работе проверяющего.
Почему образы 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?
Нет. Проблемы, описанные в отчете, касаются того, как программное обеспечение проверяет идентичность внешних сервисов, а не правил, по которым Эфириум достигает согласия в блокчейне. Обновление клиента изменяет доверие к сертификатам в затронутой программной среде. Некоторые развертывания валидаторов могут по-прежнему подвергаться операционным рискам при подмене внешних сервисов. Эта возможность зависит от соединения и роли сервиса и не означает нарушения правил консенсуса Эфириума.
Какие клиенты были обновлены?
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. Необходимо определить среду выполнения и хранилища сертификатов, используемые каждым затронутым процессом, включая те, которые предоставляются внутри контейнеров. После применения рекомендуемых обновлений следует убедиться, что обновленные службы работают корректно и необходимые соединения продолжают функционировать. Отключение проверки сертификатов для восстановления неудавшихся соединений устраняет защиту, которую эти проверки должны были обеспечить.