Los clientes de Ethereum corrigen una falla que podría redirigir recompensas de ETH

Los desarrolladores de clientes de Ethereum, Teku y Besu, han lanzado actualizaciones de seguridad para abordar una vulnerabilidad de certificado que podría permitir a los atacantes suplantar servicios utilizados por los validadores y potencialmente redirigir sus recompensas de bloque.

Resumen

• Los clientes de Ethereum, Teku y Besu, han lanzado actualizaciones de seguridad después de que se encontrara una vulnerabilidad de certificado que podría permitir a los atacantes redirigir las recompensas de bloque de los validadores a sus propias direcciones.
• La vulnerabilidad se originó a partir de claves criptográficas débiles asociadas con ocho autoridades de certificación operadas por la empresa india eMudhra, lo que podría permitir a los atacantes crear certificados fraudulentos.
• Teku advirtió que los atacantes podrían suplantar servicios externos utilizados por los validadores de Ethereum y manipular propuestas de bloque u obtener firmas sensibles de validadores bajo ciertas configuraciones.
• Las configuraciones predeterminadas de la red principal de Teku no se vieron afectadas, y los desarrolladores confirmaron que no se había informado de ninguna explotación de la vulnerabilidad.
• Los operadores que utilizan instalaciones independientes de Teku o Besu deben actualizar sus entornos de Java por separado, ya que las últimas correcciones de la imagen de Docker no actualizan automáticamente los certificados de Java instalados localmente.

Según los avisos de seguridad que acompañan a los lanzamientos, el problema se originó a partir de claves de autoridad de certificación comprometidas pertenecientes al proveedor indio de certificados digitales eMudhra, lo que dejó ciertas configuraciones de nodos de Ethereum expuestas a conexiones HTTPS forjadas.

Teku lanzó la versión 26.10.3 el 27 de octubre, mientras que Besu introdujo la versión 26.10.2 un día antes. Ambas actualizaciones eliminan la confianza en los certificados afectados de eMudhra de sus imágenes de Docker, que los operadores utilizan para implementar y ejecutar el software de nodos de Ethereum.

La vulnerabilidad podría afectar a los validadores que dependen de servicios externos para firmar transacciones, comunicarse con nodos de beacon o recibir información sobre la construcción de bloques. Un atacante necesitaría interceptar una conexión afectada y presentar un certificado forjado que el software del validador acepte como legítimo.

Los desarrolladores de Teku confirmaron que las configuraciones predeterminadas de la red principal no se vieron afectadas y dijeron que no se había informado de ninguna explotación de la vulnerabilidad.

Falla de seguridad de Ethereum rastreada a certificados comprometidos de eMudhra

El problema de seguridad comenzó con un error criptográfico que involucraba a ocho autoridades de certificación intermedias operadas por eMudhra, cuyas claves privadas se encontraron generadas con una aleatoriedad insuficiente.

Los investigadores identificaron el problema el 17 de octubre, descubriendo que las claves privadas podían recuperarse matemáticamente a partir de la información disponible en los certificados públicos.

Según un aviso de seguridad del 26 de octubre de Microsoft, seis de los certificados afectados se utilizaron para asegurar conexiones a internet, mientras que los otros dos estaban asociados con la firma de código.

Las claves comprometidas podrían permitir a alguien crear certificados que parecieran genuinos para aplicaciones que continuaran confiando en las autoridades de certificación afectadas.

eMudhra revocó los certificados intermedios afectados el 18 de octubre, mientras que los proveedores de tecnología comenzaron a eliminar la confianza en las cadenas de certificados comprometidas de su software.

Microsoft, posteriormente, bloqueó las autoridades de certificación afectadas a través de una actualización de seguridad de Windows el 20 de octubre y lanzó otra actualización el 26 de octubre para eliminar siete certificados asociados de su lista de confianza.

Sin embargo, el problema seguía siendo relevante para Ethereum porque Teku y Besu utilizan Java, cuya validación de certificados no verifica el estado de revocación por defecto.

