Teku y Besu actualizaron sus respectivas imágenes Docker tras el evento de eMudhra, ya que la clave de certificado débil representaba un riesgo para el software que se conecta a servicios externos, incluyendo algunas implementaciones de validadores de Ethereum.
- Teku 26.10.3 y Besu 26.10.2 eliminan los certificados afectados de la confianza en las imágenes de Docker debido al evento eMudhra.
- Teku indica que los nodos de red principal por defecto no se ven afectados; el grado real de exposición depende de la conexión HTTPS y del entorno de ejecución de Java utilizado por el operador.
- Los riesgos divulgados involucran servicios y operadores de validadores suplantados; no se ha informado ningún aprovechamiento en el aviso de Teku.
Para los operadores, la pregunta más inmediata es: ¿aceptará su software certificados falsificados al conectarse a otros servicios? La respuesta depende de la conexión utilizada y la instalación de Java, por lo que una actualización del cliente no implica que todos los validadores enfrenten el mismo riesgo.
Actualización de las imágenes Docker de Teku y Besu
El equipo del cliente de Ethereum ha lanzado una actualización para corregir un problema de certificado que surgió fuera de la cadena de bloques. Los cambios relacionados afectan cómo el software determina la autenticidad de los servicios remotos.
Teku 26.10.3 y Besu 26.10.2 eliminaron la confianza en las raíces de certificados afectados desde sus imágenes Docker. Este lanzamiento se debió al descubrimiento de claves débiles relacionadas con la autoridad de certificación eMudhra.
Para los operadores de validadores, el problema radica en que un atacante se hace pasar por el servicio al que se conecta el software. Según el rol de dicho servicio, una respuesta falsificada puede alterar las responsabilidades o afectar a dónde se dirigen ciertas tarifas de bloque.
Pero esto no significa que todos los validadores de Ethereum estén expuestos al riesgo. El aviso de seguridad de Teku indica que los nodos de la red principal por defecto no se ven afectados y actualmente no se han reportado explotaciones.
La diferencia radica en el método de instalación. Los operadores que utilizan un servicio HTTPS externo deben verificar conexiones que pueden no estar presentes en implementaciones completamente localizadas.
Estas actualizaciones son aplicables a entornos de instalación específicos. La imagen de Docker parcheada incluye modificaciones en tiempo de ejecución empaquetadas dentro del contenedor, mientras que el software instalado desde el archivo archivado podría utilizar Java proporcionado por el operador.
Este evento afectó la infraestructura circundante de los validadores, pero las reglas de consenso de Ethereum no cambiaron.
¿Por qué los problemas de certificados se convierten en riesgos de seguridad?
Los certificados ayudan al software a determinar si está conectado al servicio esperado. Las autoridades de certificación confiables respaldan la identidad correspondiente al certificado del servidor.
Este mecanismo es común en sitios HTTPS, pero también es aplicable en aplicaciones que no se comunican a través de un navegador. Los servicios de fondo también pueden depender de estas validaciones de identidad.
La autoridad de certificación puede utilizar certificados intermedios debajo de los certificados raíz de confianza. Las claves privadas asociadas a estos certificados intermedios deben mantenerse seguras, ya que pueden utilizarse para emitir más certificados.
En este incidente, el problema no fue solo que alguien obtuvo la información de inicio de sesión normal del servidor. Las claves intermedias afectadas pueden recuperarse a partir de información ya pública.
El equipo de seguridad de Go indicó que esta vulnerabilidad permite recuperar la clave privada a nivel de microsegundos. Su descripción también señala que los atacantes pueden luego crear certificados para dominios que no controlan.
Si una aplicación vulnerable considera que el certificado aún puede rastrearse hasta una autoridad en la que confía, podría aceptarlo. Así, la suplantación de identidad podría pasar por las verificaciones diseñadas originalmente para rechazar a los imitadores.
Sin embargo, los atacantes aún necesitan alguna forma de interceptar o redirigir la conexión de la víctima. Las claves débiles no los colocan automáticamente entre cada usuario y cada servidor.
Esta condición reduce las formas en que puede ocurrir un ataque, pero no hace que la invalidación del certificado sea inofensiva. Si el software trata al impostor como un punto final legítimo, la interceptación de red se vuelve más peligrosa.
La investigación de Kudelski Security examinó la jerarquía de certificados afectados. El problema radica en que el software podría aceptar certificados emitidos por claves que un atacante puede reproducir.
eMudhra atribuye las claves débiles a errores de procesamiento.
El comunicado de evento de eMudhra indica que un investigador informó sobre 8 claves intermedias débiles el 17 de octubre. La empresa revocó estas 8 claves al día siguiente.
La empresa indicó que estos certificados intermedios se generaron durante una ceremonia de claves el 30 de abril de 2025. Según la empresa, los pasos defectuosos de wrap y unwrap generaron copias débiles además de las claves fuertes originales.
La empresa afirmó que utilizó módulos de seguridad hardware certificados. Explicó que atribuyó el fallo a un paso en los procesos periféricos, y no a la falta de este tipo de dispositivos.
La empresa también indicó que los siete certificados intermedios nunca se utilizaron en entornos de producción, y el restante aún no ha emitido ningún certificado. La empresa afirmó que el incidente no provocó la intrusión en la infraestructura ni la fuga de datos.
Estas afirmaciones explican la descripción de eMudhra sobre su funcionamiento interno. Sin embargo, el proveedor de software aún debe enfrentar otra posibilidad: otras partes podrían utilizar claves recuperables.
El sistema de certificados no puede depender únicamente del compromiso del operador original de no emitir más contenido. Una vez que otros puedan reproducir una clave de firma, este compromiso ya no puede controlar todos los certificados que podrían crearse.
Por lo tanto, las medidas de respuesta han trascendido a la empresa que generó la clave. Los fabricantes de navegadores, los proveedores de sistemas operativos y los equipos de lenguajes de programación deben considerar qué software aceptarán sus usuarios.
Estas correcciones se transmitirán a los usuarios a través de diferentes actualizaciones. El navegador puede recibir una lista de bloqueo, mientras que otra aplicación Java independiente aún podría seguir utilizando el conjunto antiguo de certificados de confianza.
Las claves débiles y las aplicaciones que aceptan dichas claves son dos partes distintas del mismo problema. La revocación del certificado resuelve el problema a nivel de registro institucional, pero los clientes también necesitan una forma confiable de identificar qué rutas de confianza afectadas deben rechazar.
Los servicios externos presentan diferentes riesgos para los validadores
Los nodos de Ethereum están compuestos por software que asumen diferentes responsabilidades. La documentación de los clientes de Ethereum distingue entre clientes de ejecución y clientes de consenso: el primero se encarga de la ejecución de transacciones y el estado, mientras que el segundo sigue el consenso de prueba de participación.
El software de validador añade la responsabilidad de proponer bloques y emitir pruebas para la cadena. Los operadores pueden ejecutar estos componentes localmente o conectarse a algunos a través de servicios externos.
Teku es un cliente de consenso, Besu es un cliente de ejecución. Ambos utilizan Java, lo que explica por qué la confianza en los certificados en tiempo de ejecución está relacionada con sus lanzamientos.
Los servicios fuera de la máquina local agregarán una verificación de identidad a este arreglo. El software debe confirmar que el punto de respuesta es el proveedor esperado.
Por ejemplo, el operador podría utilizar un servicio de firma remota en lugar de mantener las operaciones de firma dentro del mismo proceso. Algunos podrían depender de puntos finales externos para proporcionar datos o servicios de construcción de bloques.
El daño que pueden causar los imitadores depende de lo que se permita hacer al servicio. Un servicio que solo recibe datos de monitoreo tiene un riesgo diferente al de un servicio que participa en decisiones de firma.
La ruta de red también es importante. Las conexiones a través de infraestructura pública tienen oportunidades de interceptación diferentes en comparación con los componentes limitados al mismo host o a una red privada estrictamente controlada.
La red privada no puede evitar que ocurran todos los fallos, pero puede reducir la oportunidad de que los atacantes obtengan la ubicación necesaria para interrumpir el tráfico.
Por lo tanto, el nombre del cliente por sí solo no permite determinar si hay exposición. El mismo software puede implementarse en entornos que utilizan diferentes puntos de conexión, bibliotecas de confianza y controles de acceso.
La pregunta real que se debe responder es: ¿qué conexión aprobó el certificado a través de la ruta afectada? Una vez determinado esto, los operadores pueden evaluar qué nivel de permisos debería haber tenido el servicio suplantado en el funcionamiento del verificador.
¿Por qué la instalación mediante imagen de Docker y archivo comprimido son diferentes?
Las imágenes de Docker empaquetan la aplicación junto con su entorno de ejecución necesario, que puede incluir el entorno de ejecución de Java y los certificados confiados por dicho entorno.
Actualizar Java en el host no reemplaza automáticamente Java en las imágenes existentes. Los contenedores aún pueden seguir utilizando los archivos empaquetados en su interior.
Esta es la razón por la que las notas de lanzamiento del cliente mencionan específicamente los cambios en Docker. Las notas de Teku indican que su imagen base Eclipse Temurin aún no incluía el retiro correspondiente, por lo que se modificó directamente la imagen del cliente.
Las notas de lanzamiento de Besu también indican que la eliminación del certificado se aplica a las imágenes de Docker y requiere explícitamente que los usuarios que instalaron manualmente verifiquen su propia versión de Java.
La instalación archivada dejará esta responsabilidad al operador. Es posible que el cliente de Ethereum ya se haya actualizado, pero su entorno de ejecución independiente aún podría contener un almacén de certificados antiguo.
Por otro lado, durante el mantenimiento también se presentan diferencias similares. Reemplazar el tiempo de ejecución del host afectará los procesos que utilizan ese tiempo de ejecución, pero no afectará otra instalación que use una ruta de Java diferente.
El evento de Oracle recomienda a los usuarios actualizar los entornos de ejecución afectados o seguir las alternativas indicadas en su documentación. También requiere reiniciar las instancias en ejecución y considerar por separado cada instalación independiente.
Esto hace que los procesos en ejecución sean más importantes que las actualizaciones descargadas. El servidor puede contener archivos parcheados, pero los procesos antiguos seguirán ejecutándose hasta que se reemplacen o se reinicie.
El almacén de certificados personalizado añade otra variación. Una organización podría utilizar un almacén de certificados mantenido para sus propios servicios, en lugar de solo el almacén proporcionado por defecto por Java.
El verdadero objetivo es determinar qué está utilizando realmente el cliente. El método de instalación, la ubicación en tiempo de ejecución y la configuración de confianza determinan conjuntamente si la corrección publicada ya ha llegado a la conexión que la necesita.
Diferencias en la revocación de verificación entre diferentes aplicaciones
Revocación significa que el certificado ya no debe aceptarse. Pero esto no garantiza que cada aplicación verifique la información de revocación más reciente antes de establecer una conexión.
Diferentes aplicaciones obtienen esta información de distintas maneras. Algunas consultan servicios en línea, otras utilizan listas de bloqueo proporcionadas por proveedores, y algunas dependen principalmente de certificados en bibliotecas de confianza locales.
La respuesta del equipo Go explica por qué el proveedor de tiempo de ejecución podría necesitar intervenir directamente. El equipo lanzó una liberación de seguridad de emergencia el 19 de octubre y señaló que proporcionó una versión parcheada aproximadamente 7.5 horas después de recibir la notificación.
Esta acción bloquea la ruta de certificados afectada involucrada en las aplicaciones que utilizan la validación de Go relacionada. Los usuarios de Java necesitan obtener protección a través de su propio entorno de ejecución y configuración de confianza.
Teku indica que Java no verifica la revocación por defecto. Por eso, aunque eMudhra ya haya revocado estos certificados intermedios, sigue siendo necesario eliminar la confianza localmente.
La eliminación del certificado raíz y el bloqueo del certificado intermedio también pueden actuar en diferentes niveles. El primero rechaza una ruta específica comprometida, mientras que el segundo puede rechazar cadenas de certificados más amplias que conduzcan al certificado raíz eliminado.
La implementación correcta corresponde al proveedor y a la organización que mantiene la aplicación. Si se adopta temporalmente una medida que deshabilite la verificación de identidad, solo se eliminará la protección, pero no se resolverá el problema de confianza.
Los servicios legítimos también podrían necesitar ajustes. Si sus certificados dependen de rutas que los clientes ahora rechazan, los proveedores de servicios deben ofrecer alternativas aceptables, en lugar de confiar en que los usuarios restablezcan la confianza insegura.
Esto también explica por qué un evento de certificado puede durar varios días. La detección puede ser inmediata, pero la protección se implementa gradualmente a través de los distintos procesos de lanzamiento y mantenimiento de navegadores, aplicaciones empaquetadas e infraestructura privada.
Para los operadores de validadores, el resultado clave es si las conexiones relacionadas han rechazado identidades no confiables. Los anuncios de revocación en otros lugares del ecosistema de software no demuestran que el proceso de su nodo haya alcanzado este resultado.
Are rewards and validator staking exposed in the same way?
Las responsabilidades de staking, firma y pago de tarifas de los validadores están interrelacionadas, pero están sujetas a mecanismos diferentes. Un problema que afecta a una de ellas no debe describirse automáticamente como un control sobre todas ellas.
La documentación de staking de Ethereum indica que los validadores reciben recompensas por cumplir con sus responsabilidades y son sancionados por estar desconectados o por comportamientos inapropiados demostrables. Los permisos de firma y los permisos de retiro desempeñan roles distintos en el sistema.
La clave del certificado pertenece al sistema de identidad utilizado para la conexión. No es la clave privada de firma del validador ni revela directamente las credenciales para gestionar los retiros de ETH apostados.
Sin embargo, el servicio suplantado aún podría afectar el comportamiento de los validadores. Su impacto depende de qué solicitudes o respuestas maneja ese servicio y qué controles adicionales aún se mantienen.
El bloque de propuesta incluye el destinatario de las tarifas relacionadas con el pago. Si alguna ruta puede modificar la propuesta o la configuración, podrían surgir consecuencias sin necesidad de controlar todo el staking.
El servicio de firma plantea otro conjunto de problemas, ya que participa en la autorización de las acciones de los validadores. Sus propias medidas de protección, incluidas las limitaciones en las solicitudes y las salvaguardias contra firmas conflictivas, afectan hasta qué punto un atacante puede actuar.
La omisión de responsabilidades causada por una interrupción del servicio también es una consecuencia posible. Incluso sin transferir ningún pago, el atacante puede reducir las recompensas al impedir respuestas correctas.
Las implicaciones financieras de estos resultados no son las mismas. No se deben confundir la pérdida de la oportunidad de proponer un bloque, las penalizaciones por desconexión normal y las sanciones por slashing.
La notificación del cliente describe las posibles consecuencias bajo configuraciones afectadas, pero no demuestra que cada operador haya experimentado estas consecuencias ni que se hayan robado cantidades correspondientes de ETH.
Para los titulares que utilizan servicios de stake, lo realmente relevante es la implementación real del servicio. La cantidad de ETH gestionada no indica qué servicios remotos o bibliotecas de certificados utiliza su operador.
Los validadores también dependen de software externo a Ethereum.
Las reglas de la red Ethereum son solo una parte de lo que los operadores dependen. El hardware, el entorno de ejecución, el alojamiento, la configuración y los servicios externos afectan la capacidad del validador para cumplir correctamente con sus funciones.
La autoridad de certificación se encuentra fuera del protocolo Ethereum, pero su fallo se vuelve relevante cuando el software de validador depende de ella para identificar servicios. Solo con esto, basta para traer un problema general de seguridad en internet a la infraestructura de staking.
La diversidad de clientes sigue siendo valiosa, ya que diferentes implementaciones pueden reducir la dependencia de un único código base. Pero esto no significa que cada dependencia sea independiente.
Dos clientes pueden utilizar el mismo entorno de ejecución de lenguaje de programación. Diferentes operadores también pueden utilizar el mismo proveedor de alojamiento, servicio de firma o infraestructura de construcción de bloques.
Estos componentes compartidos generan una superficie de exposición común, independientemente de las diferencias en el software de Ethereum. Por lo tanto, para comprender los casos de despliegue, no basta con observar solo la cantidad de marcas de clientes.
La externalización también conlleva compensaciones. Un servicio de firma dedicado puede mejorar la forma de proteger las claves, pero también hace que la conexión de autenticación con dicho servicio sea más importante.
La ejecución local también tiene sus propios requisitos de mantenimiento. Colocar los componentes en la misma máquina puede reducir parte de la exposición de red, pero los operadores aún deben gestionar las actualizaciones de software y el acceso a esa máquina.
Este evento no implica automáticamente una arquitectura más segura en todos los casos. Indica que es necesario comprender y mantener las responsabilidades de cada conexión.
Esta diferencia también es importante para los usuarios comunes de ETH. La actualización de certificados en la infraestructura de nodos no significa que cada billetera deba transferir fondos, ni que los saldos de las cuentas de Ethereum hayan cambiado.
Las acciones relacionadas corresponden a los operadores del software afectado. Solo ellos tienen la capacidad de identificar los entornos de ejecución, puntos de conexión y configuraciones de confianza involucrados, y luego aplicar las instrucciones correspondientes del proveedor a los sistemas que establecen estas conexiones.
El operador debe aplicar y verificar las actualizaciones
Estas publicaciones proporcionan a los operadores un método para eliminar las rutas de confianza afectadas desde las imágenes de Docker admitidas. Los usuarios archivados deben manejar los entornos de ejecución individuales según las directrices de sus proveedores de Java.
La disponibilidad del parche es solo el primer paso. El entorno actualizado también debe ejecutarse correctamente y mantener la configuración esperada y los servicios funcionando normalmente.
Para los proveedores de servicios, una interrupción causada por un certificado recientemente rechazado puede requerir la actualización del certificado en el punto final. Al restaurar el servicio, se debe mantener la verificación de identidad en lugar de omitirla.
La divulgación posterior podría detallar aún más el impacto. Los operadores podrían identificar configuraciones que aceptaron la cadena de certificados afectada o informar eventos relacionados con servicios específicos.
Actualmente, los informes de notificación de Teku no se han aprovechado y distinguen entre el uso predeterminado de la red principal y las conexiones externas afectadas. Esta es la evidencia más clara disponible para describir la superficie de exposición actual de Ethereum.
Los operadores afectados tienen motivos para actualizar. Cualquier pérdida financiera depende de qué servicio suplantó el atacante, si interceptó el tráfico y qué permitió el verificador que hiciera ese servicio.
¿Qué debe tener en cuenta?
- Actualización del cliente: Supervise los lanzamientos de Teku y Besu y confirme que está ejecutando la versión corregida.
- Java certificate: Consulte las guías del proveedor para el entorno de ejecución de Java y la biblioteca de certificados utilizados en cada instalación.
- Enlaces externos: revisar los enlaces HTTPS que apuntan a servicios de firma remota, datos y construcción de bloques.
- Notificación de seguridad: Esté atento a las confirmaciones de ataques o explicaciones adicionales publicadas por el equipo del cliente y el proveedor de Java.
Preguntas frecuentes
¿Qué es el evento eMudhra?
Este incidente involucra claves privadas débiles asociadas con el certificado intermedio de la autoridad de certificación eMudhra. Los investigadores descubrieron que estas claves pueden recuperarse a partir de información pública, lo que podría permitir a otras personas generar certificados para dominios que no controlan. El software que confía en la ruta de certificados afectada podría aceptar esta identidad falsificada. Sin embargo, los atacantes aún necesitan algún método para interceptar o redirigir conexiones con el fin de suplantar servicios objetivo.
¿Ha fallado el consenso de Ethereum?
No. Los problemas en el informe se refieren a cómo el software verifica la identidad de servicios externos, no a las reglas de consenso de Ethereum en la blockchain. La actualización del cliente modifica la confianza en los certificados dentro del entorno de software afectado. Algunas implementaciones de validadores aún podrían enfrentar riesgos operativos si se suplanta un servicio externo. Esta posibilidad depende de la conexión y el rol del servicio, y no implica que las reglas de consenso de Ethereum hayan sido comprometidas.
¿Qué clientes se han actualizado?
Teku 26.10.3 y Besu 26.10.2 han modificado sus imágenes Docker para eliminar los certificados afectados. Teku es un cliente de consenso y Besu es un cliente de ejecución, ambos utilizan Java. La forma de instalación es importante, ya que este cambio aplica al entorno proporcionado en estas imágenes. Los operadores que instalan los archivos de cliente y proporcionan su propio entorno de ejecución de Java deben consultar por separado las instrucciones para ese entorno de ejecución.
Will all validators be affected?
No. El aviso de Teku indica que los nodos de red principal por defecto no se ven afectados. El riesgo depende de si una implementación realizó conexiones HTTPS externas relevantes y si su verificación de certificados acepta la ruta de confianza afectada. Diferentes operadores pueden ejecutar el mismo cliente en distintos servicios, versiones de Java y bibliotecas de certificados. Por lo tanto, el nombre del cliente o la cantidad de ETH apostada no indican si un validador específico está expuesto.
¿Puede la actualización de Docker reemplazar todos los métodos de instalación?
No. La imagen de Docker parcheada actualiza el entorno empaquetado dentro de la imagen, pero la instalación archivada podría utilizar Java proporcionado por el operador por separado. Otros contenedores o servicios también podrían tener sus propios entornos de ejecución. El operador debe identificar qué método de instalación está utilizando cada proceso en ejecución y seguir las instrucciones del proveedor correspondiente. Los archivos parcheados en el servidor no protegen los procesos que aún se ejecutan en entornos antiguos.
¿Se ha confirmado la explotación?
En el momento descrito en este artículo, las notificaciones de Teku no informaron ningún aprovechamiento. La divulgación relacionada describe una debilidad y sus posibles consecuencias, pero no demuestra que los atacantes hayan utilizado esta vulnerabilidad para validadores. Esta distinción es importante al discutir pérdidas. Que exista una posible vía de suplantación de servicio no equivale a que las responsabilidades de firma hayan sido manipuladas, los pagos de tarifas hayan sido desviados o el ETH apostado haya sido robado.
Will validator deposits be automatically exposed?
No. La clave de firma del certificado es diferente de la clave de firma del validador y también de los credenciales para controlar los retiros. Recuperar la clave del certificado afectada no revela automáticamente las claves necesarias para retirar los ETH apostados. El servicio suplantado aún podría alterar responsabilidades o afectar la información utilizada por los validadores, dependiendo de la forma de implementación. Se debe evaluar el posible impacto de este servicio, en lugar de considerarlo como un acceso automático a todo el depósito.
¿Qué debe hacer el operador?
Los operadores deben seguir las notas de lanzamiento correspondientes de Teku o Besu, así como las instrucciones de su versión de Java. Es necesario identificar el entorno de ejecución y el almacén de certificados utilizados por cada proceso afectado, incluyendo los proporcionados dentro del contenedor. Después de aplicar las actualizaciones recomendadas, se debe confirmar que los servicios actualizados están funcionando correctamente y que las conexiones necesarias siguen funcionando normalmente. Desactivar la verificación de certificados para recuperar conexiones fallidas elimina la protección que estas verificaciones deberían proporcionar.