Teku y Besu parchean el riesgo del certificado eMudhra que afecta las configuraciones HTTPS de los validadores

iconCrypto Economy
Compartir
AI summary iconResumen
Una brecha de seguridad que involucra claves de la autoridad de certificación eMudhra comprometidas ha llevado a Teku y Besu a lanzar actualizaciones. Teku 26.10.3 y Besu 26.10.2 ahora no confían en cuatro raíces de certificados afectadas. Se recomienda a los validadores que usan configuraciones HTTPS actualizar. Los usuarios de Docker deben actualizar las imágenes del cliente, mientras que las configuraciones independientes necesitan aplicar parches manualmente en Java. La actualización de noticias de ethereum destaca un riesgo para las configuraciones HTTPS de validadores, aunque no se han confirmado ataques.

TL;DR

  • Teku 26.10.3 y Besu 26.10.2 eliminan la confianza en las raíces de certificados vinculadas a eMudhra tras la exposición de claves intermedias comprometidas, lo que ponía en riesgo algunas configuraciones de validadores basadas en HTTPS frente a riesgos de suplantación.
  • Los nodos principales predeterminados de Teku no se vieron afectados, y no se ha informado de ninguna explotación, mientras que el riesgo dependía de los validadores que se conectaban a servicios externos mediante HTTPS.
  • Los usuarios de Docker deben actualizar las imágenes del cliente, mientras que los operadores independientes deben aplicar parches por separado a Java; los usuarios de Java 26 deben migrar a las compilaciones compatibles de Java 25.

Teku y Besu lanzaron actualizaciones de seguridad después de que claves comprometidas de la autoridad de certificados eMudhra expusieran las configuraciones de nodos de Ethereum a conexiones HTTPS falsificadas. Teku’s release notes recomiendan la versión 26.10.3, que elimina la confianza en cuatro raíces de certificados afectadas desde las imágenes de Docker, mientras que Besu lanzó la versión 26.10.2. Las actualizaciones abordan la confianza en certificados en la capa de distribución de software, no una falla en las reglas de consenso de Ethereum. Los nodos mainnet predeterminados de Teku no se vieron afectados, manteniendo el incidente distinto de las vulnerabilidades en el protocolo Ethereum.

Claves de certificado comprometidas generaron un riesgo de suplantación

Los investigadores descubrieron que las claves privadas de ocho autoridades de certificación intermedias de eMudhra podían recuperarse porque se generaron con aleatoriedad insuficiente. Aunque los certificados fueron revocados, Java no verifica la revocación por defecto, dejando los entornos de ejecución capaces de aceptar certificados falsificados. Un atacante situado entre un nodo y un servicio HTTPS podría, por lo tanto, suplantar ese extremo en configuraciones vulnerables. Este episodio refuerza por qué Ethereum client diversity and operational security van más allá del código de consenso.

Teku 26.10.3 y Besu 26.10.2 eliminan la confianza en las raíces de certificados vinculadas a eMudhra

Los escenarios de mayor riesgo involucraban validadores conectándose a servicios externos mediante HTTPS. Un punto final falsificado podría manipular la información de construcción de bloques, redirigir los receptores de comisiones o obtener firmas a través de un firmante externo impersonado. Teku indicó que un atacante podría provocar que un cliente validador que utiliza un nodo de baliza remoto proponga un bloque que pague comisiones a la dirección del atacante. El riesgo dependía de la posición en la red y las configuraciones del servicio remoto, no simplemente de ejecutar Teku o Besu. No se ha reportado ninguna explotación.

Teku 26.10.3 elimina la confianza en emSign ECC Root CA G3, emSign Root CA G1, emSign Root CA G2 y AAA Certificate Services en las imágenes de Docker. La actualización de Besu aplica el mismo enfoque. Los operadores que ejecutan binarios directamente deben actualizar Java por separado, ya que las actualizaciones del cliente no reemplazan el almacén de certificados del entorno host. Por lo tanto, las implementaciones en Docker y independientes requieren rutas de corrección diferentes. Esta distinción es relevante tras los incidentes en la infraestructura de validadores de Ethereum, que mostraron cómo las dependencias externas al protocolo pueden afectar las operaciones de staking.

Java 26 crea una complicación porque ha alcanzado el final de su vida útil y no recibirá la compilación con los parches necesarios, lo que significa que los operadores afectados deben migrar a Java 25. La red peer-to-peer de Ethereum no se expuso porque no depende de estas autoridades de certificación. Las correcciones reducen el riesgo del almacén de confianza de terceros sin reparar una explotación en vivo en el mainnet ni cambiar el protocolo de Ethereum. Este episodio sigue a otros trabajos de seguridad, incluyendo la corrección del enrutamiento de depósitos Glamsterdam, subrayando cómo la seguridad del validador depende del código del protocolo y la infraestructura de apoyo.

Descargo de responsabilidad: La información contenida en esta página puede proceder de terceros y no refleja necesariamente los puntos de vista u opiniones de KuCoin. Este contenido se proporciona solo con fines informativos generales, sin ninguna representación o garantía de ningún tipo, y tampoco debe interpretarse como asesoramiento financiero o de inversión. KuCoin no es responsable de ningún error u omisión, ni de ningún resultado derivado del uso de esta información. Las inversiones en activos digitales pueden ser arriesgadas. Evalúa con cuidado los riesgos de un producto y tu tolerancia al riesgo en función de tus propias circunstancias financieras. Para más información, consulta nuestras Condiciones de uso y la Declaración de riesgos.