Como resultado, las instalaciones de Java afectadas podrían seguir aceptando certificados asociados con las autoridades comprometidas incluso después de su revocación.

Cómo los atacantes podrían redirigir las recompensas de los validadores de Ethereum

El aviso de seguridad de Teku identificó varios posibles escenarios de ataque que involucran a validadores que se comunican con servicios externos a través de conexiones HTTPS.

Un escenario implica a un atacante que se hace pasar por un nodo faro remoto utilizado por un validador para coordinar sus funciones en Ethereum.

Si el atacante intercepta con éxito la conexión y presenta un certificado falsificado, el validador podría recibir información manipulada sobre el bloque que estaba preparando para proponer.

Según Teku, tal ataque podría hacer que un validador proponga un bloque que dirija las tarifas de transacción a una dirección controlada por el atacante.

El aviso identificó los servicios de firma externos como otro componente potencialmente expuesto. Estos servicios mantienen las claves de firma del validador por separado del software principal del nodo y proporcionan firmas cuando se solicitan.

Un atacante que se haga pasar por un firmante externo podría potencialmente obtener firmas asociadas con las salidas de los validadores, dependiendo de la configuración y las protecciones disponibles.

Teku clasificó este escenario como particularmente grave, aunque las configuraciones que utilizan autenticación mutua TLS podrían limitar las consecuencias a una denegación de servicio.

Otras conexiones potencialmente afectadas incluyen clientes de ejecución, constructores de bloques, relés y servicios utilizados para recuperar información de configuración del validador.

La vulnerabilidad no afectó a los protocolos de red peer-to-peer subyacentes de Ethereum, que no dependen de las autoridades de certificación comprometidas.

Teku y Besu lanzan correcciones para nodos de Ethereum afectados

Tras la divulgación, Teku lanzó la versión 26.10.3 para eliminar cuatro raíces de certificados de sus imágenes de Docker, incluyendo emSign ECC Root CA G3, emSign Root CA G1, emSign Root CA G2 y AAA Certificate Services.

Besu introdujo las mismas eliminaciones de certificados en la versión 26.10.2, abordando el riesgo para los operadores que utilizan sus imágenes de Docker actualizadas.

Sin embargo, las versiones no actualizan automáticamente las instalaciones de Java mantenidas por separado por los operadores de nodos.

Los usuarios que ejecutan Teku o Besu a través de distribuciones binarias independientes deben verificar su entorno de ejecución de Java instalado y actualizar sus certificados de confianza donde sea necesario.

Teku advirtió que los operadores que aún utilizan Java 26 necesitarían migrar a Java 25 porque la primera versión había llegado al final de su vida útil y no recibiría la compilación parcheada requerida.

El aviso identificó además ciertas configuraciones de testnet como potencialmente expuestas, incluyendo configuraciones que descargan su estado inicial de blockchain a través de HTTPS.

Las actualizaciones de seguridad siguen otras preocupaciones recientes relacionadas con la infraestructura de validadores de Ethereum. A principios de este mes, crypto.news informó que MetaMask había comenzado a salir de los validadores afectados tras un incidente de seguridad de infraestructura separado divulgado el 30 de septiembre.

Más recientemente, los desarrolladores de Ethereum corrigieron un error de depósito de validadores en la próxima actualización Glamsterdam después de que los investigadores identificaran un escenario en el que las cuentas de constructores podrían recibir ETH destinado a los validadores.

La actualización Glamsterdam ha enfrentado retrasos por separado después de que los desarrolladores pospusieran la activación de su testnet Hoodi para investigar preocupaciones de compatibilidad de contratos inteligentes relacionadas con EIP-8037.

El aplazamiento del 26 de octubre eliminó la activación programada de los cambios de ejecución de Amsterdam y los cambios de consenso de Gloas, junto con un aumento propuesto en el límite de gas de Hoodi a 200 millones. Los desarrolladores de Ethereum no han anunciado una nueva fecha de activación.