Los desarrolladores de Ethereum han resuelto dos vulnerabilidades separadas que podrían haber puesto en riesgo los depósitos de los validadores y las recompensas de bloques: una involucraba certificados web débiles y la otra estaba incorporada en las reglas preliminares de la próxima actualización Glamsterdam de la red. Teku, un cliente de consenso, y Besu, un cliente de ejecución, lanzaron parches para atender la exposición. Los nodos de Ethereum ejecutan un cliente de consenso y un cliente de ejecución en paralelo, lo que significa que ambas capas de la pila del nodo requerían la misma limpieza de certificados.

Teku lanzó la versión 26.10.3 el 27 de octubre, un día después de que Besu publicara la versión 26.10.2 el 26 de octubre. Ambas versiones eliminan las autoridades certificadoras afectadas de las imágenes de Docker utilizadas para ejecutar nodos de Ethereum, según la página de versiones de Teku.

Alertan sobre claves de certificados débiles

Investigadores descubrieron el 17 de octubre que ocho certificados intermedios emitidos por la empresa india eMudhra dependían de claves privadas que los atacantes podían calcular a partir de información disponible públicamente. Con esas claves, los atacantes podrían haber emitido certificados para servicios falsificados. eMudhra revocó los certificados, pero algunas instalaciones de Java seguían confiando en ellos, porque Java no verifica la revocación de certificados de forma predeterminada. Tanto Teku como Besu están escritos en Java, y así es como la debilidad alcanzó las operaciones de nodos de Ethereum.

El descubrimiento se produjo en la misma semana en que Google presentó un sistema de seguridad para custodia de criptomonedas diseñado para dividir las claves privadas entre entornos separados.

Cómo podrían haberse desviado las tarifas de los validadores

La falla de certificados era importante porque los validadores dependen de conexiones a servicios externos. Un atacante capaz de interceptar dicha conexión podría hacerse pasar por el servicio del otro extremo. Teku advirtió que una conexión falsificada a un nodo remoto podría hacer que las tarifas de bloques se pagaran a una dirección controlada por el atacante. Los servicios de firma externos representaban un riesgo adicional en las configuraciones afectadas, ya que los atacantes podrían obtener firmas que redirijan las recompensas.

"Un nodo de Teku predeterminado en mainnet no está afectado y no requiere ninguna acción", declaró Teku. El equipo del cliente reportó que no se conocía ninguna explotación.

Reglas de depósitos de Glamsterdam corregidas

En un esfuerzo separado, los desarrolladores revisaron las reglas propuestas de Glamsterdam después de que el investigador avsetsin identificara un error de enrutamiento de depósitos. También pospusieron la actualización de la testnet Hoodi, que estaba programada para el 26 de octubre.

Bajo el borrador anterior, un builder y un validador que compartieran una sola clave pública podrían haber provocado que los depósitos de staking ingresaran a la cuenta del builder. Glamsterdam está diseñado para separar la construcción de bloques de la validación, y la propuesta revisada clasifica los depósitos pendientes por credenciales de retiro, distinguiendo los depósitos de validadores de los depósitos de builders.

Los equipos de clientes inicialmente rechazaron la corrección el 19 de octubre porque no llegaron a un acuerdo. Posteriormente, los desarrolladores agregaron pruebas y fusionaron las reglas revisadas el 26 de octubre.

Diferentes próximos pasos para los operadores de nodos

La corrección de Glamsterdam ha entrado en las especificaciones de Ethereum, pero los equipos de software aún deben implementarla. Glamsterdam se ejecutó previamente en la testnet Sepolia, mientras que Hoodi espera una nueva fecha de activación.

Los operadores que ejecuten Teku o Besu fuera de Docker deben actualizar Java por separado. El riesgo de certificados abarcaba pagos provenientes de las gas fees de Ethereum, como las tarifas de prioridad pagadas a los validadores, en lugar de los saldos ordinarios de las billeteras de los usuarios. Teku recomendó a los usuarios de Java 26, que ya no cuenta con soporte, migrar a Java 25.

Los parches de certificados resuelven las imágenes de Docker afectadas, mientras que la corrección de Glamsterdam espera su adopción en todo el ecosistema de clientes de Ethereum.