Electrum corrige una falla que servidores maliciosos usaban para desviar bitcoin

Electrum, uno de los monederos de bitcoin más antiguos y utilizados, es un cliente ligero: no descarga ni valida toda la cadena de bloques, sino que consulta a servidores públicos de su red. Su propia documentación explica las reglas de esa relación. Las transacciones ya incluidas en un bloque se comprueban mediante verificación simplificada de pagos (SPV), pero para las transacciones no confirmadas, las que aún esperan en la mempool, el cliente se fía del servidor principal al que está conectado. Durante años se consideró una concesión aceptable del diseño. El 24 de octubre el proyecto publicó un aviso de seguridad de gravedad alta según el cual alguien encontró la manera de explotarla en la práctica, y con víctimas.

El ataque descrito en el aviso funciona así. Cuando el usuario emite una transacción legítima, un servidor malicioso la retiene en lugar de difundirla a la red. Después actualiza el historial del monedero con una transacción distinta que gasta las mismas entradas, pero envía los fondos a una dirección del atacante. Esa transacción falsa lleva firmas inválidas, y aun así el cliente no lo detectaba, porque no verificaba las firmas de las transacciones no confirmadas. El monedero la mostraba como pendiente en lugar de la original. Si el usuario, al verla atascada, recurría a reemplazo por comisión (RBF) para acelerarla, Electrum la volvía a firmar con una comisión mayor, esta vez con firmas válidas, y el pago terminaba en manos del atacante.

Según el aviso, algunos servidores ya hacían esto activamente y el equipo recibió dos reportes de usuarios. El primero notó que, tras emitir su transacción, el historial mostraba otra distinta, y comprobó que la original nunca llegó a la red. El segundo aumentó la comisión de la transacción falsa y perdió dinero. En ambos casos la dirección del atacante se había generado por fuerza bruta para que sus cuatro últimos caracteres coincidieran con los del destinatario real, un detalle pensado para engañar a quien solo mira el final de la dirección. En el segundo caso, el servidor construyó la transacción falsa con comisión cero, presumiblemente para empujar al usuario a subirla. La cronología del proyecto indica que el primer reporte privado llegó el 11 de octubre, sin que entonces se identificara la vía del aumento de comisión. El segundo llegó el 18 de octubre, la corrección se etiquetó en el repositorio el 23 y los binarios y la divulgación pública salieron el 24.

La versión 4.8.3 hace que el cliente verifique las firmas de las entradas que pertenecen al propio monedero en las transacciones de la mempool antes de añadirlas a su historial local. El proyecto recomienda actualizar. Para quien no pueda hacerlo de inmediato, aconseja revisar las direcciones de salida y los importes cada vez que firme una transacción, sea o no para aumentar la comisión. Los usuarios que se conectan a un servidor de su confianza, por ejemplo uno propio, no están afectados. El aviso reconoce un límite de la corrección: solo se validan las entradas propias, de modo que las transacciones entrantes no confirmadas siguen sin verificarse, porque el cliente no tiene un motor de consenso completo y tendría que validar recursivamente las transacciones padre hasta llegar a las ya minadas. La misma versión incluye otros cambios, entre ellos la actualización de certifi y pip para dejar de confiar en el certificado revocado de eMudhra y emSign, caso que Neoventix ha seguido.

Como análisis, el episodio muestra cómo un supuesto de confianza documentado y conocido desde hace años puede convertirse en una vía de robo cuando alguien combina varias piezas: retener la transacción, suplantarla con una falsa, generar una dirección parecida y esperar a que el propio usuario firme. La firma criptográfica de quien paga sigue siendo la última barrera, y aquí se volvió en contra del usuario porque firmaba una transacción que el monedero le presentaba como suya. Para quienes usan clientes ligeros, la lección práctica es que una transacción pendiente que no se reconoce no debe tocarse sin revisar su destino completo, y que conectarse a un servidor propio sigue siendo la configuración más segura.

Fuentes: Aviso de seguridad de Electrum; Notas de la versión 4.8.3; Commit de la corrección; Documentación de Electrum sobre la confianza en los servidores.