Ethereum elimina cuatro certificados comprometidos de sus clientes

Teku 26.10.3 y Besu 26.10.2 eliminan cuatro raíces de certificados de sus imágenes de Docker tras el incidente relacionado con la autoridad de certificación eMudhra. La versión de Teku se publicó el 27 de octubre y la de Besu, el 26. Los operadores que utilicen instalaciones binarias deben comprobar por separado su entorno de ejecución de Java.

Por qué importa

El incidente afectó a claves privadas recuperables de ocho autoridades de certificación intermedias emSign G3. eMudhra afirmó que un error en un script generó claves débiles y que los certificados intermedios se revocaron tras un aviso recibido el 17 de octubre. El aviso de Teku advierte que Java no comprueba por defecto si los certificados han sido revocados, por lo que la revocación por sí sola quizá no proteja los entornos afectados.

Teku afirma que los nodos de Ethereum mainnet con la configuración predeterminada y sin URL HTTPS no se ven afectados, y que no tiene constancia de que se haya explotado el fallo. El riesgo depende de la configuración: un atacante tendría que interceptar una conexión HTTPS afectada para suplantar el endpoint correspondiente. Teku enumera posibles dependencias HTTPS, como firmantes remotos, nodos beacon, clientes de ejecución, builders, relays y servicios de validación. La incidencia no afecta a su red entre pares, ya que libp2p y discv5 no utilizan autoridades de certificación.

Impacto en el mercado

Las correcciones eliminan de las imágenes de Docker emSign ECC Root CA G3, emSign Root CA G1, emSign Root CA G2 y AAA Certificate Services. Teku señala que sus imágenes de Docker hasta la versión 26.10.2, incluidas las variantes -jdk25 y -jdk26, conservaban una raíz implicada. Actualizar Java en el host no actualiza el entorno de ejecución incluido en esos contenedores.

El cambio de Besu se aplica a las imágenes de Docker; quienes utilicen archivos tar o zip podrían seguir teniendo un JDK que confíe en esas raíces. Del mismo modo, quienes utilicen la versión binaria de Teku dependen del entorno de ejecución de Java instalado por el operador. Si se intercepta una conexión afectada, un atacante podría suplantar un nodo beacon remoto y, potencialmente, redirigir las comisiones de propuesta o provocar que se incumplan tareas del validador. Teku también advierte que suplantar a un firmante externo expuesto podría permitir obtener firmas de salida de validadores; la autenticación de cliente mediante TLS mutuo limita el impacto citado a una denegación de servicio.