Certificado defectuoso de eMudhra lleva a Teku y Besu a publicar correcciones en Docker; los usuarios de binarios deben revisar aparte Java
Los programas de cliente de Ethereum Teku y Besu publicaron actualizaciones de Docker que eliminan la confianza en cuatro raíces de certificados vinculadas a un compromiso de la autoridad de certificación eMudhra. Las instalaciones binarias deben revisar por separado el entorno de ejecución de Java del que dependen, ya que actualizar el cliente no lo modifica.
Escrito por la redacción de IA de CoinArticle · a partir de 2 fuentes citadas. Cómo trabajamos
Qué cambian las versiones
Teku 26.10.3, publicada el 27 de octubre, y Besu 26.10.2, publicada el 26 de octubre, dejan de confiar en sus imágenes de Docker en cuatro raíces de certificados: emSign ECC Root CA – G3, emSign Root CA – G1, emSign Root CA – G2 y AAA Certificate Services. Las correcciones afectan a los almacenes de confianza incluidos, es decir, las listas de autoridades de certificación que Java acepta por defecto.
Ambos proyectos limitan la corrección a los contenedores. Besu indica que sus distribuciones en tar y zip podrían seguir ejecutando un JDK que confía en las raíces afectadas. La distribución binaria de Teku utiliza el entorno de ejecución de Java que el operador tenga instalado, por lo que esos operadores deben comprobarlo y, si es necesario, corregir ese entorno por separado del cliente.
El incidente de eMudhra
El problema de fondo implicaba claves privadas recuperables de ocho autoridades de certificación intermedias de emSign G3. Según la declaración de incidente de eMudhra, un investigador informó el 17 de octubre de la existencia de intermedias débiles, y la empresa revocó las ocho al día siguiente. eMudhra reconoció un error de script que generó las claves débiles.
La cobertura difiere sobre cómo se explotaron las claves. El relato del equipo de seguridad de Go describe la recuperación de las claves privadas en microsegundos, lo que permitiría a un atacante emitir un certificado para un dominio que no controla. La investigación de Kudelski Security examina la misma jerarquía de certificados y describe el riesgo como software que acepta un certificado firmado con una clave reproducible. El aviso de Teku señala que Java no comprueba la revocación por defecto, por lo que las intermedias revocadas pueden seguir siendo aceptadas por entornos de ejecución sin corregir.
La exposición depende de la configuración
El aviso de seguridad de Teku indica que los nodos de mainnet con configuración predeterminada que no usan URL HTTPS no se ven afectados, y que no se ha informado de ninguna explotación. Un atacante en un entorno de ejecución sin corregir también necesitaría interceptar una conexión HTTPS afectada, de modo que la clave débil por sí sola no sitúa a un atacante entre un nodo y sus pares.
Allí donde existen conexiones HTTPS, las consecuencias varían según el rol. Las dependencias HTTPS de Teku pueden incluir firmantes remotos, nodos beacon, clientes de ejecución, constructores o relés, servicios de métricas y fuentes de datos de arranque. Según el aviso, un nodo beacon remoto suplantado podría redirigir las comisiones de propuesta o provocar la pérdida de obligaciones, y un firmante externo suplantado podría obtener firmas para salidas de validadores. La autenticación de cliente mediante TLS mutuo en el firmante limita ese segundo caso a una denegación de servicio. El aviso también señala Sepolia, Hoodi y Ephemery, que descargan el estado inicial por HTTPS cuando se lanzan con una base de datos vacía. La red peer-to-peer de Teku, incluidos libp2p y discv5, no utiliza autoridades de certificación y queda fuera de este problema.
Qué deben comprobar los operadores
Primero, los operadores deben identificar si su configuración realiza conexiones HTTPS salientes a los servicios enumerados anteriormente. Los usuarios de Docker deben actualizar a las imágenes corregidas. El aviso de Teku indica que todas sus imágenes de Docker hasta la 26.10.2, incluidas las variantes -jdk25 y -jdk26, conservan la raíz ECC de emSign implicada, y que actualizar Java en el host no cambia el entorno de ejecución dentro de un contenedor.
Los usuarios de binarios y archivos deben verificar qué JDK ejecuta su nodo y si sigue confiando en las raíces afectadas. Las reglas de consenso de Ethereum no cambian con este incidente; el problema concierne al software y a la infraestructura de certificados que rodea a los validadores.
Por qué importa
Para los traders
El riesgo relacionado con los validadores es operativo y no a nivel de protocolo, así que conviene vigilar cualquier explotación informada o nuevas versiones de clientes antes de reevaluar la exposición.
Para los inversores
El episodio pone de relieve el riesgo de las autoridades de certificación de terceros en la infraestructura de validadores, lo que podría influir en cómo los operadores de nodos y los servicios de staking valoran las prácticas de seguridad en los próximos meses.
Para los desarrolladores
Cualquier servicio que confíe en el almacén de certificados predeterminado de Java debe auditar sus raíces incluidas y su gestión de la revocación, ya que Java no comprueba la revocación por defecto.
Este artículo es solo informativo y no constituye asesoramiento financiero. Lee el aviso legal completo.
