Un fallo de seguridad en Eclair, una de las implementaciones del protocolo Bitcoin Lightning, podía permitir que un nodo malicioso vaciara el saldo local de un canal mediante una comisión de cierre excesiva. En el peor escenario, el operador aceptaría una propuesta que destinara todo ese saldo a los mineros de Bitcoin en forma de tasas de transacción.
ACINQ publicó el 14 de septiembre la versión Eclair 0.14.3, una actualización de seguridad que corrige tres vulnerabilidades activables por pares de la red. Los problemas afectaban al cierre de canales, las operaciones de splicing —que modifican la transacción de financiación sin cerrar el canal— y la financiación sobre la marcha de nuevos canales.
Una comisión podía absorber todo el saldo del canal
El fallo más directo se encontraba en los cierres cooperativos. Cuando Eclair era responsable de calcular la comisión de cierre, un nodo atacante podía proponer una cantidad superior al saldo local de su contraparte. El mecanismo de negociación alternativa de Eclair podía aceptar esa propuesta, eliminando la salida correspondiente al operador y convirtiendo, en la práctica, todo su saldo local en comisión para los mineros.
La actualización impide ahora aceptar propuestas de comisión que superen el máximo configurado por el operador. ACINQ, empresa tecnológica centrada en Bitcoin, colaboradora del desarrollo de Lightning y responsable de Eclair y de Phoenix Wallet, recomendó actualizar el software ante la posibilidad de que otros nodos maliciosos explotasen estos problemas.
Riesgos durante el splicing y los pagos en tránsito
La segunda vulnerabilidad podía dejar fondos bloqueados durante una operación de splicing incompleta. Este proceso permite cambiar la transacción que financia un canal de Lightning sin tener que cerrarlo. En determinadas circunstancias, Eclair podía firmar primero y quedar a la espera de la firma del otro participante. Si este no la entregaba, el estado más reciente del canal podía depender de una transacción que la víctima no estaba en condiciones de publicar.
Ese escenario también abría una vía para provocar pérdidas en pagos que todavía estaban en tránsito. Un atacante podía dejar que expirase la parte entrante de un pago reenviado, publicar un estado antiguo del canal y utilizar el secreto del pago para cobrar la parte saliente. Con la versión 0.14.3, Eclair fuerza el cierre utilizando el estado más reciente respaldado por una transacción de financiación firmada por completo.
El tercer problema afectaba a la financiación sobre la marcha, una función que permite abrir un canal mientras se reenvía un pago. Un monedero malicioso podía manipular los plazos de expiración para cobrar en cadena el pago saliente mientras el entrante expiraba. La pérdida recaería entonces sobre el operador que actuaba como intermediario.
El software actualizado comprueba las comisiones de retransmisión y los márgenes de tiempo antes de comprometer los fondos. Además, establece por defecto un límite de 50 satoshis por vByte para las comisiones estimadas automáticamente en aperturas de canales y operaciones de splicing. La medida reduce la exposición a datos externos de comisiones que fueran incorrectos o estuvieran manipulados.
Más presión sobre la seguridad de Lightning
Bitcoin Optech describió Eclair 0.14.3 como una versión de seguridad centrada en vulnerabilidades relacionadas con cierres de canales, splicing y financiación sobre la marcha. El incidente llega mientras otros operadores del ecosistema Lightning afrontan intentos de intrusión dirigidos contra infraestructuras expuestas.
A comienzos de septiembre, BTCPay Server comunicó que había detectado bots sondeando servidores cuyos administradores habían vuelto a habilitar manualmente el acceso externo a LND, otra implementación de Lightning. Los atacantes buscaban un punto de cambio de contraseña sin autenticación durante el breve periodo en que el monedero de LND permanecía bloqueado. Si el intento tenía éxito, podían sustituir la contraseña y solicitar un macaroon de administrador con control sobre el nodo.
BTCPay respondió introduciendo contraseñas únicas para los monederos de LND y bloqueando en el perímetro de red las rutas de gestión de monederos sin autenticación. También recomendó no exponer manualmente la API de LND. Los dos casos reflejan la presión creciente sobre la seguridad de Lightning, a medida que los atacantes buscan fallos de software o configuraciones expuestas que permitan desviar o tomar el control de fondos.
