Una vulnerabilidad en Eclair, uno de los programas utilizados para operar nodos de Bitcoin Lightning, podía permitir que un nodo malicioso vaciara el saldo local de un canal mediante una comisión de cierre desproporcionada. En el peor escenario, el dinero del operador no acabaría en manos del atacante, sino convertido íntegramente en comisiones para los mineros de Bitcoin.
ACINQ, la empresa tecnológica especializada en Bitcoin que desarrolla Eclair y la cartera Phoenix Wallet, publicó el 14 de septiembre la versión 0.14.3. La actualización corrige tres fallos que podían provocar pérdidas o bloquear fondos durante el cierre de canales, la modificación de su financiación y la apertura de canales vinculada al reenvío de pagos.
Una comisión capaz de consumir todo el saldo
El ataque más directo afectaba a los cierres cooperativos de canales. Cuando Eclair era responsable de calcular la comisión de cierre, un nodo malicioso podía proponer un importe superior al saldo local de la víctima. El mecanismo de negociación alternativa del programa podía aceptar esa propuesta y eliminar la cantidad que correspondía al operador.
El resultado sería una transacción en la que todo el saldo local del canal se destinaría a pagar las comisiones de la red de Bitcoin. La versión corregida rechaza ahora cualquier propuesta de comisión de cierre que supere el máximo configurado por el operador.
Bitcoin Optech describió Eclair 0.14.3 como una actualización de seguridad que aborda problemas relacionados con el cierre de canales, el splicing —el cambio de la transacción que financia un canal sin cerrarlo— y la financiación sobre la marcha.
Riesgos durante operaciones incompletas
El segundo fallo podía dejar fondos inmovilizados durante una modificación de canal que no hubiese llegado a completarse. Si Eclair firmaba primero y el otro participante retenía su firma, el estado más reciente del canal podía depender de una transacción que el operador 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 caducara 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 actualización, Eclair fuerza el cierre utilizando el estado más reciente respaldado por una transacción de financiación que cuente con todas las firmas necesarias.
El tercer problema afectaba a la función de financiación sobre la marcha, que permite abrir un canal mientras se reenvía un pago. Una cartera maliciosa podía manipular los plazos de expiración para cobrar en la cadena de bloques el pago saliente mientras el entrante caducaba. En ese caso, la pérdida recaería sobre el operador que hacía de intermediario.
Eclair comprueba ahora las comisiones de reenvío y los márgenes temporales de expiración antes de comprometer los fondos. Además, la versión 0.14.3 establece un límite predeterminado de 50 satoshis por vByte para las comisiones estimadas automáticamente en aperturas de canales y modificaciones de financiación. La medida reduce la exposición a datos externos de comisiones que sean incorrectos.
Más presión sobre la infraestructura de Lightning
ACINQ recomendó encarecidamente a los operadores actualizar el software. La advertencia llega en un momento de mayor presión sobre la infraestructura de Lightning, con intentos dirigidos también contra otras implementaciones.
A principios de septiembre, BTCPay Server informó de que había detectado bots sondeando servidores cuyos administradores habían vuelto a habilitar manualmente el acceso externo a LND. Los atacantes apuntaban a una ruta sin autenticación para cambiar la contraseña durante un breve periodo en el que la cartera de LND permanecía bloqueada. Si el intento tenía éxito, podían sustituir la contraseña y solicitar un macaroon de administrador, un credencial con capacidad para controlar el nodo.
BTCPay respondió introduciendo contraseñas únicas para las carteras de LND y bloqueando en el perímetro de su red las rutas de gestión de carteras sin autenticación. También recomendó no exponer manualmente la interfaz de programación de LND. Los incidentes reflejan el interés creciente de los atacantes por encontrar fallos en el ecosistema de Lightning que les permitan tomar el control de los nodos o desviar fondos.
